0 序言

在之前工作過程中，進行測試時，如果單板有故障，習慣性地會去找軟件同事幫忙讀一下故障碼。很多時候，這個故障碼會提示我的排查方向。如果沒有軟件的診斷支持，我也能一步一步去逼近問題，但效率比較低。

前司的產品，各個模塊都是自研的，所以其故障診斷的邏輯可以自行定制。新的項目里說要加一個診斷功能，只要硬件在設計上做支持，軟件添加相應代碼即可。但對于汽車這種復雜產品而言，在前期分布式架構階段，整車廠更像一個集成商的角色，買各家供應商的ECU。行業只要有分工，就必須要有規范，這樣才能提高生產效率，實現收益最大化。于是，各家遵循統一的診斷標準就是必然的事。即使后期EEA發展成中央集成架構，OEM自己研發所有的控制器，這種診斷標準應該也會沿襲下來。

越是復雜的系統越是需要完善的故障診斷系統，否則問題定位的代價會很大，售后成本會很高。此外，智能化是汽車的發展趨勢之一，智能化的本質就是將人做的是交給車自己來做。人根據五官收集的信息做出綜合判斷，然后進行相關操作。如果要車去做決策，首先就需要讓車能夠獲得足夠多的信息。自動駕駛的感知和定位模塊，是車對外界環境的感知。另一方面，車還需要對自身內部有足夠強的感知能力，那就需要有監測和診斷系統。如果一個傳感器或執行器損壞了，而系統不自知，那么這是一個不穩定的開環系統，遲早要翻車。另外，根據我個人的感受，一個產品的診斷系統做得是否完善，很大程度上反應了這個產品的成熟度。因為只有一個產品的其他主要功能都搞好了，穩定了，工程師們可能才會有余力著重去提升產品的其他部分。

? 1 UDS概述

說到車的診斷，就要引出今天的主角，即UDS協議。UDS（Unified Diagnostic Services）是ISO 14229定義的一種汽車通用診斷協議，位于OSI模型中的應用層，它可在不同的汽車總線（如CAN、LIN、Flexray、以太網）上實現，用于車輛電子系統的故障診斷和通信。它提供了一組標準化的診斷服務，允許診斷工具與車輛的電子控制單元（ECU）進行通信，以診斷和解決故障。

說點UDS具體的場景應用：

（1）ECU開發過程要用到它來構建bootloader，上傳和下載數據，即軟件刷寫，控制器Reset；

（2）測試時要用它來讀寫存儲，控制外設；

（3）產線上，要用它來校準機械件，控制例程，進行下線執行器測試，刷新軟件，配置防盜，讀取號碼，下線配置等；

（4）在行駛過程中，要用它來監測各種故障，并記下故障碼；

（5）4S店里，技師需要讀取當前故障、歷史故障，讀取故障發生時刻環境信息狀態，清除故障，判斷故障發生點，還可以用來升級ECU程序。

JTAG是針對MCU或者SOC這種芯片的調試接口協議，而UDS更像是針對整個ECU的調試接口。UDS簡單來說是一種Client/Server的通信服務，即Tester（診斷儀）向ECU發送診斷服務請求（Request），ECU則向Tester發送對應服務請求的響應（Response）。

UDS在OSI模型中的位置如下所示。ISO14229有中文版本，可以搜索《道路車輛 統一診斷服務(UDS)》

從上圖中可知ISO 14229-1定義了UDS的規范和要求。上面講到了，UDS可以在不同的總線上實現，于是下面的ISO14229-3定義了UDSonCAN，即UDS在CAN上的具體實現，ISO14229-3還是屬于應用層的。同理，ISO14229的其他部分標準分別規定了UDS在不同總線上的實現細節。其中UDSonIP規定的是基于IP實現的UDS，常用的IP網絡其實就是以太網了。ISO 14229-2定義了會話層的相關標準。

在學習過程中，有看到這樣的說法：“UDS（Unified Diagnostic Services）是ISO 15765和ISO 14229定義的一種汽車通用診斷協議”，這說的不嚴謹，這說的其實是UDS在CAN總線上的實現，其網絡模型如下。ISO15765-2可以用ISO 14229-2加上ISO14229-3替代。

