FOTA-车端自动化测试方案设计（1）
基于CANoe编程实现FOTA车端的自动化测试
1）需求分析
FOTA（Firmware Over-The-Air）, 可拆分为两点核心内容：“下载” 和 “安装”。下载即指从服务器获取升级包。安装是将已下载的程序文件刷写进目标节点。
“下载”不必需依赖于实车，也不依赖于车内其它对手件，过程中仅TBOX与服务器端的交互。服务器端需要的认证信息，都可以通过构造数据来执行测试。拆包、断点续传等功能性验证也仅属于TBOX控制器本身。
此处重点讲述的是仿真车内网络，控制支持OTA的节点配合完成OTA流程，验证TBOX刷写流程的正确性。
2）物理组网
分析实车环境与仿真测试环境的差异，先列出脱离实车后组网模型上的必需件。
- 12V B+供电源
- 业务触发的必需件ECU（根据TBOX的系统功能规格需求书可确定必需存在的ECU，比如车内时钟来源节点，主机等）
- 仿真设备（硬件：VN1640，软件：CANoe）
- 上位机（PC，Windows系统）
- 程控继电器（模拟点火硬线信号的通断）
- 服务器（若采用内外测试，则需要此部分。硬件：服务器级别的PC；软件：开发模拟测试云平台，需实现认证，转发，TSP通信协议数据包的构造和解析。 若现网测试则忽略此部分）
3）方案实施分析
针对我举例的TBOX产品，FOTA安装过程本质是基于UDS协议实现的编程模式下诊断写入的过程。
我们透析需求，实际上就需要做两件事
a. 解决车内网络通信信号的仿真
b. 解决TBOX作为诊断仪在总线上诊断请求能被目标OTA ECU的诊断应答（被刷写ECU的应用层业务逻辑封装）
重点讲第2点，需实现单对单的物理寻址请求的逻辑处理，单对多的功能寻址请求的逻辑处理。我的设计思路是建立两条链路，分别支持物理寻址，功能寻址。
分析实现难度，衡量利弊。接下来是选择从哪一层去实现，不同层所用的协议不一样，因而实现的复杂程度也不一样。举个例子，要建一个Client与Server进行网络通信，如果你对底层比较清晰，可以直接采用套接字实现。否则你可以选择较上层的协议去实现。
从数据链路层/物理层切入实现，需兼顾帧格式的问题，包含多帧分包传输，流控策略，连续帧拆分与组装等。在保证数据正确性上要写过多逻辑。且需要对ISO 11898有比较深的了解。 虽然整体框架和逻辑简单，但可扩展性差。
从传输层切入实现，托管了数据处理的细节，ECU间的耦合度低，是比较好的选择。但在框架设计会复杂一些。
最终选择的实现方案：
基于CANoe的CanTp建模库，在CAN上实现了传输协议ISO/DIS 15765–2，控制传输大量数据，能支持多通道并发。
仿真整车上支持OTA的节点，每个节点都可通过两个连接(物理寻址-Connection 1 和 功能寻址-Connection 2)，使用OSEK TP节点层DLL与诊断仪通信，在同一连接上在同一时间可以发送和接收数据。仿真FOTA刷写流程。
----------------------未完待续--------------------
