3. OTA核心协议与标准：UDS协议基础、ISO 14229与OTA、SOTA协议、HTTPS与MQTT在OTA中的应用
好，咱们进入第三章。这一章聊的是OTA的“交通规则”——协议与标准。
你想想看，一辆车要升级，总得有个“说话”的方式吧？ECU听不懂HTTP，云端也不懂CAN报文。所以，我们需要一套大家都认的协议来搭桥。我个人习惯把OTA协议分成两类：车内通信协议和车云通信协议。今天咱们就把这两头都捋清楚。
3.1 UDS协议基础：诊断刷写的“老大哥”
UDS，全称Unified Diagnostic Services，统一诊断服务。很多刚入行的朋友觉得UDS就是用来读故障码的。其实，它也是OTA刷写的核心承载协议。
UDS定义在ISO 14229里。它规定了ECU怎么“听”、怎么“答”。比如，你要让ECU进入刷写模式，就得发一个特定的诊断请求。
核心概念：UDS基于“请求-响应”模型。客户端（通常是TBOX或诊断仪）发请求，服务端（ECU）给响应。
常用的UDS服务，跟OTA强相关的有这么几个：
- 0x10（诊断会话控制）：让ECU从普通模式切换到编程模式。我遇到过有些ECU在编程模式下会关掉CAN通信的某些功能，踩过坑。
- 0x27（安全访问）：刷写前必须“解锁”。说白了就是ECU问你“你谁啊？”，你得回答一个密钥。这个密钥算法各家不一样，有的用种子密钥，有的用PKI。
- 0x34（请求下载）：告诉ECU：“我要发数据了，你准备好接收，数据长度是xxx”。
- 0x36（传输数据）：真正传固件数据的服务。数据被切成一块一块的，通过0x36连续发送。
- 0x37（请求退出传输）：数据发完了，告诉ECU可以校验了。
- 0x31（例程控制）：刷完后，让ECU执行一些后处理，比如擦除旧数据、重启。
我的经验：UDS刷写最怕“超时”。ECU在接收0x36时，如果两帧之间的间隔太长，它会认为通信中断，直接退出刷写。所以，TBOX发送数据的节奏一定要稳，不能忽快忽慢。
3.2 ISO 14229与OTA：标准是怎么落地的？
ISO 14229定义了UDS的“语法”，但没规定“怎么传”。在车载以太网普及之前，UDS主要跑在CAN总线上。CAN的带宽只有500kbps，刷一个100MB的固件，理论上要半小时以上。这显然不现实。
所以，OTA场景下，UDS通常跑在DoIP（ISO 13400）上。DoIP就是“基于IP的诊断协议”。它把UDS报文封装在TCP/UDP包里，通过以太网传输。
关键点：DoIP的传输速率可以达到100Mbps甚至更高。我参与的一个项目，用DoIP刷写一个网关，从CAN的40分钟缩短到了以太网的3分钟。效果立竿见影。
ISO 14229-1里还定义了“诊断仪在线”和“ECU在线”的机制。OTA升级时，TBOX充当诊断仪，ECU是服务端。TBOX需要周期性地发送“0x3E（测试仪在线）”报文，告诉ECU：“我还活着，别退出刷写模式。”
避坑指南：我曾经遇到过一个ECU，它的0x3E超时时间设置得非常短，只有2秒。TBOX如果网络稍微卡顿一下，ECU就自动退出了。后来我们统一把超时时间改成了5秒，并让TBOX每1秒发一次0x3E，才彻底解决。
3.3 SOTA协议：专为OTA而生的“轻骑兵”
SOTA，全称Software Over-The-Air。它不是ISO标准，而是行业里一些头部Tier1和OEM共同推动的“事实标准”。
为什么需要SOTA？因为UDS太“重”了。UDS的每个请求都要等响应，而且CAN的报文结构固定，灵活性差。SOTA协议则更轻量，它直接定义了一套“下载-存储-激活”的流程。
SOTA协议的核心要素：
- 升级包描述文件：一个JSON或XML文件，里面写了“升级哪个ECU”、“固件版本号”、“校验值”、“依赖关系”等。
- 分块下载：支持断点续传。车端下载到一半，网络断了，下次可以从断点继续，不用重头来。
- 差分升级：只传输新旧版本之间的差异部分，而不是整个固件。我见过一个项目，差分后数据量减少了80%。
- 回滚机制：如果新版本激活失败，自动回退到旧版本。
我的建议：如果你的项目是从零开始做OTA，我建议直接参考SOTA协议的思想，而不是完全照搬UDS。UDS更适合诊断，SOTA更适合大规模升级。两者可以结合：用SOTA做下载管理，用UDS做刷写执行。
3.4 HTTPS与MQTT在OTA中的应用
车和云怎么通信？目前主流就两个：HTTPS和MQTT。
3.4.1 HTTPS：可靠但“重”
HTTPS就是HTTP + TLS。它最大的优点是可靠。每个请求都有响应，数据完整性有保障。OTA中，HTTPS通常用来做两件事：
- 下载固件包：大文件下载，HTTPS的断点续传（Range请求）非常成熟。
- 上报状态：车端升级完成后，通过HTTPS POST请求告诉云端“升级成功”或“失败”。
但HTTPS也有缺点：连接开销大。每次请求都要三次握手+TLS握手，对于频繁的小数据交互，效率不高。
3.4.2 MQTT：轻量但“活”
MQTT是发布/订阅模式。云端可以主动“推”消息给车端，车端也可以“订阅”某个主题。
在OTA中，MQTT的典型应用场景：
- 下发升级指令：云端发布一个“升级任务”到某个Topic，所有订阅了这个Topic的车都能收到。
- 心跳与状态同步：车端定期发布“在线状态”到云端。我习惯用MQTT的遗嘱消息（Last Will）来检测车辆是否离线。
- 小文件传输：比如升级策略、配置文件，用MQTT的QoS 1或QoS 2保证送达。
对比总结：
| 特性 | HTTPS | MQTT |
|---|---|---|
| 连接方式 | 请求-响应 | 发布-订阅 |
| 适用场景 | 大文件下载、状态上报 | 指令下发、心跳、小数据 |
| 实时性 | 低（需轮询） | 高（云端主动推） |
| 资源消耗 | 高（TLS握手） | 低（长连接） |
| 断点续传 | 原生支持 | 需应用层实现 |
避坑指南：我曾经在一个项目里，全部用MQTT来下载固件包。结果发现，当网络质量差时，MQTT的QoS 2重传机制会导致大量重复数据，反而比HTTPS还慢。后来我们改成了“MQTT下发指令 + HTTPS下载固件”的组合方案，问题才解决。
3.5 协议选型建议
说了这么多，到底怎么选？我个人的经验是：
- 车内通信：如果ECU支持DoIP，优先用UDS over DoIP。如果还是CAN，那就老老实实用UDS over CAN，但要做好分块和流控。
- 车云通信：大文件下载用HTTPS，指令和状态用MQTT。别想着一个协议打天下。
- 差分升级：建议在SOTA协议层面实现，不要依赖底层传输协议。
嗯，这一章的内容就到这里。协议是OTA的骨架，选对了，后面就顺了。下一章咱们聊聊升级包的制作和签名，那可是“血肉”部分。