CAPL编程实现诊断刷写，车联网FOTA流程自动化测试（方案篇）

　　原创内容，转载请注明出处

　　本文围绕车联网的ECU，TBOX的FOTA升级业务展开描述。主要讲如何通过CANoe编程实现自动化测试，验证TBOX在FOTA业务过程中作为一个诊断仪刷写整车其它ECU的流程、以及业务逻辑处理的正确性。通常情况下，主机厂都采用实车测试的方式验证FOTA业务。但是实车测试对对手件的稳定性有很高要求，在整车项目开发的很长周期内，整车上的所有的ECU都处于开发阶段，前期是无法开展TBOX的FOTA功能的验证工作的，所以仿真测试就势在必行了。

　　一、业务需求拆分

　　FOTA（Firmware Over-The-Air）, 关键行为拆分为两点：下载 and 安装。

无论实车测试亦或仿真测试，“下载”这个过程都是一样的，并且“下载”不必需依赖于实车，也不依赖于对手件。所以需要仿真的部分集中在车内网络。主要问题就是解决车内ECU的仿真，总线网络节点建模，ECU逻辑实现。　

　　二、物理组网环境

　　分析实车与仿真的差异，先列出脱离实车后组网模型上的必需件。12V B+供电源，业务触发的必需件ECU（根据TBOX的功能设计可确定必需存在的ECU），仿真设备CANoe, 工作站PC

　　实车测试组网示意图：

　　仿真测试组网示意图：

　　对比可以看到，仿真的测试方案新接入了电源，除了必需存在的主机外，其余的ECU(EPS,PEPS,BCM,ACU,TCU等)全由{PC+CANoe}仿真实现。

　　三、测试方案选择

　　TBOX的FOTA安装过程，是基于UDS协议实现的刷写。所以此处FOTA安装流程的本质就是编程模式下的诊断写入过程。

我们透析需求，实际上就需要做一件事：编程实现车内行为仿真。抽丝剥茧，层层深挖下来又是两点需求

1、解决车内网络通信信号的仿真

2、解决TBOX作为诊断仪在总线上诊断请求的实现与被刷写ECU的诊断应答（被刷写ECU的应用层业务逻辑封装）

重点讲第2点，需处理单对单的物理寻址请求，单对多的功能寻址请求。

我的设计思路是建立两条链路，分别支持物理寻址，功能寻址。接下来是选择从哪一层去实现，不同层所用的协议不一样，其实现的复杂程度也不一样。举个例子，要建一个Client与Server进行网络通信，如果你对底层比较清晰，可以直接采用套接字实现。否则你可以选择较上层的协议去实现。

CAN总线的OSI模型，见下图：

分析优缺点：

　　从数据链路层/物理层切入实现，需兼顾帧格式的问题，包含多帧分包传输，流控策略，连续帧拆分与组装等。在保证数据正确性上要写过多逻辑。且对ISO 11898有比较深的了解。虽然整体框架和逻辑简单，可扩展性差。

　　从传输层切入实现，托管了数据处理的细节，ECU间的耦合度低，是比较好的选择。不过框架设计会复杂一些。

具体实现方案：基于CANoe的CanTp建模库，在CAN上实现了传输协议ISO/DIS 15765–2，控制传输大量数据，支持多通道并发。仿真整车上支持OTA的节点，每个节点都可通过两个连接(物理寻址-Connection 1 和功能寻址-Connection 2)，使用OSEK TP节点层DLL与诊断仪通信，在同一连接上在同一时间可以发送和接收数据。仿真FOTA刷写流程。

通信模型与系统框架：　

CAPL代码具体实现，详见下一篇