第1章：车端OTA Agent架构设计
大家好，我是老张。做车联网这些年，我踩过最多的坑，就是车端OTA Agent的设计。说白了，Agent就是车上的升级管家。它要管下载、管校验、管备份、管刷写，还得保证车不能变砖。
今天我就把这套架构设计思路，掰开了揉碎了讲给你听。
1.1 模块划分：别把鸡蛋放一个篮子里
我个人习惯把Agent拆成5个核心模块。为什么是5个？你想想看，升级这件事涉及通信、存储、安全、执行、监控，缺一个都不行。
| 模块名称 | 职责 | 我踩过的坑 |
|---|---|---|
| 通信模块 | 负责与云端MQTT/HTTP通信，接收指令、上报状态 | 曾经因为重连机制没做好，车在隧道里丢了升级包 |
| 存储管理模块 | 管理升级包下载、校验、分区映射 | 分区写满导致升级失败，后来加了空间预检 |
| 安全模块 | 验签、解密、证书管理 | 嗯，这个后面细说，坑最多 |
| 执行引擎 | 状态机调度、刷写流程编排 | 核心中的核心 |
| 监控与日志 | 异常捕获、断点续传、看门狗 | 没这个模块，出了问题只能去4S店读黑匣子 |
核心原则：模块间通过消息队列解耦。通信模块收到升级指令后，丢给执行引擎，执行引擎再调存储模块。谁也别直接调用谁，出了问题好排查。
1.2 状态机设计：升级就像开车，得看红绿灯
状态机是Agent的大脑。我见过很多团队把状态机画得跟蜘蛛网似的，其实没必要。核心状态就6个：
IDLE → DOWNLOADING → VERIFYING →
INSTALLING → COMMITTING → IDLE
↘ REVERTING ↗为什么会这样设计？
- IDLE（空闲）：啥也不干，等指令。这时候功耗最低
- DOWNLOADING（下载中）：从云端拉包。支持断点续传，我建议分片下载，每片1MB
- VERIFYING（校验中）：验签名、算哈希。这一步不能省，我曾经遇到过包被篡改的情况
- INSTALLING（安装中）：写分区。这时候车不能开，得锁车
- COMMITTING（提交）：重启后确认新版本能用。如果起不来，自动回滚
- REVERTING（回滚）：回到上一个稳定版本。保命用的
注意：状态切换必须幂等。也就是说，重复收到同一个状态指令，效果应该一样。我见过有人没做幂等，结果网络重传导致状态机乱跳。
1.3 升级流程编排：先做什么，后做什么
流程编排说白了就是定好顺序。我建议用「两阶段提交」的思路：
- 准备阶段：
- 检查电量（低于60%不升级）
- 检查网络（信号太差不下载）
- 检查存储空间（预留20%余量）
- 下载并校验升级包
- 执行阶段：
- 备份当前系统（A/B分区的话这步可省）
- 写入新系统
- 校验写入完整性
- 重启进入新系统
- 如果启动失败，自动切回备份
我的经验：每个步骤都要设超时。下载超时30分钟，安装超时5分钟，重启等待3分钟。超时了就进异常处理，别死等。
1.4 异常处理机制：别让车变砖
异常处理是OTA的底线。我总结了三层防护：
| 层级 | 异常类型 | 处理策略 |
|---|---|---|
| 第一层 | 网络中断、下载失败 | 重试3次，间隔指数退避。还不行就报错，等下次机会 |
| 第二层 | 校验失败、签名错误 | 立即停止，删除已下载的包，上报云端 |
| 第三层 | 刷写失败、启动失败 | 自动回滚到上一个版本。如果回滚也失败，进入救援模式 |
我记得有一次，某款车型在升级过程中突然断电。重启后Agent检测到升级未完成，自动触发了回滚。整个过程车主都没感觉到，只是启动慢了几秒。这就是三层防护的价值。
避坑指南：我曾经遇到过看门狗超时设置太短，导致正常升级被误判为死机。后来我把看门狗分成两段：升级期间用长超时（10秒），空闲时用短超时（3秒）。
1.5 小结
车端Agent设计，说白了就是三件事：模块划清楚、状态管明白、异常兜住底。你想想看，车在路上跑，升级出问题可不是闹着玩的。
下一章我会讲云端平台的设计，包括任务调度、包管理、策略下发这些。到时候咱们再聊。