0 序言

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

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

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

? 1 UDS概述

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

說點UDS具體的場景應(yīng)用：

（1）ECU開發(fā)過程要用到它來構(gòu)建bootloader，上傳和下載數(shù)據(jù)，即軟件刷寫，控制器Reset；

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

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

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

（5）4S店里，技師需要讀取當(dāng)前故障、歷史故障，讀取故障發(fā)生時刻環(huán)境信息狀態(tài)，清除故障，判斷故障發(fā)生點，還可以用來升級ECU程序。

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

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

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

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

以太網(wǎng)可以確定會成為未來車輛內(nèi)的主干總線，當(dāng)10base-T1標準完善，以太網(wǎng)可能會完全取代CAN總線。因此本文關(guān)注UDS在CAN和以太網(wǎng)上的實現(xiàn)。

在剛學(xué)習(xí)的時候，會對UDSonCAN和DoCAN有疑問，不知道二者有什么區(qū)別。DoCAN的全稱是Diagnosis on CAN。UDSonCAN和DoCAN是在通信模型不同層中的不同叫法，其規(guī)定了不同層的技術(shù)標準。UDSonCAN僅存在于應(yīng)用層，而DoCAN只適用于網(wǎng)絡(luò)層和傳輸層。

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

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

OBD與UDS的區(qū)別是：

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

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

本文不關(guān)心OBD，只關(guān)心UDS。

2 基于CAN總線實現(xiàn)的UDS

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

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

2.1 ISO14229-1是什么

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

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

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

? ? 2.2 ISO14229-1請求/響應(yīng)機制

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

2.2.1 不帶Subfunction的機制

下圖是不具有Subfunction的UDS診斷服務(wù)請求和響應(yīng)機制。

（1）診斷方（Tester）向ECU發(fā)送指定的請求數(shù)據(jù)（Request），這條數(shù)據(jù)中需要包含SID，且SID處于該應(yīng)用層數(shù)據(jù)的第一個字節(jié)。

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

（3）肯定響應(yīng)（Positive Response）格式為：（SID+0X40）+數(shù)據(jù)。例如，請求0X10服務(wù)，肯定響應(yīng)第1個字節(jié)為0X50；請求0X22服務(wù)，肯定響應(yīng)第1個字節(jié)為0X62。

（4）否定響應(yīng)（Negative Response）格式為：0X7F+SID+NRC。例如，請求0X10服務(wù)，否定響應(yīng)第1個字節(jié)為固定的0X7F，第2個字節(jié)為0X10，第3個字節(jié)為NRC。NRC是否定響應(yīng)碼，可以根據(jù)返回的NRC判斷是什么原因?qū)е碌姆穸憫?yīng)。下圖是常見的一些NRC碼，需要看全的NRC碼，可以去查看標準原文。

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

2.2.2 帶Subfunction的機制

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

? 2.2.3 根據(jù)數(shù)據(jù)標識符讀寫

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

2.3 診斷服務(wù)示例

2.3.1 診斷會話控制服務(wù)-0x10

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

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

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

?

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

模式切換遵循以下規(guī)則：

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

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

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

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

這里解釋以下S3參數(shù)，S3參數(shù)可分為S3server和S3client。前者是服務(wù)器的定時參數(shù)，通常取5000ms，僅用于非默認會話模式。在該模式下，如果在S3server時間內(nèi)，服務(wù)端沒有接受到任何診斷請求服務(wù)，則退出非默認會話，返回默認會話。S3client是客戶端的定時參數(shù)，通常取4000ms?？蛻舳藶榱吮３址悄J會話的連接，可以通過發(fā)送3E請求（待機握手服務(wù)）來保持連接，但必須在S3server的時間內(nèi)發(fā)送一次。相當(dāng)于每4000ms，客戶端告訴服務(wù)端它還在，不要退出非默認會話。

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

以客戶端發(fā)送了10 01為例，服務(wù)器端應(yīng)回復(fù)50 01 xx xx xx xx。這里的xx是響應(yīng)的相關(guān)參數(shù)，如下圖所示。

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

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

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

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

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

如果設(shè)置P2server_max=50ms，P2*server_max=5000ms，則肯定響應(yīng)就是50 01 00 32 01 F4。

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

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

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

2.3.2 安全訪問服務(wù)-0x27

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

安全服務(wù)的實現(xiàn)過程如下圖所示。

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

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

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

如果在解鎖狀態(tài)下，重復(fù)發(fā)送解鎖請求，比如發(fā)送27 01的命令，則ECU會回復(fù)67 01 00 00，表明ECU已解鎖。

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

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

? 2.3.3 根據(jù)標識符讀數(shù)據(jù)-0x22

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

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

? ? 2.3.4 根據(jù)標識符讀數(shù)據(jù)-0x2E

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

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

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

? ? 2.4 ISO15765-2標準

15765-2作為車輛診斷通信的一個組成部分，規(guī)范了“傳輸協(xié)議和網(wǎng)絡(luò)層服務(wù)”。

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

網(wǎng)絡(luò)層協(xié)議數(shù)據(jù)單元（N_PDU，Network_Protocol Data Unit）包含N_AI，N_PCI，N_Data。即地址信息，協(xié)議控制信息和數(shù)據(jù)。

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

N_PCI標識網(wǎng)絡(luò)層幀的類型。網(wǎng)絡(luò)層協(xié)議數(shù)據(jù)單元（N_PDU）有四種類型，即單幀（SF）、首幀（FF）、連續(xù)幀（CF）、流控制幀（FC）。