以太網可以確定會成為未來車輛內的主干總線，當10base-T1標準完善，以太網可能會完全取代CAN總線。因此本文關注UDS在CAN和以太網上的實現。

在剛學習的時候，會對UDSonCAN和DoCAN有疑問，不知道二者有什么區別。DoCAN的全稱是Diagnosis on CAN。UDSonCAN和DoCAN是在通信模型不同層中的不同叫法，其規定了不同層的技術標準。UDSonCAN僅存在于應用層，而DoCAN只適用于網絡層和傳輸層。

這里要說下OBD，因為在看診斷的時候，也有看到OBD的概念，這也是UDS下面的一個分支。

OBD（全稱：On Board Diagnostics），即車載自動診斷系統，是汽車排放和驅動性相關故障的標準化診斷規范，有嚴格的排放針對性，其實質就是通過監測汽車的動力和排放控制系統來監控汽車的排放。當汽車的動力或排放控制系統出現故障，有可能導致一氧化碳(CO)、碳氫化合物(HC)、氮氧化合物(NOx)或燃油蒸發污染量超過設定的標準，故障燈就會點亮報警。

OBD與UDS的區別是：

（1）OBD是關注車輛實時排放的理念形成的行業規范，而UDS是診斷服務的統一化規范。電動車不需要滿足這個標準，因為沒有尾氣排放。燃油車通常既要滿足OBD，又要滿足UDS。診斷服務下面才會講到，看完診斷服務可以回頭看這里。UDS的診斷服務代碼是從0x10開始的，小于0x10的代碼則被OBD用了。

（2）UDS是面向整車所有ECU的，而OBD是面向排放系統ECU的。既然UDS可以用于所有的ECU，那是否能把OBD完全取代呢？這點不太清楚。

本文不關心OBD，只關心UDS。

2 基于CAN總線實現的UDS

ISO 14229-1定義了UDS的所有服務規范。UDS在CAN上的應用，相對于在其他總線上應用上可能有一些差別，把這部分摘出來形成標準就是ISO 14229-3，這是為了將UDS的主體部分摘出來，盡量和具體的總線解耦，便于后期標準各部分的擴展。ISO 14229-3的內容不是很多，主要是會話層的內容，定義了數據傳輸和接收的一些時間參數，如果不是深入做協議棧的開發，這部分甚至可以直接跳過。

在網絡層和傳輸層，遵循的是ISO 15765-2的標準。這里主要是為了解決應用層數據長度與CAN總線數據長度不統一的問題。UDS并不僅僅是為了CAN總線設計的，其最大容量可以達到4095字節，而經典CAN總線的數據長度是8個字節。如何科學、快捷、安全地將多個字節通過CAN總線傳輸出去，就成了一個需要解決的問題，這就需要用到ISO 15765-2。所以下面主要從ISO 14229-1和ISO 15765-2兩個方面來看基于CAN總線實現的UDS。

2.1 ISO14229-1是什么

ISO14229-1描述的是與診斷相關的服務需求，并未涉及通信機制，所以它可以在不同的汽車總線上實現。實際應用中，測試人員同步外部的診斷儀和車相連，而所謂的診斷服務，是指車能夠提供哪些信息反饋。

比如ECU接受特定的命令，進行重啟；又或者，ECU根據某個指令反饋某個存儲器某個地址的數據。這些都是已經約定好了的一些服務，這些服務的集合就是ISO14229-1標準。還是上面那句話，IS014229-1規定了要提供哪些服務，至于在具體總線協議上怎么實現，它不管。

UDS診斷包括6大類，26種服務，每種服務都有自己獨立的ID，即SID（Service Identifier）。

? ? 2.2 ISO14229-1請求/響應機制

在應用層，UDS的通信機制很簡單。診斷方發送服務請求，ECU返回響應。診斷服務的請求和響應根據是否具有Subfunction（子功能）分為兩類。什么是Subfunticon呢？以0x10這個服務為例，其服務種類是Diagnostic Session Control，即診斷會話控制。其實就是控制ECU進入不同的會話權限。這個服務常用的有三個子功能，服務子功能的代號是01-03。其中01是指默認會話；02是指編程會話；03是擴展會話。上電后ECU初始狀態是默認會話，這個狀態下，ECU能支持的診斷服務是有限的，如果想要ECU把更多的診斷服務開放出來，就需要申請其他子功能，比如進入擴展會話模式。關于0x10這個服務，下面細講。

