第1章：DoIP车辆声明与发现机制
各位工程师朋友，今天我们来聊聊DoIP协议里一个非常有意思的环节——车辆声明与发现。说白了，就是让诊断设备能在网络上找到车辆，并且知道这辆车是谁。
我记得刚接触DoIP那会儿，总觉得这玩意儿不就是个广播嘛，有啥好研究的？后来在项目里踩了坑才明白，这里面的门道还真不少。
1.1 为什么需要车辆发现机制？
你想想看，传统诊断用的是CAN总线，物理连接一插上，ECU就在那儿。但以太网不一样，网络里可能同时挂着好几辆车，或者一个车间里几十台设备都在线。诊断仪怎么知道哪辆车是它要找的？
这就是车辆发现机制要解决的问题。DoIP协议定义了一套广播机制，让车辆主动“喊”出自己的身份，也让诊断仪能主动“问”出车辆的信息。
核心思路：车辆在网络上通过UDP广播报文，宣告自己的存在。诊断仪收到后，就能知道车辆的IP地址、VIN码等关键信息。
1.2 三个关键标识符：VIN、GID、EID
在DoIP的世界里，车辆用三个标识符来表明身份。我习惯把它们比作人的身份证、临时编号和工牌号。
| 标识符 | 全称 | 长度 | 说明 |
|---|---|---|---|
| VIN | Vehicle Identification Number | 17字节 | 车辆唯一身份码，全球唯一 |
| EID | Entity ID | 6字节 | 逻辑实体标识，通常是ECU的MAC地址 |
| GID | Group ID | 6字节 | 组标识，用于分组管理 |
VIN 不用多说，每辆车出厂就定死了。但有个坑——VIN是在车辆上电后，从某个ECU读出来的。如果那个ECU还没启动，VIN就是空的。这时候EID就派上用场了。
EID 我建议你把它当成车辆的“临时身份证”。在VIN还没就绪时，诊断仪可以通过EID来识别车辆。EID通常是网关的MAC地址，这个不会变。
GID 说实话，我在实际项目中用得不多。它主要用于逻辑分组，比如把同一批次的车辆分到一个组里。但大多数OEM直接把它置为0。
我的经验：曾经有个项目，诊断仪死活连不上车，查了半天发现是VIN还没准备好，但诊断仪只发了VIN请求。后来改成先用EID匹配，问题就解决了。所以建议大家在设计时，优先支持EID发现。
1.3 车辆声明报文（Vehicle Announcement）
车辆声明报文，就是车辆主动广播自己存在的一种方式。它使用UDP协议，目标端口是UDP_DISCOVERY（默认13400）。
什么时候会发这个报文？主要有三种场景：
- 车辆上电启动时——网关初始化完成后，立即广播一次
- 网络连接建立时——比如车辆刚连上诊断网络
- 收到诊断仪的请求时——作为响应的一部分
报文格式长这样：
| 字节偏移 | 字段名 | 长度 | 说明 |
|---------|--------|------|------|
| 0 | 协议版本 | 1 | 当前为0x02 |
| 1 | 反向协议版本 | 1 | 取反，用于校验 |
| 2-3 | 负载类型 | 2 | 0x0004表示声明 |
| 4-5 | 负载长度 | 2 | 后续数据长度 |
| 6-22 | VIN | 17 | 不足补0x00 |
| 23-28 | EID | 6 | MAC地址 |
| 29-34 | GID | 6 | 组ID |
| 35 | 逻辑地址 | 2 | 网关的逻辑地址 |
嗯，这里要注意：VIN字段如果还没准备好，全部填0x00。诊断仪看到VIN全0，就知道得用EID来识别。
1.4 车辆发现请求（Vehicle Discovery）
除了车辆主动广播，诊断仪也可以主动发起发现请求。这就像你在停车场喊一声“谁的车牌号是京A12345？”
发现请求也走UDP广播，目标端口同样是13400。诊断仪可以指定要查找的VIN、EID或GID，也可以什么都不指定（那就是找所有车辆）。
请求报文格式：
| 字节偏移 | 字段名 | 长度 | 说明 |
|---------|--------|------|------|
| 0 | 协议版本 | 1 | 0x02 |
| 1 | 反向协议版本 | 1 | 取反 |
| 2-3 | 负载类型 | 2 | 0x0001表示发现请求 |
| 4-5 | 负载长度 | 2 | 后续数据长度 |
| 6-22 | 目标VIN | 17 | 全0表示不指定 |
| 23-28 | 目标EID | 6 | 全0表示不指定 |
| 29-34 | 目标GID | 6 | 全0表示不指定 |
车辆收到这个请求后，会检查自己是否匹配。如果匹配，就回复一个车辆声明报文。
避坑指南：我曾经遇到过一个情况，车间里同时有20台车在线，诊断仪发了一个空发现请求，结果20台车同时回复声明报文，UDP广播风暴直接把网络打爆了。后来我们加了一个随机延迟机制，每台车在收到请求后，随机等待0-500ms再回复，问题就解决了。
1.5 实际项目中的最佳实践
说了这么多理论，咱们聊聊落地时要注意的点：
- 广播频率要控制：车辆声明报文不要发太频繁。我一般建议上电后发3次，间隔100ms、200ms、500ms。之后除非收到发现请求，否则不再主动广播。
- VIN和EID的优先级：诊断仪应该优先用VIN匹配，如果VIN无效，再退回到EID。车辆端要保证EID始终有效。
- 多网关场景：有些车有多个DoIP网关，每个网关都有自己的EID。诊断仪需要能处理多个声明报文，并选择正确的那个。
- 安全考虑：车辆声明报文是明文广播的，任何人都能收到。所以在生产环境中，建议只在诊断模式下开启DoIP发现功能。
我的习惯：在开发阶段，我会在诊断仪上打印所有收到的声明报文，包括VIN、EID、IP地址和时间戳。这样调试时一眼就能看出车辆是否正常上线，有没有重复广播等问题。
好了，关于车辆声明与发现机制，今天就聊到这儿。下一章我们会深入DoIP的路由激活和连接管理，到时候再跟大家分享更多实战经验。