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

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

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

ISO134001-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ù)包中有效載荷（Paylo（ad））部分內(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：2023，是第一版DoIP協(xié)議草案；0x02代表ISO13400-2：2023；0x03代表目前（最新）的ISO13400-2：2023。0xFF為默認值，用于在客戶端DoIP實體支持多個協(xié)議版本，且沒有有關(guān)實體支持的DoIP版本信息時，測試設(shè)備發(fā)送的DoIP報文才使用此默認值。但是建議提前確認好使用的協(xié)議版本，以便數(shù)據(jù)傳輸?shù)目煽啃?，一般以（最新版）本為?zhǔn)。

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

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

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

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

診斷消息：封裝有上層的診斷協(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報頭一方面能夠標(biāo)識其為DoIP報文，另一方面通過DoIP協(xié)議中的報頭處理機制，能夠屏蔽錯誤或無法處理等情況的報文，如果報文不能被正確的處理，DoIP實體需要響應(yīng)一個長度為1字節(jié)的否定響應(yīng)代碼（Not（Ac）know（led）ge，NACK）。否定應(yīng)答代碼用來指示在DoIP報頭中檢測到的特定錯誤，并指示接收到否定響應(yīng)代碼的DoIP實體執(zhí)行后續(xù)操作。需要注意的是，如果出現(xiàn)特殊的錯誤情況，不得進行否定響應(yīng)，具體情況可參考ISO13400文檔。

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

下面將結(jié)合ISO13400文檔中相關(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è)備之間來回重復(fù)的錯誤響應(yīng)代碼（NACK）發(fā)送，避免了惡意消耗帶寬的網(wǎng)絡(luò)攻擊手段。

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

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

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

[DoIP-042]的要求與[DoIP-041]類似，DoIP報文類型需要滿足ISO13400標(biāo)準(zhǔn)規(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.4DoIP報頭傳輸層（端口）分配

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

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

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

UDP_（TE）ST_EQUIPMENT_REQUEST：動態(tài)分配。

1.5

DoIP診斷的主要階段

車輛識別車輛識別階段作用于車輛與測試設(shè)備建立連接的初期，為了測試設(shè)備能夠準(zhǔn)確的識別目標(biāo)車輛和DoIP實體，并明確建立連接的目標(biāo)IP地址以及其安裝在哪輛車上。該階段包括三種類型的DoIP報文，分別為車輛聲明、車輛識別請求

和車輛識別響應(yīng)。車輛聲明和車輛識別響應(yīng)由車輛端或DoIP實體端發(fā)送至測試設(shè)備，車輛識別請求由測試設(shè)備發(fā)送至車輛端或DoIP實體端，詳細信息如下表所示。

下面將分別介紹上述三種類型DoIP報文，報文名稱后括號內(nèi)的16進制數(shù)為對應(yīng)DoIP報文類型標(biāo)識符。車輛識別請求：不包含任何應(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地址在長度與ISO13400中要求EID長度一致，都為6字節(jié)。VIN文稱車輛識碼，車輛唯一標(biāo)識序列號，由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)如下圖所示。

路由激活

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

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

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

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

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

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

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

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

響應(yīng)代碼（ResponseCode）為DoIP實體對路由請求報文的響應(yīng)狀態(tài)，如果車內(nèi)節(jié)點拒絕路由激活請求，則通過該響應(yīng)代碼告知測試設(shè)備拒絕原因，成功的路由激活意味著接下來可以通過TCP_DATA路由診斷消息到車內(nèi)網(wǎng)絡(luò)。不同響應(yīng)代碼的含義在ISO13400-2：2023中有明確的規(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)。但當(dā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ù)），且其報文類型標(biāo)識符一致，都為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)，即當(dāng)前DoIP報文可以通過檢測，并能將高層協(xié)議的診斷數(shù)據(jù)傳輸?shù)侥繕?biāo)車內(nèi)的DoIP實體進行處理；NACK代表否定響應(yīng)，即當(dāng)前DoIP報文的信息未通過檢測，則高層協(xié)議的診斷數(shù)據(jù)無法被車內(nèi)DoIP實體處理。

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

源邏輯地址（SourceAddress）和目標(biāo)邏輯地址（TargetAddress）分別為測試設(shè)備和車內(nèi)網(wǎng)絡(luò)中目標(biāo)DoIP實體的邏輯地址，用來標(biāo)識發(fā)送方和接收方是否與路由激活階段