2.2.1 不帶Subfunction的機制

下圖是不具有Subfunction的UDS診斷服務請求和響應機制。

（1）診斷方（Tester）向ECU發送指定的請求數據（Request），這條數據中需要包含SID，且SID處于該應用層數據的第一個字節。

（2）ECU接收到請求數據（Request）后會返回響應，可返回肯定響應或者否定響應。肯定響應是指正常回應服務請求，而否定響應是指由于某種原因沒有回應服務請求。在否定響應中，會有一個否定響應碼，即NRC，會表明否定響應的原因。有些地方也將肯定響應翻譯成正響應，否定響應翻譯成負響應。

（3）肯定響應（Positive Response）格式為：（SID+0X40）+數據。例如，請求0X10服務，肯定響應第1個字節為0X50；請求0X22服務，肯定響應第1個字節為0X62。

（4）否定響應（Negative Response）格式為：0X7F+SID+NRC。例如，請求0X10服務，否定響應第1個字節為固定的0X7F，第2個字節為0X10，第3個字節為NRC。NRC是否定響應碼，可以根據返回的NRC判斷是什么原因導致的否定響應。下圖是常見的一些NRC碼，需要看全的NRC碼，可以去查看標準原文。

舉兩個例子，比如否定響應碼0x11表示的是ECU不支持診斷方請求的服務，診斷方想讀取某個數據，但是ECU就沒有這個數據；0x78表示請求已經收到，但可能ECU正忙，無法回復請求。其余的NRC碼就不展開了，標準里都說明了對應的NRC碼的功能。

2.2.2 帶Subfunction的機制

下圖是有Subfunction的UDS診斷服務請求和響應機制。與不帶Subfunction的請求響應相比，其實也就是多了個Subfunction的編碼。

? 2.2.3 根據數據標識符讀寫

除了SID，SID+SF兩種請求命令的構成方式以外，還有SID+DID，SID+SF+DID兩種。其中DID是Data Identifier，即數據標識符。DID表示存儲數據的地方，一般存儲整車廠和零件供應商定義的數據，包括模擬輸入和輸出信號（比如轉速信號），數字輸入和輸出信號（比如車門信號），內部數據和系統狀態信息等。根據DID就可以知道需要調取哪些數據，而不必知道具體的內存位置。

2.3 診斷服務示例

2.3.1 診斷會話控制服務-0x10

UDS涉及26個服務，這里只試著講其中幾個，一個個講就是翻譯標準了，沒啥意義。先來看下診斷會話控制服務，上文在講Subfunction的時候其實就有提到0x10。

診斷會話控制服務被用來使能服務端中的不同診斷會話模式，診斷會話模式分為兩大類：默認會話和非默認會話，其中非默認會話又包括編程會話和擴展會話，如下圖所示。

這里分為三種會話模式，主要考慮的是服務的使用權限問題，不同會話模式下能使用的服務有區別，如下圖所示。

?

默認會話是指ECU在剛上電時保持的會話狀態，其服務的使用權限小，即可操作的功能單元服務少，比如不能使用27，28，83，84等服務；編程會話是僅使用與刷寫程序相關的診斷服務，比如27，31，34，36，37等服務；而擴展會話相較于默認會話，其使用服務的權限大，即可操作的功能單元服務多，默認會話模式下不能使用的服務，在擴展模式下都能使用。

模式切換遵循以下規則：

（1）當ECU上電時，ECU總是從默認會話模式開始。

（2）當ECU上電后，非默認會話沒被激活時，ECU會一直處于默認會話模式。

（3）當進入非默認會話后，如果服務端的S3定時器超時或請求了默認會話，將進入默認會話；

（4）當進入非默認會話后，如果控制服務端的S3定時器不超時，比如使用待機握手服務（$3E），則即可進行編程會話與擴展會話切換。

