4、OTA升级核心流程：升级包生成、升级包分发、升级包下载、升级包校验、升级执行、回滚机制
各位工程师朋友，这一章咱们来聊聊OTA升级的完整流程。说实话，很多刚入行的朋友觉得OTA就是“发个包、刷个机”，其实远没那么简单。我在多个域控项目里摸爬滚打后，总结出六个核心环节：生成、分发、下载、校验、执行、回滚。缺一个，系统就可能翻车。
4.1 升级包生成——源头决定成败
升级包怎么来的？不是把固件压缩一下就完事。我个人习惯把生成过程拆成三步：
- 差异提取：对比新旧固件，只打包变化的部分。比如你只改了某个CAN信号的处理逻辑，没必要把整个100MB的镜像重传。
- 元数据封装：包含版本号、目标域控ID、校验哈希、签名信息。我见过一个项目，元数据里忘了写目标ECU的硬件版本，结果升级包刷到了不兼容的硬件上……嗯，那场面挺尴尬的。
- 压缩与加密：用LZMA或zstd压缩，再用AES-256加密。为什么加密？你想想看，升级包在公网传输，被中间人篡改了怎么办？
核心要点：升级包生成时，一定要包含“回滚区”的备份数据。我在项目中遇到过，升级执行到一半断电了，如果没有备份，域控直接变砖。
// 伪代码：升级包结构
typedef struct {
uint32_t magic; // 魔数 0xOTA1
uint32_t version; // 版本号
uint8_t target_domain; // 目标域控ID
uint8_t hw_compat; // 硬件兼容性掩码
uint32_t payload_len; // 有效载荷长度
uint8_t signature[64]; // ECDSA签名
uint8_t payload[]; // 压缩加密后的固件
} OtaPackage;
4.2 升级包分发——别让网络成为瓶颈
分发策略我建议用“分层推送”。说白了，就是云端先推给网关，网关再推给各个域控。为什么这么做？
- 避免广播风暴：如果云端同时给30个域控发数据，4G模块的带宽瞬间被打满。
- 支持断点续传：网关收到一半断了，可以接着上次的偏移量继续下载。我曾经在高速公路上测试，信号时断时续，没有断点续传的话，一个50MB的包得重传七八次。
分发时还要考虑优先级。比如ADAS域控的升级包优先级最高，因为涉及安全；而娱乐域控的包可以慢慢传。你想想看，如果娱乐域控下载占满了带宽，导致ADAS升级超时，那可就危险了。
4.3 升级包下载——多线程与校验并行
下载阶段，我习惯用“分块下载+边下边验”的策略。具体来说：
- 把升级包切成1MB的块。
- 每个块下载完成后，立即计算SHA256。
- 如果校验失败，只重传这个块，而不是整个包。
小技巧：下载进度不要只显示百分比。我在项目里加了一个“当前块号/总块数”的显示，调试时一眼就能看出卡在哪个块上。
另外，下载路径要支持“主备切换”。如果主服务器挂了，自动切到备用CDN。嗯，这里要注意：切换时不要中断当前正在下载的块，否则用户会看到进度条往回跳。
4.4 升级包校验——三道防线
校验不是只做一次。我设计了三道防线：
| 防线 | 校验内容 | 失败处理 |
|---|---|---|
| 第一道 | 包完整性（CRC32） | 丢弃，重新下载 |
| 第二道 | 签名验证（ECDSA） | 记录日志，停止升级 |
| 第三道 | 版本兼容性检查 | 回滚到旧版本 |
我曾经遇到过一个案例：签名验证通过了，但版本兼容性检查失败——因为新固件依赖的某个底层驱动版本不对。从那以后，我坚持在第三道防线里加上“依赖链校验”。
4.5 升级执行——原子操作与看门狗
执行阶段是最容易出问题的。我的原则是：要么全做，要么全不做。
- 双分区策略：A分区运行旧固件，B分区写入新固件。写入完成后，切换启动标志。这样即使写入过程中断电，重启后还是从A分区启动。
- 看门狗喂狗：每写入一个扇区就喂一次狗。如果写入卡死，看门狗超时复位，系统自动回滚。
- 进度上报：每10%上报一次进度到网关。我建议用状态机来管理：IDLE -> DOWNLOADING -> VERIFYING -> UPDATING -> REBOOTING -> COMPLETED。
警告：升级执行期间，严禁切断域控的供电。我在实验室测试时，用程控电源模拟了100次随机断电，结果有3次双分区都损坏了。后来加了“备份分区写保护”才解决。
4.6 回滚机制——最后的救命稻草
回滚不是简单的“把旧固件写回去”。我把它分成三种场景：
- 自动回滚：升级后第一次启动，如果域控在30秒内没有上报“升级成功”的心跳，网关自动触发回滚。
- 手动回滚：用户通过诊断仪发送回滚指令。注意，回滚指令需要二次确认，防止误操作。
- 安全回滚：如果新固件有安全漏洞，云端强制所有域控回滚到上一个安全版本。
回滚时，要保留“回滚日志”。我习惯把日志写到独立的Flash区域，内容包括：回滚原因、旧版本号、新版本号、回滚耗时。这样后续分析问题时，有据可查。
避坑指南：我曾经在回滚时忘记恢复“用户配置参数”。比如用户之前设置的座椅记忆、音效均衡器，回滚后全丢了。后来我强制要求：回滚前必须备份用户参数区，回滚完成后恢复。
好了，这六个环节环环相扣。生成时考虑回滚，分发时考虑断点，下载时考虑校验，执行时考虑原子性，回滚时考虑数据完整性。你想想看，任何一个环节出问题，整个OTA系统就不可靠了。下一章咱们聊聊多域控协同升级时的时序问题，那个更刺激。