2、系统架构设计：OTA升级的端云架构、车端核心模块
好，我们直接进入正题。OTA升级这件事，说白了就是「云上发指令，车上干活」。但车不是手机，你想想看，手机死机了重启就行，车要是升级到一半趴窝了，那可是安全大事。所以架构设计的第一原则就是：云要稳，端要牢，中间链路不能断。
2.1 端云架构：谁负责什么？
我个人习惯把OTA端云架构分成三层：
- 云端平台：负责包管理、策略下发、状态监控。
- 车端主控：负责下载、校验、调度、回滚。
- 目标控制器：真正执行刷写的ECU。
这里有个容易踩的坑——很多人以为云端直接控制刷写。其实不是。云端只负责「告诉车该升级了」，具体怎么升、升哪个、失败了怎么办，全是车端自己决定。我在项目中遇到过某厂商把刷写逻辑写在云端，结果网络一抖，车端收到半截指令就开刷，直接刷成砖。嗯，从那以后我坚持：车端必须有完整的本地决策能力。
核心原则：云端是「建议者」，车端是「执行者」。
2.2 车端核心模块之一：OTA Manager
OTA Manager 是整个升级流程的「大脑」。它不直接刷写，它管的是流程。
它的职责很清晰：
- 接收云端推送的升级任务
- 检查车辆状态（车速、电量、挡位、故障码）
- 决定「现在能不能升」
- 调度 Update Agent 干活
- 监控升级进度，上报结果
我建议把 OTA Manager 设计成一个状态机。为什么？因为升级流程太长了，下载、校验、准备、刷写、重启、验证，每一步都可能失败。状态机能让逻辑清晰，也方便做断点续传。
// 伪代码：OTA Manager 状态机示例
enum OtaState {
IDLE,
DOWNLOADING,
VERIFYING,
PREPARING,
UPDATING,
REBOOTING,
VERIFY_AFTER_REBOOT,
ROLLBACK,
COMPLETED,
FAILED
};
你看，每个状态都对应一个明确的动作。如果升级到一半掉电了，重启后根据持久化状态，该重下重下，该重验重验。说白了，状态机是OTA可靠性的第一道防线。
避坑指南：我曾经见过一个项目，OTA Manager 用全局变量存状态。掉电后全丢了，车永远不知道升到哪一步了。后来我强制要求：状态必须写进非易失存储，而且每次状态切换都要写。
2.3 车端核心模块之二：Update Agent
Update Agent 是「干活的」。OTA Manager 说「开始刷」，它就撸起袖子干。
它的核心能力包括：
- 差分还原：从云端下载的是差分包，它要还原出完整镜像
- 镜像校验：还原后做哈希校验，确保包没被篡改
- 刷写执行：通过UDS、DoIP或私有协议把数据写到目标ECU
- 进度反馈：实时告诉OTA Manager刷到百分之几了
这里有个技术细节：Update Agent 通常运行在网关或域控制器上，它和目标ECU之间是网络通信。你想想看，如果刷写过程中网络断了怎么办？我建议做块级确认——每发完一块数据，等ECU确认收到再发下一块。虽然慢一点，但可靠。
注意：Update Agent 必须支持「刷写超时重试」。我遇到过某ECU刷到一半卡住了，Agent 傻等30分钟没反应。后来加了超时机制，3次重试失败后直接上报给OTA Manager，触发回滚。
2.4 车端核心模块之三：Rollback Manager
Rollback Manager 是「最后的保险」。说实话，这个模块最容易被忽略，但出事时它最救命。
它的职责很简单：
- 升级前备份当前版本镜像
- 升级失败时恢复备份
- 管理回滚版本号，防止重复回滚
我个人的设计习惯是：Rollback Manager 必须独立于 OTA Manager 运行。为什么？因为如果 OTA Manager 自己挂了，Rollback Manager 还能救场。它俩应该跑在不同的进程里，甚至不同的核上。
回滚策略一般分两种：
| 策略 | 说明 | 适用场景 |
|---|---|---|
| 全量回滚 | 把整个ECU刷回旧版本 | 刷写失败、启动失败 |
| 增量回滚 | 只恢复被修改的分区 | 部分升级失败、兼容性问题 |
嗯，这里要注意：回滚不是万能的。如果新版本把Bootloader刷坏了，那连回滚程序都跑不起来。所以我的建议是：Bootloader 区域永远不要参与OTA升级，或者至少保留一个独立的「救急通道」。
一句话总结：OTA Manager 管流程，Update Agent 管刷写，Rollback Manager 管兜底。三个模块各司其职，缺一不可。
2.5 模块间的协作关系
这三个模块怎么配合？我给你画个简单的流程：
- OTA Manager 收到云端任务，检查车辆状态
- 通过后，通知 Update Agent 开始下载
- 下载完成，Update Agent 做校验，通过后通知 OTA Manager
- OTA Manager 决定「开始刷写」，Update Agent 执行
- 刷写成功，OTA Manager 做最终验证
- 如果第3步或第5步失败，OTA Manager 调用 Rollback Manager 回滚
你看，整个流程是串行的，但每个模块内部都是独立的。这样做的好处是：任何一个模块崩溃，都不会影响其他模块的恢复能力。
个人经验：我建议在模块之间加一个「心跳监控」。OTA Manager 定期问 Update Agent 和 Rollback Manager「你还活着吗？」如果连续3次没回应，就认为对方挂了，直接进入安全模式。这个机制救过我一回——有一次 Update Agent 内存泄漏挂了，OTA Manager 及时发现，没让升级继续下去。
好了，端云架构和车端核心模块就讲到这里。说白了，架构设计就是「把复杂的事情拆成简单的模块，再让它们可靠地协作」。下一节我们会聊升级包的差分算法和签名校验，那又是另一层深度了。