這里解釋以下S3參數，S3參數可分為S3server和S3client。前者是服務器的定時參數，通常取5000ms，僅用于非默認會話模式。在該模式下，如果在S3server時間內，服務端沒有接受到任何診斷請求服務，則退出非默認會話，返回默認會話。S3client是客戶端的定時參數，通常取4000ms。客戶端為了保持非默認會話的連接，可以通過發送3E請求（待機握手服務）來保持連接，但必須在S3server的時間內發送一次。相當于每4000ms，客戶端告訴服務端它還在，不要退出非默認會話。

下面來看下0x10的請求和響應格式。0x10是有多個子功能的，所以其請求格式為SID+SF。比如請求默認會話模式，客戶端會發送10 01；編程會話模式，則發送10 02，其他以此類推。需要說明的是上面提到了0x10的三個子功能，其實0x10的子功能不止三個，其他的子功能如下圖，這里不展開。

以客戶端發送了10 01為例，服務器端應回復50 01 xx xx xx xx。這里的xx是響應的相關參數，如下圖所示。

參數通常是會話參數，即P2Server和P2*Server，如下圖所示。

這里來解釋一下P2Server和P2*Server。

P2Server的定義如下，表示從服務器端接收到請求消息到開始發送響應消息的時間。通常取值為50ms。

P2*Server的定義如下，表示從服務器端接收到請求消息到開始發送響應消息的時間。通常取值為5000ms。

P2*Server的定義如下，表示從ECU發送了NRC為0x78的否定響應消息到開始發送下一個響應消息之間的additional max.time，通常取5000ms。

如果設置P2server_max=50ms，P2*server_max=5000ms，則肯定響應就是50 01 00 32 01 F4。

需要說明的是，時間參數不止以上兩個。會話層，即ISO 14229-2還定義了其他時間參數，有需要的可以查找標準。

當客戶端發送診斷服務請求，服務端需要回復否定響應時，這時否定響應格式為?7F+SID+NRC，0x10服務支持的部分NRC如下圖所示。

比如客戶端發送請求10 05，但服務端未定義05，即不支持該子功能，則產生否定響應7F 10 12；比如請求10 01 01，不符合請求格式SID+SF的長度，則產生否定響應7F 10 13。

2.3.2 安全訪問服務-0x27

訪問數據服務和某些診斷服務需要考慮保密或安全等原因，比如下載/上傳診斷服務例程或數據進入ECU并從其讀取特定的內存位置，或者下載到ECU中的不正確例程或數據可能會損壞電子設備或其他車輛部件，或危及車輛的排放和安全標準。為了解決這些情況，就定義了安全訪問服務。

安全服務的實現過程如下圖所示。

上圖中請求種子使用的格式是27 2n-1，原因是ECU需要解鎖情況有多種，比如擴展會話模式下讀寫數據前需要解鎖，比如采用27 01；編程會話模式下刷寫程序前也需要解鎖，比如采用27 03；當然可能還包括其他情況，故上圖采用27 2n-1就更具有概括性，可適用多種情況。2n-1具體對應解鎖什么服務，由整車廠自己定義。

當請求種子后，ECU就需要響應，發送種子。當客戶端收到種子后，通過某種算法獲得密鑰后，客戶端發送密鑰給ECU。發送密鑰的子功能代碼都是偶數。

舉個例子，假設擴展會話模式下，讀寫數據前需要先解鎖，比如約定好了，這種場景下解鎖采用的是27 01命令。我們發送27 01請求種子；ECU發送67 01 36 57，其中36 57是種子。密鑰是種子的二進制補碼，于是客戶端計算出密鑰是C9 A9；隨后通過27 02 C9 A9發送密鑰給ECU；ECU驗證正確后，回復67 02，表明解鎖成功。解鎖成功后，就可以讀寫數據了。

如果在解鎖狀態下，重復發送解鎖請求，比如發送27 01的命令，則ECU會回復67 01 00 00，表明ECU已解鎖。

27 01解鎖的是數據讀寫的功能，如果要解鎖刷寫程序的功能，假設刷寫程序解鎖的子功能代碼是03，則需要重復上面的，使用27 03等指令取解鎖刷寫程序的功能。

0x27服務支持的否定響應碼如下。舉個例子，如果客戶端給服務端發送的密鑰不對，那么服務端將會發送否定響應，即7F 27 35。

? 2.3.3 根據標識符讀數據-0x22

