第1章：DoIP协议报文结构

1.1 通用DoIP头部

咱们直接进入正题。DoIP的报文结构，说白了就是一套固定的"信封"格式。不管你要发什么诊断数据，都得先把这个信封写好。

通用DoIP头部一共8个字节，固定不变。我刚开始接触DoIP时，总觉得这8个字节有点浪费带宽。后来踩过坑才明白——没有这个固定头部，接收方根本不知道该怎么解析后面的数据。

字段	长度（字节）	说明
协议版本	1	当前固定为0x02（ISO 13400-2:2012）
反向协议版本	1	发送方支持的协议版本，用于兼容性检查
Payload类型	2	标识报文的具体用途
Payload长度	4	后续数据的字节数，最大支持4GB

这里有个细节我想强调一下。协议版本字段，发送方填自己支持的版本号。反向协议版本，则填自己能解析的最高版本。为什么要这么设计？

我遇到过这样一个案例：某Tier1供应商的ECU固件升级后，协议版本从0x01跳到了0x03。结果诊断仪还是按0x01的格式发报文，ECU收到后一看反向协议版本是0x01，就知道对方是老版本，自动切换回兼容模式。嗯，这个设计确实巧妙。

1.2 Payload类型详解

Payload类型字段占2个字节，它告诉接收方：这包数据到底是干嘛用的。我把它分成三大类，这样好记。

1.2.1 节点管理类（0x0001 - 0x0006）

这类报文负责车辆的"入网"和"心跳"。你想想看，诊断仪连上车辆后，总得先打个招呼吧？

• 0x0001：车辆识别请求。诊断仪问："你是谁？"
• 0x0002：车辆识别响应。ECU答："我是某某车型，VIN码是..."
• 0x0003：路由激活请求。诊断仪说："我要开始诊断了"
• 0x0004：路由激活响应。ECU确认："好的，给你分配一个逻辑地址"
• 0x0005：保活报文。双方定期发"我还活着"的信号
• 0x0006：保活响应。确认收到

1.2.2 诊断消息类（0x8001 - 0x8002）

这才是咱们真正关心的数据。UDS诊断请求和响应，都封装在这里面。

• 0x8001：诊断请求（从诊断仪发往ECU）
• 0x8002：诊断响应（从ECU发回诊断仪）

说白了，0x8001和0x8002就是UDS报文的"运输车"。UDS的SID、DID、DTC这些数据，都作为Payload放在后面。

1.2.3 其他类型

还有一些不常用的，比如0x4001（事件通知）、0x4002（事件确认）。我做了这么多年项目，用到这些的场景屈指可数。新手可以先跳过，用到时再查表。

1.3 源地址与目标地址

这两个字段藏在诊断消息类的Payload里，不在通用头部中。很多初学者会搞混，我当年也犯过这个错。

源地址和目标地址各占2个字节。它们的作用很简单：

• 源地址：发送方的逻辑地址。诊断仪通常是0x0E00，ECU的地址由OEM分配
• 目标地址：接收方的逻辑地址。可以是单个ECU，也可以是广播地址0xFFFF

这里有个实际例子。假设诊断仪（逻辑地址0x0E00）想读取发动机ECU（逻辑地址0x0001）的故障码：

// 诊断请求报文（简化版）
通用头部：
  协议版本: 0x02
  反向协议版本: 0x02
  Payload类型: 0x8001 (诊断请求)
  Payload长度: 0x00000007

Payload内容：
  源地址: 0x0E00
  目标地址: 0x0001
  UDS数据: 0x19 0x02 0xFF (读取DTC的请求)

ECU收到后，会解析出目标地址是0x0001，发现跟自己匹配，于是处理UDS数据，然后返回：

// 诊断响应报文
通用头部：
  协议版本: 0x02
  反向协议版本: 0x02
  Payload类型: 0x8002 (诊断响应)
  Payload长度: 0x0000000A

Payload内容：
  源地址: 0x0001
  目标地址: 0x0E00
  UDS数据: 0x59 0x02 0xFF 0x12 0x34 0x56 (响应数据)

1.4 报文结构总结

咱们把整个流程串起来。一个完整的DoIP诊断报文，从外到内分三层：

1. 以太网层：MAC地址、IP地址、UDP/TCP端口号。这是网络传输的基础
2. DoIP通用头部：8字节固定格式，告诉接收方"这是什么类型的报文"
3. DoIP Payload：包含源地址、目标地址，以及真正的UDS诊断数据

我个人习惯把DoIP报文想象成一个俄罗斯套娃。最外面是以太网帧，打开是DoIP头部，再打开才是UDS诊断数据。每一层都有自己的职责，缺一不可。

下一章咱们聊聊路由激活的具体流程。那一步要是搞错了，后续所有诊断都发不出去。嗯，到时候我会分享一个我踩过的"血泪坑"。