汽車電子ECU環(huán)境的零、UDS診斷命令備忘錄

寫在前面：UDS實踐性強，邏輯復雜，很多服務(wù)非要體驗過一次才能理解，導致包括我在內(nèi)的初學者感覺晦澀難懂，不明覺厲，因此將自己的理解寫下來、整理下來，與君共勉。

零、UDS診斷命令備忘錄

常見的UDS報文

常見的20個NRC

一、簡介

UDS（Unified Diagnostic Services，統(tǒng)一的診斷服務(wù)）診斷協(xié)議是在汽車電子ECU環(huán)境下的一種診斷通信協(xié)議，在ISO 14229中規(guī)定。它是從ISO 14230-3（KWP2000）和ISO 15765-3協(xié)議衍生出來的?！敖y(tǒng)一”這個詞意味著它是一個“國際化的”而非”公司特定的”標準。到目前為止，這種通信協(xié)議被用在幾乎所有由OEM一級供應(yīng)商所制造的新ECU上面。這些ECU控制車輛的各種功能，包括電控燃油噴射系統(tǒng)（EFI），發(fā)動機控制系統(tǒng)，變速箱，防抱死制動系統(tǒng)(ABS)，門鎖，制動器等。

診斷工具與車內(nèi)的所有控制單元均有連接，且這些控制單元均啟用了UDS服務(wù)。不同于僅使用OSI模型第一層、第二層的CAN協(xié)議，UDS服務(wù)使用OSI模型的第五層和第七層（會話層和應(yīng)用層）。服務(wù)ID（SID）和與服務(wù)相關(guān)的參數(shù)包含在CAN數(shù)據(jù)幀的8個數(shù)據(jù)字節(jié)中，這些數(shù)據(jù)幀是從診斷工具發(fā)出的。

目前市面上的新車都具有用于車外診斷的診斷接口，這使得我們可以用電腦或診斷工具（業(yè)內(nèi)稱為測試器Tester）連接到車輛的總線系統(tǒng)上。因此，UDS中定義的消息可以發(fā)送到支持UDS服務(wù)的控制器（業(yè)內(nèi)稱ECU）。這樣我們就可以訪問各個控制單元的故障存儲器或用新的固件更新ECU的程序。除此之外，UDS還用于下線檢測時把一些信息（如VIN碼）寫入到汽車的各個零部件中。這些功能也是UDS最為核心的功能。

使用電腦進行車輛診斷，診斷線插在OBD接口上

為什么我們要設(shè)計UDS這樣的診斷協(xié)議呢？在汽車診斷協(xié)議誕生之前，修車只能靠師傅的經(jīng)驗，因為汽車零部件不會告訴你它哪里出了問題。但有了診斷協(xié)議之后，一旦零部件出了問題或者出過問題，它們會把故障信息保存在內(nèi)存里面，維修師傅就可以通過通信總線讀取這些故障信息，比如一個ECU經(jīng)歷欠壓故障之后，它會將欠壓故障代表的DTC（診斷故障碼）存儲起來，可選擇性保存的還有發(fā)生故障時的快照信息（比如此時的車速、讀到的電壓值等）?？煺招畔⒂兄跍y試工程師和售后技師查找發(fā)生故障的原因。

除了CAN總線以外，UDS也可在不同的汽車總線（例如 LIN, Flexray, Internet 和K-line）上實現(xiàn)。

如下圖所示，ISO 14229也就是UDS協(xié)議僅對應(yīng)用層、會話層做出了定義。這里有個疑問，UDS專指ISO 14229-1嗎？這種說法是不對的，UDS包含了ISO 14229下屬的7個子協(xié)議，其中ISO 14229-2還是會話層的，所以UDS僅包括應(yīng)用層的說法也是錯誤的。

說明下，我們本篇文章我們僅使用CAN來描述UDS。對于CAN來說，物理層和數(shù)據(jù)鏈路層遵循ISO 11898協(xié)議；網(wǎng)絡(luò)層方面，Classical CAN僅有8個字節(jié)的數(shù)據(jù)場與應(yīng)用層處理多幀數(shù)據(jù)的需求構(gòu)成了矛盾，ISO 15765-2協(xié)議解決了該問題，我們用CAN的8字節(jié)數(shù)據(jù)場會騰出一到兩個字節(jié)的做法，來體現(xiàn)網(wǎng)絡(luò)層的控制信息。

