第二章 OTA系统架构解析：云端、车端与通信链路
好，咱们进入第二章。这一章我打算把OTA系统的骨架给你拆开看看。说白了，就是搞明白升级包从哪来、怎么传、到车端后怎么执行。我个人习惯把OTA架构分成三块：云端、车端、还有中间那条通信链路。这三块但凡有一块掉链子，升级就大概率翻车。
2.1 云端架构：升级包管理与策略分发
云端是整个OTA的大脑。你想想看，几十万辆车，每辆车的硬件版本、软件基线都不一样，云端得管得明明白白。
2.1.1 升级包管理
升级包管理，核心就三件事：打包、存储、版本控制。
- 差分包生成：我见过不少团队直接推全量包，一个包几个G，车机下载到一半断网了，又得重来。后来我们改用差分算法（bsdiff、xdelta），只传变化的部分。嗯，这里要注意：差分包的还原算法必须在车端预置好，否则车端解不出来就尴尬了。
- 包签名与校验：每个升级包必须带数字签名。我在项目中遇到过有人试图篡改升级包，幸好签名校验拦住了。签名算法推荐RSA-2048或ECDSA，哈希用SHA-256。
- 版本依赖树：不是所有版本都能直接升到最新版。比如从A版本到C版本，中间必须经过B版本。这个依赖关系，云端得维护清楚。
核心要点：升级包管理不只是存文件，更是管理版本间的「可达路径」。
2.1.2 策略分发
策略分发，说白了就是「让哪批车、在什么时间、用什么方式升级」。
我常用的策略维度有这些：
| 策略维度 | 说明 | 我踩过的坑 |
|---|---|---|
| VIN范围 | 按车辆识别码分批 | 曾经没考虑产线批次差异，导致同一VIN段的车硬件不一致，升级后黑屏 |
| 地理区域 | 按国家/省份分批 | 某次在高原地区推送升级，电池管理参数没适配，差点出问题 |
| 时间窗口 | 凌晨2-4点静默升级 | 用户没关车机，升级到一半电瓶亏电了…后来加了电量阈值检查 |
| 灰度比例 | 先1%再10%再全量 | 灰度比例太小，问题暴露太慢；比例太大，风险又高。我一般从5%起步 |
我的习惯：策略分发一定要支持「一键回滚」。有一次灰度推送后发现了严重bug，我直接触发回滚策略，5分钟内所有已升级车辆都收到了回滚指令。这个能力，必须在架构设计阶段就做进去。
2.2 车端架构：OTA Manager 与 Update Agent
车端是执行升级的「手和脚」。我习惯把车端软件拆成两个模块：OTA Manager 和 Update Agent。
2.2.1 OTA Manager
OTA Manager 是车端的「大脑」，负责跟云端通信、管理升级状态、协调整车资源。
它的核心职责：
- 接收策略：从云端拉取升级任务，判断当前车辆是否满足条件（电量>70%、车速=0、挡位在P档等）
- 状态管理：维护升级状态机——空闲、下载中、校验中、安装中、回滚中、完成。每个状态都要能持久化，防止掉电后状态丢失。
- 人机交互：什么时候弹窗提醒用户？什么时候静默升级？我建议：涉及功能安全的升级（如制动系统），必须用户确认；娱乐系统升级，可以静默。
注意：OTA Manager 绝对不能单点故障。我曾经遇到过 Manager 进程崩溃，导致升级状态卡在「安装中」，车辆无法启动。后来我们加了看门狗和双备份机制。
2.2.2 Update Agent
Update Agent 是干活的「手」。它只管一件事：执行升级脚本。
Agent 的设计原则：
- 原子性：要么全升成功，要么全回滚。不能出现一半升了一半没升的情况。
- 幂等性：同一个升级包，执行两次结果一样。防止重复执行导致系统错乱。
- 失败回滚：每个升级步骤都要有对应的回滚步骤。我习惯用「升级脚本 + 回滚脚本」成对编写。
举个简单的升级脚本示例：
// 伪代码：升级MCU固件
step1: 检查当前版本 == 1.0
step2: 备份当前固件到备份分区
step3: 写入新固件到主分区
step4: 校验新固件哈希
step5: 重启MCU
step6: 检查新版本 == 2.0
// 回滚脚本
rollback_step1: 从备份分区恢复固件
rollback_step2: 重启MCU
rollback_step3: 检查版本 == 1.0
你看，每个正向步骤都有对应的反向步骤。这就是原子性的保证。
2.3 通信链路：HTTPS 与 MQTT
通信链路是OTA的「血管」。选错协议，升级体验会非常糟糕。
2.3.1 HTTPS：下载升级包
HTTPS 用于下载升级包。为什么选它？
- 断点续传：下载到一半断网了，下次从断点继续。这个功能在车联网环境下太重要了。
- 加密传输：TLS 1.2/1.3 保证升级包不被窃听或篡改。
- CDN加速：大文件分发必须用CDN，否则云端带宽扛不住。
我建议的下载策略：
- 分片下载，每片1MB，并行4-8个连接
- 每片下载完成后校验哈希
- 整体下载完成后，再校验一次完整包哈希
避坑指南：我曾经遇到过某运营商的网络对HTTPS的443端口做了限速，下载速度只有10KB/s。后来我们加了「下载速度监控」，如果低于阈值，自动切换到备用域名或备用端口。
2.3.2 MQTT：控制信令
MQTT 用于传输控制信令。比如云端下发「开始升级」指令、车端上报「升级进度」。
MQTT 的优势：
- 轻量级：报文头只有2字节，适合车机这种资源受限的环境
- QoS分级：关键指令用QoS 1（至少一次），进度上报用QoS 0（最多一次）
- 持久会话：车辆断网重连后，能收到离线期间下发的指令
我常用的Topic设计：
车辆上行：
vehicle/{vin}/status - 上报车辆状态（电量、版本等）
vehicle/{vin}/progress - 上报升级进度（百分比）
云端下行：
cloud/{vin}/command - 下发升级指令
cloud/{vin}/cancel - 取消升级
嗯，这里要注意：Topic 中不要包含敏感信息，VIN虽然是唯一标识，但建议做哈希处理后再放到Topic里。
小结
这一章我们聊了OTA的三层架构：
- 云端：管好升级包和分发策略，灰度发布是保命符
- 车端：Manager 管状态，Agent 管执行，原子性是底线
- 链路：HTTPS 下大包，MQTT 传指令，各司其职
下一章，我会带你看看具体的测试用例怎么设计。说白了，架构搞清楚了，测试用例就是顺着架构一层层往下挖。咱们第三章见。