3、车辆发现与声明：VIN/GID/EID的广播机制、车辆声明报文格式、测试用例设计要点
好，咱们进入第三个核心话题——车辆发现与声明。
说实话，这部分是DoIP协议里我最喜欢的一块。为什么？因为它最“热闹”。你想想看，一辆车刚上电，谁都不认识谁，它得扯着嗓子喊一声“我在这儿！我是谁！”——这就是车辆发现机制的本质。
3.1 三种标识符：VIN、GID、EID
先搞清楚这三个东西分别是什么，不然后面报文解析你肯定晕。
| 标识符 | 全称 | 长度 | 特点 |
|---|---|---|---|
| VIN | Vehicle Identification Number | 17字节 | 全球唯一，出厂固定 |
| EID | Entity Identification | 6字节 | 每个DoIP实体唯一，通常是MAC地址 |
| GID | Group Identification | 6字节 | 用于分组，可自定义 |
我个人习惯把EID叫做“硬件身份证”，VIN是“车辆户口本”。GID嘛，更像是一个临时工牌——可以随时换。
核心要点：VIN是逻辑标识，EID是物理标识。测试时如果VIN没写对，EID还能兜底。但反过来，EID错了，基本就找不到设备了。
3.2 广播机制：谁先喊谁有理？
车辆上电后，会主动发送两种广播报文：
- Vehicle Identification Request（广播请求）——测试设备发，车辆应答
- Vehicle Announcement（主动声明）——车辆自己发，不请自来
我记得第一次调试时，发现车辆怎么都不应答。查了半天，原来是广播地址配错了。DoIP要求使用UDP广播，目标端口是13400，源端口可以任意。但很多工程师会忽略一个细节——广播报文必须从0.0.0.0地址发出，否则某些网关会直接丢弃。
避坑指南：我曾经遇到过一个案例，车辆在CAN网络上正常，但DoIP就是发现不了。最后定位到是EID和MAC地址不匹配。有些网关会做MAC地址过滤，EID必须和实际MAC一致，否则报文会被硬件层丢弃。
3.3 车辆声明报文格式
报文结构其实不复杂，但字段顺序容易搞混。我直接给个实际抓包解析的例子：
Vehicle Announcement Message (UDP, 13400):
- Protocol Version: 0x02
- Inverse Protocol Version: 0xFD
- Payload Type: 0x0004 (Vehicle Announcement)
- Payload Length: 32
- Logical Address: 0x0E80 (网关地址)
- VIN (17 bytes): "LSVAU2A34N1234567"
- EID (6 bytes): 0x112233445566
- GID (6 bytes): 0x000000000000
- Further Action Required: 0x00
- Reserved: 0x00注意看Further Action Required这个字段。很多测试用例会忽略它，但它其实很重要。如果这个字节是0x01，表示车辆还有后续动作要执行，比如等待VIN写入。测试时如果发现车辆反复声明，多半是这个标志位没清零。
3.4 测试用例设计要点
这部分我直接上干货。设计用例时，我一般会从三个维度切入：
3.4.1 正常流程测试
- 车辆上电后，是否在1秒内发出Vehicle Announcement？
- 广播报文中的VIN是否与车辆实际VIN一致？
- EID是否与MAC地址匹配？
- GID是否与配置的分组ID一致？
嗯，这里有个小技巧。测试VIN一致性时，不要只看字符串。有些ECU会把VIN存成ASCII码，但大小写处理有bug。我建议你写个脚本，把VIN逐字节比对，而不是直接字符串比较。
3.4.2 异常场景测试
- VIN为空（全0）时，车辆是否还能被EID发现？
- EID重复（两个ECU用相同EID），网络会不会冲突？
- GID不匹配时，车辆是否拒绝通信？
- 广播报文长度错误（比如少发1字节），接收端如何处理？
警告：EID重复是实际项目中最隐蔽的坑。我曾经在台架上同时接了三个DoIP节点，结果有两个用了相同的MAC地址（硬件设计问题）。测试时发现车辆时有时无，排查了整整两天。所以，EID唯一性测试必须做，而且要在多节点环境下做。
3.4.3 时序与重试测试
- 车辆声明报文是否按协议要求间隔发送（通常3次，间隔100ms）？
- 如果第一次广播丢失，后续重试能否补上？
- 车辆在行驶中（车速>0）是否还发送声明？
说到时序，我习惯用Wireshark的IO Graph功能来观察。把三次声明的间隔画出来，一眼就能看出有没有抖动。标准要求是100ms±10ms，但有些ECU实现得比较粗糙，间隔能差到50ms。这种问题在单节点测试时发现不了，但一接入整车网络就会出乱子。
3.5 实战经验总结
最后分享几个我踩过的坑：
- VIN写入时机：有些ECU在VIN没写入前，会发送全0的VIN。这时候测试设备必须能通过EID来识别车辆。我见过一个测试脚本只认VIN，结果死活连不上刚下线的车。
- 多网关场景：现在很多车有多个DoIP网关（比如T-Box和IVI各一个）。它们会各自发送声明，但VIN相同。测试时要注意区分逻辑地址，否则容易混淆。
- 网络唤醒：车辆休眠后，有些ECU不会主动发送声明。需要测试设备先发一个广播请求，车辆才会应答。这个行为在ISO 13400里是可选的，但很多OEM强制要求。
一句话总结：车辆发现测试，说白了就是验证“车能不能被找到，找到的信息对不对”。别小看这步，我见过太多项目因为VIN少写一个字符，导致产线停线半天。
好了，这一章的内容就到这儿。下一章我们会聊路由激活——也就是车辆发现之后，怎么建立正式的诊断通道。那个环节的坑更多，咱们到时候细说。