引言
OTA（Over-The-Air）是智能汽车的标志性能力：特斯拉用 OTA 推送新功能，蔚来用 OTA 修复缺陷，车企靠 OTA 把「出厂即巅峰」变成「持续进化」。但 OTA 也是召回风险的放大器——一次失败的刷写可能让整车变砖，一次被篡改的升级包可能是攻击者的后门。
车载 OTA 的工程难点在于「不可失败」：手机刷机失败可以重刷，汽车刷写失败可能让车停在车库甚至行驶中失控。所以 OTA 必须设计成「要么成功，要么回到原状态」，且整个过程不能被断电、断网、篡改打断。这依赖 A/B 分区、签名验签、断点续传、看门狗、以及严格的车辆状态前置条件。
法规层面，UN R156（软件更新管理体系，SUMS）自 2022 年起对新车强制，要求车厂建立软件更新管理体系并证明 OTA 的安全性。这与 R155（网络安全）共同构成 OTA 的合规底座。本文逐层拆解。
目录
- OTA 类型：SOTA 与 FOTA
- 端到端 OTA 流程
- A/B 分区与回滚
- 差分升级
- UDS 刷写协议在 OTA 中的编排
- 签名与验证链
- 依赖编排与车辆状态
- 失败恢复与看门狗
- 安全合规 UN R156 与 R155
1. OTA 类型：SOTA 与 FOTA
OTA 按更新对象分两类，差异巨大：
| 维度 | SOTA | FOTA |
|---|---|---|
| 全称 | Software OTA | Firmware OTA |
| 对象 | 应用、地图、配置 | ECU 固件、OS |
| 影响 | 非安全关键 | 可能安全关键 |
| 风险 | 低 | 高（可变砖） |
| 回滚 | 简单（重装） | 需 A/B 分区 |
| 典型 | 车机 App、地图包 | 域控固件、MCU 固件 |
| 车辆状态 | 可行驶中 | 必须驻车 |
实际 OTA 往往是混合的：
一次升级包可能包含：
- 中控 Android 应用（SOTA）
- 智驾域控固件（FOTA）
- MCU 固件（FOTA，通过网关下发）
- 地图数据（SOTA）
按依赖顺序编排：先 FOTA（底层）后 SOTA（上层）
或按风险分级，分批推送
2. 端到端 OTA 流程
从云端到车端是一条完整链路：
云端：
1. 构建：CI 产出固件/应用包
2. 签名：用私钥签名升级包
3. 打包：生成升级描述（版本、依赖、前置条件）
4. 存储：CDN 分发
5. 编排：按 VIN / 车型 / 版本筛选目标车辆
6. 推送：下发升级通知（MQTT/HTTP）
车端：
1. 检查：OTA 客户端检查版本与兼容性
2. 下载：断点续传下载升级包
3. 校验：验签 + 完整性校验
4. 前置检查：车辆状态（驻车、电量、网络）
5. 安装：写入分区 / 刷写 ECU
6. 激活：切换启动分区，重启
7. 验证：新版本自检
8. 上报：结果回传云端
失败处理：
任一步失败 → 回滚到原版本
上报失败原因（云端可重试或人工介入）
关键设计：下载与安装分离。先在后台下载完，用户选择合适时机安装（避免下载中断影响使用）。
3. A/B 分区与回滚
A/B 分区是 FOTA 的可靠性基石：
A/B 分区布局（以域控为例）：
┌──────────┬──────────┐
│ Slot A │ Slot B │
│ Bootloader│ Bootloader│
│ Kernel │ Kernel │
│ RootFS │ RootFS │
│ App │ App │
└──────────┴──────────┘
当前运行 A，升级写入 B
校验通过 → 切换启动标志 → 重启进 B
失败 → 保持 A 启动
元数据分区：
记录当前活动槽、启动成功标志、尝试次数
尝试次数超限 → 强制回滚
Android 的 A/B（无缝更新）：
system_a / system_b
boot_a / boot_b
A/B 分区共享 data 分区
更新时写非活动槽，重启切换
关键机制：
1. 启动计数器：启动失败 N 次自动回滚
2. 看门狗：应用卡死时复位
3. 元数据原子写：掉电不损坏
4. 空间代价：分区翻倍（存储成本）
非 A/B（单分区）方案：
只能原地升级，失败即变砖
靠 Bootloader 恢复通道兜底
存储省，但风险高
4. 差分升级
差分升级只传「新旧版本的差异」，大幅省流量：
差分原理：
旧固件 + 差分包 → 新固件
生成（云端）：
bsdiff / xdelta / 自研算法
比较 old.bin 与 new.bin，生成 patch
应用（车端）：
读取 old.bin，应用 patch，生成 new.bin
写入新分区
压缩率：
同版本迭代：差分包是整包的 5%~20%
大版本：可能 30%~50%
例：100 MB 固件，差分包 8 MB
→ OTA 流量从 100 MB 降到 8 MB
流式差分（更优）：
边下载边应用 patch，不等整包下载完
节省内存与时间
代价：
车端需算力做 patch 应用（CPU 耗时）
需存储旧固件（A/B 分区天然有）
差分算法对固件布局敏感（对齐、填充）
块级差分（block-based）：
按块比较，适合文件系统镜像
如 Android 的块级 OTA
注意：
差分升级要求旧版本精确匹配
版本错配则 patch 失败 → 回退整包
5. UDS 刷写协议在 OTA 中的编排
车端 OTA 最终落到 UDS 刷写，但 OTA 客户端要编排多个 ECU：
单 ECU 刷写（见诊断篇）：
0x10 0x02 → 0x27 解锁 → 0x31 擦除
→ 0x34/0x36/0x37 → 0x31 校验 → 0x11 复位
OTA 客户端编排：
1. 读目标 ECU 当前版本（0x22 F189/F18C）
2. 比对目标版本，决定刷写列表
3. 按依赖顺序刷写（网关 → 域控 → 子 ECU）
4. 每个 ECU：
进入编程会话、安全解锁、刷写、校验、复位
5. 全部成功后做整车验证
6. 任一失败 → 中止并回滚已刷的 ECU
传输通道：
DoIP（以太网）：域控与网关
DoCAN（CAN FD）：子 ECU（通过网关路由）
网关做诊断路由（DoIP ↔ DoCAN）
并发与串行：
独立 ECU 可并发刷写（提速度）
有依赖的必须串行
注意总线带宽（并发过多会拥塞）
耗时估算：
100 MB 固件，DoIP 1 Gbps：
理论 0.8 s，实际含擦除/校验约 30~60 s
DoCAN 2 Mbps：
100 MB 需约 400 s（7 分钟）
→ 大固件必须走 DoIP
6. 签名与验证链
签名是 OTA 安全的根基，防止恶意固件：
签名（云端）：
1. 计算升级包哈希（SHA-256）
2. 用私钥签名哈希（RSA-2048 / ECDSA P-256）
3. 签名随包分发
私钥存于 HSM，严格管控
验签（车端）：
1. 用公钥验签（公钥固化在 Bootloader/安全区）
2. 比对哈希，确认包未被篡改
3. 通过才允许刷写
验证链（信任根）：
BootROM（不可改，信任根）
→ 验签 Bootloader
→ 验签 Kernel
→ 验签 RootFS/App
→ 验签 OTA 包
每一级验证下一级，形成信任链
安全启动（Secure Boot）：
上电时逐级验签，失败则拒绝启动
防止运行未授权代码
与 OTA 验签配合：OTA 包必须能过安全启动
密钥管理：
公钥固化（不可改）
支持密钥轮换（预留多个公钥槽）
私钥泄露 → 灾难（可刷任意固件）
硬件安全：
HSM（硬件安全模块）存密钥、做验签
TEE（可信执行环境）隔离
防回滚（Anti-rollback）：拒绝旧版本（有漏洞的版本）
防回滚是容易被忽略的点：攻击者可能刷入「有已知漏洞的旧版本」，所以 Bootloader 要记录最低允许版本。
7. 依赖编排与车辆状态
OTA 不是「下载就装」，要满足前置条件：
前置条件（Preconditions）：
1. 车辆状态：必须驻车（P 档）、手刹拉起
2. 电量：> 30%（防止刷写中亏电）
3. 网络：稳定连接（下载阶段）
4. 无故障：关键 ECU 无未处理故障
5. 用户确认：弹窗告知，用户同意
6. 时间窗：预约安装（夜间）
依赖编排：
升级包有依赖图：
包 A 依赖包 B 的 ≥ 2.0 版本
包 C 必须在包 D 之后
拓扑排序决定刷写顺序
版本兼容矩阵：
云端维护车型 × 版本的兼容矩阵
避免不兼容组合
灰度发布：
先小批量（1%）→ 观察 → 逐步放量
异常则暂停推送
A/B 测试不同版本
车辆状态机：
Idle → Downloading → Ready → Installing → Verifying → Done
安装中车辆不可用（或限制使用）
失败 → RollingBack → Failed
8. 失败恢复与看门狗
OTA 的可靠性靠多层兜底：
失败场景与恢复：
1. 下载中断 → 断点续传（记录已下载偏移）
2. 验签失败 → 丢弃重下
3. 刷写中断（断电/断网）→ 重试或回滚
4. 新版本启动失败 → 看门狗复位 → 回滚
5. 应用崩溃 → 重启应用 → 多次失败 → 回滚
看门狗配合：
新版本启动后必须在一定时间内「喂狗」
未喂狗 → 硬件看门狗复位 → 回到旧分区
这是「新版本挂死也能回滚」的关键
启动成功标志：
新版本启动后自检通过 → 写「成功」标志
下次启动不再回滚
未写标志 + 尝试次数超限 → 回滚
掉电安全：
元数据原子写（先写副本再切换指针）
刷写过程掉电 → 分区不完整 → 启动时校验失败 → 回滚
兜底通道：
Bootloader 独立且不可被 OTA 覆盖
最坏情况通过有线（OBD/以太网）恢复
售后救援最后防线
9. 安全合规 UN R156 与 R155
OTA 是法规监管的重点：
UN R156（Software Update Management System，SUMS）：
对象：软件更新管理体系
要求：
1. 建立软件更新管理体系（流程、责任）
2. 记录车辆软件版本（RXSWIN）
3. 证明更新的安全性（不影响车辆安全）
4. 告知用户更新内容与影响
5. 更新失败的可恢复性
时间：2022 年 7 月对新车型强制
RXSWIN（Software Identification Number）：
记录每辆车的软件版本标识
更新后必须更新 RXSWIN
用于追溯与召回
UN R155（Cybersecurity Management System，CSMS）：
对象：网络安全
与 OTA 的交集：
OTA 通道是攻击面，必须加密与认证
升级包必须签名
防止中间人攻击
建立漏洞响应流程（VDP）
其他：
ISO 24089：道路车辆软件更新工程（与 R156 配套）
ISO/SAE 21434：网络安全工程（与 R155 配套）
合规落地：
建立 OTA 平台（云端）
建立版本管理与追溯系统
建立安全事件响应流程
第三方审计与认证
权衡取舍
| 决策点 | 选项 A | 选项 B | 建议 |
|---|---|---|---|
| 分区 | A/B | 单分区 | 支持 OTA 的必须 A/B，可回滚 |
| 升级包 | 整包 | 差分 | 小版本差分，大版本整包 |
| 下载时机 | 即时 | 预约 | 后台下载，用户预约安装 |
| 传输 | DoIP | DoCAN | 大固件 DoIP，子 ECU DoCAN |
| 发布 | 全量 | 灰度 | 灰度发布，异常可暂停 |
| 回滚 | 自动 | 手动 | 自动回滚 + 尝试次数限制 |
| 密钥 | 软件存储 | HSM | 安全关键用 HSM |
常见坑清单
- 无 A/B 分区：一次失败刷写即变砖，OTA 车型必须 A/B。
- 验签可绕过：签名校验被跳过，攻击者可刷恶意固件，必须硬校验。
- 防回滚缺失：可刷入有漏洞的旧版本，需记录最低允许版本。
- 前置条件不严：电量不足时刷写导致中途断电，必须检查电量与档位。
- 下载与安装耦合：下载中车辆不可用，应分离下载与安装。
- 断点续传缺失：弱网环境反复重下，浪费流量，需记录偏移。
- 看门狗未配合：新版本挂死无法回滚，必须新版本启动喂狗。
- 元数据非原子写：掉电损坏元数据导致无法判断活动分区。
- 依赖未编排：底层未升级就刷上层，版本不兼容，需拓扑排序。
- 无灰度：全量推送带 bug 的版本，导致大规模召回，需灰度。
小结
车载 OTA 的核心是「不可失败的可靠性」：A/B 分区保证可回滚，签名验签保证不可篡改，看门狗保证挂死可恢复，前置条件保证刷写不被打断，依赖编排保证多 ECU 协调。它把「刷写」这件危险的事，变成用户可接受的「点一下」。
实践路径：先理解 A/B 分区与回滚，再学签名验签与信任链，然后做多 ECU 依赖编排，最后对接云端与合规。刷写的底层协议见 诊断协议 UDS 与 OBD ；传输通道见 CAN FD 与车载以太网 ；Adaptive 侧的应用级更新见 AUTOSAR Adaptive 与面向服务架构 。
OTA 与功能安全的交叉见 功能安全 ISO 26262 工程实践 ；通用物联网固件的升级机制可对比物联网固件 OTA 升级一章。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。