如果希望深入學習下UDS網(wǎng)絡(luò)層的知識，請移步：

UDS網(wǎng)絡(luò)層/TP層（ISO 15765-2）的解讀

排放相關(guān)的診斷內(nèi)容，即ISO 15031-5主要針對OBD協(xié)議，為法規(guī)強制要求燃油車滿足的協(xié)議，電動車是無需滿足的。燃油車通常既滿足UDS協(xié)議，又滿足OBD協(xié)議，這兩個協(xié)議不沖突。小伙伴們有沒有發(fā)現(xiàn)UDS協(xié)議的服務(wù)ID(SID)最小的是0x10，那是因為小于0x10的服務(wù)是OBD協(xié)議中規(guī)定的。

學習UDS之前，希望您對CAN的基礎(chǔ)知識有初步的了解，知道一個CAN幀的基本構(gòu)成，熟悉至少一種CAN盒的使用方法。協(xié)議方面，應(yīng)通過PPT、論文、原版英文協(xié)議重點學習ISO 15765-2和ISO 14229-1的協(xié)議內(nèi)容，之后可以將Git上的開源UDS協(xié)議棧移植到你熟悉的嵌入式平臺上，進行數(shù)據(jù)收發(fā)；或使用CAN盒與支持UDS診斷的設(shè)備進行數(shù)據(jù)收發(fā)，對UDS有一個大致的認識。切記知行合一，實踐很重要。

摘自ISO 14229-1-2013

摘自ISO 14229-1-2013

摘自恒潤科技公開資料

摘自恒潤科技公開資料

二、UDS的服務(wù)

UDS本質(zhì)上是一系列服務(wù)的集合。UDS的服務(wù)包含6大類，共26種。每種服務(wù)都有自己獨立的ID，即SID。

SID：Service Identifier，診斷服務(wù)ID。UDS本質(zhì)上是一種定向的通信，是一種交互協(xié)議（Request/Response），即診斷方(Tester)給ECU發(fā)送指定的請求數(shù)據(jù)（Request），這條數(shù)據(jù)中需要包含SID，且SID處于該應(yīng)用層數(shù)據(jù)的第一個字節(jié)。如果是肯定的響應(yīng)（Positive Response），首字節(jié)回復[SID+0x40]，舉例子就是請求0x10，響應(yīng)0x50；請求0x22，響應(yīng)0x62。如果是否定的響應(yīng)（Negative Response），首字節(jié)回復0x7F，第二字節(jié)回復剛才詢問的SID。比如Tester請求0x10服務(wù)，我想進入編程模式，ECU給出否定響應(yīng)，首字節(jié)0x7F，第二字節(jié)回復0x10，代表我否定你的0x10服務(wù)請求，第三字節(jié)是NRC(否定響應(yīng)碼)，代表我否定你的依據(jù)。

肯定響應(yīng)和否定響應(yīng)的形式一定要熟悉。

通常，在CAN總線中，Addressing information尋址信息會在CAN的幀ID中體現(xiàn)出來，例外是遠程尋址，但不常使用。所謂的尋址信息包含了源地址(Source Address)和目標地址(Target Address)，就是這條信息是由誰發(fā)給誰的，類似于收件人和發(fā)件人。當然，ECU回信給Tester時，ECU就變成源地址了。因此源地址和目標地址在UDS中并不是一成不變的。

UDS的尋址模式分兩種，一種是物理尋址（點對點、一對一），根據(jù)物理地址的不同進行訪問，但只能訪問單個ECU節(jié)點，Tester為SA源地址，ECU作為TA目標地址；對應(yīng)的，另一種是功能尋址（廣播、一對多），根據(jù)功能的不同進行訪問，它能訪問多個ECU節(jié)點，對于標準幀來說，通常是0x7DF。

