3. OTA系统架构
OTA（Over-The-Air）升级并不是“把安装包推到车上”这么简单，它是一条跨越云端、通信链路、车端网关、升级代理与目标ECU的完整工程链路。理解这条链路上每个角色的职责与交互顺序，是设计OTA测试用例、评估安全升级方案的前提。本节从系统架构视角，拆解五类核心组成及其协作关系。
一、核心原理：五层组成与职责边界
OTA系统可以抽象为五个相互协作的层次，每一层都有明确的职责边界，任何一层缺失或越权都会导致升级失败或安全风险。
- 云端（OTA云平台）：负责升级包管理、版本策略、灰度发布、车辆分组、任务下发、状态回传与审计。它是升级任务的“决策中心”，掌握全量车辆版本画像。
- 移动端（App/小程序）：面向用户，负责升级提醒、用户授权确认、预约升级时间、进度展示与结果反馈。它是“用户交互入口”，不直接传输升级包。
- 通信链路：包括车-云之间的蜂窝网络（4G/5G）、Wi-Fi，以及车内以太网/CAN/LIN等总线。它决定传输带宽、时延与断点续传能力。
- 车端网关（T-Box/中央网关）：负责与云端建立安全通道、身份认证、升级包下载缓存、完整性校验，并将升级任务分发给升级代理。
- 升级代理（OTA Agent）：部署在车端计算单元或域控制器上，负责升级包解压、签名验证、刷写编排、断电保护、回滚与状态上报，是“执行中枢”。
升级代理是整条链路的关键枢纽：它向上承接云端任务与网关下载结果，向下驱动目标ECU进入刷写模式，并在异常时触发回滚，保证车辆始终处于可运行状态。
二、交互关系：一次完整升级的时序
以一次典型的FOTA升级为例，五类组成的交互顺序如下：
- 云端生成升级任务，按VIN或车型分组，通过HTTPS/MQTT向车端网关推送任务通知。
- 车端网关完成双向TLS认证后，向云端请求升级包元数据（版本号、大小、哈希、签名）。
- 网关在后台下载升级包，支持断点续传；下载完成后校验SHA-256与数字签名。
- 升级代理从网关获取已校验的升级包，解析刷写清单，检查车辆状态（电量、挡位、车速）。
- 满足条件后，代理按依赖顺序驱动目标ECU进入Bootloader，分块刷写并逐块校验。
- 刷写完成后代理触发ECU重启与自检，将结果经网关回传云端，同时同步到移动端展示。
移动端在整个过程中不参与数据传输，只承担“用户授权”和“结果呈现”。这一点在测试中常被误解，导致用例设计偏离真实链路。
三、方法流程：升级代理的内部编排
升级代理是测试关注的重点对象，其内部通常包含以下处理阶段，每个阶段都对应可验证的测试点：
| 阶段 | 关键动作 | 典型测试点 |
|---|---|---|
| 任务接收 | 解析云端任务，校验VIN与版本匹配 | 错误VIN、重复任务、过期任务 |
| 包校验 | SHA-256、数字签名、版本防回滚 | 篡改包、降级包、签名失效 |
| 前置条件检查 | 电量、挡位、车速、网络状态 | 低电量、行驶中、弱网 |
| 刷写执行 | 分块写入、逐块校验、依赖顺序 | 断电、断点、刷写超时 |
| 回滚与上报 | 失败回滚、状态回传云端 | 回滚成功率、状态一致性 |
四、案例与场景：一次弱网升级的复盘
某车型在山区进行FOTA升级，车辆处于4G弱网环境。云端下发任务后，车端网关下载升级包至60%时网络中断。由于网关支持断点续传，恢复网络后继续下载并完成校验。但升级代理在执行刷写时发现蓄电池电量低于阈值，主动中止并回滚，同时向云端上报“条件不满足”。移动端向用户展示“建议充电后重试”。
该案例说明：通信链路的稳定性、网关的续传能力、代理的前置条件判断与回滚机制，共同决定了升级的最终成功率。测试用例必须覆盖“弱网+低电量+中断恢复”的组合场景，而不是只测理想链路。
常见误区：把移动端当作升级包传输通道。实际上移动端只负责用户交互，升级包始终由云端经通信链路直达车端网关。若测试用例让App承担包传输，会偏离真实架构，导致安全与性能评估失真。
五、安全升级方案中的架构约束
在安全升级方案中，五类组成还需满足以下约束：云端必须支持任务签名与密钥轮换；通信链路必须启用TLS双向认证；车端网关必须校验包完整性与来源；升级代理必须实现防回滚与安全启动链；移动端必须确保用户授权不可伪造。这些约束最终都会转化为OTA测试用例中的安全测试项，例如签名篡改、重放攻击、降级攻击与中间人攻击的验证。
# 车端网关校验升级包的关键参数示例
package:
version: "2.3.1"
size: 184320000
sha256: "a3f1...9c2e"
signature: "MEUCIQ...=="
min_battery: 40%
allowed_gear: "P"
rollback: enabled