2. OTA系统架构
OTA升级，说白了就是一场「云端指挥、车端执行」的协同作战。我做了这么多年OTA，最深的体会是：架构设计没想清楚，后面全是坑。今天咱们就把这套架构掰开揉碎了讲。
2.1 云端架构：大脑与指挥中心
云端是整个OTA系统的中枢。它不直接跟车打交道，但所有升级策略、包管理、状态监控都在这里完成。
2.1.1 升级包管理
升级包管理听起来简单，不就是存个文件吗？其实远不止这些。
| 模块 | 职责 | 我踩过的坑 |
|---|---|---|
| 包存储 | 差分包、全量包、增量包的版本化存储 | 曾经没做分片存储，一个5GB的全量包把对象存储搞崩了 |
| 包校验 | MD5/SHA256校验、签名验证 | 有一次签名算法没对齐，车端死活不认包 |
| 包分发 | CDN加速、断点续传、分片下载 | 弱网环境下不分片，下载成功率不到60% |
| 版本关联 | 维护ECU版本依赖树、兼容性矩阵 | 没做依赖检查，升级完网关发现域控不兼容 |
我个人习惯把升级包管理分成三层：原始包层（OEM上传的原始固件）、差分包层（基于bsdiff/hdiff生成的差分文件）、分发包层（按车型、区域、VIN打包后的分发单元）。这三层各自独立，但版本号必须严格对应。
核心原则：一个升级包 = 元数据 + 载荷。元数据里必须包含：包ID、版本号、目标ECU列表、依赖版本、签名、校验和。载荷就是实际的二进制数据。缺任何一项，车端都会拒收。
2.1.2 策略下发
策略下发是云端最考验设计能力的地方。你想想看，几十万辆车同时请求升级，怎么保证不把服务器打爆？怎么保证升级顺序不乱？
我建议的策略下发流程是这样的：
- 灰度策略：先放1%的车，观察24小时，没问题再逐步放开。我曾经见过一次全量下发，结果某个ECU的兼容性问题导致5000辆车黑屏。
- 条件策略：车辆必须满足：电量>70%、车速=0、P档、信号强度>3格、无故障码。少一条都不给下发。
- 时间窗口：默认凌晨2:00-5:00执行，用户也可以手动预约。我习惯在策略里加一个「强制窗口」，用于安全召回场景。
- 分批下发：按VIN号段分批，每批间隔30分钟，避免CDN带宽被打满。
避坑指南：我曾经遇到过策略下发后，车端因为时区没对齐，凌晨2点没执行升级。后来我在策略里统一用UTC时间，车端再转成本地时间。嗯，这个细节很容易被忽略。
2.2 车端架构：执行者与守护者
车端架构是OTA落地的最后一公里。云端再牛，车端执行不了也是白搭。
2.2.1 OTA Client
OTA Client是车端的大脑，负责跟云端通信、管理升级任务、协调各个ECU。它通常跑在车机或T-BOX上。
Client的核心职责：
- 通信管理：跟云端保持心跳，接收升级指令，上报状态。我习惯用MQTT做指令通道，HTTPS做文件下载通道。
- 任务管理：维护升级任务队列，支持暂停、取消、重试。任务状态机必须严谨，我见过因为状态跳转不对导致重复升级的案例。
- 状态上报：每30秒上报一次进度，关键节点（下载完成、校验通过、升级开始、升级完成）必须立即上报。
- 异常处理：网络中断、电量不足、用户取消，这些场景都要有兜底逻辑。
警告：OTA Client绝对不能单点依赖。我建议Client本身要有看门狗机制，如果Client挂了，系统要能自动恢复并重新拉取任务。否则车就变成「升级孤儿」了。
2.2.2 Update Agent
Update Agent是真正的执行者。它直接跟ECU打交道，负责刷写固件、校验数据、回滚恢复。
Agent的设计要点：
| 能力 | 说明 | 我的经验 |
|---|---|---|
| 多ECU并行升级 | 同时支持网关、域控、座舱、T-BOX升级 | 并行数建议不超过3个，否则总线负载扛不住 |
| 断点续刷 | 刷写中断后从断点继续，不用重头来 | 这个功能救过我很多次，尤其是刷写大ECU时 |
| 双区备份 | A/B分区切换，升级失败自动回滚 | 没有双区备份的OTA，我建议直接不要上线 |
| 安全校验 | 刷写前校验签名，刷写后校验完整性 | 签名校验不过，直接拒绝执行，没商量 |
Agent跟Client之间怎么通信？我习惯用本地Socket或者DDS。Client下发任务，Agent执行并回传进度。两者之间要有心跳，如果Agent超过30秒没响应，Client要主动查询状态。
2.3 端云协同流程：从下发到完成
好了，云端和车端都讲完了，咱们看看它们怎么配合。我画了一张流程图，把整个端云协同的流程串起来。
整个流程我拆成五个关键步骤：
- 策略匹配：云端根据车辆VIN、当前版本、区域、用户标签，匹配出可用的升级策略。匹配成功后生成升级任务。
- 任务下发：云端通过MQTT把任务推送给车端OTA Client。任务里包含：包下载地址、校验信息、升级条件、执行时间窗口。
- 条件检查：Client收到任务后，先检查车辆状态是否满足条件。不满足就等待，满足就开始下载。
- 下载与校验：Client从CDN下载升级包，边下载边校验。下载完成后做完整校验，校验通过后交给Agent。
- 执行与上报：Agent执行刷写，每一步都上报进度。刷写完成后做最终校验，校验通过后激活新版本，然后上报完成状态给云端。
关键设计：整个流程中，云端和车端各自维护一个状态机。云端状态机：待下发 → 已下发 → 下载中 → 下载完成 → 升级中 → 升级完成 → 已确认。车端状态机：空闲 → 任务接收 → 条件检查 → 下载中 → 校验中 → 升级中 → 升级完成 → 上报完成。两个状态机必须严格对应，否则会出现状态不一致的问题。
2.4 端云协同的避坑指南
做了这么多年OTA，我总结了几条端云协同的避坑经验：
- 状态同步要有超时机制：车端上报状态后，云端如果在30秒内没收到确认，车端要重试。我曾经遇到过网络抖动导致状态丢失，车端以为升级成功了，云端以为失败了，两边对不上。
- 幂等性设计：同一个任务下发多次，车端不能重复执行。我习惯用任务ID+版本号做去重，车端收到任务先查本地有没有执行过。
- 离线升级能力：车端下载完包后，即使断网也能执行升级。升级完成后，等网络恢复再上报状态。这个能力在信号不好的地下车库特别重要。
- 云端要有兜底策略：如果车端超过24小时没上报状态，云端要主动发起查询。如果连续3次查询无响应，标记为「失联车辆」，走人工处理流程。
我的习惯：每次上线新版本前，我都会在云端模拟1000辆车的并发升级场景，看看策略下发、CDN带宽、车端任务队列能不能扛住。嗯，这个模拟测试救过我很多次，有一次发现策略引擎在并发2000时响应时间飙到了5秒，赶紧优化了数据库索引。
好了，云端架构、车端架构、端云协同流程，这三块是OTA系统的骨架。骨架搭好了，后面加功能、做优化才稳当。下一块咱们聊聊升级包是怎么生成的，差分算法又是怎么工作的。