一直搭台架，一直优化测试方案，过程中思考了下不同方案的优缺点和适用范围，简记之以作备忘录

实车测试与仿真测试

a) 仿真测试方案与实车测试方案相比，它只保留与OTA特性关联的控制器，主要采用编程控制和仿真节点实现场景模拟测试。剥离不相关部件可能存在的测试干扰因子，更轻量化。

图1，组网示意图

在实车测试环境验证OTA特性，配合过程数据采集和事后诊断数据读取，可综合判断业务逻辑的正确性，可达成功能层面的测试。

在台架上利用专业仿真工具模拟实车的网络环境和支持OTA的控制器，程控电源模拟车内供电状态，通过在上位机编程实现自动地分析业务过程数据，以及对比业务执行前后的数据差异，可判断功能正确性、协议一致性、数据加解密、数据校验、业务流程、算法等的实现是否满足设计规范。是一个测试范围覆盖广且可以批量化布置的测试解决方案。

举例1：仿真台架实现更灵活的节点配置，真实控制器与仿真节点的自由切换。

图2，总线拓扑图

从拓扑图来看，每一个在OTA系统内的控制器均可通过仿真的方式实现。激活仿真节点可实现仿真测试，屏蔽仿真节点加入真实ECU则实现台架测试。我在系统设计时做了三项优化，使得它极具灵活性与扩展性。封装底层协议，从传输层建立双通道，可并发支持多路物理寻址和功能寻址；统一数据出入口，实现过程监控，对标准接口实现通用化编码设计；测试数据与业务逻辑分离，模块解耦。所以从控制器 1至控制器 n，测试时可以根据需求加入或移除节点。这非常便于我们在开发过程中持续集成，增量测试。

b) OTA刷写流程图分析两种测试方案的场景构造与灵活性

图3，OTA刷写简要流程示意

仿真测试流程，其中蓝色高亮步骤均可操作控制输入，更灵活的构建测试场景，充分地实现场景覆盖。

仿真测试方案与实车测试方案的主要差异点在于仿真测试方案实现了车内网络节点的灵活配置，测试控制条件可自由组合。对于构造异常场景的测试条件比较简单，它是非破坏性的，可反复用于试验。整个测试数据、过程可控可追溯。

举例2：控制测试条件构造异常场景，在整个流程中不同位置设置断点条件验证OTA处理逻辑。非损毁的可反复的测试手段。

图4，刷新失败重试机制流程示意

此处更新流程的蓝色高亮的步骤均可控制输入与灵活组合，相比实车测试可以更充分的验证整个OTA机制。支持重复验证而且不存在实车测试时将控制器损坏的风险，这点在橙色高亮的步骤产生的效果很明显，完全不用担心车辆无法启动或需物理维修的问题。

最后，这两种肯定要配合来做FOTA验证的，台架可做到专一针对，实车能贴合真实复杂场景。