3. 车载软件升级概述
车载软件升级并不是“把新包推给车”这么简单，它同时牵涉到升级对象、传输通道、刷写协议、引导程序、车辆状态与生命周期治理。理解 OTA、SOTA、FOTA、UDS 诊断刷写、Bootloader 之间的关系，是后续讨论可信发布与升级安全工程的基础。
一、核心概念：OTA 是总称，SOTA 与 FOTA 是两类对象
OTA（Over-The-Air）指通过无线通道完成软件或数据的远程更新，是总体能力。按升级对象不同，通常分为两类：
- SOTA（Software Over-The-Air）：面向应用层、座舱娱乐、地图、语音、T-Box 应用等软件包，通常不直接改变车辆动力、制动、转向等基础控制逻辑，风险相对可控。
- FOTA（Firmware Over-The-Air）：面向 ECU 固件、Bootloader、底层驱动、标定数据等，可能影响车辆基础功能与安全，必须经过更严格的签名校验、回滚设计与刷写条件约束。
需要强调：SOTA 与 FOTA 的边界并非绝对。某些座舱域控制器固件升级也属于 FOTA；某些 ECU 的应用层参数更新也可能被归入 SOTA。工程上更应关注升级对象是否影响安全目标，而不是只盯名称。
二、UDS 诊断刷写：FOTA 的底层通道
在车载网络中，FOTA 通常不是“直接写 Flash”，而是通过 UDS（Unified Diagnostic Services，ISO 14229）诊断服务完成。典型刷写流程如下：
- 进入扩展会话：
10 03，使 ECU 从默认会话切换到可执行刷写相关服务的状态。 - 安全访问：
27 01请求种子，27 02发送密钥，通过后获得刷写权限。 - 写入指纹：
2E F1 84，记录诊断仪、版本、时间等追溯信息。 - 擦除内存：
31 01 FF 00，对目标 Flash 区域执行擦除。 - 请求下载：
34，告知 ECU 数据长度与地址。 - 传输数据：
36，按块传输固件数据。 - 退出传输：
37，结束数据下载。 - 校验与激活：
31 01 FF 01执行完整性校验，11 01复位 ECU，切换到新固件。
上述服务号只是典型示例，实际项目会结合 OEM 规范、CAN/CAN-FD/DoIP 传输层与安全芯片能力调整。刷写过程中任何一步失败，都可能导致 ECU 停留在 Bootloader 或不可用状态，因此必须有超时、重试与回滚策略。
三、Bootloader：升级的“安全底座”
Bootloader 是 ECU 上电后最先运行的一段引导程序，负责判断是跳转到应用固件，还是停留在刷写模式等待诊断指令。它通常包含：
- 启动决策：检查应用区有效性标志、CRC、签名与版本，决定是否跳转。
- 刷写服务：实现 UDS 刷写服务、Flash 驱动、传输层与安全访问。
- 回滚与恢复：当新固件校验失败或启动失败时，回退到旧版本或进入安全模式。
- 防变砖机制：双分区 A/B 备份、看门狗、掉电保护与最小可用通信能力。
关键点：Bootloader 本身也可能被升级，但它必须比应用固件更稳定、更难被篡改。若 Bootloader 被恶意替换，后续所有签名校验都可能失效。
四、升级场景与生命周期管理
车载升级不是单次动作，而是覆盖“发现—下载—校验—刷写—激活—验证—回滚—审计”的生命周期。常见场景包括：
| 场景 | 典型对象 | 关键约束 | 失败后果 |
|---|---|---|---|
| 座舱应用升级 | SOTA 应用、地图、语音包 | 用户确认、网络流量、存储空间 | 应用不可用，可重装 |
| ECU 固件升级 | FOTA 固件、标定数据 | 车辆静止、电量充足、诊断会话 | ECU 变砖，需回滚或返厂 |
| 安全补丁升级 | 网关、T-Box、安全芯片 | 签名校验、防降级、审计留痕 | 安全漏洞暴露，合规风险 |
| 批量召回式升级 | 多车型、多 ECU 组合 | 版本矩阵、灰度发布、法规备案 | 大规模不一致，售后压力 |
生命周期管理要求对每个软件包建立版本、依赖、适用车型、刷写条件、回滚策略、审计记录。例如，一个 FOTA 包必须明确：适用 ECU 硬件版本、当前软件版本范围、是否允许降级、刷写电压窗口、所需会话与安全等级。缺少这些元数据，升级系统就无法判断“该不该推、能不能刷、失败怎么办”。
五、案例与误区复盘
某车型在 OTA 推送网关固件时，未校验车辆蓄电池电压，部分车辆在刷写过程中因电压跌落导致网关进入 Bootloader 且无法退出。复盘发现：刷写条件只检查了“车辆静止”，没有检查“电量与电压”，也没有设计 A/B 分区回滚。改进措施包括：
- 刷写前读取电压与电量，低于阈值直接拒绝。
- 采用双分区，新固件校验通过后再切换启动标志。
- Bootloader 保留最小通信能力，支持重新刷写。
- 升级任务增加超时、重试与断点续传。
- 服务端记录每次升级的 VIN、版本、结果与失败原因。
常见误区：把 OTA 等同于“远程下载”；把 SOTA 当作“低风险所以不用签名”；把 Bootloader 当作“永远不变的基础设施”；把刷写失败当作“重试即可”。这些认知都会在真实车辆环境中放大为安全与召回风险。
综上，OTA 是能力框架，SOTA/FOTA 是对象分类，UDS 是刷写通道，Bootloader 是安全底座，生命周期管理是治理主线。只有把这几层关系同时纳入设计，车载软件升级才具备可信、可控、可回滚的工程基础。