车载 OTA 测试内部学习笔记(实战案例)

车载 OTA 不是“下载一个包然后安装”，而是一条 云端 → T-Box → 网关 → 目标 ECU → 重启切分区 → 自检回传 的链路。

整车 OTA 链路架构图

测试笔记：

云端管“发得对不对”，T-Box 管“收得全不全”，网关管“传得过去不”，ECU 管“写得进不进、起不起得来”。

A/B 分区是车载 OTA 的命根子：写失败、起不来、自检超时，都能切回去。

参考台架 + 实车的主流拆分方式：

案例 ：升级进行到 52% 切断 12V 低压电 → 必须回旧版本

环境
- 台架：T-Box + 网关 + 目标 ECU（支持 A/B）
- 工具：CANoe 看状态机、可编程电源控 12V、继电器随机掉电
- 包：全量 FOTA 包，目标 ECU 当前跑 Slot A

步骤
1. 云端下发任务，车端开始下载并写入 Slot B
2. 进度到 ~52% 时，可编程电源把 KL30 拉到 0V（模拟低压电瓶掉电）
3. 保持断电 10s，再上电
4. 观测 Bootloader 启动选择逻辑与 retry_count
5. 车端重新上电后检查当前运行槽、版本号、能否正常起步

预期结果
- 升级不“变砖”
- Slot B 未标记 successful，Bootloader 仍选 Slot A
- 仪表提示“升级中断，已恢复上一版本”
- 车辆可正常上电、挂挡、行驶
- 云端收到“失败-断电-已回滚”日志

判定口径：不是“能重启就行”，而是运行槽=A、版本号=旧版、无新增 DTC、功能可用。

车载 OTA 在国内上车前绕不开几条：

- GB 44496—2024《汽车软件升级通用技术要求》：验签、失败回滚、版本追溯必须有
- UN R156 / WP29 SUMS：升级管理体系可审计
- ISO 21434：传输链路的网络安全
- 升级失败恢复要符合“恢复原状态”要求
- OTA 不能拿来规避召回——安全缺陷修复该备案就备案

测试报告里建议单开一节：合规判定，把每条标准映射到用例编号。