0x22是根據DataIdentifier（即DID）去請求讀取數據，其請求格式為SID+DID。這里請求的DID可以是一個，也可以是多個。其肯定響應的格式為(SID+40)+DID+Data，看一個例子。其中22是SID，響應時SID+40=62。F1 90為DID，紫色部分則為具體的數據。

再看請求兩個DID的情況。其中01 0A和01 10為兩個DID。A6-7E這部分數據為01 0A這個DID的數據，8C為DID=01 10的數據。

? ? 2.3.4 根據標識符讀數據-0x2E

0x2E是根據DataIdentifier（即DID）去請求寫入數據，其請求格式為SID+DID+Data.

注意這里一次只寫一個DID的數據，不像讀取數據服務可以一次讀取多個DID的數據。通過該服務可以：寫入一些配置信息到ECU（比如VIN碼，即車輛識別碼），清除非易失性數據，重置學習值，設置一些可選內容。

需要注意的是，2E服務需要ECU解鎖了才能執行，默認會話模式不支持該服務，所以要先進入非默認會話模式，然后解鎖，才能寫入數據。假設F1 90為DID，根據該DID寫入數據的整個過程見下圖。

? ? 2.4 ISO15765-2標準

15765-2作為車輛診斷通信的一個組成部分，規范了“傳輸協議和網絡層服務”。

UDS網絡層，又稱為TP層（Transport Protocol Layer）。其存在的目的是為了解決ISO 11898協議中定義的經典CAN數據鏈路層與ISO 14229協議中定義的應用層，彼此之間數據長度不統一的問題。經典CAN數據鏈路層最大能夠支持8個字節，但ISO 14229并不僅僅是為了CAN總線設計的，最大容量達到4095個字節。比如VIN碼是17個字節，CAN總線必然需要傳遞3幀才能傳完VIN碼，那么如何科學、快捷、安全地將多個字節通過經典CAN來進行傳輸，就成了一個需要解決的問題。ISO 15765-2 協議由此誕生。

網絡層協議數據單元（N_PDU，Network_Protocol Data Unit）包含N_AI，N_PCI，N_Data。即地址信息，協議控制信息和數據。

N_AI包含了源地址、目標地址和尋址方式信息，后面再展開。

N_PCI標識網絡層幀的類型。網絡層協議數據單元（N_PDU）有四種類型，即單幀（SF）、首幀（FF）、連續幀（CF）、流控制幀（FC）。

N_Data包含應用層協議控制信息和數據，即上文我們談到的那些。

2.4.1 N_AI

在發送報文的時候，需要在報文里體現自己是誰，報文要發給誰。這就是源地址（N_SA）、目標地址（N_TA）、目標地址類型（N_TAtype）、可選地址擴展（N_AE）。關于這幾個地址有幾點要說明。

（1）源地址和目標地址很好理解，但需要說明的是，一個設備的接收地址和發送地址是不一樣的。比如一個設備只接收目的地址為0x741的數據，但是它在回復數據時，使用0x749為源地址。即收發是使用不同的地址。

（2）目的地址類型分為兩種，物理地址和功能地址。物理地址是指一對一的尋址，功能地址是指廣播。每個ECU有不同的物理地址，當你想與特定的ECU通信時，需要以特定的物理地址為目的地址。但當你想廣播一個信息的時候，那就使用功能地址為目的地址，比如我們約定0x7DF為目的地址，當總線上出現了0x7DF為目的地址的信息后，所有的ECU都要動作。

（3）N_AE用于遠程診斷，遠程診斷的概念是指數據域里的內容將會包含“遠程地址(RA)”作為遠程節點的標識。

N_AI在CAN數據鏈路層的數據包中是要映射到CAN ID部分的。在這里插一句，通常上層協議的數據包直接填進下層協議的Data段，在這里有點特殊。先看下CAN的數據包格式。

CAN的仲裁段就是CAN ID，網絡層的數據包會被拆散，其中N_AI會被映射到CAN ID段，N_PCI和N_Data整體會成為CAN的Data段。根據N_AI的映射方式，網絡層定義了幾種尋址方式。

（1）標準地址

