基于以太網的車輛診斷協(xié)議DOIP系統(tǒng)機制

?1.DoIP系統(tǒng)網絡層和傳輸層

ISO 134001-2定義了用于車輛診斷的網絡層和傳輸層協(xié)議以及服務，是DoIP協(xié)議的主要部分，內容通過需求、表格和狀態(tài)機三個部分來共同表示。通常，在狀態(tài)機中規(guī)定了通信過程的動作的順序，轉換流程在需求中指定。其中包括了車輛終端在網絡中IP地址的分配、車輛識別、連接建立、通信協(xié)議消息格式、到車輛節(jié)點的數據路由、狀態(tài)信息和錯誤處理?？梢詫⑦@些流程劃分為DoIP通信的三、個主要階段，分別為：車輛識別、路由激活和診斷通信階段。

1.2.DoIP報頭格式和報頭處理

由于DoIP現(xiàn)協(xié)議是基于以太網技術的車輛診斷協(xié)議，所以診斷數據在OSI參考模型各分層傳遞方式與傳統(tǒng)以太網一致。DoIP協(xié)議規(guī)范了網絡通信中TCP/UDP數據包中有效載荷（Payload）部分內容，在TCP/IP與更高層診斷協(xié)議之間提供了統(tǒng)一接口，DoIP報文由DoIP報頭和有效載荷組成，其中有效載荷根據DoIP報文的不同功能有不同的類型，其與傳統(tǒng)以太網幀的關系如下圖所示。

DoIP報頭 由協(xié)議版本 、反向協(xié)議版本、有效載荷類型和有效載荷長度組成，下表展示了DoIP報頭結構。

協(xié)議版本用來表示DoIP協(xié)議版本的編號，其范圍為0x00到0xFF。0x01代表ISO/DIS13400-2：2010，是第一版DoIP協(xié)議草案；0x02代表ISO13400-2：2012；0x03代表目前最新的ISO13400-2：2019。0xFF為默認值，用于在客戶端DoIP實體支持多個協(xié)議版本，且沒有有關實體支持的DoIP版本信息時，測試設備發(fā)送的DoIP報文才使用此默認值。但是建議提前確認好使用的協(xié)議版本，以便數據傳輸的可靠性，一般以最新版本為準。

反向協(xié)議版本是協(xié)議版本與16進制字節(jié)0xFF之間邏輯異或運算的結果，該值與DoIP協(xié)議版本配合起到協(xié)議版本驗證的作用，以確保能接收到正確的DoIP報文。

有效載荷類型用于標識DoIP通信中使用的不同類型報文，也 可 被 稱 為 DoIP 報 文 類 型 。其 中 主 要 分 為 三 種 分 組 ：節(jié) 點 管 理 報 文 、車輛信息報文和診斷報文，三個分組下又被分成了不同類型報文，包括對應傳輸層協(xié)議如下表所示。

節(jié)點管理消息：用于節(jié)點管理的消息組成。從通信階段來看，車輛識別和路由激活階段的消息，以及車輛與測試設備連接后用于查詢測試設備是否仍處于活躍狀態(tài)的活動檢查消息一起屬于該類別。

車輛信息消息：用于收集執(zhí)行診斷之前可能有用的DoIP實體和特定車輛的信息，例如檢索當前被診斷車輛的診斷電源模式以及其他車輛工作條件信息，以此來判斷當前車輛條件是否適合進行診斷。

診斷消息：封裝有上層的診斷協(xié)議，在本文中討論的為目前應用較為廣泛的UDS協(xié)議。

有效載荷長度：用來表示包含DoIP報文是數據的長度，該長度以字節(jié)為單位，且不包括DoIP報頭字節(jié)。根據DoIP報文有效載荷類型的不同，有的類型長度固定，有的類型長度可變。但是范圍需要控制在0到4294967295個字節(jié)，這要求在數據傳輸之前根據報文類型的不同對數據的大小進行計算以確保數據完整正確的傳輸。

1.3??DoIP 報頭處理

DoIP報頭一方面能夠標識其為DoIP報文，另一方面通過DoIP協(xié)議中的報頭處理機制，能夠屏蔽錯誤或無法處理等情況的報文，如果報文不能被正確的處理，DoIP實體需要響應一個長度為1字節(jié)的否定響應代碼（Not Acknowledge，NACK）。否定應答代碼用來指示在DoIP報頭中檢測到的特定錯誤，并指示接收到否定響應代碼的DoIP實體執(zhí)行后續(xù)操作。需要注意的是，如果出現(xiàn)特殊的錯誤情況，不得進行否定響應，具體情況可參考ISO 13400文檔。