N_Data包含應(yīng)用層協(xié)議控制信息和數(shù)據(jù)，即上文我們談到的那些。

2.4.1 N_AI

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

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

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

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

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

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

（1）標準地址

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

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

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

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

很容易發(fā)現(xiàn)這種格式似乎并不好，因為不僅要浪費數(shù)據(jù)域的一個字節(jié)，在數(shù)據(jù)處理上CPU也要在得到數(shù)據(jù)后進行判斷篩選，而它的目的只是為了擴展CAN標準幀的地址而已，那我們?yōu)槭裁床恢苯佑肅AN的“擴展幀”格式“標準混合地址”呢？所以正常CAN ID夠用的情況下，似乎不需要使用這個格式。

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

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

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

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

? 2.4.2 N_PCI

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

當(dāng)一次通訊數(shù)據(jù)內(nèi)容只需要一條CAN數(shù)據(jù)包就能包含時，就使用單幀格式。它的N_PCI需要占用1個字節(jié)，如下。

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

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

下面來分別介紹這三種類型的數(shù)據(jù)幀。

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

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

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

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

BS：表示的是塊的大小，即發(fā)送端一次性能夠發(fā)送多少個連續(xù)幀。要注意的是，BS表示的是在發(fā)送端沒有接受到流控信號時，能夠發(fā)生的幀的數(shù)目。而當(dāng)BS為0則表示，在數(shù)據(jù)傳輸?shù)臅r，接收端不再發(fā)送流控幀了。發(fā)送端應(yīng)當(dāng)連續(xù)不斷的發(fā)送數(shù)據(jù)。

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

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

? ? 2.4.3 網(wǎng)絡(luò)層定時參數(shù)

網(wǎng)絡(luò)層除了定義了網(wǎng)絡(luò)層相關(guān)協(xié)議，還定義了定時參數(shù)。

N_As:發(fā)送方發(fā)送CAN數(shù)據(jù)幀經(jīng)過鏈路層發(fā)送的時間。

N_Ar:接受方發(fā)送CAN數(shù)據(jù)幀經(jīng)過鏈路層發(fā)送的時間。

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

N_Br:接受方發(fā)送流控幀的間隔時間。

N_Cs:發(fā)送方發(fā)送連續(xù)幀的間隔時間。

N_Cr:接受方接收連續(xù)幀的等待時間。

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

3 基于以太網(wǎng)實現(xiàn)的UDS

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

回頭來看這張圖，ISO 14229-1定義了各種服務(wù)規(guī)范，與總線無關(guān)。所以基于以太網(wǎng)實現(xiàn)UDS，這部分就不需要重新講了。

ISO 14229-5，也就是UDSonIP，定義了當(dāng)UDS在以太網(wǎng)總線上實現(xiàn)時需要遵循的一些特有原則，這部分的標準內(nèi)容不多。

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

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

再往下是ISO 14229-2，定義了會話層的相關(guān)內(nèi)容，主要是數(shù)據(jù)傳輸/接收的一些參數(shù)設(shè)置，前文已經(jīng)講過了。

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

3.1 DoIP的網(wǎng)絡(luò)架構(gòu)

支持DoIP的車輛網(wǎng)絡(luò)架構(gòu)圖如下。

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

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

3.2 DoIP的數(shù)據(jù)幀格式

在講DoIP數(shù)據(jù)幀格式之前，先回顧下完整的以太網(wǎng)數(shù)據(jù)幀如下。

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

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

這里解釋下套接字的概念，在TCP/IP網(wǎng)絡(luò)中，區(qū)分不同的應(yīng)用程序進程間的網(wǎng)絡(luò)通信和連接時主要有以下3個參數(shù)：通信的目的地址、使用的傳輸協(xié)議（TCP或UDP）和使用的端口號（此處說明一下，Socket不僅在TCP有，在UDP同樣有）。通過將這3個參數(shù)結(jié)合起來，與一個Socket進行綁定，應(yīng)用層就可以與傳輸層一起通過套接字接口區(qū)分來自不同應(yīng)用程序進程或網(wǎng)絡(luò)連接的通信，實現(xiàn)數(shù)據(jù)傳輸?shù)牟l(fā)服務(wù)。為了區(qū)別不同的應(yīng)用程序進程和連接，許多計算機操作系統(tǒng)為應(yīng)用程序與TCP/IP交互提供了稱為套接字（Socket）的接口。

UDP段數(shù)據(jù)格式如下。

DoIP段數(shù)據(jù)格式如下。

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

?

常用的數(shù)據(jù)類型如下：

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

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

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

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

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

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

? 3.3 車輛發(fā)現(xiàn)與聲明

在實現(xiàn)診斷通信之前，需要先發(fā)現(xiàn)車輛、建立TCP連接和建立診斷連接。先看車輛發(fā)現(xiàn)和聲明。

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

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

3.4 TCP連接

診斷儀通過創(chuàng)建tcp socket，然后調(diào)用connect方法向DoIP設(shè)備發(fā)起TCP連接請求（目的ip是DoIP設(shè)備ip，目的端口號是13400），而DoIP設(shè)備在啟動前已經(jīng)通過創(chuàng)建tcp socket監(jiān)聽在13400端口，接收到tcp連接請求后就會完成三次握手。

3.5 診斷連接

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

? 4 總結(jié)

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

審核編輯：黃飛

?