4. OTA升级的通信架构：基于DoIP的升级通信与UDS协议应用
好，咱们进入第四讲。这一章我打算聊聊OTA升级的通信架构。说白了，就是升级数据怎么从云端跑到ECU里去的。我个人习惯把通信架构比作一条高速公路——路修不好，车跑得再快也得堵死。
在AUTOSAR体系下，OTA升级的通信主要依赖两个东西：DoIP和UDS。DoIP负责把数据包从以太网送进来，UDS负责定义这些数据包的含义和交互流程。嗯，咱们一个一个拆开讲。
4.1 DoIP：升级数据的“高速公路”
DoIP，全称Diagnostics over IP。你想想看，传统的诊断通信用的是CAN总线，速率顶天了也就1Mbps。升级一个几百KB的固件，那得等多久？我在项目中遇到过，用CAN刷写一个2MB的MCU固件，整整花了40分钟。客户直接投诉说“这车升级比看病还慢”。
DoIP的出现就是为了解决这个问题。它把诊断数据封装到TCP/UDP包里，跑在以太网上。100Mbps甚至1Gbps的带宽，刷写时间直接降到分钟级甚至秒级。
核心要点：DoIP不是一个新的诊断协议，它只是UDS在以太网上的“运输工具”。UDS的请求/响应内容不变，变的只是底层的传输介质。
DoIP的协议栈分几层，我画了个图帮你理解：
你看，最上层还是UDS应用层，中间加了DoIP消息封装层。这一层负责把UDS的请求/响应打包成DoIP格式的报文。我记得刚开始接触DoIP时，总搞不清它和普通以太网通信的区别。后来想明白了——DoIP本质上是一个诊断隧道，它规定了车辆ECU如何被发现、如何建立连接、如何传输诊断数据。
4.2 DoIP的关键机制
DoIP有几个关键机制，我挑最重要的说：
- 车辆发现：通过UDP广播，Tester可以找到网络上有哪些DoIP节点。每个节点会回复自己的VIN码、逻辑地址等信息。
- 路由激活：建立TCP连接后，Tester发送路由激活请求，ECU确认后分配一个源地址。这一步相当于“握手”。
- 诊断消息传输：UDS请求/响应被封装在DoIP消息体中，通过TCP连接传输。支持大数据的拆分和重组。
避坑指南：我曾经在项目中遇到过一个问题——DoIP的TCP连接超时设置太短，导致大数据传输时频繁断连。后来我把超时时间从5秒改到了30秒，问题就解决了。记住，OTA升级的数据包往往很大，TCP参数要适当放宽。
4.3 UDS协议在OTA中的角色
UDS（Unified Diagnostic Services）是ISO 14229定义的一套诊断服务。在OTA升级中，UDS负责定义“怎么刷”、“刷哪里”、“刷完怎么验证”。
我列个表，把OTA升级中常用的UDS服务整理一下：
| UDS服务ID | 服务名称 | 在OTA中的作用 |
|---|---|---|
| 0x10 | 诊断会话控制 | 切换到编程会话模式，解锁ECU的刷写权限 |
| 0x27 | 安全访问 | 验证Tester身份，防止非法刷写 |
| 0x31 | 例程控制 | 触发擦除、校验、激活等例程 |
| 0x34 | 请求下载 | 告知ECU即将开始数据传输，协商数据块大小 |
| 0x36 | 传输数据 | 实际传输固件数据块，支持连续传输 |
| 0x37 | 请求退出传输 | 结束数据传输，ECU开始校验完整性 |
| 0x2E | 写入数据标识符 | 写入升级状态、版本号等元数据 |
| 0x22 | 读取数据标识符 | 读取当前版本号、升级状态等信息 |
你看，整个升级流程就是这些UDS服务的组合。我习惯把OTA升级的UDS交互流程总结为三个阶段：
- 准备阶段：0x10切换会话 → 0x27安全访问 → 0x31擦除例程
- 传输阶段：0x34请求下载 → 0x36传输数据（循环） → 0x37请求退出
- 验证阶段：0x31校验例程 → 0x2E写入版本 → 0x22读取确认
核心要点：UDS的0x36传输数据服务支持“连续帧”模式。也就是说，你可以一次性发送多个数据块，不需要每个块都等ECU的响应。这在OTA升级中能大幅提升传输效率。我建议把连续帧的窗口大小设为5-10个块，既保证效率，又不会因为丢包导致大量重传。
4.4 DoIP + UDS的典型升级流程
好，咱们把DoIP和UDS串起来，看看一个完整的OTA升级通信流程是什么样的：
这个流程看起来步骤多，但实际跑起来很快。我做过一个项目，用DoIP+UDS刷写一个8MB的固件，从开始到激活完成，总共只用了12秒。相比CAN的40分钟，简直是天壤之别。
注意事项：DoIP虽然快，但它对网络环境有要求。如果车载以太网的交换机配置不当，或者线束质量不好，很容易出现丢包和重传。我曾经在实车上遇到过，因为一个劣质的以太网连接器，导致升级成功率从99%掉到了70%。排查了整整两天才找到原因。所以，硬件质量一定要把好关。
4.5 通信架构设计的几个关键点
最后，我总结几个通信架构设计时容易忽略的点：
- 超时机制：UDS的每个服务都有超时时间。OTA升级中，擦除和校验操作耗时较长，建议把P2*Server（响应超时）设为5秒以上，避免误判为超时。
- 数据块大小：0x34请求下载时，ECU会返回它支持的最大数据块大小。我建议Tester根据这个值动态调整，不要硬编码。有的ECU支持4KB，有的只支持1KB，硬编码容易出问题。
- 错误处理：UDS的否定响应码（NRC）要仔细处理。比如0x78（请求正确接收，响应待定）表示ECU正在忙，Tester应该等待而不是立即重试。
- 安全校验：0x27安全访问的种子和密钥算法要足够复杂。我见过一些项目直接用固定密钥，结果被逆向工程破解了。至少要用AES-128级别的加密。
嗯，这一章的内容就到这里。通信架构是OTA升级的骨架，骨架搭好了，后面的升级策略、安全机制才能稳稳地往上放。你想想看，如果通信链路都不稳定，再好的升级算法也是白搭。
个人经验：我建议你在设计通信架构时，先做一轮“最坏情况分析”。比如，假设网络延迟100ms，丢包率5%，ECU处理速度最慢，看看整个升级流程能不能在客户要求的时限内完成。这个分析能帮你提前发现很多坑。
公众号:蓝海资料掘金营，微信deep3321