01 概述

所謂的DoIP其實就是基于以太網的通訊協議對UDS協議的數據進行傳輸，即Diagnostic communication over Internet Protocol。其本身也是一種協議，規范于ISO13400標準。由于DoIP可以傳輸大量數據，以及響應速度快，且可以通過以太網進行遠程診斷，因此DoIP逐步成為代替傳統的CAN等總線方式，成為車載網絡診斷的必然趨勢。

DoIP在車載領域的應用首先汽車系統的整體框架要能夠支持DoIP，正因為車載以太網的快速發展，相較于傳統的車載系統，目前的車載系統的整體框架都會加入一層DoIP協議層，在TCP/IP之上。并且為了更好的配合OBD診斷，遠程診斷，FOTA等等技術，對整體的車載架構進行了調整，利用swich將MPU，MCU，其它以太網ECU統統通過以太網進行連接，并對外網與內網進行隔離。

當然，DoIP并不僅僅只是UDS的載體，雖然在ISO13400標準中內容不多，但是它也有自己的一些邏輯，不可能說在TCP/IP之上加了一層封裝就完成了自己的任務，這樣的話安全性就沒有保證了，畢竟車載以太網通過網絡能夠將車內與車外進行網絡的連接，而DoIP又是診斷的入口，這個門口如果不好好看住，會存在安全性的問題的。

簡單的說，DoIP能夠進行車輛發現，狀態查詢，路由激活（含安全認證），診斷數據收發，這些內容將在后續進行詳細的展開。

有了DoIP，那么UDS的數據傳輸就可以搭載在DoIP之上，并在DoIP前序邏輯都OK的情況下，進行UDS的傳輸。當然DoIP之上也可以不搭載UDS數據，這屬于客戶定制，能夠滿足以太網傳輸的一些其它特殊需求。

02 DoIP的網絡拓撲

在ISO13400-2中有如下一張圖，比較具有代表性，我們本文主要就根據此網絡拓撲圖來介紹DoIP的網絡拓撲

從圖中不難看出，整車的網絡拓撲被分為了兩個部分，即內部網絡和外部網絡，圖中的network node可以默認為支持以太網連接的某個節點，如，雷達，攝像頭等，但是不支持DoIP協議，不過大家可以對名稱中含有DoIP前綴的節點進行網絡分析。從圖中我們很容易看出DoIP的網絡拓撲有以下幾個角色組成，

1.External test equipment

此部分為外部測試設備，通常為OBD診斷儀或者其他診斷客戶端

2. DoIP edge node gateway

此部分和DoIP gateway有什么區別？其實沒什么區別，唯一的區別就是多了個使能線的判斷，從圖中可以看出External test equipment和DoIP edge node gateway之間有一條線叫做Activation line。那么這條線的功能就是對協議棧進行使能作用的，當然External test equipment和DoIP edge node gateway之間不只是Activation line相連的，這個圖只是功能示意圖，少了很多細節，其實是通過標準的OBD-II接頭相連的，其中一個針腳就是Activation line。具體可以看ISO 13400-4的介紹。

回過來，這個角色的作用是什么？

首先它是個gateway，作為一個網關它的子網內掛載著若干ECU，與DoIP gateway一樣

其次它是車內網與車外網交互的一個入口，具有控制著DoIP協議棧是否工作的一個開關功能。

該角色可以同時支持Server端和Client端，Server好理解，測試設備可以診斷該網關下的某個ECU節點。那么Client端是怎么回事呢？想象一下，如果DoIP edge node gateway作為入口，那么怎樣和內部其它子網的DoIP ECU進行交互呢？當然是由DoIP edge node gateway進行轉發。這只是其中一個應用場景，當進行轉發的時候會進行身份切換，即由Server端切換到Client端。另外一個場景是OTA升級，DoIP edge node gateway的應用層可以跑一個OTA客戶端程序，進行對內網ECU的診斷及刷寫，此時就是一個Client身份。

3. DoIP gateway

DoIP gateway與角色二 DoIP edge node gateway區別不是很大。實際的應用場景通常會讓MCU充當這個角色，而MPU充當DoIP edge node gateway的角色，也有反過來的情況，那么該角色通常單單的跑Server端程序。

4. DoIP node

該角色很好理解，對支持以太網連接的同時支持DoIP協議的ECU認為是DoIP node。

該角色通常單單的跑Server端程序。

整個車輛網絡由四個角色組成，外部測試設備作為客戶端，對車內網的各個支持DoIP協議棧的ECU進行診斷。（部分CAN ECU通常掛載在MCU上，由MCU進行DoIP轉DoCAN的路由）車外網的外部測試設備通過OBD-II與車內網的edge gateway進行通信，edge gateway用來使能車內網的DoIP功能。在路由打通后，發送的診斷數據根據目的地址的不同分別流向車內網的不同ECU。

03 DoIP的接收方式和協議格式

3.1 端口

從DoIP名字可以看出，該協議是在TCP/IP之上的，那么要想接收DoIP協議的報文，協議書規定需要監聽一個專門分配給DoIP協議棧使用的端口號即13400，UDP，TCP都要監聽此接受端口，而發送端口是在一個范圍內的隨機值[49152~65535],當然代碼中協議棧要對對端的發送端口進行緩存，用于回送數據。

指定了端口號，客戶端和服務端可以在此端口上進行收發數據。那么對該端口收到的數據是否真的是DoIP報文，就行對該網絡報文進行解析。（有可能是網絡攻擊，有可能是其它應用恰好使用了該端口號）

