汽车在线升级系统仿真测试平台

朱永健 王曼娜 张行 鞠伟男

（中国汽车技术研究中心有限公司，天津 300300）

0 引言

在汽车智能化和网联化趋势下，汽车成为移动互联网终端，在线升级（Over The Air，OTA）技术应用越来越广泛。随着汽车OTA 技术普及应用，新车型搭载OTA 功能已成为主流趋势，升级内容也从软件（Software OTA，SOTA）扩展到固件（Firmware OTA，FOTA），汽车产品竞争力和生命周期将被重新定义[1]。与传统的消费者到4S 店进行线下软件升级相比，OTA 升级更好地解决了以下3 个问题：（1）降低缺陷产品召回成本，降低产品负面影响；（2）更新扩展功能，增加用户体验；（3）加快车联网生态建设[2]。

当前，OTA 技术已成为众多汽车制造商的标准配置。同时，由于OTA 技术可能会带来潜在的风险，特别是汽车电子控制单元（Electronic Control Unit,ECU）固件更新的FOTA 技术。因此，针对OTA系统的测试就尤为重要。2022 年4 月15 日工信部装备工业发展中心发布《关于开展汽车软件在线升级备案的通知》[3]。该通知发布一方面印证了OTA技术得到了广泛应用，另一方面也说明了汽车OTA技术的兼容性和可靠性需要经过严格的测试验证。然而在实际测试过程中，OTA 测试在实车工况难以实现，特别是刷写稳定性、网络工况、故障工况等，并且企业需要测试的车型多、版本多，人工测试工作量大、成本高、效率低。因此，本文设计了一套汽车OTA 仿真测试平台，旨在解决实车OTA 测试和人工测试带来的问题。

1 OTA技术

OTA 技术是通过无线通信的方式将OTA 云服务器的软件升级包下发到车辆端，对被升级的控制器进行升级的过程。OTA 流程见图1，详细阐述如下。

图1 OTA流程

（1）升级包发布

待升级的升级包打包上传到内容服务提供商（Telematics Service Provider, TSP）云服务器后进行加密和签名，传输条件满足后传递至车辆端。

（2）升级包下发

车辆端主节点（Master）在接收到OTA 云服务器的软件升级包后进行存储，在满足推送条件后提示用户进行升级；用户确认升级后进入升级流程，Master会对升级的前置条件进行判断，如挡位、车速、电池荷电状态（State of Charge,SOC）等。

（3）升级包刷写

满足前置条件后，对升级包进行解密验签，对相应的控制器进行刷写[4-5]。

2 OTA测试环境

汽车OTA 系统仿真测试平台具备零部件刷写测试、系统集成测试以及整车测试与验证的软件升级全生命周期的自动化测试能力。

在整车V字型开发模型中（图2），主要测试包括：

图2 OTA开发流程

（1）零部件刷写测试

针对整车研发初期的零部件开发阶段，零部件开发完成后，需要进行零部件刷写功能的Bootloader 测试和Master功能测试。

（2）系统集成测试

零部件开发完成后，所有零部件需要安装在仿真测试台架，进行OTA 系统集成测试，包括车端测试和云端测试。

（3）整车仿真测试

集成测试完成后，在实车场景下，验证整车OTA功能的安全性和可靠性[6]。

3 OTA系统仿真测试平台

OTA 系统仿真测试平台由OTA 自动化测试机柜和系统测试台架组成（图3）。

图3 系统方案

测试机柜提供满足OTA 测试系统运行以及仿真的环境，主要包含工控机、程控电源、通信总线接口卡、输入/输出（Input/Output,I/O）板卡等。工控机运行上位机系统环境及仿真环境，总线接口卡和I/O 板卡模拟、采集待测ECU测试所需的信号。

测试台架提供被测ECU 的放置架、断线测试盒（Break-Out Box, BOB）信号转接盒和接线端子等。

3.1 测试机柜

测试机柜搭载的OTA 测试系统软件，功能包括仿真与分析、软件集成及测试，用于零部件刷写测试、系统集成测试和整车仿真测试。

3.1.1 控制器仿真

测试系统上位机分别仿真OTA 主节点和被刷节点，模拟测试过程中发送和监控信号，验证OTA 主节点和被刷节点的测试结果。

3.1.2 流程仿真

上位机对OTA 主节点和云端服务器的升级流程进行测试（图3）。第1，上位机配置测试任务，同时将测试任务下发到车端；第2，云服务器配置升级任务，并将升级任务下发到车端，进行升级包创建、升级任务发布、人机界面的升级任务检测、任务下载、升级前置条件检测和升级任务执行；第3，在升级流程进行中通过BOB 注入故障，模拟异常场景；第4，通过CANoe监控并记录升级的数据信息。

3.1.3 场景仿真