每一個ECU都有2個CAN的診斷幀ID，分別對應(yīng)物理尋址的收與發(fā)。通常由主機廠來確定不同ECU的這兩個特定的診斷ID。比如0x701對應(yīng)接收Tester的消息，0x709對應(yīng)發(fā)給Tester的消息。

UDS的26種服務(wù)

UDS的服務(wù)分為6大類，但常用的服務(wù)是加背景色的15種。這15種服務(wù)又可粗略地劃分為權(quán)限控制、讀取數(shù)據(jù)/信息、寫入數(shù)據(jù)/信息、通信控制、功能控制這幾類（注：這幾類是我自己劃分的）。

ISO14229-1英文原文中大篇幅的對26種服務(wù)進行了解釋，英文原文鏈接如下。學習時如果遇到困惑可以找標準中的相關(guān)語句進行翻譯，協(xié)議是所有學習材料的根本。

ISO14229-1-2013-汽車診斷協(xié)議.pdfmax.book118.com/html/2018/0725/5214111100001303.shtm

本文重點介紹以下幾個服務(wù)：$10Diagnostic Session Control（診斷會話），$14Clear Diagnostic Information（清除診斷信息），$19Read DTC Information，$22Read Data By Identifier（通過ID讀數(shù)據(jù)），$27Security Access（安全訪問），$2EWrite Data By Identifier（通過ID寫數(shù)據(jù)），$3ETester Present（待機握手）。其他的服務(wù)樓主有時間會補齊，敬請期待。

26種服務(wù)，其中15種較為常用

少了0x38

$10診斷會話 Diagnostic Session Control

$10包含3個子功能，01 Default默認會話，02 Programming編程會話，03 Extended擴展會話，ECU上電時，進入的是默認會話（Default）。

為什么設(shè)計三個會話模式呢？因為權(quán)限問題。默認會話權(quán)限最小，可操作的服務(wù)少；擴展模式通常用于解鎖高權(quán)限診斷服務(wù)，例如寫入數(shù)據(jù)/參數(shù)、讀寫診斷碼；編程模式用于解鎖bootloader相關(guān)的診斷服務(wù)，即程序燒錄。

題外話，講個故事。這三個會話模式好比普通項目成員（默認會話）、項目組長（擴展會話）和會計（編程會話）的關(guān)系，小職員權(quán)限最小，小職員有的權(quán)限項目組長全有，項目組長還多了些其他的高端權(quán)限（如寫數(shù)據(jù)、例程控制）。會計則不同，它有些自己獨有的權(quán)限（刷寫程序），但項目組的很多權(quán)限它沒有（讀/擦故障碼），因為它只干會計相關(guān)的事，本身不參與項目。

這里來一張權(quán)限表格。帶顏色的區(qū)域代表需要解鎖操作。

15個服務(wù)在不同會話中的權(quán)限情況（本表僅作參考）

如果您進入了一個非默認會話的狀態(tài)，一個定時器會運轉(zhuǎn)，如果一段時間內(nèi)沒有請求，那么到時間后，診斷退回到默認會話01(最低權(quán)限)。當然，我們有一個$3E的服務(wù)，可以使診斷保持在非默認的狀態(tài)。

UDS的請求命令有4種構(gòu)成方式，即SID，SID+SF（Sub-function），SID+DID（Data Identifier）（讀寫用），SID+SF+DID。每種服務(wù)都有自己不同的構(gòu)成方式，查看服務(wù)說明即可，不用死記硬背。

NRC：Negative Response Code（否定響應(yīng)碼）。如果ECU拒絕了一個請求，做出否定響應(yīng)（Negative Response），它會在第三字節(jié)回復一個NRC。不同的NRC有不同的含義。本文開頭時有一個常見NRC的圖，當然完整版請參照ISO14229附錄A。

這里提一下一個特殊的NRC——0x78，requestCorrectlyReceived-ResponsePending（RCRRP，請求已被正確接收-回復待定）。這個NRC表明請求消息被正確地接收，請求消息中的所有參數(shù)都是有效的，但是要執(zhí)行的操作還沒有完成，Server端還沒有準備好接收另一個請求。一旦請求的服務(wù)已經(jīng)完成，服務(wù)器應(yīng)該發(fā)送一個積極的響應(yīng)或消極的響應(yīng)，響應(yīng)代碼應(yīng)與此不同。這個NRC的消極響應(yīng)可以被Server端重復，直到被請求的服務(wù)完成并且最終的響應(yīng)消息被發(fā)送。

