車載以太網DoIP 協議測試的研究與分析

李志濤，耿偉峰

（長城汽車股份有限公司技術中心，河北 保定 071000）

汽車電子技術的飛速發展，促進了車載網絡通信技術的廣泛應用，同時高性能車載娛樂系統、大數據、車聯網、云服務、自動駕駛等新技術使得車載網絡對帶寬、兼容性的要求越來越高，傳統的車載CAN總線通信受限于帶寬原因，已越來越不能滿足車輛智能化和網聯化的要求。車載以太網技術以其高帶寬、兼容性強、可靠性高、擴展性良好的特性，逐漸在車輛上普及應用，尤其在軟件刷新、遠程OTA等通信應用場景需求中，實現基于車載以太網的DoIP協議，已成為車載以太網技術應用的必然。

1 標準概述

DoIP（Diagnostic communication over Internet Protocol），是基于IP網絡的汽車診斷協議，全稱為基于IP網絡的診斷通信，其具備更快的數據傳輸速率，從而在復雜的數據診斷和軟件刷新的場景下節約時間和成本。

DoIP協議用于UDS診斷的傳輸，該協議由ISO 13400標準定義，ISO 13400規定了DoIP的傳輸層、網絡層、數據鏈路層和物理層，應用層和會話層部分由ISO 14229實現。應用層的UDS診斷服務，通過傳輸控制（TCP/UDP）協議和網絡（IP）協議，經數據鏈路層的封裝，然后由物理層轉換后發送到網絡上，完成車內以太網控制器與外部測試設備之間的診斷通信。DoIP通信過程是基于TCP/UDP進行診斷報文的傳輸，診斷報文中的Payload攜帶相應診斷服務數據信息，診斷服務數據遵循傳統的診斷協議。因此，準確來說DoIP協議是一個擴展的傳輸層協議，為基于車載以太網的診斷搭建了一個通信橋梁。DoIP協議在OSI 7層模型中的位置及分布見圖1。

圖1 DoIP標準架構分布

ISO 13400-1處于應用層（層7）之上，是對一些通用信息、應用場景的描述。ISO 13400-2定義了傳輸層和網絡層（層4和層3），ISO 13400-2中規定了DoIP通信在傳輸層中使用TCP和UDP協議，在網絡層中使用IPv4或IPv6協議、專屬于DoIP通信的內容等。ISO 13400-3定義了DoIP診斷通信對Ethernet數據鏈路層和物理層的要求等；ISO 13400-4定義以太網診斷連接器要求。同時在ISO 13400-2中定義了基于DoIP通信的診斷架構模型，架構模型見圖2。

圖2 車載網絡架構示意圖

其中，DoIP診斷架構須實現以下特性：①車輛與測試設備具有檢測對方并加入到網絡的能力；②具備車輛信息聲明的能力；③獲取車輛基本狀態信息，如車輛診斷模式信息查詢；④建立與通信連接的保持、維護機制等；⑤實現測試設備與車輛內部ECU節點之間的數據路由；⑥錯誤狀態處理，如物理網絡斷開等。

2 通信診斷

2.1 DoIP數據結構

DoIP數據是層層向下傳遞的，直至構成完整的以太網幀，通過物理層的介質發出。DoIP數據封裝在以太網幀中，包含報頭和有效數據，其中Protocol Version定義了DoIP的協議版本號；Protocol Version為版本號取反；Payload Type定義了數據類型（標識本幀數據的用途）；Payload Length定義數據長度（標識后面的數據長度）；DoIP Payload包含了Payload Type對應的具體數據，Payload數據中又分為源地址、目標地址、應用數據。DoIP數據報文的格式見圖3。

圖3 DoIP數據報文

DoIP報文類型分為3類：節點管理類、車輛信息類與診斷類。節點管理類報文主要包括DoIP報頭否定響應、車輛信息獲取、通信路由激活、診斷設備在線檢查，如車輛識別請求/響應報文，路由激活請求/響應報文等；車輛信息類主要包括獲取DoIP實體狀態信息、車輛電源模式信息，如DoIP實體狀態請求/響應報文，診斷電源模式信息請求/響應報文。診斷類主要包括診斷報文處理以及UDS數據交互，如診斷報文、診斷請求確認響應報文。

2.2 診斷流程

ISO 13400中定義了DoIP通信的標準流程，該流程中Tester（測試設備）和DoIP網關（邊緣節點）通過IP網絡連接，DoIP網關連接了子網（非以太網車載網絡），Tester在當前網絡拓撲中能夠實現診斷DoIP網關或者子網絡上的非DoIP實體的功能。診斷會話流程見圖4。

圖4 DoIP診斷會話流程

