目录
- 1 摘要
- 2 DoIP entity status request/response（0x4001、0x4002）
- 2.1 使用场景
- 2.2 报文结构
- 2.2.1 0x4001：DoIP entity status request
- 2.2.2 0x4002：DoIP entity status response
- 3 Diagnostic power mode information request/response（0x4003、0x4004）
- 3.1 使用场景
- 3.2 报文结构
- 3.2.1 0x4003：Diagnostic power mode information request
- 3.2.2 0x4004：Diagnostic power mode information response
- 4 0x8001-0x8003：Diagnostic Message and Positive/Negetive Acknowledgment
- 4.1 DOIP诊断报文处理流程
- 4.2 报文结构
- 4.2.1 诊断报文（0x8001-Diagnostic Message）
- 4.2.2 诊断肯定确认报文（0x8002-Diagnostic message positive acknowledgment）
- 4.2.3 诊断否定响应报文（0x8003-Diagnostic message negative acknowledgment）
- 5 总结
1 摘要
本文接着对DOIP报文的车辆信息类以及诊断类报文进行介绍。主要从各类报文的使用场景、报文结构以及实例示例等方面进行详细解析。建议大家回顾上文专题的介绍，有利于系统性学习。
上文回顾：
车载以太网网络测试-20【传输层-DOIP协议-3】
2 DoIP entity status request/response（0x4001、0x4002）
2.1 使用场景
-
查询DoIP实体的状态：
该报文用于向目标DoIP实体（如车辆中的ECU）请求其当前的状态信息。状态信息可能包括DoIP实体的活动状态、网络配置、诊断能力等。 -
诊断系统监控：
诊断工具或测试设备可以通过发送DoIP entity status request报文，监控车辆中各个DoIP实体的运行状态，确保它们正常工作。 -
故障排查：
当诊断系统出现通信问题时，可以通过发送该报文检查目标DoIP实体的状态，帮助排查问题。 -
支持动态配置：
在诊断过程中，诊断工具可能需要动态获取DoIP实体的状态信息，以调整通信参数或诊断策略。
- 应用场景：
- 车辆诊断过程中，诊断工具需要检查某个ECU的DoIP状态。
- 在车辆启动或网络初始化时，诊断系统需要确认所有DoIP实体的状态。
- 在通信故障时，诊断工具需要检查目标DoIP实体的状态以定位问题。
通过DoIP entity status request报文，诊断系统可以高效地获取DoIP实体的状态信息，确保诊断通信的可靠性和稳定性。
2.2 报文结构
2.2.1 0x4001：DoIP entity status request
DoIP entity status request 报文的 Payload Type 为 0x0004，且没有有效载荷（Payload Length 为 0x00000000）。因此，其帧结构如下：
| 字段 | 值 | 描述 |
|---|---|---|
| Protocol Version | 0x02 | DoIP 协议版本。 |
| Inverse Version | 0xFD | 协议版本的反码。 |
| Payload Type | 0x0004 | 报文类型，表示 DoIP entity status request。 |
| Payload Length | 0x00000000 | 有效载荷长度为 0。 |
| Payload | 无 | 无有效载荷。 |
一个完整的 DoIP entity status request 报文的十六进制表示如下：
02 FD 00 04 00 00 00 00
2.2.2 0x4002：DoIP entity status response
该报文是DoIP entity status request的响应报文，DoIP节点用该响应报文来向诊断设备发送状态信息。报文的数据段定义如下：
DoIP实体状态请求和应答报文通过UDP报文实现。
- Node Type (1 byte)
- 节点类型，表示实体的类型（如0x00表示未定义，0x01表示DoIP网关，0x02表示DoIP节点等）。
- Max Concurrent TCP Data Connections (1 byte)
- 最大并发TCP数据连接数，也即是最多允许同时多少个TCP的连接存在。
- Currently Open TCP Data Connections (1 byte)
- 当前打开的TCP数据连接数。
- Max Data Size (4 bytes)
- 最大数据大小（以字节为单位），DoIP实体在一次逻辑请求中能够处理的最大数据量。
如下图所示：
3 Diagnostic power mode information request/response（0x4003、0x4004）
3.1 使用场景
在 DoIP 协议中，Diagnostic power mode information request/response 是用于获取或设置车辆电源模式信息的诊断服务。
-
Diagnostic power mode information request (0x4003)
- 作用：客户端（如诊断工具）使用此请求向车辆电子控制单元（ECU）查询当前的电源模式状态。
- 使用场景：在诊断过程中，诊断工具可能需要了解车辆的电源模式（如点火状态、休眠状态等），以便执行适当的诊断操作。
- 数据格式：通常是一个简单的请求报文，不包含额外的数据参数。
-
Diagnostic power mode information response (0x4004)
- 作用：ECU 对
Diagnostic power mode information request的响应，返回当前车辆的电源模式信息。 - 数据内容：响应报文通常包含以下信息：
- 电源模式状态：如“点火开关打开”、“点火开关关闭”、“休眠模式”等。
- 其他相关信息：如电源模式的转换状态或时间戳等（具体取决于实现）。
- 使用场景：诊断工具根据返回的电源模式信息，决定下一步的诊断操作。例如，如果车辆处于休眠模式，诊断工具可能需要先唤醒车辆。
- 电源模式的意义
车辆的电源模式是诊断通信的重要参数，因为它直接影响诊断操作的可行性和安全性。例如：- 在点火开关关闭的情况下，某些 ECU 可能无法响应诊断请求。
- 在休眠模式下，车辆可能处于低功耗状态，诊断工具需要发送唤醒信号才能进行通信。
3.2 报文结构
3.2.1 0x4003：Diagnostic power mode information request
该报文可以被诊断设备用来请求DoIP节点的电源模式信息，报文数据段没有数据。
3.2.2 0x4004：Diagnostic power mode information response
该报文是Diagnostic power mode information request的响应报文。报文的数据段定义如下：
示例如下图：
4 0x8001-0x8003：Diagnostic Message and Positive/Negetive Acknowledgment
0x8001到0x8003是用于诊断报文和确认的报文类型。
4.1 DOIP诊断报文处理流程
- DoIP遵循如下流程：
- 诊断设备发送一条诊断请求（0x8001-Diagnostic Message），该请求报文中包含有UDS诊断数据（DOIP报文的Payload）；
- DoIP节点收到后先对DoIP帧头、诊断数据长度等做判断，先返回一个DoIP层（传输层）的响应，如果各个条件都满足，则返回肯定响应（0x8002-Diagnostic message positive acknowledgment），否则返回否定响应（0x8003-Diagnostic message negative acknowledgment）。
- 当DoIP节点的DOIP传输层返回肯定响应后，再将诊断请求报文中包含的UDS诊断数据上报给UDS应用程序（应用层）进行处理，处理完成后，**不论是UDS肯定响应还是UDS否定响应，都用诊断报文（0x8001-Diagnostic Message）**将UDS诊断响应数据发送给诊断设备。
4.2 报文结构
4.2.1 诊断报文（0x8001-Diagnostic Message）
- 用于发送诊断请求或响应消息。诊断请求通常由诊断客户端（如诊断工具）发送，诊断响应由诊断服务器（如车辆ECU）返回。
- 典型场景包括读取故障码、读取传感器数据、执行诊断例程等。
| 字段 | 长度 (字节) | 描述 |
|---|---|---|
| Source Address（SA） | 2 | 发送诊断报文的源地址（通常是测试设备的地址）。 |
| Target Address（TA） | 2 | 接收诊断报文的目标地址（通常是ECU的地址）。 |
| User Data（UD） | 可变 | 实际的诊断数据（如 UDS 请求或响应）。 |
以下是一条包含UDS诊断请求数据的DoIP诊断报文示例：
说明：
- 诊断请求报文：
协议版本：02协议版本取反：FDPayload type：8001（诊断报文）Payload Length：00 00 00 06源逻辑地址：0E 80（诊断设备逻辑地址）目标逻辑地址：10 21（DOIP节点逻辑地址）UDS数据：3E 00（请求UDS的3E服务）
- 诊断肯定响应
协议版本：02协议版本取反：FDPayload type：8002（诊断肯定确认报文）Payload Length：00 00 00 05源逻辑地址：10 21目标逻辑地址：0E 80UDS数据：00（诊断请求报文争取被处理）
- 诊断响应响应
协议版本：02协议版本取反：FDPayload type：8001（诊断报文）Payload Length：00 00 00 06源逻辑地址：10 21（DOIP节点逻辑地址）目标逻辑地址：0E 80（诊断设备逻辑地址）UDS数据：7E 00（肯定响应UDS的3E服务）
4.2.2 诊断肯定确认报文（0x8002-Diagnostic message positive acknowledgment）
- 用于确认成功接收到诊断消息。例如，当诊断服务器成功接收到诊断请求后，可以发送一个Positive Acknowledgment作为确认。
- 这种确认通常用于确保消息的可靠传输。
- SA以及TA：和上文一致，为源和目标逻辑地址；
- ACK code：包含诊断报文的肯定确认码；
- Previous diagnostic message data：用于携带先前发送的诊断消息的相关数据。它通常包含了导致当前错误响应的原始诊断消息的内容或部分内容。这个参数的存在有助于诊断系统或测试工具识别和定位问题的根源。
对于诊断肯定确认报文的ACK code应置为0x00，具体定义如下：
- 备注：
0x00：路由确认（ACK）报文，表示诊断报文已正确接收、处理并放入目标网络的传输缓冲区。
每个DoIP实体应在正确处理诊断报文并将其复制到目标网络传输缓冲区后，立即发送诊断消息的肯定确认（ACK），并将ACK代码设置为0x00（参见表29）。
4.2.3 诊断否定响应报文（0x8003-Diagnostic message negative acknowledgment）
- 用于指示接收到的诊断报文存在问题，例如格式错误、不支持的功能等。
- 当诊断服务器无法处理接收到的诊断请求时，会发送Negative Acknowledgment，并附带错误原因。
与肯定响应报文的区别就是响应码变成了否定响应码，用来指示否定响应的原因，定义如下：
- 示例1：（无效的SA地址NACK为0x02）
建立TCP连接且路由激活后，使用无效的SA地址发送诊断请求，DoIP实体返回NACK为0x02的否定响应报文，并主动断开TCP连接（ISO 13400-2 强制要求）
- 示例2：诊断否定报文示例（目的逻辑地址无效NACK为0x03）
建立TCP连接且路由激活后，使用无效的TA地址发送诊断请求，DoIP实体返回NACK为0x03的否定响应报文（无需断开TCP连接）
5 总结
上文对DOIP协议定义的车辆信息类以及诊断类报文进行了介绍，主要包含各类报文的使用场景、报文结构以及实例示例。希望能对大家学习DOIP协议有所帮助！