當使用此NRC時，服務(wù)器應(yīng)始終發(fā)送最終響應(yīng)(不管正響應(yīng)還是負響應(yīng))，與suppress-PosRspMsgIndicationBit值（抑制肯定響應(yīng)位）或NRCs（SNS、SFNS、SNSIAS、SFNSIAS和ROOR）對功能尋址的處理請求的響應(yīng)抑制要求無關(guān)。這里的有一個特殊的知識點，即什么情況下，功能尋址是不需要給出否定響應(yīng)的呢？如果被測ECU需要回復上面5個NRC（SNS 0x11、SFNS 0x12、SNSIAS 0x7E、SFNSIAS 0x7F和ROOR 0x31）時，不需要回復否定響應(yīng)。

NRC 0x78壞了規(guī)矩的例子

14229-1協(xié)議第329頁

例子：以CAN總線網(wǎng)絡(luò)舉例。CAN幀一共8個字節(jié)，第一字節(jié)被網(wǎng)絡(luò)層占用。(ISO 15765-2的知識)

進入01會話成功，進入02會話失敗，進入03會話成功

請求（Request）:02 10 02 xx xx xx xx xx ; 02是網(wǎng)絡(luò)層單幀SF，表示應(yīng)用層包含有2個字節(jié)，10是服務(wù)ID(SID)，02是子功能——進入編程會話。但ECU婉拒了它的請求。

摘自ISO 14229-1:2013 p39

我們看下上面的圖表，這個是ISO 14229定義的0x10服務(wù)應(yīng)具有的請求報文格式，M意為Mandatory 強制?？梢钥吹?x10服務(wù)僅有兩個字節(jié)，整條報文是“服務(wù)ID+子功能”，比較簡單。

肯定響應(yīng):02 50 02 xx xx xx xx xx；02即應(yīng)用層含兩個字節(jié)，50=10+40表示對SID的肯定回復，02是子功能。

否定響應(yīng):03 7F 10 7E xx xx xx xx；03同上，7F表示否定響應(yīng)，10是SID，7E是NRC（否定響應(yīng)碼）。

$3E待機握手

$3E服務(wù)用于向服務(wù)器指示診斷儀仍然連接在網(wǎng)絡(luò)上，之前已經(jīng)激活的診斷服務(wù)功能可以仍然保持激活狀態(tài)。

例子：023E80 00 00 00 00 00，發(fā)送一個3E服務(wù)的報文，保持非默認會話狀態(tài)。80表示無需回復。

$27安全訪問

$27安全訪問：ECU當中有很多數(shù)據(jù)是整車廠獨有的，并不希望開放給所有客戶，它需要做一個保密的設(shè)定。我們在讀取一些特殊數(shù)據(jù)的時候，要先進行一個安全解鎖。ECU上電之后是一個鎖定的狀態(tài)（Locked），我們通過$27服務(wù)，加上一個子服務(wù)，再加上一個鑰匙，這樣的服務(wù)請求可以進行解鎖。比如下面的例子，2n-1是一個子服務(wù)，這里我們先用n=1，即01子服務(wù)來舉例子。通過首輪Tester種子的請求（27+01），ECU會返回67+01+AA+BB+CC+DD，AA~DD就是種子了。之后第二輪，診斷端的Tester會利用種子進行運算（根據(jù)整車廠的算法），生成k1（不一定是1個字節(jié)），之后發(fā)送請求，子服務(wù)是2n，這里我們還是假定n=1，即02子服務(wù)。這樣Tester發(fā)出的就是27+02+[k1]。之后，ECU同樣也會根據(jù)第一輪的種子自行算出k2。當ECU檢查出k1和k2完全一致時，解鎖（Unlocked）成功。

$27安全訪問服務(wù)的否定響應(yīng)服務(wù)ID也是7F。還記得剛才否定響應(yīng)的格式嗎？7F+27+NRC（否定響應(yīng)碼）。

