李志濤，耿偉峰

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

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

1 標準概述

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

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

圖1 DoIP標準架構分布

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

圖2 車載網絡架構示意圖

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

2 通信診斷

2.1 DoIP數據結構

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

圖3 DoIP數據報文

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

2.2 診斷流程

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

圖4 DoIP診斷會話流程

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

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

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

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

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

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

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

2.3 應用場景

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

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

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

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

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

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

3 協(xié)議測試

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

3.1 ECU級測試

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

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

3.2 系統(tǒng)級測試

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

圖5 系統(tǒng)測試示意圖

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

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

4 測試示例

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

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

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

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

5 結束語

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