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

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

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

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

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

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

協(xié)議版本用來表示DoIP協(xié)議版本的編號，其范圍為0x00到0xFF。0x01代表ISO/DIS13400-2：2010，是第一版DoIP協(xié)議草案；0x02代表ISO13400-2：2012；0x03代表目前最新的ISO13400-2：2019。0xFF為默認值，用于在客戶端DoIP實體支持多個協(xié)議版本，且沒有有關(guān)實體支持的DoIP版本信息時，測試設(shè)備發(fā)送的DoIP報文才使用此默認值。但是建議提前確認好使用的協(xié)議版本，以便數(shù)據(jù)傳輸?shù)目煽啃?，一般?a href="http://ttokpm.com/article/bbs/" target="_blank">最新版本為準。

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

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

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

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

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

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

1.3??DoIP 報頭處理

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

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

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

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

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

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

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

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

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

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

1.4 DoIP報頭傳輸層端口分配

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

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

以上端口名稱與端口號的對應(yīng)關(guān)系為， TCP_DATA：13400 UDP_DISCOVERY：13400

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

1.5?DoIP診斷的主要階段

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

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

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

路由激活

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

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

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

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

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

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

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

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

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

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

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

診斷通信

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

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

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

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

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

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

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

編輯：黃飛

?