2. OTA系统架构设计：云端架构、车端/设备端架构、通信链路设计

OTA升级，说白了就是给设备“打补丁”或者“换系统”。但这事儿放在车上，可不像手机升级那么简单。你想想看，手机升级失败最多变砖，车要是变砖了，那可是人命关天。

所以，架构设计是OTA的根基。我见过不少团队，一上来就写代码，结果做到一半发现云端和车端对不上，通信链路也不稳定，最后推倒重来。嗯，咱们今天就把这事儿聊透。

2.1 云端架构：大脑与指挥中心

云端是整个OTA系统的“大脑”。它不光是存个升级包，还得管版本、管设备、管策略、管安全。我个人习惯把云端拆成四个核心模块：

2.2 车端/设备端架构：执行者与守护者

车端架构，我把它叫做“双区备份 + 最小系统”。为什么？因为升级过程中一旦断电或通信中断，车必须还能动。

车端核心组件包括：

• OTA Client：负责与云端通信，下载升级包，校验完整性。
• 更新管理器：负责解析升级策略，协调各ECU的升级顺序。
• 备份恢复模块：管理A/B分区，失败时自动回滚。
• 安全模块：验签、解密、防回滚保护。

这里有个关键设计——A/B分区切换。说白了就是系统有两套分区，一套在跑，一套待升级。升级时写备用分区，写完后切换启动。如果切换失败，还能切回老分区。

2.3 通信链路设计：可靠与安全的桥梁

通信链路是连接云端和车端的“血管”。设计不好，升级包下到一半断了，或者被中间人篡改了，后果很严重。

我一般把通信链路分成三段：

1. 云端到T-Box：走HTTPS或MQTT over TLS，保证传输加密。大文件用断点续传，我建议用HTTP/2，支持多路复用。
2. T-Box到网关：车内以太网或CAN FD。这里要注意带宽限制，CAN FD一次只能传几十字节，大包要分包重组。
3. 网关到ECU：CAN、LIN或FlexRay。每个ECU的升级协议不同，网关要做协议转换。

2.4 整体架构图

下面这张图，是我在项目里常用的OTA系统架构。它把云端、车端和通信链路串在了一起。

2.5 关键设计决策

架构搭完了，但有几个决策点，我建议你提前想清楚：

• 差分 vs 全量：差分包小，但生成和还原都耗算力。全量包大，但简单可靠。我一般建议：大版本升级用全量，小补丁用差分。
• 同步 vs 异步：同步升级简单，但用户体验差。异步升级可以后台下载，但要做好状态同步。我个人倾向异步+用户确认。
• 单区 vs 双区：单区成本低，但风险高。双区安全，但占用存储。功能安全要求高的ECU，必须双区。