第2章：OTA系统架构设计：云端架构、车端架构、通信协议选型（MQTT/HTTP）

好，咱们进入正题。上一章聊了OTA升级的基本概念，这一章咱们要动真格的了——把整个OTA系统的骨架搭起来。说白了，就是搞清楚升级指令从云端怎么发到车端，车端又怎么接住、怎么执行。

我个人习惯把OTA架构拆成三块来看：云端、车端、还有连接它们的通信管道。这三块缺一不可，哪块出问题，升级就翻车。

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

云端是整个OTA系统的中枢。它不光是存固件的地方，更是一个调度中心。我在项目中遇到过最头疼的事，就是云端架构设计得太“重”，结果百万级车辆同时请求升级时，服务器直接挂了。嗯，那场面，真是惨不忍睹。

一个成熟的OTA云端架构，通常包含这几个核心模块：

  • 用户管理模块：管理车辆账号、权限、升级策略。说白了，就是决定“哪辆车能升，哪辆车不能升”。
  • 固件管理模块：存储固件包、版本号、校验哈希。这里要注意，固件包一定要做增量差分，不然车机那点存储空间根本扛不住。
  • 升级任务调度模块：这是最核心的。它负责把升级任务下发给指定车辆，还要考虑并发、重试、回滚策略。
  • 日志与监控模块：记录每辆车的升级状态、失败原因。我建议你从一开始就把日志设计好，不然后期排查问题就像大海捞针。

核心要点：云端架构要支持水平扩展。别想着单机扛所有，微服务化是必须的。我见过不少团队一开始图省事，用单体应用，结果车卖到10万辆就撑不住了，最后重构成本高得吓人。

2.2 车端架构：执行者与守门员

车端架构，说白了就是车上的软件怎么接住云端发来的升级包，然后安全地刷进去。车端不像手机，手机升级失败了最多变砖，车要是升级失败，那可是要出安全问题的。

车端OTA架构通常分三层：

  1. 通信层：负责与云端建立连接，接收升级指令和固件包。这一层通常跑在T-Box或车机通信模组上。
  2. 升级管理服务层：这是车端的“大脑”。它负责校验固件完整性、检查车辆状态（比如电量、车速、档位）、协调各ECU的升级顺序。
  3. 执行层：真正刷写固件的模块。每个ECU都有自己的刷写协议，升级管理服务层需要调用对应的刷写接口。

我的经验：车端一定要做“双区备份”。什么意思？就是保留一个可启动的旧版本固件，万一新固件刷失败了，还能回滚到旧版本。我曾经在一个项目中没做这个，结果升级到一半断电了，车直接变砖，最后只能拖回4S店用诊断仪刷写。那叫一个狼狈。

2.3 通信协议选型：MQTT vs HTTP

好，到了大家最纠结的部分了。云端和车端之间用什么协议通信？MQTT还是HTTP？

我先说结论：控制指令用MQTT，固件下载用HTTP。为什么？听我慢慢道来。

2.3.1 MQTT：轻量级、双向、实时

MQTT是发布/订阅模式，说白了就是云端发布一个主题，车端订阅这个主题。云端一发消息，车端立马就能收到。这种模式特别适合控制指令的传输，比如“开始升级”、“暂停升级”、“查询状态”。

MQTT的优点很明显：

  • 实时性高：消息推送几乎是毫秒级的。
  • 双向通信：车端也能主动发消息给云端，比如上报升级进度。
  • 轻量级：协议头很小，适合车机这种资源受限的环境。
  • 支持QoS：可以保证消息不丢失。我建议控制指令用QoS 1，至少送达一次。

注意：MQTT的QoS 2虽然能保证消息只送达一次，但开销很大，车端处理起来有压力。除非是极其关键的指令（比如安全相关的回滚指令），否则别用QoS 2。

2.3.2 HTTP：大文件传输的王者

固件包动辄几百MB，甚至上GB。用MQTT传这么大的文件？别闹了，MQTT的Payload有限制，而且传输大文件会阻塞其他消息。

HTTP的优势在于：

  • 支持断点续传：车端下载到一半断网了，恢复后可以接着下，不用从头再来。
  • 支持分块下载：可以把固件包切成多个小块并行下载，速度更快。
  • 成熟度高：各种CDN、负载均衡、缓存策略都很成熟。

我个人习惯的做法是：云端先通过MQTT下发一个“升级通知”，里面包含固件包的下载URL和校验值。车端收到后，再用HTTP去下载固件包。下载完成后，车端通过MQTT上报“下载完成”状态，云端再下发“开始刷写”指令。

2.3.3 协议对比表

特性 MQTT HTTP
通信模式 发布/订阅（双向） 请求/响应（单向）
实时性 高（毫秒级） 低（依赖轮询）
协议开销 小（2字节最小头） 大（请求头几百字节）
大文件传输 不适用 适用（支持断点续传）
适用场景 控制指令、状态上报 固件包下载

2.4 通信流程示例

光说不练假把式。我画一个典型的OTA升级通信流程，你感受一下：

1. 云端通过MQTT下发升级通知（包含固件URL、版本号、校验值）
2. 车端收到通知，检查车辆状态（电量>50%、车速=0、档位=P）
3. 车端通过HTTP下载固件包（支持断点续传）
4. 车端校验固件完整性（SHA256比对）
5. 车端通过MQTT上报“下载完成”
6. 云端通过MQTT下发“开始刷写”指令
7. 车端执行刷写，并实时上报进度（MQTT）
8. 刷写完成，车端重启，通过MQTT上报“升级成功”
9. 云端记录升级日志

避坑指南：我曾经在一个项目中，车端下载完固件后没有做完整性校验，结果刷进去一个损坏的固件包，导致ECU变砖。从那以后，我要求所有项目必须做双重校验：下载完成后校验一次，刷写前再校验一次。别嫌麻烦，安全第一。

2.5 小结

这一章咱们把OTA系统的三大块——云端、车端、通信协议——都捋了一遍。你想想看，其实核心就一句话：MQTT管控制，HTTP管下载，两者配合才能打好配合。

下一章，咱们要深入车端，聊聊升级包怎么在ECU之间安全地刷写。嗯，那才是真正考验架构设计能力的地方。

← 上一章 📖 返回目录 下一章 →