實際通信的截圖，黃色位置是密鑰區(qū)域

例子：

Tester：0227 0500 00 00 00 00 安全訪問，05子功能

ECU：0667 0508 27 11 F0 00 肯定響應(yīng)，回復了對應(yīng)安全級別的種子

Tester：06 27 06FF FF FF FF 00 發(fā)送密鑰，4個FF。注意06是與05成對使用的。

ECU：03 7F 27 7800 00 00 00 若為否定響應(yīng)，7F+27+NRC

ECU：0267 0600 00 00 00 00 若為肯定響應(yīng)，通過安全校驗

細說下安全驗證算法。安全驗證算法包括1個核心，3個主體。

第一個主體通常和ECU有關(guān)。比如我們先用22服務(wù)讀取ECU的SN，取其中4個字節(jié)，作為“調(diào)味料”參與，顯然這個“調(diào)味料”對于這個ECU來說是不變的，也能通過22服務(wù)方便的讀取到。

第二個主體seed，通常與ECU的運行時間有關(guān)系，是主料，在27服務(wù)發(fā)送奇數(shù)子功能時回復。seed通常一直在發(fā)生變化，無法發(fā)現(xiàn)其規(guī)律。

第三個主體是執(zhí)行次數(shù)，就是算法要執(zhí)行幾輪。執(zhí)行1輪和2輪得到的結(jié)果肯定是不一樣的對吧。

最大的核心就是算法了。舉個簡單的算法，比如seed和ECU SN前4個字節(jié)加一下，循環(huán)左移兩位，執(zhí)行3輪，return這個數(shù)作為key，結(jié)束。安全驗證就是一把鎖，算法越復雜，短時間解開的成本越高，越不易被破解掉。如果失敗次數(shù)過多還會觸發(fā)懲罰機制，一段時間內(nèi)都無法再嘗試解鎖，防止人為的破解。

$22讀數(shù)據(jù)

$22讀數(shù)據(jù)，Request（請求）：22+DID（Data Identifier，通常是兩個字節(jié)）

Response（響應(yīng)）：62+DID+Data

DID有一部分已經(jīng)被ISO 14229-1規(guī)定了。比如0xF186就是當前診斷會話數(shù)據(jù)標識符，0xF187就是車廠備件號數(shù)據(jù)標識符，0xF188就是車廠ECU軟件號碼數(shù)據(jù)ID，0xF189就是車廠ECU軟件版本號數(shù)據(jù)標識符。

14229-1協(xié)議第339頁

$2E寫數(shù)據(jù)

$2E寫數(shù)據(jù)，Request（請求）：2E+DID+Data

Response（響應(yīng)）：6E+DID

寫入一個VIN碼

正確的順序是10開頭的幀請求、30開頭的幀回復、21開頭再請求、22開頭繼續(xù)請求、03開頭回復確認。我們一幀一幀來看。

10 14根據(jù)ISO15765-2代表這是一組多幀中的首幀（屬于傳輸層的信息），一會要發(fā)0x14=20個字節(jié)的有效數(shù)據(jù)。之后是2E+F190（代表這是VIN碼）+VIN碼的前3個字節(jié)。意思是作為外部工具，想寫入一個VIN碼數(shù)據(jù)。這件事情正常是發(fā)生在車輛下線時。

30 00 0A是TP層（傳輸層）的信息，表示這是一個流控幀，ECU發(fā)出的，表示可以一直連續(xù)發(fā)，但連續(xù)幀最短的間隔時間要求是10ms。

21是TP層的信息，表示這是一個連續(xù)幀，序號為1。后面是VIN碼的第4字節(jié)到第10字節(jié)。

22是TP層的信息，表示這是一個連續(xù)幀，序號為2。后面是VIN碼的第11字節(jié)到第17字節(jié)。

03是TP層的信息，這里說的這個TP層的信息是傳不到應(yīng)用層的，即這是一個用完就會拋棄的信息。03的0表示這是一個單幀，3表示后面有3個有效字節(jié)。6E表示我們確認執(zhí)行了2E服務(wù)的請求，這個請求寫入的ID是F1 90，即VIN碼。

