3. OTA系统架构
OTA（Over-The-Air）升级不是“把包丢给车”这么简单，它是一条跨越云端、移动端与车端的多阶段数据链路。理解三端各自的职责、它们之间使用的通信协议，以及升级任务在不同阶段的数据流向，是后续做联调、排障和脚本自动化的基础。本节从架构分层出发，梳理三端交互原理，并重点说明 HTTP、HTTPS、MQTT 在 OTA 链路中的分工。
一、三端职责与整体架构
OTA 系统通常由三个角色构成：云端（OTA Platform）负责升级包管理、任务编排、车辆分组、策略下发与状态汇总；车端（Vehicle / T-Box / OTA Agent）负责接收任务、下载升级包、校验签名、分发到目标 ECU 并执行刷写；移动端（App / 小程序）负责用户交互，例如查看可升级版本、确认升级、查看进度、预约升级时间。
三端并不是两两全连接。典型链路是：移动端通过 HTTPS 调用云端业务接口；车端通过 MQTT 与云端保持长连接接收任务通知，再通过 HTTPS 从对象存储下载升级包；车端执行结果又通过 MQTT 或 HTTPS 回传云端，云端再同步给移动端展示。也就是说，MQTT 负责“通知与状态”，HTTPS 负责“业务请求与文件传输”，这是理解整个数据流的关键。
二、通信协议分工：HTTP、HTTPS 与 MQTT
在 OTA 链路中，三种协议承担不同角色，不能混用：
- HTTPS：用于移动端与云端的业务接口、车端与对象存储的升级包下载、以及部分状态回传。HTTPS 在 HTTP 之上加入 TLS，保证传输加密与服务器身份认证，是 OTA 中“必须使用”的协议。
- HTTP：仅用于内网调试、测试环境或非敏感数据接口。生产环境若使用明文 HTTP 传输升级包或任务信息，会带来篡改与窃听风险，属于典型误区。
- MQTT：基于发布/订阅模型，适合车端与云端之间的长连接、低带宽、异步消息通信。云端向车辆下发任务通知、车辆上报升级进度，通常走 MQTT。
| 协议 | 典型用途 | 方向 | 特点 |
|---|---|---|---|
| HTTPS | 业务 API、升级包下载、状态查询 | 请求/响应 | 加密、可靠、适合大文件与敏感数据 |
| HTTP | 内网调试、测试桩 | 请求/响应 | 明文、仅限非生产环境 |
| MQTT | 任务通知、进度上报、心跳 | 发布/订阅 | 长连接、低功耗、异步、支持 QoS |
三、一次 OTA 升级的完整数据流
以“用户确认升级”为起点，典型数据流如下：
- 移动端通过 HTTPS 调用云端接口，查询车辆可升级版本，并提交升级确认。
- 云端生成升级任务，通过 MQTT 向目标车辆推送任务通知（含任务 ID、包地址、校验值）。
- 车端收到通知后，通过 HTTPS 从对象存储下载升级包，支持分片与断点续传。
- 车端校验包签名与完整性，写入本地缓存，并按策略分发到目标 ECU。
- 车端执行刷写，过程中通过 MQTT 周期性上报进度与状态。
- 云端汇总状态，移动端通过 HTTPS 轮询或订阅方式获取最新进度。
- 升级完成后，车端上报最终结果，云端记录版本并更新车辆档案。
联调关注点：任务通知是否到达、包地址是否可访问、签名校验是否通过、进度上报是否连续、失败后是否可重试。这五个点覆盖了 OTA 数据流的主要断点。
四、案例场景：一次“任务已下发但车端未下载”的排障
某次联调中，云端显示任务已下发，但车端始终没有开始下载。排查顺序如下：
1. 检查 MQTT 连接状态
mosquitto_sub -h broker.ota.example.com -p 8883 \
-t "vehicle/+/ota/task" -v
2. 查看车端日志中的任务接收记录
grep "OTA_TASK_RECEIVED" /var/log/ota-agent.log
3. 验证包地址是否可访问
curl -I https://cdn.ota.example.com/pkg/v2.3.1.bin
4. 检查签名校验结果
grep "SIGNATURE_VERIFY" /var/log/ota-agent.log最终定位为：云端下发的包地址是内网地址，车端在公网环境无法访问。这类问题在联调中非常常见，本质是云端配置与车端网络环境不一致，而不是协议本身的问题。
常见误区：把 MQTT 当作文件传输通道。MQTT 适合小消息通知，不适合传输几十兆甚至几百兆的升级包。升级包必须走 HTTPS 下载，MQTT 只负责“告诉车端去哪里下载”。
五、复盘：三端交互的稳定性设计
要让三端交互稳定，需要在设计阶段考虑以下几点：
- 幂等性：同一任务重复下发时，车端应能识别并避免重复刷写。
- 断点续传：升级包下载支持 Range 请求，网络中断后可继续。
- QoS 等级：MQTT 任务通知建议使用 QoS 1，确保至少送达一次。
- 超时与重试：车端下载、校验、刷写各阶段都应有独立超时与重试策略。
- 状态机：任务状态应明确（待下发、已下发、下载中、校验中、刷写中、成功、失败），避免状态歧义。
理解三端架构与协议分工后，后续的脚本联调就可以按“移动端触发 → 云端编排 → MQTT 通知 → HTTPS 下载 → 车端执行 → 状态回传”这条主线逐段验证，快速定位问题发生在哪一端、哪一协议、哪一阶段。