下表展示了ISO 13400文檔中描述的5種錯誤報文對應的否定響應代碼和跟進操作，包括如何處理消息和通信連接，并對未來可能出現(xiàn)的情況保留的更新空間。

下面將結合ISO 13400文檔中相關“需求”，進一步討論DoIP報頭處理機制是如何在數據傳輸之初提供可靠性保障，并解釋這些機制背后的思想。

需求[DoIP-039]指出，DoIP實體應該忽略帶有否定響應代碼（NACK）的DoIP報文，換句話說，否定響應只有DoIP實體發(fā)送至測試設備單向有效，而在另一個方向無效。隨后的[DoIP-040]指出測試設備不得發(fā)送帶有錯誤響應代碼（NACK）的報文。這兩個需求共同阻止DoIP實體與測試設備之間來回重復的錯誤響應代碼（NACK）發(fā)送，避免了惡意消耗帶寬的網絡攻擊手段。

需求[DoIP-031]指出，接收節(jié)點應忽略任何以多IP或廣播IP為源地址的數據包。從安全角度來說，有助于防止攻擊者將此類數據發(fā)送至合法主機，如防止DoIP實體回復多播或廣播地址。

需求[DoIP-041]到[DoIP-045]包含了上面表格中幾種不同類型錯誤的詳細描述和采取跟進操作，ISO13400-2：2019文檔中圖16通過狀態(tài)機描述了對DoIP報頭檢查順序，也就是說定義了按照什么順序處理消息和Socket連接。這兩點有助于減輕由協(xié)議版本或DoIP報文類型識別錯誤而產生的數據解析歧義。

[DoIP-041]規(guī)定DoIP實體接收到的DoIP報頭中協(xié)議版本和反向協(xié)議版本應為ISO 13400標準中規(guī)定的值，對報文協(xié)議版本進行提前確認有助于保證了數據解析的正確性。此機制也是一種簡單的數據完整性檢查機制，但其僅覆蓋8個報頭字節(jié)的前兩個字節(jié)，顯然無法較好確保數據完整。

[DoIP-042]的要求與[DoIP-041]類似，DoIP報文類型需要滿足ISO 13400標準規(guī)定的值。由于這些值定義明確，因此DoIP實體能夠明確接收的是哪種類型報文。針對協(xié)議的攻擊一般采用發(fā)送隨機消息，發(fā)送的數據無意義，以上兩種檢測機制有效降低了這類攻擊的效果。

[DoIP-043]和[DoIP-044]的規(guī)定類似，都是對有效載荷長度的檢查，區(qū)別在[DoIP-043]是將有效載荷長度與接收實體設置的最大處理長度比較，檢查是否有處理能力，而[DoIP-044]則是與接收實體中內存最大容量相關，可能出現(xiàn)滿足最大處理長度但內存空間被占用，暫時無法接收的情況。此機制可以防止數據溢出，避免占用接收實體過多資源，某些網絡攻擊也會利用數據溢出使ECU產生故障。

[DoIP-045]規(guī)定接收數據的DoIP實體應檢測有效載荷長度與DoIP報文類型要求的長度是否匹配。如果兩者不匹配，則該報文的內容存在問題，接收實體不需要處理。

1.4 DoIP報頭傳輸層端口分配

由于DoIP是基于Socket的網絡通信方式，所以實現(xiàn)通信之前，需要對數據傳輸使用的端口進行分配。ISO 13400文檔依據不同的功能對TCP和UDP協(xié)議的端口使用進行了建議。

在建立TCP通信過程中，測試設備自動選擇端口號作為發(fā)送端口，向車內DoIP實體的13400端口發(fā)送消息；建立UDP通信過程分為兩類，一類是測試設備主動發(fā)送的請求報文，另一類是測試設備被動接收的報文，這兩類報文的目標端口都是13400端口。下表展示了DoIP診斷過程中各類報文的端口使用情況。

以上端口名稱與端口號的對應關系為， TCP_DATA：13400 UDP_DISCOVERY：13400

UDP_TEST_EQUIPMENT_REQUEST：動態(tài)分配。

1.5?DoIP診斷的主要階段