注意，比如0xF190等DID不支持直接寫入數(shù)據(jù)，需要用$10來進行會話轉(zhuǎn)換。也就是說，對于寫數(shù)據(jù)的請求，一般來說需要在一個擴展會話，和安全等級1的狀態(tài)下才能進行。

$19 讀DTC

19服務(wù)是一套診斷服務(wù)中的重中之重。協(xié)議中篇幅長達63頁，通信舉例達到了18個?？梢哉f沒有19服務(wù)，就沒有完整的UDS。

DTC（diagnostic trouble code）：如果系統(tǒng)檢測到了一個錯誤，它將存儲為DTC。DTC可表現(xiàn)為：一個顯而易見的故障；通訊信號的丟失（不會使故障燈亮起）；排放相關(guān)的故障；安全相關(guān)的錯誤等。DTC可以揭示錯誤的位置和錯誤類型。通常DTC占用3個字節(jié)，OBD II占用兩個字節(jié)。圖中FTB為Fault Type Byte。

故障碼包括四個大類，分別是PCBU，P是powertrain動力系統(tǒng)，C是Chassis底盤，B是Body車身，U是network通信系統(tǒng)。一個DTC信息占用4個字節(jié)。最后一個字節(jié)是DTC的狀態(tài)。DTMMiddleByte和DTCLowByte兩個字節(jié)是我們熟知的類似P0047（ISO15031中的故障碼）中“0047”的純數(shù)字故障碼。第一個字節(jié)在乘用車中，前兩個bit代表P/C/B/U（動力/底盤/車身/網(wǎng)絡(luò)）中的一個，之后六個bit是數(shù)字，合在一起的樣子形如“C01”。第一個字節(jié)的前2個bit中，用00/01/10/11分別表示P/C/B/U。（感謝aymjwwl007）

舉個例子，U312345這個故障碼（我杜撰的），它的狀態(tài)是Test failed疊加Confirmed，那么DTC信息這四個字節(jié)就應(yīng)該是0xF1(二進制11110001)，0x23，0x45，0x09。

這是ISO15031中的故障碼，和UDS中的故障碼在長度上有一定的不同

$19擁有28個子服務(wù)（Sub-Function）。常用的子服務(wù)有：

01 (讀取符合掩碼條件的DTC數(shù)量)（必須支持）,后面的參數(shù)是DTC狀態(tài)掩碼，若為01表示我想讀當前故障，若為08表示我想讀歷史故障，若為09表示當前故障和歷史故障都想讀。關(guān)注公眾號【車端】

在肯定回復時，組合應(yīng)該是59(19+40) - 01 （子功能） - 09 （本ECU所支持的掩碼條件）-01 DTC的格式（ISO14229-1為01） - 00 01 （目前滿足條件的DTC有一個）

02（讀取符合掩碼條件的DTC列表及其狀態(tài)）（必須支持），后面的參數(shù)是DTC狀態(tài)掩碼，解讀同上。

在肯定回復是，59 - 02（子功能）- 09（本ECU所支持的掩碼條件） - XX XX XX ( DTC,車廠定義 ) - 01 （這個故障碼怎么了，01表示當前故障）

04（讀取快照信息），也叫凍結(jié)幀。

06（讀取擴展信息）。

0A（讀取ECU支持的所有DTC列表及其狀態(tài)）（必須支持）。這個就不必發(fā)DTC狀態(tài)掩碼了。所有支持的DTC列表及其狀態(tài)都會打印出來。

黃色框是DTC，緊跟著的是DTC狀態(tài)

同時讀取當前/歷史故障，黃色框是DTC，緊跟著的是DTC狀態(tài)

剛才提到，一個DTC除了它自己的3個字節(jié)，還有一個字節(jié)專門用于表達DTC的狀態(tài)，這個字節(jié)我們叫它DTC狀態(tài)掩碼。這個狀態(tài)字節(jié)每個位的含義下面列舉出來。注意，在實際項目中，并不是所有的DTC狀態(tài)都是支持的。DTC狀態(tài)掩碼前7個位的理解是UDS的一個難點。

