4. OTA升级流程

OTA升级不是“把固件推给车就结束”，而是一条从版本定义到最终激活、并始终保留回滚能力的工程流水线。任何一个环节缺少可验证的约束，都会把风险带到用户侧。本节按八个阶段拆解全流程，并给出关键控制点与常见误区。

一、核心原理：八阶段闭环与三道闸门

完整的OTA流程可归纳为：版本管理 → 包制作 → 发布 → 下载 → 校验 → 安装 → 激活 → 回滚。其中存在三道“闸门”：发布前的准入闸门、安装前的校验闸门、激活前的条件闸门。三道闸门分别回答三个问题：这个版本允许上车吗？这个包完整且可信吗？当前车辆状态允许切换吗？

版本管理是整条链的“单一事实源”。每个ECU固件、每个应用、每个配置项都应有唯一版本号，并记录依赖关系。包制作把多个固件与元数据打包成可分发单元；发布决定“给谁、何时、以什么节奏”；下载与校验保证传输完整；安装把新固件写入备用分区；激活完成分区切换；回滚则是在激活失败或体验异常时回到已知可用版本。

二、方法流程：每个阶段的工程动作

1. 版本管理。建立版本矩阵，记录ECU名称、硬件版本、软件版本、依赖关系、兼容范围。版本号建议采用语义化规则，例如 APP-2.3.1 表示应用层第2大版本、第3功能版本、第1修复版本。任何一次发布都必须能回答“这个版本依赖哪些基础版本”。

2. 包制作。将固件、配置、元数据、签名打包为升级包。元数据至少包含目标车型、目标ECU、版本号、包大小、哈希值、签名、依赖项、安装条件。差分包可显著降低下载量，但必须保证差分基线与目标版本严格匹配。

{
  "package_id": "OTA-2024-0417-001",
  "target_ecu": "VCU",
  "version": "2.3.1",
  "base_version": "2.2.0",
  "type": "differential",
  "size_bytes": 18432000,
  "sha256": "9f2c...e1a7",
  "signature": "MEUCIQ...",
  "conditions": {
    "min_battery": 40,
    "gear": "P",
    "network": "WiFi"
  }
}

3. 发布。发布策略决定风险暴露面。常见做法是先内部车辆、再种子用户、再灰度比例、最后全量。发布系统应支持暂停、撤回、指定VIN白名单。发布前必须完成准入评审：测试报告、已知问题、回滚方案、影响范围。

4. 下载。车端通过HTTPS或专用通道下载，支持断点续传与分片校验。下载过程要记录进度、失败原因、重试次数。弱网环境下应避免反复全量重下，优先续传。

5. 校验。下载完成后先校验分片哈希，再校验整包哈希，最后验证数字签名。只有签名验证通过，包才允许进入安装阶段。校验失败必须丢弃并重新下载，不能“跳过校验强行安装”。

6. 安装。安装通常写入备用分区（A/B分区或双备份区），不直接覆盖当前运行分区。安装过程中要监控写入进度、坏块、空间不足等异常。安装完成后标记“待激活”，但此时车辆仍运行旧版本。

7. 激活。激活是真正的版本切换。必须满足条件：电量高于阈值、挡位为P、网络稳定、无正在进行的诊断或充电任务。激活后执行自检，确认关键ECU通信正常、故障码无异常。

8. 回滚。若激活后自检失败或用户反馈异常，系统应能自动或手动回滚到旧分区。回滚不是“重新下载旧包”，而是直接切换回保留的旧版本分区，因此速度更快、成功率更高。

三、案例场景：一次VCU升级的完整链路

某车型对VCU进行2.3.1版本升级，流程如下：版本管理确认2.3.1依赖BMS 1.8.0以上；包制作生成差分包18.4MB并签名；发布选择5%灰度；车端在WiFi下下载并断点续传；校验通过SHA-256与签名；安装写入B分区；激活前检测电量52%、挡位P、网络良好；激活后自检通过，上报成功。若自检发现CAN通信异常，则触发回滚，切回A分区2.2.0版本，并上报失败原因。

四、误区与复盘

五、关键参数与检查清单

把八阶段与三道闸门固化到流程和工具中，OTA升级才能从“能推包”走向“可管、可控、可回退”的工程能力。