CANoe编程实现FOTA车端的自动化测试（一）

FOTA（Firmware Over-The-Air) 固件在线升级，包括车辆底层算法至顶层应用的综合升级，用户通过刷新程序进行 FOTA 升级，影响的是动力系统、ADAS 系统等，而SOTA（Software Over the Air)软件升级，一般是指离用户更近的应用程序、人机交互界面等功能的升级。

1.汽车OTA流程

车辆从主机厂服务器更新程序到指定ECU的过程中的主要部件。首先通过蜂窝网络建立车辆与服务器之间的安全连接，确保全新的，待更新的固件安全地传输到车辆的TelematicsUnit，然后再传输给OTAManager。OTAManager管理车辆所有ECU的更新过程。它控制着将固件更新分发到ECU，并告知ECU何时执行更新-在多个ECUs需要同时更新的情况下尤为重要-例如推送一项新功能，而该新功能涉及多个ECUs。更新过程完成后，OTAManager将向服务器发送确认。所以OTA主要分为下载和安装两个过程。

2.FOTA车端的自动化测试环境的搭建

无论实车测试亦或仿真测试，“下载”这个过程都是一样的，并且“下载”不必需依赖于实车，所以需要仿真的部分集中在车内网络。主要问题就是解决车内ECU的仿真，总线网络节点建模，ECU逻辑实现。　
分析实车与仿真的差异，先列出脱离实车后组网模型上的必需件。仿真测试方案的必要组件包括12V B+供电源，业务触发的必需件ECU（根据TBOX的功能设计可确定必需存在的ECU），仿真设备CANoe, 工作站PC。测试方案中ECU(EPS,PEPS,BCM,ACU,TCU等)全由PC和CANoe仿真实现。
实车测试组网示意图：

　仿真测试组网示意图：
　

3.测试方案实施

TBOX的FOTA安装过程，是基于UDS协议实现的刷写。所以此处FOTA安装流程的本质就是编程模式下的诊断写入过程。
通过分析整个仿真测试只需要做一件事：编程实现车内行为仿真。具体是下面两点：

解决车内网络通信信号的仿真
解决TBOX作为诊断仪在总线上诊断请求的实现与被刷写ECU的诊断应答（被刷写ECU的应用层业务逻辑封装）

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

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

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

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

接口模型：