原创内容，如若喜欢，转载时请在开篇处注明出处
车辆网领域有个关键ECU——TBOX，本文围绕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协议实现的刷写，通过CAN总线传输数据。所以此处FOTA安装的本质是编程模式下的诊断写入过程。（延伸：个人认为通过Ethernet总线传输数据，是车联网+智能驾驶未来发展的必然趋势，它可以更高效的传输，承载庞大的数据量，相对较低的成本）
我们透析需求，实际上就需要做一件事：编程实现车内行为仿真。抽丝剥茧，层层深挖下来又是两点需求
1、车内通信信号的仿真
2、诊断的请求与应答（被刷写ECU的应用层业务逻辑封装）
重点讲第2点，前面讲过FOTA安装过程中TBOX扮演了诊断仪的角色，所以实现第2点的需求时，需满足单对单的物理寻址请求，单对多的广播式功能寻址请求。
我的设计思路是建立两条链路，分别支持物理寻址，功能寻址。接下来是选择从哪一层去实现，不同层应用的协议不一样，其实现的复杂程度也不一样。举个例子，要建一个Client与Server进行网络通信，如果你对底层比较清晰，可以直接采用套接字实现。否则你可以选择较上层的协议去实现。
CAN总线的通信也是符合OSI模型，见下图：
分析优缺点：
从物理层切入实现，需兼顾帧格式的问题，包含多帧分包传输，流控策略，连续帧拆分与组装等麻烦事情，在保证数据正确性上要写过多逻辑。且对ISO11898有比较深的了解。 整体框架和逻辑简单，可扩展性差。
从传输层切入实现，托管了数据处理的细节，ECU间的耦合度低，是比较好的选择。不过框架设计会复杂一些。
具体实现方案：基于CANoe的CanTp建模库，在CAN上实现了传输协议ISO/DIS 15765–2，控制传输大量数据，支持多通道并发。仿真整车上支持OTA的节点，每个节点都可通过两个连接(物理寻址-Connection 1 和 功能寻址-Connection 2)，使用OSEK TP节点层DLL与诊断仪通信，在同一连接上在同一时间可以发送和接收数据。仿真FOTA刷写流程。
通信模型与系统框架：
CAPL代码具体实现，详见下一篇