DoIP的整個診斷流程大致可以分為5步：車輛連接、車輛聲明、TCP通信連接及路由激活、診斷數據交互、TCP連接關閉。

1）車輛連接：Tester和DoIP網關之間要建立正確的物理連接，通過車輛激活線激活DoIP網關的診斷功能，然后分配Tester及DoIP網關的IP地址，分配IP地址一般通過DHCP動態分配或Auto IP分配，主機廠可依據需求確定IP地址的分配方式，一般兩種分配方式均要求實現。

2）車輛聲明：車輛連接并上電后，車輛將自身的識別信息以廣播形式自發3次于所在網絡中。Tester若未獲取車輛自動上報的識別信息，Tester需進行車輛信息識別請求報文的發送（identification request），如果網絡中有車輛的話，車輛對這個車輛識別請求信息進行響應，發送車輛識別請求響應信息（車輛聲明），測試設備便發現了被測車輛。車輛聲明實現Tester和車內特定的DoIP實體的點對點連接，若網絡中包含多個Tester、車輛、DoIP實體，通過車輛識別請求與響應報文的信息交互，即車輛發現過程可以找到特定車輛及DoIP實體。

3）TCP通信連接及路由激活：Tester端和DoIP實體通過TCP三次握手機制建立TCP連接，然后Tester與DoIP實體節點之間進行路由激活，來激活車載以太網診斷通信套接字（Socket），Tester發送路由激活請求報文信息至DoIP實體節點，確認Tester的邏輯地址、激活類型等信息是否合法。通過后，DoIP實體回復路由激活響應報文，實現路由功能的激活。

4）診斷通信：Tester發送診斷請求報文（DoIP Payload Type 0x8001），診斷請求報文中包含目標的邏輯地址，用來區分不同的診斷實體，邊緣節點（DoIP網關）收到請求后回復診斷請求確認ACK（DoIP Payload Type 0x8002），告知Tester收到診斷請求，與此同時會發送診斷請求給車內所需診斷通信的DoIP實體節點。車內節點收到請求后回復診斷響應報文（DoIP Payload Type 0x8001），該響應報文經由DoIP網關轉發給Tester。若邊緣節點判定Tester發送的診斷請求有無效信息時（無效的目標地址，信息超長等），此時邊緣節點會回復NACK（DoIP Payload Type 0x8003）。

5）TCP連接關閉，當Tester端退出診斷通信連接時，用于DoIP通信的套接字TCP_DATA Socket被關閉，DoIP診斷通信斷開。

由于基于TCP協議傳輸數據時，數據包可能被其他人截取、篡改，這給數據傳輸過程中的信息安全帶來了極大的挑戰，因此最新版ISO 13400-2 2019協議將信息安全因素考慮進去，在整個DoIP診斷通信過程中增加了TLS（Transport Layer Security），即在建立TCP連接后，進行TLS握手流程，實現數據加密，再進行后續的路由激活、診斷數據交互。

2.3 應用場景

在ISO 13400-1中，描述了DoIP診斷典型的通信場景，主要描述了以下4種診斷連接方案。

1）單個測試設備與單個車輛之間的物理介質連接：此應用能夠確保在進行IP診斷時，通信連接不會被其他車輛或設備干擾。

2）單個測試設備與單個車輛之間的網絡連接：在多個車輛或多個外部測試設備都連接到同一個網絡時，外部測試設備和車輛都應該擁有識別能力，能夠在網絡下識別出需要建立連接的目標，并拒絕接受其他車輛或外部測試設備的診斷請求。

3）單個設備與多輛車之間的網絡連接：多輛車與單個外部測試設備網絡連接，要求外部測試設備具備一對多連接的能力。

4）多個測試設備與單個車輛之間的網絡連接：該應用方案要求車輛具備一對多連接的能力，能夠清楚地區分診斷請求和對每個邏輯連接負責的外部測試設備的響應。外部測試設備能夠判斷當前車輛是否在與其他設備進行通信。

參照如上應用場景，在車輛診斷具體應用時可選取對應的設計方案，滿足診斷場景需求，如售后模式車輛的故障檢測、產品/工廠模式車輛ECU的軟件更新、在工廠模式總裝工位的檢測、售后車輛遠程診斷、OTA升級等。

3 協議測試

遵循目前國際上通用的V模式開發流程，DoIP協議測試分為ECU級與系統級測試，主要測試內容包括車輛診斷激活使能線測試、以太網UDS測試、DoIP數據報文格式、DoIP診斷流程、DoIP時間參數、刷寫測試等，同時主機廠會在ISO標準需求的基礎上依據系統設計需求及應用場景等，自定義相關測試內容。