场景仿真使用可编程工具控制或模拟车端信号的方式，模拟OTA 升级过程中可能出现的各种异常场景，并通过监控OTA 执行中的数据，分析判断是否符合预期。异常场景库是根据测试规范预先设计的可执行脚本集合，使用中可根据测试场景需要调整脚本中的参数。按照建立的异常场景库，测试OTA 流程是否存在功能缺陷，如果存在，则记录相应的场景数据。

异常场景库包括用户操作异常、车况异常和网络异常。其中，用户操作导致的异常主要包括升级过程中对车辆的使用异常，例如车辆起停、车机系统复位、车辆上下电使用异常。车辆状况的异常主要包括零件号不匹配、软件不匹配和关联件不兼容。车辆网络异常主要包括下载通讯网络异常和车内通讯网络异常。

3.1.4 测试系统

OTA 测试系统基于测试脚本工具，绑定测试用例，创建测试任务并进行自动化OTA测试。

创建测试任务之后，通过测试任务管理测试用例，包括车、管、云协同执行测试用例，测试用例独立运行，互不影响。测试结束后，系统自动生成测试报告。

测试系统支持零部件测试、系统集成测试和整车测试与验证。通过修改测试系统配置参数，覆盖整车开发周期中不同阶段的测试场景。

3.2 测试台架

测试台架的功能为能够实现整车多个ECU 同时进行测试。

3.2.1 断线测试盒（BOB）信号转接盒

断线测试盒（BOB）功能为实现单个ECU 的上下电、总线断路和配置终端电阻功能。BOB转接盒分为3类：

（1）普通BOB

功能为支持上下电，2路CAN和5路LIN通信。

（2）网关BOB

功能为支持上下电，3路CAN和7路LIN通信。

（3）以太网BOB

功能为以太网接口，可以接3路1000/100Base-T1双绞线。

3.2.2 测试台架实现

首先根据设计需求确定3 种BOB 转接盒类型和数量。其次根据实际需求，按照台架网络拓扑结构，将3 种BOB 转接盒进行排布，实际每个BOB 对应的位置是固定的，所以每次更换拓扑图的时候，需要更改线束和相应的BOB布局。

4 系统测试

4.1 测试案例

以升级前先决条件检测为例，分别执行不满足先决条件的测试和满足先决条件的测试，判断机制在Master中进行，测试流程设计如下（图4）。

图4 先决条件测试流程

（1）开始测试流程。

（2）测试平台进行设备自检，若自检通过，则进入下一步操作；若自检不通过，则测试结束。

（3）测试平台依次设置不满足先决条件的信号。（4）被测对象触发升级。

（5）测试平台判断被测系统是否进入升级。

（6）若被测对象未进入升级流程，则符合法规要求，并重复操作所有先决条件不满足测试。

（7）若被测对象进入升级流程，则不符合法规要求，测试结束。

（8）所有先决条件不满足测试结束后，测试平台设置满足先决条件的信号。

（9）被测对象触发升级。

（10）测试平台判断被测系统是否进入升级。

（11）若被测对象进入升级流程并完成升级，测试结束。

（12）若被测对象未进入升级流程，则不符合法规要求，测试结束。

4.2 测试结果

如图5 为某控制器升级前先决条件判断的日志，Master 会根据设计需求去判断车速、电池荷电状态（SOC）、电源模式、车辆模式和充电状态。Master 设置先决条件判断的条件如下。

（1）车速≤4 km/h。

（2）70%≤SOC≤100%。

（3）电源模式为0（ON挡）。

（4）车辆模式不为1（未保持P挡会置1）。

（5）充电状态为1（未充电）。

其中台架模拟发送信号条件如下。

（1）车速为0 km/h。

（2）电量为50%。

（3）电源模式为ON挡。

（4）车辆模式P挡，未充电状态。

（5）模拟当前SOC 为50%，不满足70%≤SOC≤100%的要求，SOC 判断不通过，前置条件判断不通过，不能进入升级流程。

车机端给用户的提示结果如图6 所示，提示SOC条件不满足升级条件，与Master抓取的日志结果一致。

图6 车机端先决条件判断结果

4.3 测试总结

根据汽车OTA 系统仿真测试平台的测试结果与车机端实际显示的结果对比一致，该测试平台测试效果满足设计要求。

5 结束语

OTA技术成为智能网联汽车功能优化和迭代升级的重要手段，需要通过OTA技术升级的ECU数量也越来越多，对OTA进行全面综合的测试，特别是可靠性和稳定性测试就显得尤为重要。汽车OTA系统仿真测试平台通过软硬件结合的设计思路，解决整车企业OTA测试问题。该测试平台是一个可覆盖OTA 全功能、全场景以及稳定性测试的自动化测试平台。

汽车OTA 系统仿真测试平台相较于当前人工手动OTA 测试方式，缩短了研发周期、降低了研发成本、提高了测试的准确性。