2、OTA系统架构：云端架构与车端架构的协同设计
好，咱们进入第二章。这一章我打算聊聊OTA的系统架构。说白了，就是升级这件事，云端怎么管，车端怎么干，中间怎么传。
很多刚入行的朋友，一上来就盯着刷写流程看。其实架构设计才是地基。地基没打好，后面全是坑。我自己就吃过这个亏，后面会讲到。
2.1 云端架构：升级包管理与策略下发
云端是整个OTA的大脑。它不直接刷数据，但它决定什么时候刷、刷什么、刷给谁。
2.1.1 升级包管理
升级包管理，听起来简单，不就是存个文件吗？其实远不止这些。
我习惯把升级包管理拆成三个核心模块：
- 包存储：原始固件、差分补丁、元数据文件。存储方式要考虑CDN加速，尤其是全国范围推送时。
- 版本管理：每个ECU的当前版本、目标版本、兼容性矩阵。这块容易乱，我建议用语义化版本号，别自己发明规则。
- 包校验：MD5/SHA256签名。嗯，这里要注意，签名算法别用太弱的，曾经有项目因为MD5碰撞导致刷错包，还好发现得早。
核心要点：升级包管理不只是存储，更是版本追溯和审计的基础。每次升级都要能回滚，这是底线。
2.1.2 策略下发
策略下发，说白了就是云端告诉车端：你该升级了。但怎么告诉，什么时候告诉，这里面门道很多。
我见过两种主流策略：
- 主动推送：云端直接下发指令，车端被动接收。适合紧急安全更新。
- 拉取模式：车端定期询问云端，有没有新版本。适合常规功能升级。
我个人更倾向于混合模式。紧急更新用推送，常规更新用拉取。为什么？因为车端网络环境复杂，有时候推送了车端收不到，拉取反而更可靠。
经验之谈：策略下发时，一定要考虑“静默升级”和“用户确认”两种场景。我曾经在项目中，把所有升级都做成静默的，结果用户投诉说“车自己变了，我都没同意”。后来加了用户确认开关，投诉就少了。
2.2 车端架构：OTA Client与Update Agent
车端是执行层。云端下指令，车端干活。车端架构我习惯分成两层：OTA Client 和 Update Agent。
2.2.1 OTA Client
OTA Client 是车端的“通信员”。它负责和云端握手、下载包、校验完整性。
它的核心职责：
- 通信管理：与云端建立HTTPS连接，处理断点续传。车端网络不稳定，断点续传是刚需。
- 下载管理：分片下载、进度汇报、暂停恢复。我建议下载时做分片校验，别等整个包下完才发现坏了。
- 安全校验：验证云端签名，防止中间人攻击。这块不能省，曾经有团队因为没做签名校验，被黑客植入了恶意固件。
避坑指南：OTA Client 不能占用太多系统资源。我曾经见过一个Client，下载时把CPU吃满了，导致车机卡死。后来加了资源限制，才解决问题。
2.2.2 Update Agent
Update Agent 是车端的“执行者”。它负责真正的刷写操作。
它的核心职责：
- 刷写引擎：解析升级包，调用底层刷写接口。不同ECU的刷写协议不同，UDS、DoIP、XCP，都得支持。
- 状态管理：记录升级进度、失败原因、回滚状态。这块我建议用非易失性存储，防止掉电丢失。
- 回滚机制：如果升级失败，能自动回滚到上一个版本。这是安全底线，不能没有。
你想想看，如果Update Agent没有回滚能力，升级失败后车就变砖了。那用户得多崩溃？
2.3 通信链路设计
通信链路是连接云端和车端的桥梁。设计得好，升级又快又稳；设计得不好，各种断连、超时、失败。
我总结了几条关键设计原则：
| 设计要点 | 说明 | 我的建议 |
|---|---|---|
| 协议选择 | HTTPS还是MQTT？ | 大文件用HTTPS，控制指令用MQTT |
| 断点续传 | 支持从断点处继续下载 | 必须支持，车端网络太差 |
| 带宽控制 | 限制下载速度，避免占满带宽 | 建议动态调整，根据当前网络负载 |
| 安全加密 | TLS 1.2以上，证书双向认证 | 别用自签名证书，容易被攻击 |
核心要点：通信链路设计要兼顾可靠性和效率。可靠性靠断点续传和重试机制，效率靠分片下载和带宽控制。
我记得有一次，项目上线后发现升级成功率只有70%。查了半天，原来是通信链路没有做重试机制。网络一抖，下载就断了。后来加了三次重试，成功率直接升到98%。
嗯，这就是架构设计的重要性。一个小细节没考虑到，整个系统就崩了。
2.4 小结
这一章我们聊了OTA系统架构的三个核心部分：云端负责管理和策略，车端负责执行和回滚，通信链路负责连接和传输。三者缺一不可。
下一章，我会深入讲讲升级包的制作和差分算法。到时候我会分享一个我踩过的坑，关于差分补丁生成失败导致整车变砖的案例。敬请期待。