DoIP（二）——报文类型与功能解析

1. DoIP报文类型全景解析

DoIP协议的核心在于其丰富的报文类型设计，就像快递行业有不同的面单类型一样。我在实际车辆诊断项目中经常接触到的报文主要分为五大类：车辆发现类、路由激活类、诊断数据类、节点管理类和特殊功能类。每种报文的数据结构都像乐高积木，由固定格式的报头和可变长度的数据块组成。

先说说最基础的报头结构，它相当于快递面单的固定栏目。报头包含四个关键字段：协议版本（1字节）、协议版本取反（1字节）、数据类型（2字节）和数据长度（4字节）。这里有个容易踩坑的地方——数据类型字段采用大端序（Big-Endian）存储。有次我在解析0x0001类型的报文时，因为搞错字节顺序导致整个诊断会话失败。

2. 车辆发现类报文详解

2.1 车辆声明报文（0x0004）

这就像车辆的"自我介绍"，当诊断设备接入网络时，所有支持DoIP的ECU都会通过UDP广播发送这个报文。我抓包发现典型报文结构如下：

# 示例报文结构 doip_header = { 'protocol_version': 0x02, 'inverse_version': 0xFD, 'payload_type': 0x0004, 'payload_length': 0x0013 } payload = { 'VIN': 'LSVNL123456789012', # 17字节 'logical_address': 0x0E80, # 2字节 'EID': '00:11:22:33:44:55', # 6字节 'GID': '66:77:88:99:AA:BB', # 6字节 'further_action': 0x00 # 1字节 }

进一步动作字段特别重要，它决定ECU后续行为：

• 0x00：仅声明存在
• 0x01：准备进入编程模式
• 0x02：已锁定（不可诊断）

2.2 车辆识别请求（0x0001）与响应（0x0002）

诊断设备发送0x0001请求时，就像在停车场喊"谁的车牌是XXX？"。我实测发现有两种触发方式：

1. 广播模式：发送空VIN字段，所有ECU都会响应
2. 定向查询：填写具体VIN，只有匹配ECU响应

响应报文0x0002的结构与声明报文类似，但增加了路由激活状态字段。这里有个实际案例：某车型在OTA升级时会临时关闭路由功能，此时响应报文中的这个字段就会变为0x00（不可用）。

3. 诊断数据传输类报文

3.1 诊断报文（0x8001）

这是最常用的报文类型，相当于把UDS诊断请求/响应打包在以太网帧里。具体传输过程像这样：

1. 诊断设备发送0x8001报文，数据部分包含完整的UDS请求
2. ECU返回相同类型的0x8001报文，携带UDS响应

# 诊断请求示例（读取故障码） doip_diag_req = { 'header': { 'type': 0x8001, 'length': 0x0005 }, 'data': bytes([0x22, 0xF1, 0x90]) # UDS请求：读取DTC } # 对应响应示例 doip_diag_res = { 'header': { 'type': 0x8001, 'length': 0x0006 }, 'data': bytes([0x62, 0xF1, 0x90, 0x01, 0x23]) # UDS响应+故障码数据 }

关键点：诊断报文必须通过已激活的TCP连接传输。我遇到过因为路由未激活直接发诊断请求导致超时的情况。

3.2 大数据包分片传输（0x8002）

当处理OTA升级等大文件传输时，就需要用到这个类型。它像快递公司的分箱服务：

1. 发送方先发0x8002报文，包含总大小和MD5校验值
2. 接收方确认后，开始传输实际数据块
3. 每块数据都有序号标识，最后进行整体校验

实测某车型ECU的传输参数：

• 单块最大尺寸：1400字节（避免IP分片）
• 超时重试次数：3次
• 校验算法：CRC32+MD5双校验

4. 路由管理类报文

4.1 路由激活请求（0x0005）与响应（0x0006）

就像打电话要先拨号一样，诊断前必须激活路由。请求报文中最重要的两个参数：

1. 源地址：诊断设备的逻辑地址
2. 激活类型：
   • 0x00：默认（无特殊要求）
   • 0x01：编程会话（刷写时使用）
   • 0x02：扩展诊断会话

响应报文中的确认码需要特别注意：

• 0x00：成功
• 0x01：未知错误
• 0x10：不支持的激活类型
• 0x11：已达到最大连接数

4.2 连接保活机制（0x0007/0x0008）

TCP连接建立后，双方通过心跳报文维持连接。我在压力测试时发现：

• 默认心跳间隔：5秒
• 连续3次无响应则认为断连
• 保活报文负载长度必须为0

5. 特殊功能报文解析

5.1 节点状态查询（0x4001）

这个功能就像系统体检，可以获取ECU的：

• 内存使用率
• CPU负载
• 网络吞吐量
• 诊断会话状态

某次故障排查时，我通过这个报文发现某ECU的内存泄漏问题——连续查询显示可用内存持续下降。

5.2 诊断电源模式控制（0x4003）

用于控制ECU的电源状态，常见模式：

• 0x01：休眠模式
• 0x02：唤醒模式
• 0x03：复位ECU

重要安全限制：部分关键ECU（如EMS）会拒绝休眠请求，这个在混动车型上特别常见。

6. 实战中的报文交互流程

以完整的诊断会话为例，典型报文交互顺序如下：

1. UDP广播发现可用ECU（0x0001/0x0004）
2. TCP连接建立（端口13400）
3. 路由激活（0x0005/0x0006）
4. 诊断数据传输（0x8001）
5. 保活心跳（0x0007/0x0008）
6. 连接关闭（TCP FIN）

在OTA升级场景中，还需要插入0x8002类型的大数据传输阶段。有个实际经验：在传输每100个数据块后主动发送心跳报文，可以显著降低超时断开概率。