關(guān)于DTC狀態(tài)掩碼更詳細的解釋參見文末的學習資料22，張老師有詳細的解答。

DTC狀態(tài)掩碼，默認值0x50

Request/Response。括號標識循環(huán)，可以讀出很多DTC

$14清除DTC

清除（復位）DTC格式，它可以改變DTC的狀態(tài)。DTC狀態(tài)中的八個位，除bit4和bit6外均會被清零，包含當前故障（TestFailed）和歷史故障（ConfirmedDTC）。bit4和bit6這兩個testNotCompleted開頭的會被強制置1。

3個FF代表清除所有DTC。

Request：14+FF+FF+FF；

Response：54 。

14服務(wù)

$2F IO控制

該服務(wù)可以通過DID(數(shù)據(jù)標識符)來進行輸入信號的替換和控制零部件負載輸出。這是一個用在產(chǎn)線上較多的服務(wù)。該報文的請求至少由4個字節(jié)組成。第一個字節(jié)是2F，第二第三字節(jié)是DID，其中第二字節(jié)是高位。第四字節(jié)是input Output Control Parameter（并不算一個子功能），可以看做IO控制類型。

IO控制類型分為4類，

00是控制權(quán)還給ECU，Return Control To ECU。

01是復位為默認值，Reset to Default。

02是凍結(jié)當前的狀態(tài)，F(xiàn)reeze Current State。

03是短暫接管控制權(quán)，Short Term Adjustment。

若控制類型是00-02這三種，請求報文是4個字節(jié)。

若控制類型是03，請求報文的第五字節(jié)是控制代碼，可以是數(shù)字量，比如01是開，00是關(guān)；也可以是模擬量，比如空調(diào)風門的開度。

2F服務(wù)，黃色區(qū)域為2個字節(jié)的DID

上面這個圖可以理解為，關(guān)閉開關(guān)，之后打開開關(guān)，之后控制權(quán)還給ECU，之后想復位回默認值，但是發(fā)現(xiàn)ECU不支持。這里NRC用0x22是否準確，還望大神告知。

2F服務(wù)有一個問題，如果通過2F服務(wù)修改了某個值，后續(xù)也不把控制權(quán)還給ECU，那么這個修改的有效時間是一直持續(xù)下去？

正確的做法是如果擴展會話超時，即切回默認會話，此時控制權(quán)應(yīng)還給ECU，畢竟 2F的03子功能是"暫時接管控制權(quán)"。

6種模式的配置

非默認會話在實際中又細分為編程會話（Programming Diagnostic Session）和擴展會話（Extended）。在UDS的實際應(yīng)用中，我們需要對26種服務(wù)針對不同會話、不同尋址模式的支持度進行配置。

也就是說，物理尋址+默認會話、物理尋址+編程會話、物理尋址+擴展會話、功能尋址+默認會話、功能尋址+編程會話、功能尋址+擴展會話，共6個模式。那么我們可以腦補一個26行、6列的表格了。

舉個例子，對于10、11、3E、22（22有分歧）服務(wù)，它們需要支持所有的6個模式（物理+功能尋址）。

對于14、19服務(wù)，DTC相關(guān)，要求支持默認+擴展會話的4個模式（物理+功能尋址）。

對于27服務(wù)，即安全訪問服務(wù)，僅支持擴展+物理、編程+物理2個模式。

對于2E、2F服務(wù)，僅支持擴展+物理1個模式，且要求安全等級為1。

對于34、36、37服務(wù)，涉及程序下載，僅支持編程+物理1個模式，且要求安全等級為2。

對于28、85服務(wù)，有些要求支持編程+擴展會話的4個模式，有些則要求僅支持擴展會話的2個模式。

對于31服務(wù)，要求安全等級為1，有些要求支持擴展+物理、編程+物理2個模式，有些則要求僅支持擴展+物理1種模式。

抑制肯定響應(yīng)指示位的配置

