第3章 DoIP协议基础

3、DoIP协议基础：诊断通信、路由激活、车辆发现

好，咱们进入DoIP的世界。

说实话，我第一次接触DoIP时，心里想的是：「这不就是把UDS诊断报文塞进以太网里吗？」后来踩了几个坑才发现——事情远没那么简单。DoIP不是简单的「换根网线」，它定义了一套完整的发现、激活、通信机制。

今天咱们就掰开揉碎，聊聊DoIP的三个核心模块：车辆发现、路由激活、诊断通信。这三个东西，说白了就是「找到车、连上车、跟车说话」。

3.1 车辆发现——怎么在网络上找到一辆车？

你想想看，一个诊断仪插到车载以太网上，它怎么知道网线上挂着几辆车？每辆车的IP地址是多少？

DoIP的解决方案是——广播+应答。

具体流程是这样的：

诊断仪发送一个车辆发现请求（Vehicle Announcement Request），广播到整个网段。
支持DoIP的ECU收到后，会回复一个车辆声明消息（Vehicle Announcement Message）。
这个声明消息里包含了：VIN码、逻辑地址、EID（实体ID）、GID（组ID）等信息。

嗯，这里要注意：车辆声明消息不是只回复一次。DoIP规范里规定，ECU上电后会主动发送三次声明，间隔时间分别是0ms、500ms、1000ms。我当年调试时，就因为这个「三次声明」的时序问题，跟测试团队扯了半天皮——他们以为只发一次就够了。

车辆声明消息的关键字段：

VIN：车辆识别码，17位，全球唯一。
Logical Address：逻辑地址，标识ECU在诊断体系中的身份。
EID：实体ID，通常是ECU的MAC地址或自定义ID。
GID：组ID，用于将多个ECU分组管理。
Further Action Required：标志位，告诉诊断仪「我还有后续动作，别急着断开」。

我个人习惯，在项目初期会先写一个简单的抓包脚本，验证车辆声明消息是否正常发出。你想想看，如果连车都发现不了，后面所有工作都是白搭。

3.2 路由激活——诊断仪和ECU之间的「握手」

找到车了，下一步是什么？

直接发诊断请求？不行。DoIP要求先做路由激活（Routing Activation）。

为什么要有这一步？说白了，就是为了安全。DoIP网络里可能同时存在多个诊断仪，如果不做激活，谁都能随便发诊断报文，那不乱套了？

路由激活的流程：

诊断仪发送路由激活请求（Routing Activation Request），里面包含自己的逻辑地址和激活类型。
ECU收到后，检查激活类型是否合法。如果合法，回复路由激活响应（Routing Activation Response），状态码为0x10（成功）。
如果不合法，回复对应的否定响应码，比如0x02（不支持该激活类型）、0x03（冲突）等。

避坑指南：

我曾经遇到过一个奇葩问题：诊断仪发了路由激活请求，ECU也回复了成功，但后续的诊断报文就是收不到。查了两天才发现——ECU的TCP socket没有正确绑定到激活的通道上。说白了，路由激活不只是「握手」，它还要在ECU内部建立一条逻辑通道。通道没建好，后面全白费。

路由激活的激活类型（Activation Type）有几种：

激活类型值	含义	典型场景
0x00	默认激活	普通诊断
0x01	带安全认证的激活	需要身份验证的场景
0x02	诊断仪主动断开	诊断结束时的清理
0x03-0xFF	保留/自定义	OEM自定义用途

我个人建议，在实现路由激活时，一定要把超时机制做严谨。DoIP规范里没有明确规定超时时间，但根据经验，诊断仪发送激活请求后，ECU应该在2秒内回复。超过这个时间，诊断仪应该重试或报错。

3.3 诊断通信——终于可以发UDS报文了

路由激活成功后，诊断仪和ECU之间就建立了一条逻辑诊断通道。这时候，诊断仪可以发送UDS诊断请求了。

DoIP的诊断通信，本质上就是把UDS报文封装在DoIP的Payload里，通过TCP传输。具体格式如下：

DoIP Header (8 bytes) + UDS Payload (N bytes)

DoIP Header结构：
- Protocol Version (1 byte): 0x02 (DoIP ISO 13400-2)
- Inverse Protocol Version (1 byte): 0xFD
- Payload Type (2 bytes): 0x8001 (诊断请求/响应)
- Payload Length (4 bytes): UDS报文的长度

举个例子，发送一个UDS的「读取数据标识符」（0x22）请求：

// 诊断请求：读取VIN码（DID 0xF190）
// DoIP Header
02 FD 80 01 00 00 00 04
// UDS Payload
22 F1 90

// 诊断响应（假设VIN为"WDB1234567890ABCDE"）
// DoIP Header
02 FD 80 01 00 00 00 15
// UDS Payload
62 F1 90 57 44 42 31 32 33 34 35 36 37 38 39 30 41 42 43 44 45

注意事项：

诊断请求和响应都使用同一个TCP连接。不要为每个请求新建连接。
DoIP支持并发诊断，即多个诊断仪可以同时连接到同一个ECU。但每个诊断仪需要独立的逻辑通道。
UDS报文的最大长度受DoIP Payload Length字段限制（4字节，最大2^32-1字节），但实际中以太网MTU通常限制在1500字节左右。如果UDS报文太大，需要分片传输。

我记得有一次，客户反馈说诊断响应总是超时。我抓包一看，发现UDS响应报文被TCP分片了，但ECU没有正确处理分片重组。嗯，这个问题其实很常见——很多人只关注UDS协议本身，忽略了底层TCP的传输特性。

3.4 三个模块的关系——一张图说清楚

车辆发现、路由激活、诊断通信，这三个模块不是孤立的。它们是一个完整的流程：

车辆发现：诊断仪找到网络上的ECU，获取其IP和逻辑地址。
路由激活：诊断仪与ECU建立逻辑通道，完成安全握手。
诊断通信：通过已建立的通道，发送UDS诊断请求/响应。

你想想看，如果车辆发现没做好，后面两步根本走不下去。如果路由激活失败，诊断通信也无法进行。所以，调试DoIP时，我建议按照这个顺序一步步验证：

第一步：确认车辆声明消息能正常收到。
第二步：确认路由激活请求/响应能正常交互。
第三步：确认UDS诊断报文能正常收发。

我的调试小技巧：

用Wireshark抓包时，可以设置过滤条件 doip，直接看到所有DoIP报文。如果发现车辆声明消息没有出现，先检查ECU的DoIP服务是否正常启动。如果路由激活失败，检查激活类型是否匹配。如果诊断通信异常，检查TCP连接状态和UDS报文格式。

好了，DoIP协议基础的三个核心模块就聊到这儿。下一章咱们会深入SOME/IP和DoIP的协同工作，看看它们怎么在同一个以太网里「和平共处」。到时候我会分享一个实际项目中的集成案例，保证干货满满。