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

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

1.2.DoIP報(bào)頭格式和報(bào)頭處理

由于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報(bào)文由DoIP報(bào)頭和有效載荷組成，其中有效載荷根據(jù)DoIP報(bào)文的不同功能有不同的類型，其與傳統(tǒng)以太網(wǎng)幀的關(guān)系如下圖所示。

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

協(xié)議版本用來表示DoIP協(xié)議版本的編號，其范圍為0x00到0xFF。0x01代表ISO/DIS13400-2：2010，是第一版DoIP協(xié)議草案；0x02代表ISO13400-2：2012；0x03代表目前最新的ISO13400-2：2019。0xFF為默認(rèn)值，用于在客戶端DoIP實(shí)體支持多個協(xié)議版本，且沒有有關(guān)實(shí)體支持的DoIP版本信息時，測試設(shè)備發(fā)送的DoIP報(bào)文才使用此默認(rèn)值。但是建議提前確認(rèn)好使用的協(xié)議版本，以便數(shù)據(jù)傳輸?shù)目煽啃裕话阋宰钚掳姹緸闇?zhǔn)。

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

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

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

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

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

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

1.3??DoIP 報(bào)頭處理

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

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

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

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

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

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

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

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

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

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

1.4 DoIP報(bào)頭傳輸層端口分配

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

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

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

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

1.5?DoIP診斷的主要階段

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

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

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

路由激活

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

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

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

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

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

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

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

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

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

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

OEM保留項(xiàng)為主機(jī)廠功能擴(kuò)展使用，與路由請求中保留項(xiàng)一樣，是可選項(xiàng)。

診斷通信

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

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

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

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

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

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

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

編輯：黃飛

?