抑制肯定響應(yīng)指示位(Suppress Positive Response Message Indication Bit)顧名思義，這個位是用來抑制肯定響應(yīng)的。即本應(yīng)回復肯定響應(yīng)幀，但是發(fā)出方要求對方靜默，不需要對方回復肯定響應(yīng)。這個位的位置和子服務(wù)在同一個字節(jié)（應(yīng)用層數(shù)據(jù)第二字節(jié)），為bit7，高位。

比如SID是0x10，子服務(wù)是0x01，如果是抑制肯定響應(yīng)的話，子服務(wù)這個字節(jié)要改成0x81。這樣發(fā)下去ECU就不會回復肯定響應(yīng)了。

通常，10、28、3E、85服務(wù)是需要支持抑制肯定響應(yīng)這個功能的。11服務(wù)部分廠家也是要求支持的。

以上只是一些粗淺的理解。對26種服務(wù)更詳細的解讀請拉到屏幕下方參考張老師的8篇文章。張老師也開通了微信公眾號，"汽車ECU網(wǎng)絡(luò)診斷技術(shù)"?？梢匀リP(guān)注一下。

UDS應(yīng)用的設(shè)備

在UDS診斷產(chǎn)品中知名度最高，應(yīng)用最廣泛的是德國Vector公司的CAN卡 VN1630/1640 配合其CANoe軟件，Vector 產(chǎn)品功能齊全，適合系統(tǒng)級汽車總線開發(fā)，被大部分汽車廠商采用。通常工程師先用Vector的CANdela進行cdd文件的開發(fā)，之后將該cdd文件導入CANoe.diva中進行功能測試。下面的鏈接是Vector提供的全套解決方案，里面的CANdesc是UDS代碼生成軟件。

ECU診斷開發(fā)解決方案 - 圖文 - 百度文庫wenku.baidu.com/view/7754e9a3770bf78a652954cc.html

Vector 產(chǎn)品很好用，節(jié)省開發(fā)時間，但價格昂貴，不適用于小廠或規(guī)模性采購。目前市面上有很多CAN 廠商（如Kvaser, ZLG 等）能提供低成本、體積小、驅(qū)動簡單、開放API 的設(shè)備，很適合進行UDS相關(guān)的二次開發(fā)。

討論

問題：如果出現(xiàn)了UDS請求并發(fā)的情況，比如2E服務(wù)，正在寫入、正在處理時，突然有11服務(wù)請求闖入，此時ECU會如何處理呢？

觀點：此時應(yīng)繼續(xù)執(zhí)行完2E的寫入服務(wù)，11服務(wù)的請求將會被丟棄，不會有任何回復。

四、AUTOSAR中的UDS

AUTOSAR使用DCM、DEM、FIM、DET模塊來共同實現(xiàn)診斷。我們主要討論前兩個模塊。

DCM，全稱Diagnostic Communication Manager，為診斷服務(wù)提供通用接口。DCM幫我們處理總線上的診斷請求，在其提供的callback函數(shù)中，我們可以添加諸如DID數(shù)據(jù)、【關(guān)注公眾號【車端】】27運算結(jié)果等信息。

DEM，全稱Diagnostic Event Manager，為DCM提供錯誤信息。應(yīng)用層可以調(diào)用DEM提供的接口以決定某個DTC被Test為Pass或Fail。

對于DCM來說，這個模塊還是太大了，我們又將其分為3個獨立的子模塊。

DSL，全稱Diagnostic Session Layer，用于確保診斷請求和響應(yīng)的數(shù)據(jù)流，監(jiān)控診斷請求和響應(yīng)的時序，管理診斷會話和安全等級。這一層是DCM的最外圈，叫他外環(huán)吧，它直接與PduR相接觸，獲取CanTp經(jīng)由PduR上傳的數(shù)據(jù)。

DSD，全稱Diagnostic Service Dispatcher，用于處理診斷數(shù)據(jù)流。它位于DCM的中環(huán)，夾在DSL和DSP的中間。

DSP，全稱Diagnostic Service Processing，實現(xiàn)每個具體的診斷服務(wù)，位于DCM的內(nèi)環(huán)，這一層事無巨細。比如22服務(wù)、27服務(wù)的callback正是源于這一層。

審核編輯：郭婷