3、DoIP车辆声明与发现：车辆声明报文(VAN)、车辆发现请求/响应、路由激活过程
好，咱们进入DoIP里最基础、也最关键的环节——车辆声明与发现。你想想看，一台诊断仪连到车载以太网上，它怎么知道周围有哪些车？车又怎么告诉诊断仪“我在这儿”？这就是VAN报文和车辆发现机制要解决的问题。
我个人习惯把这一块叫做“握手前的自我介绍”。说白了，就是车和诊断仪互相打个招呼，确认身份，然后才能进入后续的路由激活。嗯，这里要注意，如果这一步没做好，后面所有诊断通信都无从谈起。
3.1 车辆声明报文（VAN）
VAN，全称Vehicle Announcement，车辆声明报文。它的作用很简单：车主动告诉网络上的所有节点——“我来了，这是我的信息”。
我在项目中遇到过一个问题：某次测试时，诊断仪死活发现不了车辆。查了半天，发现是VAN报文的发送周期配置错了。车每10秒发一次，但诊断仪只在前5秒监听……你说巧不巧？
VAN报文的核心内容，我列个表给你看：
| 字段 | 长度 | 说明 |
|---|---|---|
| 源地址 | 2字节 | 车辆自身的逻辑地址，通常是0x0E80 |
| 目标地址 | 2字节 | 广播地址0x0000，表示发给所有人 |
| VIN | 17字节 | 车辆识别码，全球唯一 |
| EID | 6字节 | 实体ID，通常是MAC地址 |
| GID | 6字节 | 组ID，用于分组管理 |
| 逻辑地址 | 2字节 | DoIP实体的逻辑地址 |
VAN报文默认每3秒发送一次，连续发送3次。这是标准做法。但我建议你根据实际网络负载调整——如果总线上节点太多，3秒一次可能造成拥塞。我曾经在一个项目里把间隔调到了5秒，效果反而更好。
关键点：VAN报文使用UDP广播，端口是UDP 13400。诊断仪收到后，就能知道车辆的存在和基本信息。
3.2 车辆发现请求/响应
除了车主动声明，诊断仪也可以主动问：“有没有车在？”这就是车辆发现请求（Vehicle Discovery Request）。
你想想看，如果车已经上线但VAN报文还没发出来，诊断仪干等着多被动。所以主动请求机制就派上用场了。
车辆发现请求的格式很简单：
// 车辆发现请求报文结构
UDP Header (源端口: 随机, 目标端口: 13400)
Payload:
- 协议版本: 0x02
- 报文类型: 0x0001 (车辆发现请求)
- 载荷长度: 0x00000000 (无额外载荷)车辆收到这个请求后，必须回复车辆发现响应。响应里包含的信息和VAN报文基本一致，但多了一个字段——响应码。
响应码有几种情况：
- 0x00 — 成功，正常响应
- 0x01 — 车辆正在初始化，稍后再试
- 0x02 — 车辆不支持该请求
我记得有一次调试，诊断仪发请求后一直收不到响应。抓包一看，车回复了0x01。原来车辆刚上电，DoIP协议栈还没完全启动。嗯，这种情况加个重试机制就好。
避坑指南：我曾经遇到一个奇葩问题——诊断仪和车辆不在同一个VLAN里。UDP广播过不去，车辆发现请求石沉大海。所以，网络配置一定要确认好，别在二层隔离上栽跟头。
3.3 路由激活过程
好了，现在诊断仪知道车在哪了，车也知道诊断仪的存在。但还不能直接通信。为什么？因为还需要一个“激活”步骤——路由激活（Routing Activation）。
路由激活说白了就是：诊断仪告诉车辆“我要跟你建立诊断连接，请给我分配一个逻辑地址”。车辆确认后，双方才能开始真正的诊断通信。
路由激活请求的格式：
// 路由激活请求
TCP连接建立后发送
Payload:
- 协议版本: 0x02
- 报文类型: 0x0005 (路由激活请求)
- 载荷长度: 0x00000007
- 激活类型: 0x01 (默认)
- 源地址: 0x0001 (诊断仪的逻辑地址)
- 保留: 0x00000000车辆收到后，会检查几个东西：
- 源地址是否合法？
- 激活类型是否支持？
- 当前是否有其他诊断会话占用？
如果一切正常，车辆回复路由激活响应，状态码为0x00。同时，车辆会给诊断仪分配一个逻辑地址（通常是0x0E80之后的地址）。
这里有个坑——路由激活必须在TCP连接上进行。UDP只负责发现，真正的诊断通信走TCP。我见过有人搞混了，在UDP上发路由激活请求，结果当然是没有结果。
警告：路由激活成功后，车辆会维护一个激活表。如果诊断仪长时间不发任何诊断消息（比如超过5分钟），车辆可能会自动去激活。所以，记得发心跳或者定期发诊断请求保持连接。
3.4 实际项目中的经验总结
最后，我分享几个实际项目里踩过的坑，你遇到了可以少走弯路：
- VAN报文冲突：如果总线上有多台车（比如在产线上），VAN报文可能会冲突。解决办法是加随机延迟，避免所有车同时发送。
- 路由激活超时：诊断仪发路由激活请求后，车辆必须在2秒内响应。超时了就重试，最多重试3次。我习惯在代码里加个指数退避，效果不错。
- 逻辑地址分配：车辆给诊断仪分配逻辑地址时，要确保不冲突。我曾经遇到一个项目，两个诊断仪同时激活，结果分配了同一个地址……嗯，后来加了地址池管理才解决。
- 安全认证前置：有些车辆要求在路由激活时进行TLS握手。这种情况下，路由激活请求必须在TLS隧道内发送。这个我们后面章节会详细讲。
好了，这一章的内容就到这里。车辆声明与发现，看似简单，但细节很多。你只要记住一个核心逻辑：先发现，再激活，后通信。顺序别搞反，基本就不会出大问题。
一句话总结：VAN报文让车主动“喊一嗓子”，车辆发现请求让诊断仪主动“问一声”，路由激活让双方“握个手”。三步走完，诊断通信的大门就打开了。