目录
- 1摘要
- 2 节点管理报文
- 5 总结
1摘要
上一专题对DOIP报文的帧头以及涉及的一些基础知识概念进行了介绍；从本专题开始对DOIP报文的数据类型进行介绍，先对节点管理类（0x0xxx）报文进行介绍，本文主要对0x000到0x0004报文的定义、报文类型以及示例进行介绍。
上文回顾：
车载以太网网络测试-18【传输层-DOIP协议-1】
DoIP报头中有两字节的数据类型（Payload Type），代表DoIP报文类型，分为三类：0x0XXX节点管理类、0x4XXX车辆信息类、0x8XXX诊断类，其他字段暂时被ISO 13400预留或供OEM自定义使用。
标准中对报文类型的定义如下：
2 节点管理报文
节点管理报文在DoIP协议中扮演着关键角色，主要用于管理网络中的节点状态、激活/休眠节点、识别节点、维护网络拓扑以及处理错误等。通过这些报文，诊断工具能够有效地与车辆中的ECU进行通信，确保诊断过程的顺利进行。
常见的节点管理报文类型:
Routing Activation Request/Response：用于激活诊断路由。
Alive Check Request/Response：用于检查节点是否在线。
DoIP Entity Status Request/Response：用于查询节点的状态信息。
Power Mode Information：用于查询或通知节点的电源模式（如休眠、唤醒等）。
各类报文的协议以及目标端口非常重要，在写脚本的时候需要格外注意！！！
2.1 0x0000：Generic DoIP header negative acknowledge
当DoIP节点收到的DoIP报文的报头不符合规则时，返回该数据类型的报文。该报文的数据部分**只包含1字节**的否定响应码（Generic DoIP header NACK code），用来指示错误原因，定义如下：
上表中，Required action表示DoIP节点在发送完该否定响应报文后应该采取的动作，是忽略该报文还是关闭套接字。
常见NACK code示例：
2.1.1 NACK code 00（格式不正确）示例
在Diagnostics over Internet Protocol (DoIP)中，当接收到一个格式不正确的报文时，会返回一个Generic DoIP header negative acknowledge报文，其否定响应码为00（incorrect pattern format）。
- 请求报文（格式不正确）
假设请求报文的格式不正确，例如协议版本或协议版本取反字段不正确。
DOIP Header:
- Protocol Version: 0x02 (假设协议版本为2)
- Inverse Protocol Version: 0x02 (协议版本取反字段不正确，应为0xFD)
- Payload Type: 0x8001 (假设数据类型为车辆识别请求)
- Payload Length: 0x00000004 (假设数据长度为4字节)
Payload:
- Data: 0x11223344 (假设的无效数据)
- 响应报文（Generic DoIP header negative acknowledge）
当接收到上述格式不正确的请求报文时，DOIP实体会返回一个Generic DoIP header negative acknowledge报文，否定响应码为00（incorrect pattern format）。
DOIP Header:
- Protocol Version: 0x02 (协议版本为2)
- Inverse Protocol Version: 0xFD (协议版本取反字段正确，应为0xFD)
- Payload Type: 0x0000 (数据类型为Generic DoIP header negative acknowledge)
- Payload Length: 0x00000001 (数据长度为1字节)
Payload:
- NACK Code: 0x00 (否定响应码为incorrect pattern format)
当DOIP实体检测到请求报文的格式不正确时（例如协议版本取反字段不正确），它会返回一个Generic DoIP header negative acknowledge报文，否定响应码为00（incorrect pattern format）。这个响应报文用于通知发送方请求报文的格式存在问题。
2.1.2 NACK code 01（未知Payload类型）示例
在DoIP（Diagnostics over Internet Protocol）协议中，当接收到一个未知的Payload类型时，会返回一个Generic DoIP header negative acknowledge（否定确认）报文。
- 请求报文
假设请求报文的Payload类型为0x00E2（未知类型），请求报文如下：
| 字段名 | 字段值（十六进制） | 说明 |
|---|---|---|
| 协议版本 | 0x02 | DoIP协议版本（2） |
| 协议版本取反 | 0xFD | 协议版本的取反值（0xFD） |
| 数据类型 | 0x00E2 | 未知的Payload类型 |
| 数据长度 | 0x00000004 | 数据长度为4字节 |
| 数据 | 0x11223344 | 示例数据 |
请求报文完整示例：
02 FD 00 E2 00 00 00 04 11 22 33 44
- 响应报文
当接收到未知的Payload类型时，响应报文将返回一个Generic DoIP header negative acknowledge报文，否定响应码为0x01（unknown payload type）。响应报文如下：
| 字段名 | 字段值（十六进制） | 说明 |
|---|---|---|
| 协议版本 | 0x02 | DoIP协议版本（2） |
| 协议版本取反 | 0xFD | 协议版本的取反值（0xFD） |
| 数据类型 | 0x0000 | Generic DoIP header negative acknowledge |
| 数据长度 | 0x00000001 | 数据长度为1字节 |
| 否定响应码 | 0x01 | 未知的Payload类型（0x01） |
响应报文完整示例：
02 FD 00 00 00 00 00 01 01
这个示例展示了当DoIP节点接收到一个未知的Payload类型时，如何通过Generic DoIP header negative acknowledge报文进行响应。在DoIP（Diagnostics over Internet Protocol）协议中，当接收到一个未知的Payload类型时，会返回一个Generic DoIP header negative acknowledge（否定确认）报文。以下是一个示例，包含请求报文和响应报文的报头字段。
2.1.3 NACK code 02（报文过长）示例
在DOIP（Diagnostics over Internet Protocol）协议中，当接收到一个报文过长（例如数据长度超过65535字节）的请求时，会返回一个Generic DoIP header negative acknowledge（通用DOIP头部否定响应）报文，其中否定响应码为02（message too large）。以下是请求报文和响应报文的示例：
-
请求报文示例
假设请求报文的数据长度为65536字节（超过最大允许值），请求报文的DOIP头部字段如下：- 协议版本（Protocol Version）: 0x02 (表示DOIP协议版本2)
- 协议版本取反（Inverse Protocol Version）: 0xFD (0x02的取反值)
- 数据类型（Payload Type）: 0x8001 (假设为诊断消息类型)
- 数据长度（Payload Length）: 0x00010000 (65536字节，十六进制表示)
请求报文的DOIP头部如下：
02 FD 80 01 00 01 00 00 （数据……）
-
响应报文示例
由于请求报文的数据长度超过65535字节，DOIP节点会返回一个Generic DoIP header negative acknowledge报文，否定响应码为02（message too large）。响应报文的DOIP头部字段如下：- 协议版本（Protocol Version）: 0x02 (表示DOIP协议版本2)
- 协议版本取反（Inverse Protocol Version）: 0xFD (0x02的取反值)
- 数据类型（Payload Type）: 0x0000 (Generic DoIP header negative acknowledge)
- 数据长度（Payload Length）: 0x00000001 (1字节，表示否定响应码的长度)
- 否定响应码（Negative Acknowledge Code）: 0x02 (message too large)
响应报文的DOIP头部如下：
02 FD 00 00 00 00 00 01 02
通过这种方式，DOIP节点可以通知发送方其发送的消息长度超出了协议允许的范围。
2.1.4 NACK code 03（内存不足）示例
在DOIP（Diagnostic over Internet Protocol）协议中，当发生内存不足（Out of Memory）情况时，会发送一个Generic DoIP header negative acknowledge（通用DOIP报头否定响应）报文，其否定响应码为0x03。
-
场景描述
连续快速发送**两次（或多次）**数据长度接近协议允许范围的请求报文（比如：65535），导致接收方内存不足，触发0x03否定响应码。 -
请求报文
请求报文的DOIP报头字段如下：
| 字段名称 | 值（十六进制） | 说明 |
|---|---|---|
| 协议版本 | 0x02 | DOIP协议版本为2 |
| 协议版本取反 | 0xFD | 协议版本取反（0x02的取反为0xFD） |
| 数据类型 | 0x8001 | 数据类型为诊断消息（0x8001） |
| 数据长度 | 0x0000FFFE | 数据长度为65534字节 |
请求报文的DOIP报头示例：
02 FD 80 01 00 00 FF FE
- 响应报文
响应报文的DOIP报头字段如下：
| 字段名称 | 值（十六进制） | 说明 |
|---|---|---|
| 协议版本 | 0x02 | DOIP协议版本为2 |
| 协议版本取反 | 0xFD | 协议版本取反（0x02的取反为0xFD） |
| 数据类型 | 0x0000 | 数据类型为Generic DoIP header negative acknowledge |
| 数据长度 | 0x0001 | 数据长度为1字节 |
| 否定响应码 | 0x03 | 否定响应码为0x03（Out of Memory） |
响应报文的DOIP报头示例：
02 FD 00 00 00 01 03
- 完整的DOIP报文示例
请求报文：
02 FD 80 01 00 00 FF FE
<诊断数据...>
响应报文：
02 FD 00 00 00 01 03
- 解释
- 请求报文：**两次（或多次）**数据长度接近协议允许范围的请求报文（比如：65535），数据长度为65534字节。
- 响应报文：由于接收方内存不足，无法处理该请求，因此返回一个Generic DoIP header negative acknowledge报文，否定响应码为
0x03，表示“Out of Memory”。
通过以上示例，可以清楚地理解在DOIP协议中如何触发并处理0x03否定响应码。
2.1.5 NACK code 04（Invalid Payload Length）示例
在DoIP（Diagnostic over Internet Protocol）协议中，0x0000是Generic DoIP header negative acknowledge（通用DoIP头部否定响应）的数据类型。当收到一个无效的DoIP报文时，设备会发送这个否定响应报文。
- 请求报文（Invalid Payload Length）
假设请求报文的负载长度无效，以下是请求报文的DoIP头部字段：
| 字段名称 | 字段值（十六进制） | 说明 |
|---|---|---|
| 协议版本 | 0x02 | DoIP协议版本为2 |
| 协议版本取反 | 0xFD | 协议版本取反（0x02的取反为0xFD） |
| 数据类型 | 0x8001 | 假设数据类型为诊断消息（0x8001） |
| 数据长度 | 0x00000005 | 无效的负载长度（假设为5，但实际不匹配） |
请求报文的DoIP头部如下：
02 FD 80 01 00 00 00 05
- 响应报文（Generic DoIP Header Negative Acknowledge）
当设备检测到请求报文的负载长度无效时，会发送一个否定响应报文，否定响应码为0x04（Invalid Payload Length）。以下是响应报文的DoIP头部字段：
| 字段名称 | 字段值（十六进制） | 说明 |
|---|---|---|
| 协议版本 | 0x02 | DoIP协议版本为2 |
| 协议版本取反 | 0xFD | 协议版本取反（0x02的取反为0xFD） |
| 数据类型 | 0x0000 | Generic DoIP header negative acknowledge |
| 数据长度 | 0x00000001 | 数据长度为1（否定响应码的长度为1字节） |
| 否定响应码 | 0x04 | 否定响应码为0x04（Invalid Payload Length） |
响应报文的DoIP头部如下：
02 FD 00 00 00 00 00 01 04
- 请求报文：
02 FD 80 01 00 00 00 05 - 响应报文：
02 FD 00 00 00 00 00 01 04
在这个示例中，请求报文的负载长度无效（实际应该为0，发送端写成了5），设备检测到后发送了一个否定响应报文，否定响应码为0x04，表示无效的负载长度。
2.2 0x0001：Vehicle identification request message
该报文用于请求车辆识别信息的消息，其报文结构简单，主要由DOIP头部组成，没有额外的载荷数据。在DOIP（Diagnostic over Internet Protocol）协议中，0x0001 是车辆识别请求消息（Vehicle Identification Request Message）的标识符。该消息用于请求车辆识别信息，如车辆识别码（VIN）、逻辑地址等。
车辆识别请求消息（Vehicle Identification Request Message）的报文结构：
| 字段 | 长度（字节） | 描述 |
|---|---|---|
| Protocol Version | 1 | 协议版本，通常为 0x02（表示DOIP协议版本2）。 |
| Inverse Protocol Version | 1 | 协议版本的反码，通常为 0xFD（即 0x02 的反码）。 |
| Payload Type | 2 | 有效载荷类型，此处为 0x0001（表示车辆识别请求消息）。 |
| Payload Length | 4 | 有效载荷的长度，对于车辆识别请求消息，通常为 0x00000000（无附加数据）。 |
| Payload Data | 0 | 无附加数据，字段为空。 |
- 示例报文（十六进制表示）
02 FD 00 01 00 00 00 00
- 字段说明
- Protocol Version (0x02)：DOIP协议的版本号，当前为版本2。
- Inverse Protocol Version (0xFD)：协议版本的反码，用于校验。
- Payload Type (0x0001)：表示车辆识别请求消息。
- Payload Length (0x00000000)：表示有效载荷的长度，此处为0，因为没有附加数据。
- Payload Data：无附加数据。
该报文用于请求车辆识别信息，通常由诊断工具发送给车辆，车辆会返回识别响应消息（Payload Type 0x0004）。
2.3 0x0002：Vehicle identification request message with EID
在DoIP（Diagnostics over Internet Protocol）协议中，Vehicle identification request message with EID 是一种用于车辆识别的请求报文。它的主要作用是向车辆发送一个请求，要求车辆根据其**EID（Ethernet Identifier）**返回相关的车辆识别信息。该类型报文的作用和上面的一样，只是在请求报文的数据中搭载了6字节EID（一般为ECU的MAC地址），可请求指定EID的DoIP节点的其它车辆信息，用于被诊断节点的EID已知的情况。
2.3.1 报文结构
在DOIP（Diagnostic over Internet Protocol）协议中，0x0002 是车辆识别请求消息的标识符，用于通过EID（Ethernet Identifier）请求车辆识别信息。以下是该消息的报文结构：
| 字段 | 长度（字节） | 描述 |
|---|---|---|
| Protocol Version | 1 | DOIP协议版本，通常为 0x02（表示DOIP ISO 13400-2:2012）。 |
| Inverse Version | 1 | 协议版本的按位取反值，通常为 0xFD（如果协议版本为 0x02）。 |
| Payload Type | 2 | 消息类型标识符，固定为 0x0002。 |
| Payload Length | 4 | 报文长度，固定为 0x00000006。 |
| EID | 6 | 请求的EID（Ethernet Identifier），用于识别目标车辆。 |
2.3.2 工作流程
-
请求车辆识别信息：
- 该报文用于请求车辆返回其识别信息，例如车辆标识符（VIN）、EID、GID（Group Identifier）等。
- 该请求是基于车辆的EID（以太网标识符）来发送的，因此适用于支持以太网通信的车辆。
-
目标车辆筛选：
- 通过EID，可以唯一标识车辆的网络接口，从而确保请求发送到特定的车辆（如果网络中有多辆车）。
- 这种方式可以用于在多个车辆连接到同一网络时，精确地选择目标车辆。
-
响应报文：
- 车辆在收到该请求后，会返回一个Vehicle identification response message（车辆识别响应报文），其中包含车辆的详细信息，例如VIN、EID、GID等。
- 响应报文的类型通常为 0x0004。
-
应用场景：
- 该报文通常用于诊断系统或测试设备在车辆网络中识别特定车辆的场景。
- 例如，在车辆生产、维护或诊断过程中，可能需要通过EID来定位和识别目标车辆。
Vehicle identification request message with EID** 是一种用于通过EID请求车辆识别信息的报文，主要用于在车辆网络中定位和识别特定车辆。它通常与 0x0004 响应报文配合使用，以实现车辆信息的获取。
2.4 0x0003：Vehicle identification request message with VIN
在DoIP（Diagnostics over Internet Protocol）协议中，Vehicle Identification Request Message with VIN（带VIN的车辆识别请求报文）报文的作用是请求车辆识别信息，通常用于诊断仪或其他客户端设备与车辆之间的通信。
该类型报文原理同上，只是在报文数据中搭载的不是EID，而是17字节的VIN，用于DoIP节点的VIN已知的情况下，请求指定VIN的DoIP节点的其它信息。
2.4.1 报文结构
在DOIP（Diagnostic over Internet Protocol）协议中， **Vehicle Identification Request Message with VIN*报文的详细结构：
| 字段 | 字节数 | 描述 |
|---|---|---|
| Protocol Version | 1 | 协议版本号，通常为 0x02（表示 DOIP 协议版本 2）。 |
| Inverse Protocol Version | 1 | 协议版本的反码，通常为 0xFD（即 0x02 的反码）。 |
| Payload Type | 2 | 负载类型，固定为 0x0003，表示 Vehicle Identification Request with VIN。 |
| VIN (Vehicle Identification Number) | 17 | 车辆的 VIN 号，固定为 17 字节，不足部分用 0x00 填充。 |
报文示例
完整的报文如下：
| 字段 | 值（十六进制） |
|---|---|
| Protocol Version | 02 |
| Inverse Protocol Version | FD |
| Payload Type | 00 03 |
| Payload Length | 00000011 |
| VIN | 50 41 4E 47 55 30 31 32 30 35 37 34 31 35 35 32 30 |
说明
- VIN 是 17 字节的 ASCII 编码字符串，如果 VIN 不足 17 字节，则用
0x00填充。 - Protocol Version 和 Inverse Protocol Version 用于验证协议的兼容性。
这种报文用于通过 VIN 向车辆发送识别请求，车辆会返回相应的识别信息。
小知识：
汽车VIN码（Vehicle Identification Number，车辆识别码）是一个由17位字符组成的唯一编码，用于识别每一辆汽车。VIN码包含了车辆的生产信息，如制造商、车型、生产年份、发动机类型、生产地点等。它是车辆的“身份证”，在全球范围内具有唯一性。
-
VIN码的结构：
VIN码由以下三部分组成：- 世界制造商识别码（WMI）：前3位字符，表示车辆的生产国家、制造商和车辆类型。
- 车辆描述部分（VDS）：第4到第9位字符，描述车辆的具体特征，如车型、发动机类型、车身样式等。
- 车辆指示部分（VIS）：第10到第17位字符，包括生产年份、装配厂以及车辆的生产序列号。
-
VIN码的用途：
- 车辆识别：用于区分不同的车辆。
- 查询车辆历史：通过VIN码可以查询车辆的维修记录、事故历史、是否被盗等信息。
- 车辆注册和保险：在车辆注册、保险和过户时，VIN码是必要的凭证。
- 召回和维修：制造商可以通过VIN码确定车辆是否需要召回或进行特定维修。
-
VIN码的位置：
VIN码通常可以在以下位置找到：- 车辆前挡风玻璃左下角（驾驶员侧）。
- 车辆的车门边缘或门柱上。
- 车辆的发动机舱内。
- 车辆的行驶证或车辆登记证书上。
通过VIN码，可以获取车辆的重要信息，确保购买二手车时的安全性和可靠性。汽车VIN码（Vehicle Identification Number，车辆识别码）是一个由17位字符组成的唯一编码，用于识别每一辆汽车。VIN码包含了车辆的生产信息，如制造商、车型、生产年份、发动机类型、生产地点等。它是车辆的“身份证”，在全球范围内具有唯一性。
2.5 0x0004：Vehicle announcement/Vehicle identification response message
2.5.1 用途以及应用
在**DOIP（Diagnostics over Internet Protocol）**协议中，Vehicle Announcement/Vehicle Identification Response Message的主要作用是用于车辆的广播或识别响应，是车辆与诊断设备之间通信的重要部分。
该类型的报文有两种用途：
- 第一个用途是以上三种报文的响应报文（Vehicle identification response message）。
- 第二个用途是作为车辆声明报文（Vehicle announcement），标准规定，当一个DoIP节点成功获取到IP地址后，应在500ms内发送3条车辆声明报文，向网络中的所有DoIP节点广播自己的车辆信息，这时数据部分的定义和上面相同，发送时使用UDP，IP地址设置为255.255.255.255。实际应用过程中发送时间和发送报文数目可能会根据实际情况有所调整。
备注：
Vehicle announcement：车辆通过广播GID和EID向周围车辆或基础设施宣告自己的存在。
Vehicle identification response message：车辆在接收到请求后，通过EID和GID明确标识自己，以便其他车辆或系统识别。
使用场景
-
车辆启动或网络连接时：
- 车辆上电或网络连接后，会主动发送
0x0004消息，通知诊断设备其已准备好进行通信。 - 例如，车辆在维修车间启动时，诊断工具可以通过接收
0x0004消息快速识别车辆。
- 车辆上电或网络连接后，会主动发送
-
诊断设备请求车辆信息时：
- 诊断设备发送
0x0001消息（Vehicle Identification Request）后，车辆通过0x0004消息响应，提供车辆的详细信息。 - 例如，在诊断过程中，诊断工具需要获取车辆的VIN或逻辑地址时，会触发此流程。
- 诊断设备发送
-
多车辆环境中的车辆识别：
- 在有多辆车的网络中（如维修车间），
0x0004消息可以帮助诊断设备区分不同的车辆，并选择目标车辆进行诊断。
- 在有多辆车的网络中（如维修车间），
2.5.2 报文结构
报文数据共33字节，包含：
| 字段 | 长度（字节） | 描述 |
|---|---|---|
| VIN (Vehicle Identification Number) | 17 | 车辆的VIN号，固定长度为17字节，不足部分用 0x00 填充。 |
| Logical Address | 2 | 车辆的逻辑地址（Logical Address），通常为ECU的地址。 |
| EID (Ethernet Identifier) | 6 | 车辆的以太网标识符（EID），用于唯一标识车辆的网络接口。 |
| GID (Group Identifier) | 6 | 车辆的组标识符（GID），用于标识车辆所属的组。 |
| Further Action Required | 1 | 是否需要进一步操作：0x00 表示不需要，0x01 表示需要。如：安全机制 |
| VIN/GID sync. status | 1 | 表示车内的DoIP节点是否完成VIN或GID的同步`。 |
GID（Group Identifier）：
用于标识一组相关的实体或车辆，例如同一车队或同一类型的车辆。
通常用于广播消息或组播通信中，以减少冗余消息。
EID（Entity Identifier）：
用于唯一标识一个特定的实体或车辆，确保消息能够精确地发送到目标车辆。
在单播通信中，EID是必需的。
Further Action Required：
字段的作用和目的是为了指示接收方是否需要采取进一步的行动来处理或响应收到的消息。
VIN/GID Sync. Status：
目的是确保车辆识别号（VIN）和组标识符（GID）在通信网络中的一致性和准确性。常见场景如下：
- 车辆生产与出厂检测
场景：在车辆生产过程中，VIN/GID信息会被写入车辆的控制单元（如ECU、BCM等）。
用途：通过检查VIN/GID Sync. Status，确保车辆在生产线上已经正确配置并同步了VIN/GID信息。
示例：如果状态为“未同步”，则表明VIN/GID信息可能未正确写入，需要重新配置。 - 车辆诊断与维修
场景：在维修或诊断过程中，技师需要通过诊断工具读取车辆的VIN/GID信息。
用途：VIN/GID Sync. Status可以帮助技师判断车辆信息是否与诊断工具或服务器同步。
示例：如果状态为“同步失败”，则可能需要重新同步VIN/GID信息或检查通信链路。 - 车辆注册与合规性检查
场景：在车辆注册或年检时，监管机构需要验证车辆的VIN信息。
用途：VIN/GID Sync. Status可以用于确认车辆信息是否与官方记录一致。
示例：如果状态为“已同步”，则表明车辆信息已验证；如果为“未同步”，则可能需要进一步核查。 - 软件更新与配置管理
场景：在车辆软件更新或配置更改时，VIN/GID信息用于确保更新或配置适用于特定车辆。
用途：VIN/GID Sync. Status可以用于验证车辆信息是否与更新服务器同步。
示例：如果状态为“同步失败”，则可能无法完成软件更新或配置更改。 - 网络安全与防篡改
场景：在车辆网络安全中，VIN/GID信息用于验证车辆身份并防止非法访问或篡改。
用途：VIN/GID Sync. Status可以用于检测车辆信息是否被篡改或未授权修改。
示例：如果状态为“同步失败”，则可能存在安全风险，需要进一步调查。
Vehicle identification response message示例：
当诊断节点发送了以上三种车辆信息请求报文后，符合条件的DoIP节点将会返回该响应报文，报文数据部分的格式如下：
5 总结
以上对节点管理类报文（0x0000到0x0004）的原理、功能、报文结构以及示例进行了介绍；后续专题继续对DOIP协议的剩余内容进行介绍，如果存在表述问题，欢迎联系我一起交流！
扫一扫
2218
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
