2. DoIP节点发现机制：车辆声明报文(VAN)、车辆识别请求与响应、逻辑地址分配流程
好，咱们进入第二个大块头——节点发现机制。说实话，这部分是DoIP协议里最“热闹”的环节。你想啊，一辆车刚上电，诊断仪插上去，两边谁也不认识谁，总得先打个招呼、互相确认一下身份吧？
节点发现机制干的就是这个事。它包含三个核心动作：车辆声明报文（VAN）、车辆识别请求与响应、以及逻辑地址分配。我一个个拆开来讲。
2.1 车辆声明报文（VAN）——主动报到的“大喇叭”
车辆声明报文，英文叫Vehicle Announcement，简称VAN。它的作用很简单：车辆上线时主动广播自己的存在。
我记得第一次调试DoIP节点时，发现诊断仪死活搜不到车。查了半天，原来是VAN报文没发出来。嗯，这里要注意：VAN是节点上电后必须发送的第一条DoIP报文，没有它，后面的通信都免谈。
VAN报文的结构
VAN报文使用UDP广播，目标端口是UDP_DISCOVERY（默认13400）。它的Payload格式如下：
| 字节偏移 | 字段名 | 长度(字节) | 说明 |
|----------|---------------------|------------|-------------------------------|
| 0 | 协议版本 | 1 | 0x02 (ISO 13400-2:2012) |
| 1 | 反向协议版本 | 1 | 0xFE (取反) |
| 2-3 | Payload类型 | 2 | 0x0004 (车辆声明) |
| 4-7 | Payload长度 | 4 | 0x00000009 (固定9字节) |
| 8 | 逻辑地址 | 2 | 例如 0x0E80 (网关) |
| 10 | EID (实体ID) | 6 | 通常是MAC地址后6字节 |
| 16 | GID (组ID) | 6 | 0x000000000000 (未分组) |
| 22 | 保留 | 4 | 0x00000000 |说白了，VAN报文就是告诉网络上的所有设备：“嘿，我来了！这是我的逻辑地址，这是我的EID，你们记一下。”
关键点：VAN报文必须发送3次，间隔时间在500ms到1000ms之间。这是协议规定的，别偷懒只发一次。我见过有些实现只发一次，结果在丢包率高的网络环境下，诊断仪就漏掉了。
我的经验：实际项目中，我建议VAN报文发送间隔设为600ms，连续发3次。这样既满足协议，又不会因为网络抖动导致丢失。另外，EID字段我习惯直接用MAC地址的后6字节，省事且唯一。
2.2 车辆识别请求与响应——诊断仪的“点名”
VAN是车辆主动广播，但有时候诊断仪需要主动去发现特定车辆。比如维修车间里停着好几辆车，诊断仪得知道哪辆是它要连的。这时候就用到了车辆识别请求。
车辆识别请求有两种：
- 广播请求：发给所有节点，问“谁在？”
- 单播请求：发给特定EID或GID的节点，问“是你吗？”
请求报文格式
| 字段 | 值 |
|---------------|------------------------|
| 协议版本 | 0x02 |
| 反向协议版本 | 0xFE |
| Payload类型 | 0x0003 (车辆识别请求) |
| Payload长度 | 0x00000000 (无额外数据) |等等，这里有个坑。Payload长度是0，那怎么区分广播和单播？其实区别在于UDP的目标地址：
- 广播请求：目标IP是255.255.255.255，端口13400
- 单播请求：目标IP是节点的IP，端口13400
车辆收到请求后，会回复车辆识别响应。响应报文里包含车辆的VIN、EID、GID、逻辑地址等信息。
响应报文格式
| 字节偏移 | 字段名 | 长度(字节) | 说明 |
|----------|---------------------|------------|-------------------------------|
| 0 | 协议版本 | 1 | 0x02 |
| 1 | 反向协议版本 | 1 | 0xFE |
| 2-3 | Payload类型 | 2 | 0x0004 (车辆声明) |
| 4-7 | Payload长度 | 4 | 0x00000015 (21字节) |
| 8 | 逻辑地址 | 2 | 例如 0x0E80 |
| 10 | EID | 6 | MAC地址后6字节 |
| 16 | GID | 6 | 组ID |
| 22 | VIN | 17 | 车辆识别码 |
| 39 | 保留 | 4 | 0x00000000 |注意：车辆识别响应和VAN报文的Payload类型都是0x0004。区别在于：VAN的Payload长度是9字节（不含VIN），而识别响应的Payload长度是21字节（含VIN）。解析时一定要根据长度判断，别搞混了。
为什么会这样设计？我个人理解是：VAN是快速广播，只带必要信息；识别响应是应答，可以带更多细节。这样既保证了效率，又提供了灵活性。
2.3 逻辑地址分配流程——给每个ECU一个“身份证”
好了，现在车辆和诊断仪互相认识了。但车上那么多ECU，诊断仪怎么知道哪个是发动机、哪个是变速箱？这就轮到逻辑地址出场了。
逻辑地址是一个16位的数值，每个ECU在DoIP网络中都有一个唯一的逻辑地址。比如：
| 逻辑地址范围 | 用途 | 示例 |
|---|---|---|
| 0x0001 - 0x0DFF | 诊断仪（测试设备） | 0x0E80 是标准诊断仪地址 |
| 0x0E00 - 0x0EFF | 网关 | 0x0E80 是标准诊断仪地址 |
| 0x1000 - 0x1FFF | ECU（电子控制单元） | 0x1001 可能是发动机ECU |
| 0x2000 - 0xFFFF | 保留或自定义 | 看OEM定义 |
逻辑地址的分配有两种方式：
- 静态分配：出厂时写死在ECU固件里。简单可靠，但不够灵活。
- 动态分配：通过DoIP协议在运行时分配。我更喜欢这种方式，尤其是在多ECU场景下。
动态分配流程
动态分配的逻辑地址，说白了就是诊断仪给ECU发一个“分配地址”的请求，ECU收到后回复确认。流程如下：
- 诊断仪发送逻辑地址分配请求（Payload类型0x0005）
- ECU回复逻辑地址分配响应（Payload类型0x0006）
- 分配成功后，ECU使用新地址进行后续通信
请求报文里包含诊断仪建议的逻辑地址。ECU可以选择接受或拒绝。如果拒绝，诊断仪得换个地址再试。
避坑指南：我曾经遇到过一个案例，ECU在动态分配地址后，没有及时更新自己的路由表。结果诊断仪发过来的报文，ECU还是用旧地址处理，导致通信失败。解决方案是：分配地址后，ECU必须立即刷新所有内部路由缓存。
实际项目中的建议
我个人习惯在项目初期就定好逻辑地址分配策略。如果是小规模网络（比如只有网关和几个ECU），静态分配就够了。但如果是复杂的域控制器架构，动态分配更灵活。
另外，记得在分配地址时做冲突检测。诊断仪发请求前，先广播一个“地址探测”报文，看看有没有ECU在用这个地址。如果有，换个地址再试。这个步骤虽然协议没强制要求，但我建议加上，能省不少调试时间。
小技巧：逻辑地址分配完成后，我习惯让ECU再发一次VAN报文，通知全网它的新地址。这样其他节点能及时更新邻居表，避免后续通信走弯路。
2.4 总结一下
节点发现机制，说白了就是DoIP网络里的“自我介绍”和“身份认证”。VAN是主动报到，识别请求是点名应答，逻辑地址分配是发身份证。这三步走完，诊断仪和ECU才算真正“认识”了。
嗯，这里再啰嗦一句：调试时如果发现通信连不上，先检查VAN报文有没有发，再检查逻辑地址对不对。80%的问题都出在这两个地方。我踩过的坑，你们就别再踩了。