4. 远程升级系统架构
远程OTA升级并不是“把安装包从服务器推到设备上”这么简单。它是一条跨越云端、公网、车端网关、车内网络直至目标ECU的完整链路，任何一个环节设计不当，都会导致升级失败、版本不一致，甚至让车辆进入不可用状态。理解远程升级系统架构，核心是理解“谁负责决策、谁负责传输、谁负责执行、谁负责兜底”这四件事分别落在哪些组件上。
一、核心原理：五层组件各司其职
一个可落地的远程升级系统，通常由云端、通信链路、车端/设备端、升级代理、升级客户端五类核心组件构成。它们不是简单的串联关系，而是带有反馈与状态回传的闭环。
- 云端升级平台：负责升级包管理、版本策略、灰度发布、任务编排、设备分组、签名校验与升级结果统计。它是“决策中心”。
- 通信链路：包括蜂窝网络、Wi-Fi、车云MQTT/HTTPS通道等，负责把升级任务、升级包分片、状态上报在云端与车端之间可靠传递。它是“传输通道”。
- 车端/设备端：通常指T-Box、网关或域控制器，负责接收云端指令、缓存升级包、校验完整性，并调度车内升级流程。它是“车端入口”。
- 升级代理（OTA Agent）：运行在车端主控上，负责与云端会话、下载管理、断点续传、签名验证、升级条件判断（如车速、电量、挡位）以及升级状态机推进。它是“调度中枢”。
- 升级客户端（OTA Client）：部署在目标ECU或域控制器内，负责接收代理下发的固件、执行刷写、校验并回传结果。它是“执行末端”。
关键点：升级代理与升级客户端之间通常通过车内网络（CAN/CAN FD、以太网、DoIP）通信，而不是直接走公网。云端只与代理交互，代理再与客户端交互，形成分层解耦。
二、方法流程：一次升级任务的完整流转
以一次典型的车机固件升级为例，任务流转大致分为六个阶段：
- 任务创建：云端根据车型、VIN、当前版本筛选目标设备，生成升级任务并绑定升级包与策略。
- 任务下发：通过MQTT或HTTPS通道向车端升级代理推送任务通知，包含版本号、包大小、校验值、下载地址。
- 条件判断：代理检查车辆状态，如车速为0、挡位P、电量高于阈值、不在充电中，满足后才允许下载。
- 包下载与校验：代理分片下载升级包，支持断点续传，下载完成后进行哈希与签名校验。
- 刷写执行：代理将固件分发给对应升级客户端，客户端执行刷写，必要时进入Bootloader模式。
- 结果回传：客户端回传刷写结果，代理汇总后上报云端，云端更新设备版本台账并触发统计与告警。
建议在代理层实现“升级条件门控”，把车速、电量、挡位、网络质量等判断前置。这样即使云端误发任务，车端也能拒绝执行，避免行驶中刷写带来的安全风险。
三、案例场景：一次失败升级的复盘
某车型在灰度升级中，部分车辆升级到90%后卡住，最终回滚。排查发现：升级代理在下载完成后未校验分片顺序，导致升级客户端收到的固件镜像存在错位；同时代理未在刷写前再次确认电量，部分车辆在刷写过程中因低压保护中断。复盘结论是：代理层缺少“下载完整性校验”和“刷写前二次条件确认”两个关键动作。
升级状态机关键状态：
IDLE → TASK_RECEIVED → CONDITION_CHECK → DOWNLOADING
→ VERIFYING → READY_TO_FLASH → FLASHING → SUCCESS / FAILED / ROLLBACK
失败分支：
VERIFYING 失败 → 重新下载（最多3次）
FLASHING 失败 → 触发回滚 → 上报云端
四、常见误区与设计要点
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 云端直接与ECU通信 | 链路复杂、安全边界模糊 | 云端只与升级代理交互，代理再调度客户端 |
| 代理只做转发不做校验 | 损坏包进入刷写，导致变砖 | 代理完成哈希与签名校验后再分发 |
| 忽略断点续传 | 弱网下反复重下，流量与时间浪费 | 分片下载+断点续传+重试上限 |
| 刷写前不检查车辆状态 | 行驶中刷写，安全风险极高 | 车速、挡位、电量、充电状态多重门控 |
| 无回滚机制 | 失败后车辆不可用 | 双分区A/B或备份分区，失败自动回滚 |
升级代理与升级客户端的职责边界必须清晰：代理负责“决策与调度”，客户端负责“执行与反馈”。如果代理越权直接操作ECU刷写，或客户端自行决定升级条件，都会破坏架构的可维护性与安全性。
总结来看，远程升级系统架构的本质是分层解耦：云端管策略与包，链路管传输，车端管入口，代理管调度，客户端管执行。只有每一层都明确自己的职责与边界，才能让OTA升级在安全、可靠、可回滚的前提下规模化落地。