3.1 ECU級測試

ECU級別測試，主要進行應用層診斷協議測試驗證，針對上層協議ISO 14229協議，測試內容包含診斷服務和傳輸協議參數測試兩部分。診斷服務測試，根據相關協議發送正確格式的診斷請求報文，驗證ECU是否有相應的肯定診斷響應并判斷其是否滿足協議要求；錯誤協議處理機制測試，測試發送錯誤格式的診斷請求報文，驗證ECU是否有診斷響應并判斷其否定響應是否滿足協議要求。診斷傳輸協議參數測試，測試診斷服務及故障處理機制中時間參數正確性。

采用Vector公司的工具鏈，搭建測試環境，把診斷數據庫文件（CDD）導入至CANoe.Diva，添加封裝好的安全算法dll（Dynamic Link Library）文件，設置數據流時間參數的判斷標準等，單擊Generate就生成了可供CANoe調用的自動化測試的工程文件，然后在CANoe中載入生成的Diva工程文件并運行測試工程即可進行診斷的自動化測試。測試完成后，CANoe自動生成測試報告。該方案執行DoIP的UDS測試，技術成熟可靠，測試充分、高效，本文不再贅述。

3.2 系統級測試

系統級別測試基于Vector測試工具鏈，通過CANoe軟件開發測試腳本和測試工程，集成Vector硬件設備，完成系統測試環境的搭建。本系統VN5640實現以太網數據交互、采集，VT系統用于以太網鏈路的自動化故障注入，如以太網線斷路、短路等。測試環境示意如圖5所示。

圖5 系統測試示意圖

系統級測試，依據系統設計規范要求，對各系統基本需求實現的正確性、準確性、合理性進行測試，并結合不同的車輛運行場景，對系統在不同場景下的運行狀態進行檢測，考慮用戶應用角度進行應用場景的測試驗證、誤用和濫用方面的測試，同時考慮主機廠自定義及一些特殊的需求開展相應測試。主要涉及的相關測試內容為：控制器軟硬件版本讀取檢測，車輛發現請求、響應、車輛聲明報文；車輛路由激活、診斷報文格式測試，預編程條件測試（電源模式、電池電量、車速、發動機狀態、發動機轉速、手剎等）；控制器正向刷寫流程、控制器異常刷寫、高負載及故障注入等應用場景測試驗證等。

DoIP系統級測試是協議測試流程中的關鍵階段，不僅需考慮協議基本需求的實現，在此階段，需基于系統維度，結合功能需求的應用、車輛使用場景、非預期操作等開展相應的測試，驗證系統正確性與穩定性。系統級測試主要是在集成所有相關ECU的情況下，對系統或子系統進行驗證，查看是否滿足設計時的規格要求。對于較為復雜的系統，為保障測試的覆蓋率并節省測試時間，測試自動化工具選擇和環境搭建十分重要。

4 測試示例

本示例為車輛識別響應報文格式及數據正確性的測試驗證，測試車輛DoIP節點所發送的車輛識別響應報文的Protocol Version、Payload Type、Payload Length、DoIP Payload等是否滿足設計需求。測試前，參照圖5搭建測試環境，連接測試設備，完成CANoe軟硬件配置。

系統上電，車輛激活線進行激活，使能網關DoIP診斷功能，系統處于正常運行模式中。采用CANoe工具，發送不攜帶DoIP Payload參數的車輛識別請求報文至網關節點，其中Protocol Version=0x02，Payload Type=0x0001，Payload Length=0。在CANoe軟件中查看采集到的車輛識別響應報文，查看此響應報文中的各字段數值是否符合預期要求，見圖6。

圖6 車輛識別響應報文示例

CANoe采集網關節點發送的DoIP響應報文，查看并分析所采集的車輛識別響應報文，其中Protocol Version=0x02、Payload Type=0x0004、Payload Length=0x00000020、VIN、Logical Address、EID、GID、Further Action Required等字段數值，經分析符合預期要求。參照以上測試要求及步驟進行各DoIP節點ECU車輛識別響應報文數據格式及正確性的測試驗證。

5 結束語

伴隨著車輛電器功能的增加及對車輛個性化、科技化的需求，推動著車載以太網技術的迅速推廣，隨著技術的不斷成熟，將成為整車下一代骨干網絡應用的必然趨勢。同時遠程刷寫、遠程診斷等新技術的不斷出現，基于車載以太網技術的DoIP協議必然應用到車輛診斷系統中，因此，DoIP通信和測試的必要性就越發重要。本文對車載以太網的DoIP診斷通信技術與測試進行了研究分析，為進一步深入開展相關測試工作奠定了基礎。