標準地址：這個格式最常見，也最好理解，指的是使用CAN的“標準幀”11位作為N_AI，至于源地址、目標地址等等，都是根據設備具體定義；比如上面0x741、0x749、0x7DF這些ID就已經區分了源、目標、類型這些內容了。需要說明的是，源地址、目標地址還有類型不需要單獨占一個字節，不然11bit就不夠用了。由于這些數據組合有限，通過自定義的映射方式，11bit就夠用了。比如0x741，你自己就把它定義成，源地址是診斷儀、目標地址是ECU3，地址類型是功能尋址。

（2）標準混合地址：也叫“常規固定尋址”，這個格式從名字上就有點怪，其實就是在標準地址的基礎上，把CAN的“標準幀”11位改為使用“擴展幀”29位并做了特殊位定義。

對于CAN的擴展幀，ID段有29位，相對11bit就寬裕很多。因此28-24位是固定的，23-16用于表征地址類型，15-8和7-0分別表示源地址和目的地址。

（3）擴展地址：這個格式從名字上就容易讓人誤解，以為是使用CAN的“擴展幀”，但其實就是在標準地址的基礎上，把數據域的字節1拿出來用作N_TA來標識這個數據的接收者是誰。

很容易發現這種格式似乎并不好，因為不僅要浪費數據域的一個字節，在數據處理上CPU也要在得到數據后進行判斷篩選，而它的目的只是為了擴展CAN標準幀的地址而已，那我們為什么不直接用CAN的“擴展幀”格式“標準混合地址”呢？所以正常CAN ID夠用的情況下，似乎不需要使用這個格式。

（4）混合地址：又是一個從名字上就讓人容易混淆的格式！是專門用于“遠程診斷”的，遠程診斷的概念是指數據域里的內容將會包含“遠程地址(RA)”作為遠程節點的標識，混合地址的格式中對CAN的“標準幀”11位和“擴展幀”29位的使用都進行了不同的定義。

其中，混合地址的CAN“擴展幀”29位的格式如下。

可以看到，主要的區別在于16~23位的值，與之前介紹的“標準混合地址”有所不同，這個dec段可以用于節點識別數據的地址格式。而且也一樣占用了數據域中的第一個字節，作為地址擴展。

混合地址的CAN“標準幀”11位的格式如下。

? 2.4.2 N_PCI

N_PCI字段，主要用于表征幀的類型。幀的類型分單幀、首幀、連續幀、流控幀等。

當一次通訊數據內容只需要一條CAN數據包就能包含時，就使用單幀格式。它的N_PCI需要占用1個字節，如下。

其中的SF_DL是用于表示本次傳輸數據的長度，由于只有4bit，它的范圍和使用定義。

當一次通訊整包數據較長，需要拆分成多個CAN數據進行傳輸時，就需要使用首幀、連續幀與流控幀配合實現分包機制，這三種幀的多幀傳輸使用邏輯如下。

下面來分別介紹這三種類型的數據幀。

首幀的N_PCI需要占到2個字節，如下。第一個字節的高四位為1表示幀類型是首幀，低四位和第二個字節組成FF_DL共同表示多幀傳輸的字節數。那么我們可以得到一次性最多可以發送2的12次方-1個字節。那就是4095個字節了。

連續幀的N_PCI需要占用1個字節，如下。它有一個叫SN的代碼區域，這SN表示的是包的連續號，從0到15后，又置零。其功能是說明幀的連續順序。需要注意的是，首幀雖然沒有SN的區域，但是在首幀也占一個SN，因此首幀之后的連續幀需要從1開始計數。

流控幀的N_PCI需要占用3個字節，其有三個區域FS,BS,STmin。

FS：表示的是流控狀態參數。0表示的是繼續發送(CTS)，1表示的是等待(WT)，這兩個配合使用可以控制發送速度；2表示溢出(OVFLW)，用于接收者告訴發送者數據過大，在首幀后的第一條流控幀應答。

BS：表示的是塊的大小，即發送端一次性能夠發送多少個連續幀。要注意的是，BS表示的是在發送端沒有接受到流控信號時，能夠發生的幀的數目。而當BS為0則表示，在數據傳輸的時，接收端不再發送流控幀了。發送端應當連續不斷的發送數據。

STmin：表示的是兩個連續幀(FF)的時間間隔。

