目錄
- 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協議有所幫助！
)