車輛識別 車輛識別階段作用于車輛與測試設備建立連接的初期，為了測試設備能夠準確的識別目標車輛和DoIP實體，并明確建立連接的目標IP地址以及其安裝在哪輛車上。該階段包括三種類型的DoIP報文，分別為車輛聲明、車 輛 識 別 請 求 ?和 車 輛 識 別 響 應 。車輛聲明和車輛識別響應由車輛端或DoIP實體端發(fā)送至測試設備，車輛識別請求由測試設備發(fā)送至車輛端或DoIP實體端，詳細信息如下表所示。

下面將分別介紹上述三種類型DoIP報文，報文名稱后括號內的16進制數為對應DoIP報文類型標識符。 車輛識別請求：不包含任何應用數據，只為了測試設備主動要求建立連接。車輛識別請求消息的DoIP報文分為三種情況，分別為無有效載荷車輛識別請求（0x0001）、有效載荷為EID的車輛識別請求（0x0002）和有效載荷為VIN的車輛識別請求（0x0003）。區(qū)別在于有效載荷內容分別為空、6字節(jié)的EID和17字節(jié)的VIN。采取哪種情況的車輛識別請求根據實際需求而定，由測試設備希望通過EID還是VIN識別到特定的車輛決定。車輛識別請求三種DoIP報文有效載荷中的格式如下圖所示。 其中，EID為DoIP實體的唯一ID，由于要求具有唯一特性，一般建議采用網絡接口的MAC地址作為該DoIP實體的EID，且MAC地址在長度與ISO 13400中要求EID長度一致，都為6字節(jié)。VIN文稱車輛識碼，車輛唯一標識序列號，由17個英文和數字組成，在數據類型上由17個字節(jié)的ASCII碼組成。

車輛聲明（0x0004）和車輛識別響應（0x0004）：擁有同樣的有效載荷結構，其內容都為描述DoIP實體基本信息的數據，但車輛聲明和車輛識別響應的應用場景不同。車輛聲明用于在沒有接收到測試設備請求的情況下，主動向網絡廣播自己的信息，測試設備依據需求判斷是否需要與正在廣播的DoIP實體建立連接。車輛識別響應是DoIP實體接收到車輛識別請求后，對請求作出的積極響應（如上文提到的包含EID或VIN的車輛識別請求）。車輛聲明和車輛識別響應有效載荷的結構如下圖所示。

路由激活

ISO 13400規(guī)定，當測試設備需要通過車載DoIP網關將報文路由到車輛內部網絡之前，需要執(zhí)行路由激活階段，用于激活TCP_DATA Socket上的路由。該階段包括路由激活請求和路由激活響應。路由激活請求報文由測試設備發(fā)送至DoIP實體，路由激活響應由DoIP實體發(fā)送至測試設備，詳細信息如下表所示。

路由激活請求報文（0x0005）的有效載荷中包含測試設備的源地址（SourceAddress，SA）、激活類型（Activation Type）、保留給ISO 13400-2今后擴展使用的部分和可以主機廠自定義的部分。其有效載荷的格式如下圖所示。

源地址（Source Address，SA）的類型為上文中描述的邏輯地址，此處源地址為路由激活報文發(fā)送方，也就是測試設備的邏輯地址，地址范圍應遵守ISO13400-2：2019中的規(guī)定，用于標識該報文由哪個測試設備發(fā)出。

激活類型（Activation Type）用來指示不同的身份驗證或確認路由激活的特定類型。具體來說分為默認激活模式、法規(guī)要求的診斷通信激活（例如全球調和車載診斷系統(tǒng)（WWH-OBD））和由主機廠定義的激活類型，如主機廠可能需要在路由激活過程中添加安全驗證。

ISO保留部分為未來文檔完善升級保留了空間，目前默認用0x00填充。

主機廠自定義部分非強制要求項（Mandatory），由企業(yè)根據自身需求決定是否在有效載荷中保留此項。

路由激活響應報文（0x0006）為對路由激活請求報文的響應，是在車內DoIP實體成功接收到路由激活請求報文，并通過一系列驗證處理，允許車輛外部報文路由到車內之前發(fā)送的報文。其有效載荷的格式如下圖所示。

測試設備地址（Logical Address Of Client DoIP Entity）和實體地址（LogicalAddress Of DoIP Entity）分別為測試設備與車內發(fā)送路由激活響應報文的DoIP實體的邏輯地址，車內進行路由激活響應的節(jié)點一般為車內的DoIP邊緣接或車載網絡各網段的入口節(jié)點。