對收到的報文進行解析，就涉及到DoIP協議的構成，只有符合該寫一點規范才認為是合法有效的DoIP報文。

3.2 協議格式

DoIP報文由協議頭（header）+ 負載（payload）組成

協議頭[8 byte]由下面四個字段組成

Protocol version [1 byte]

Inverse protocol version [1 byte]

Payload type [2 byte]

Payload length [4 byte]

負載[N byte] 根據實際的payload type，負載數據會不同

3.3Protocol version與Inverse protocol version

通常Protocol version為0x02，目前0x02以上的值目前是reserved狀態

Inverse protocol version是Protocol version的取反的值，此例0x02去反后為0xFD

協議書上特別說明了Protocol version可以為0xFF，設這個值的作用是，當客戶端和服務端的協議版本不匹配，可以設置此值繞過協議頭版本不匹配而拒絕請求的case。

3.4 Payload type

payload type可以代表DoIP協議棧所能支持的功能，列舉如下（特意分開了Server支持的type及Client支持的type）

DoIP SERVER

DoIP Client

如上分開描述，是因為在代碼實現上，可以將邏輯拆分。

即Server端只關心自己支持的payload type，客戶端只關心自己支持的payload type，不支持的可以忽視掉。有利于模塊拆分及組合，有利于實現上一節所講個各個角色，將來通過配置文件的配置，來表示不同的角色。

3.5 Payload length

payload length這里分配了4字節，也就是所DoIP報文最大傳輸4 GB /4294967295 bytes，即0xFFFFFFFF。它只是個允許的范圍，通常來說通過DoIP進行診斷也就幾字節到幾十字節，而升級通常ECU的升級包也就幾MB。所以4 GB只是個理論上限。

該值可以做長度的有效性驗證，因為除了診斷數據，其它payload type都是有固定長度的。

還可以做什么？其實做開發時還要考慮遇到如下情況該怎么處理

1. 數據粘連

2. 數據截斷

3. 異常的超大size

4. 超過協議棧可以處理size

3.6 Payload

這里的負載是指的是DoIP協議的負載，當然當Payload type為診斷類型時，其負載除了DoIP自身的內容，

還包含了UDS數據，供上層UDS模塊進行進一步的解析。

因為每個Payload type負載都不同，這里不做解釋，在后續功能章節，進行詳細的介紹

04?DoIP診斷啟動與使用

4.1 連接建立

DoIP實體內管理著一個DoIP connection table ，用來記錄和維護診斷通信的邏輯連接。上圖就是這個表中的一個元素，即一個邏輯連接的狀態機。上圖中的方框就是連接所處的狀態，[Step]是狀態之間跳轉時發生的事情。

[Step1] 當一個新的套接字建立，邏輯連接的狀態就從“listen”跳轉到“socket initialized”，同時啟動一個定時器， initial inactivity timer。

[Step2] 當DoIP實體接收到tester發來的一個routing activation信息后，邏輯連接的狀態就從“socket initialized”跳轉到“Registered [Pending for Authentication]” ，此時 initial inactivity timer被停止，啟動一個名為general inactivity timer的定時器。

[Step3] 在完成Authentication之后，邏輯連接的狀態就從“Registered [Pending for Authentication]”跳轉到“Registered [Pending for Confrmation]” 。

[Step4] 在完成Confrmation之后，邏輯連接的狀態就從“Registered [Pending for Confrmation]”跳轉到“Registered [Routing Active] ” 。

[Step5] 如果initial timer 或general inactivity timer 過期后仍沒收到后續請求，或者authentication 和 confrmation 被拒絕了，又或者外部測試設備對alive check 消息沒有響應，則邏輯連接進入“Finalize”狀態。

[Step6]進入Finalize后，此時TCP套接字將被關閉，并重新回到“listen”狀態。

4.2 車輛發現

當DoIP實體和外部測試設備都連接到一個網絡中時，它們會利用DHCP協議獲得一個屬于自己的IP地址。在網絡中，路由器作為DHCP server，為新加入到該網絡中的設備分配IP地址。在獲取IP地址之后，有兩種車輛發現的方法，如上圖所示。一種方法是車輛主動上報自己的信息3次。如果測試設備沒有收到車輛主動上報的信息，則會發送一個identification request，如果網絡中有車輛的話，車輛對這個請求進行響應，測試設備便發現了被測車輛。

4.3 會話建立

在診斷儀發現車輛之后，會把車輛添加到自己的車輛列表中。當用戶選擇這個列表中的某輛車，如果連接建立成功，用戶就可以對車輛進行診斷了。

接下來用戶給汽車發出診斷信息，網關會根據信息接收對象把診斷信息轉發給網絡中相關的ECU，當得到ECU 的響應之后，網關再把最終的響應發送給診斷儀。當用戶選擇退出時，用于DoIP通信的這個套接字就被關閉了。

下圖是一個DoIP數據完整結構的數據舉例：

DoIP數據完整結構舉例

byte 0：ISO13400 版本

byte 1：ISO13400 版本逐比特取反

byte 2~3：數據類型，0x8001，表明這是一個診斷信息的數據包

byte 4~7：數據長度，在這個例子中的值是7，表示后面有7個字節的數據

byte 8~9：源地址

byte 10~11：目的地址

byte 12~13：具體的診斷命令，SID是22，表示讀取，DID是0xF8 10

這個數據段作為SDU傳遞給下層協議，逐層封裝成為完整的以太網幀發送出去。

審核編輯 ：李倩

?