CANFD下相關數據幀格式會有些不一樣，這里不再展開了，有興趣的去翻翻標準原文。有中文的標準，如下圖。

? ? 2.4.3 網絡層定時參數

網絡層除了定義了網絡層相關協議，還定義了定時參數。

N_As:發送方發送CAN數據幀經過鏈路層發送的時間。

N_Ar:接受方發送CAN數據幀經過鏈路層發送的時間。

N_Bs:發送方接收流控幀的等待時間。

N_Br:接受方發送流控幀的間隔時間。

N_Cs:發送方發送連續幀的間隔時間。

N_Cr:接受方接收連續幀的等待時間。

具體的參數允許范圍，請查看標準ISO 15765-2，這里不展開。

3 基于以太網實現的UDS

DoIP的全稱是Diagnostic Over Internet Protocol，即基于TCP/IP協議的診斷協議。隨著以太網技術在車載領域的應用范圍逐步擴大，越來越多的控制器支持通過以太網進行診斷通信，由于采用以太網通信技術，DoIP診斷具有超高的數據傳輸速率，速率達到了100 Mbit/s，相較于CAN總線診斷，DoIP診斷總體速率是CAN診斷的100-200倍，網絡上的傳輸速率是CAN診斷的300-400倍。并且硬件成本低，在個人電腦上只需要一個以太網接口即可實現診斷的物理連接。DoIP技術可以完美匹配IT基礎設施，固定診斷和遠程診斷均能應用，車載以太網技術將是未來解決如何快速更新ECU軟件及標定的主要策略之一。

回頭來看這張圖，ISO 14229-1定義了各種服務規范，與總線無關。所以基于以太網實現UDS，這部分就不需要重新講了。

ISO 14229-5，也就是UDSonIP，定義了當UDS在以太網總線上實現時需要遵循的一些特有原則，這部分的標準內容不多。

舉兩個例子，當使用0x10（診斷會話控制服務）時，會導致TCP連接中斷，再次開始診斷前，要重新建立TCP連接，并發送路由激活報文。

當使用0x11（ECU復位服務）時，同樣會導致TCP連接斷開，路由激活失效，再次開始診斷前也要重新建立TCP連接，并發送路由激活報文。

再往下是ISO 14229-2，定義了會話層的相關內容，主要是數據傳輸/接收的一些參數設置，前文已經講過了。

最后是我們關注的重點，ISO 13400-2，即DoIP。DoIP協議定義了從物理層(Physical Layer)到應用層(Application Layer)搭建”通信橋梁”的規則(此處可類似 CAN總線的TP層協議ISO 15765-2)

3.1 DoIP的網絡架構

支持DoIP的車輛網絡架構圖如下。

根據ISO-13400的要求，DoIP通信在物理層支持100BASE-TX (100 Mbit/s Ethernet) 和10BASE-T (10 Mbit/s Ethernet) 兩種制式。

汽車內部必須有一個DoIP的總網關，它作為和外部的診斷設備DoIP通信的唯一接口。車內網中，直接與外部診斷儀進行物理連接的節點，叫做邊緣節點（DoIP edge node）。邊緣節點可作為一個網絡交換機，將車內網與車外網組成同一子網；也可以作為一個網關，將車內網與車外網進行安全隔離，屏蔽非法的網絡訪問和網絡攻擊。除了邊緣節點之外，還有另一類網關，即車內的DoIP網關節點。車內DoIP網關節點的作用，是實現以太網到其他網絡總線（如CAN、LIN）的報文路由，這樣便實現了DoIP診斷與傳統網絡總線的兼容。多種網絡總線匯聚到DoIP網關，這大大的降低了布線的復雜性，并且提高了各總線網絡中ECU的診斷效率。車內網絡中，還存在一般的DoIP節點，這些節點只支持對自身的診斷，而不具備路由功能。最后，還有一類網絡節點（Network node），不具備DoIP診斷功能，與DoIP節點共享網絡資源。

3.2 DoIP的數據幀格式

在講DoIP數據幀格式之前，先回顧下完整的以太網數據幀如下。

IP段數據幀格式如下。在網絡層上DoIP使用IPV6協議，但為了向后兼容的原因，也支持IPV4,對于IPV4還要支持地址解析協議(ARP),對于IPV6還要支持鄰居發現協議(NDP)，這兩個協議都是用于在只知道IP地址的情況下獲取MAC地址的。