響應代碼（Response Code）為DoIP實體對路由請求報文的響應狀態(tài)，如果車內節(jié)點拒絕路由激活請求，則通過該響應代碼告知測試設備拒絕原因，成功的路由激活意味著接下來可以通過TCP_DATA路由診斷消息到車內網絡。不同響應代碼的含義在ISO13400-2：2019中有明確的規(guī)定，其中包含強制要求和主機廠可自定義部分。成功的路由激活是測試設備與車內DoIP實體進行診斷通信的前提。

ISO保留部分為未來文檔完善升級保留了空間，目前默認用0x00填充。

OEM保留項為主機廠功能擴展使用，與路由請求中保留項一樣，是可選項。

診斷通信

在完成車輛識別和路由激活后，診斷數據才能通過網絡在車輛與測試設備之間傳輸，從診斷通信階段才開始正式的診斷數據的交互。診斷通信報文因為其特定的格式，被允許路由（診斷請求）到車輛網絡，并從車輛網絡路由（診斷響應）回測試設備，DoIP實體對診斷請求的響應包括肯定響應和否定響應。但當車輛中的DoIP實體向測試設備發(fā)送診斷消息時，測試設備不應響應。值得注意的是，DoIP協(xié)議增加了對DoIP診斷報文響應，這一點需要與對DoIP上層的高層協(xié)議（如UDS協(xié)議）的響應區(qū)分開，對DoIP報文的響應，包含對邏輯地址、診斷數據長度等信息的響應，后文中會做詳細介紹；對高層協(xié)議的響應（包括肯定響應和否定響應）被填充在診斷響應報文（DoIP報文）的有效載荷中。

診斷通信階段的報文有4種，分別為診斷請求和診斷響應報文、DoIP報文ACK響應報文和DoIP報文NACK響應報文，其中診斷請求報文和診斷響應報文有效載荷的格式一致，用于承載高層協(xié)議的診斷數據（UDS診斷數據），且其報文類型標識符一致，都為0x8001；DoIP報文ACK響應報文和DoIP報文NACK響應報文結構相似，用于對DoIP報文的響應，響應過程不涉及高層協(xié)議，唯一的區(qū)別在于響應代碼是ACK還是NACK。ACK代表肯定的響應，即當前DoIP報文可以通過檢測，并能將高層協(xié)議的診斷數據傳輸到目標車內的DoIP實體進行處理；NACK代表否定響應，即當前DoIP報文的信息未通過檢測，則高層協(xié)議的診斷數據無法被車內DoIP實體處理。

診斷請求（0x8001）和診斷響應（0x8001）報文有效載荷的格式如下圖所示。

源邏輯地址（Source Address）和目標邏輯地址（Target Address）分別為測試設備和車內網絡中目標DoIP實體的邏輯地址，用來標識發(fā)送方和接收方是否與路由激活階段建立連接的一致。需要注意的是，不論當前報文為診斷請求還是診斷響應報文，其源邏輯地址都為測試設備的邏輯地址，目標邏輯地址都為車內網絡中DoIP實體的邏輯地址。

用戶數據（User Data）為高層協(xié)議的診斷數據內容（如ISO 14229-1中要求的診斷請求和診斷響應），高層協(xié)議的診斷請求和響應被將填充到“用戶數據”中，隨DoIP診斷通信報文的請求被路由到目標車內DoIP實體。如果網路中的診斷數據的目標節(jié)點是不支持DoIP協(xié)議的CAN節(jié)點，則數據應該通過支持DoIP協(xié)議的節(jié)點將接收到的用戶數據通過CAN總線轉發(fā)給目標CAN節(jié)點，并將CAN節(jié)點的診斷響應打包在DoIP報文中發(fā)送到網絡中，如果其他種類的車載網絡節(jié)點有同樣的需求，也通過類似的方式實現(xiàn)診斷數據的轉發(fā)。

DoIP報文ACK（0x8002）和NACK（0x8003）響應報文有效載荷的格式如下所示。

接收到以上兩種DoIP報文的測試設備會根據有效載荷中ACK或NACK響應代碼的含義進行下一步操作。兩種響應代碼的范圍都是0x00至0xFF，其中，ACK代碼的值為0x00時指示能夠正確接收診斷報文，0x01到0xFF由ISO 13400-2:2019文檔保留，暫時不開放使用；NACK代碼比較多，不同的代碼表示不能正確接收DoIP診斷請求報文的原因，下表展示了NACK代碼的內容。

編輯：黃飛

?