3. FOTA系统总体架构设计
车载FOTA不是“把升级包下载到车机再点安装”这么简单。它是一条跨越公网、车厂云、车端网关、域控制器、诊断栈和芯片内部安全单元的完整链路。任何一个环节的职责边界模糊，都会导致升级失败、变砖风险或安全漏洞。本节从工程落地角度，把这条链路拆成五个层次，明确每一层“该做什么、不该做什么、通过什么接口与上下游交互”。
五层职责划分
云端（FOTA Server / 车厂云平台）负责版本管理、升级包构建、车辆分组、任务下发和状态回收。它不直接与车端建立长连接，而是通过MQTT或HTTPS将升级任务推送到T-Box。云端需要维护的核心数据包括：车辆VIN与当前版本映射、升级包元数据（包大小、哈希、签名、适用车型/配置）、任务策略（灰度比例、时间窗口、失败重试次数）。典型接口是POST /ota/task下发任务，GET /ota/status/{vin}查询进度。
T-Box / 中央网关是车端与云端的唯一通信边界。T-Box负责公网接入、TLS终止、消息队列缓存和断点续传；网关负责车内网络路由，把升级包从T-Box转发到目标域控制器。关键约束是：T-Box不解析升级包内容，只做透明传输和完整性校验（如SHA-256比对），避免成为攻击面。T-Box与OTA Master之间通常走以太网或CAN FD，接口约定为OTA_Download_Request和OTA_Download_Data。
OTA Master是车端升级流程的“总调度”。它通常运行在座舱域控制器或中央计算单元上，职责包括：解析云端任务、选择目标ECU、协调下载与安装时序、管理电源状态（确保蓄电池电压充足）、处理回滚。OTA Master不直接操作芯片Flash，而是通过诊断栈下发UDS服务。它与诊断栈的接口是UDS 0x34/0x36/0x37（请求下载、传输数据、退出传输）和0x31（例程控制，用于校验和激活）。
诊断栈（UDS / DoIP）是OTA Master与ECU之间的标准协议层。它负责把OTA Master的升级指令翻译成UDS服务，并通过DoIP或CAN TP传输到目标ECU。诊断栈需要处理流控、超时、NRC（否定响应码）解析和会话保持。例如，当ECU返回0x78（请求正确接收，响应挂起）时，诊断栈必须维持连接并等待最终响应，而不是立即报错。
Qualcomm芯片侧组件是升级的最终执行者。以SA8155/SA8295为例，芯片内部涉及多个安全域：AP（应用处理器）运行Linux/Android，负责文件系统升级；Modem运行独立固件，通过QMI接口与AP通信；ADSP/CDSP运行音频和摄像头固件；Secure Processor（SPU）负责签名验证和密钥管理。OTA Master通过诊断栈触达ECU后，ECU内部的升级代理（如Qualcomm的QFPROM或Firehose协议）负责将镜像写入UFS/eMMC分区。关键接口是Firehose的program和patch命令，以及QMI的PDC（平台数据配置）激活。
接口约定的关键细节
五层之间的接口不是简单的函数调用，而是有明确时序和状态约束的协议交互。以一次典型的ECU固件升级为例，完整时序如下：
- 云端下发任务：云端通过MQTT向T-Box推送
{"task_id":"T20250101","target":"VCU","version":"2.3.1","url":"https://ota.example.com/pkg/vcu_2.3.1.bin","sha256":"a1b2c3..."}。T-Box收到后缓存到本地，并回复{"status":"received"}。 - T-Box转发到OTA Master：T-Box通过SOME-IP服务发现找到OTA Master，发送
OTA_Download_Request，携带包大小和哈希。OTA Master校验车辆状态（车速为0、挡位P、蓄电池电压>12V），满足条件后回复OTA_Download_Ready。 - OTA Master启动诊断会话：OTA Master通过DoIP向目标ECU发送
0x10 0x02（进入编程会话），ECU回复0x50 0x02。随后发送0x27 0x01请求安全访问种子，ECU返回种子，OTA Master用预置密钥计算并发送0x27 0x02，通过后进入安全状态。 - 下载与写入：OTA Master发送
0x34请求下载，指定内存地址和大小；ECU回复0x74并给出最大块长度。OTA Master按块发送0x36传输数据，每块携带序号，ECU回复0x76确认。全部传输完成后发送0x37退出传输。 - 校验与激活：OTA Master发送
0x31 0x01 0x0203触发ECU内部校验例程，ECU计算Flash中镜像的SHA-256并与预期值比对。校验通过后，OTA Master发送0x31 0x01 0x0204激活新镜像，最后发送0x11 0x01复位ECU。
在这个过程中，Qualcomm芯片侧的SPU（Secure Processor Unit）承担了不可替代的角色。当ECU收到0x34请求时，SPU会验证下载请求的签名是否由车厂私钥签发；当0x31校验例程执行时，SPU负责计算镜像哈希并与签名中的哈希比对。如果SPU验证失败，ECU会返回0x72（编程失败）并拒绝激活，OTA Master据此触发回滚流程。
职责边界与常见误区
实际工程中，以下边界最容易出问题：
- T-Box不应解析升级包。有些方案让T-Box做差分还原或解压，这会把T-Box变成攻击入口。正确做法是T-Box只做透明传输，差分还原由OTA Master或ECU内部完成。
- OTA Master不应直接操作Flash。OTA Master的职责是调度和决策，不是执行。直接操作Flash会绕过诊断栈的安全会话和SPU验证，导致安全链断裂。
- 诊断栈不应缓存升级包。诊断栈是协议转换层，缓存数据会引入内存压力和一致性问题。数据流应该是OTA Master→诊断栈→ECU，诊断栈只做转发和流控。
- Qualcomm芯片侧组件不应信任外部输入。SPU必须独立验证签名，不能因为诊断栈已经校验过就跳过验证。这是纵深防御的基本要求。
参数与状态约定示例
以下是一份可用于联调的接口参数约定表（示例值，非实测）：
| 接口 | 方向 | 关键参数 | 示例值 | 约束 |
|---|---|---|---|---|
| 云端→T-Box | 下行 | task_id, url, sha256, size | size=48MB, sha256=a1b2c3... | MQTT QoS 1, 超时30s |
| T-Box→OTA Master | 下行 | download_request, offset, length | offset=0, length=4096 | SOME-IP, 块大小≤4KB |
| OTA Master→ECU | 下行 | 0x34 address, size | address=0x08000000, size=0x3000000 | 编程会话0x02, 安全等级0x01 |
| ECU→OTA Master | 上行 | 0x74 maxBlockLength | maxBlockLength=1024 | 流控STmin=5ms |
| SPU验证 | 内部 | signature, hash | RSA-2048, SHA-256 | 失败返回0x72 |
这张表的价值在于：联调时如果ECU返回0x31（请求超出范围），可以快速判断是OTA Master下发的地址越界，还是ECU内部分区表配置错误；如果SPU验证失败，可以检查签名是否与车辆配置匹配，而不是盲目重试。架构设计的最终检验标准，就是当升级失败时，能否在5分钟内定位到具体是哪一层的哪个接口出了问题。