TCP段數據格式如下。支持DoIP的ECU的診斷服務創建的socket必須監聽在端口號13400上，外部測試設備通過連接此端口建立連接；每個支持DoIP的ECU必須支持n+1個并發的TCP socket連接，這是為了防止有多個外部測試設備同時和ECU進行診斷通信；外部測試設備創建的socket應選擇本地端口，本地端口即系統隨機的端口。

這里解釋下套接字的概念，在TCP/IP網絡中，區分不同的應用程序進程間的網絡通信和連接時主要有以下3個參數：通信的目的地址、使用的傳輸協議（TCP或UDP）和使用的端口號（此處說明一下，Socket不僅在TCP有，在UDP同樣有）。通過將這3個參數結合起來，與一個Socket進行綁定，應用層就可以與傳輸層一起通過套接字接口區分來自不同應用程序進程或網絡連接的通信，實現數據傳輸的并發服務。為了區別不同的應用程序進程和連接，許多計算機操作系統為應用程序與TCP/IP交互提供了稱為套接字（Socket）的接口。

UDP段數據格式如下。

DoIP段數據格式如下。

DoIP數據幀前面兩個字段分別是協議版本和協議版本的取反。第三個字段是數據類型，具體定義如下。

?

常用的數據類型如下：

0x0001至0x0004：用于汽車標識上報或請求，只能通過UDP報文來發送這種命令，主要用于在汽車和診斷儀進入網絡之后、診斷連接建立之前的車輛發現過程。

0x0005 和0x0006：標識的Routing activation request 和 response用于在socket建立之后，進行診斷通信的請求。

0x0007和0x0008：用于Alive check，用于檢查當前建立的診斷連接socket是否仍然在使用中，如果不再使用，則關閉socket釋放資源。

0x8001，0x8002，0x8003：分別代表的含義分別是診斷消息、診斷消息正響應和診斷消息負響應。

Data Length標識后面的user data的長度。

IS0 13400-2標準中給出了一個報文的示例如下。

? 3.3 車輛發現與聲明

在實現診斷通信之前，需要先發現車輛、建立TCP連接和建立診斷連接。先看車輛發現和聲明。

DoIP設備啟動后，首先通過UDP廣播的形式把一條DoIP報文（vehicle announcement message，Payload Type為0x0004）發給網絡上的所有的其他節點，其中就包括診斷儀，目的端口是13400，其中這條消息攜帶了DoIP設備的DoIP版本、VIN、logical address等信息，這條信息會發送三次，而之前監聽在13400端口的診斷儀接收到這條信息，就知道了DoIP設備的基本信息。

如果診斷儀沒有收到，還有一種辦法，就是診斷儀這邊主動請求，通過UDP廣播的形式，主動發一條DoIP request消息（Payload Type為0x0001），目的端口號是13400，而之前啟動后就一直監聽在13400的DoIP設備，接收到這條消息后，就會回復一條攜帶自己信息的response給診斷儀。

3.4 TCP連接

診斷儀通過創建tcp socket，然后調用connect方法向DoIP設備發起TCP連接請求（目的ip是DoIP設備ip，目的端口號是13400），而DoIP設備在啟動前已經通過創建tcp socket監聽在13400端口，接收到tcp連接請求后就會完成三次握手。

3.5 診斷連接

Socket一端連接著IP地址，一端連接著Port端口。并且Socket對于芯片而言是一種資源．因此有激活失效之分。在TCP連接建立后，診斷儀還需要發送一條Routing activation request的DoIP報文給DoIP設備，DoIP設備收到后會回復一條Routing activation response的DoIP報文，此時診斷連接建立，雙方可以診斷通信。

? 4 總結

設計一個復雜的系統后，去建立一個完善的診斷系統，往大了說，是為了提高維修效率，為公司爭取經濟利益。往小了說，是為了解放工程師自己，售后人員通過標準工具可以定位問題，就不會來找設計人員尋求技術支持。所以，工程師們，大家在設計復雜系統時，都記得給自己留條后路吧，不然量產后填坑會異常痛苦的。

審核編輯：黃飛

?