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

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

零、UDS診斷命令備忘錄

常見的UDS報(bào)文

常見的20個(gè)NRC

一、簡(jiǎn)介

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

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

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

使用電腦進(jìn)行車輛診斷，診斷線插在OBD接口上

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

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

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

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

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

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

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

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

摘自ISO 14229-1-2013

摘自ISO 14229-1-2013

摘自恒潤(rùn)科技公開資料

摘自恒潤(rùn)科技公開資料

二、UDS的服務(wù)

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

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

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

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

UDS的尋址模式分兩種，一種是物理尋址（點(diǎn)對(duì)點(diǎn)、一對(duì)一），根據(jù)物理地址的不同進(jìn)行訪問(wèn)，但只能訪問(wèn)單個(gè)ECU節(jié)點(diǎn)，Tester為SA源地址，ECU作為TA目標(biāo)地址；對(duì)應(yīng)的，另一種是功能尋址（廣播、一對(duì)多），根據(jù)功能的不同進(jìn)行訪問(wèn)，它能訪問(wèn)多個(gè)ECU節(jié)點(diǎn)，對(duì)于標(biāo)準(zhǔn)幀來(lái)說(shuō)，通常是0x7DF。

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

UDS的26種服務(wù)

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

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

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

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

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

少了0x38

$10診斷會(huì)話 Diagnostic Session Control

$10包含3個(gè)子功能，01 Default默認(rèn)會(huì)話，02 Programming編程會(huì)話，03 Extended擴(kuò)展會(huì)話，ECU上電時(shí)，進(jìn)入的是默認(rèn)會(huì)話（Default）。

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

題外話，講個(gè)故事。這三個(gè)會(huì)話模式好比普通項(xiàng)目成員（默認(rèn)會(huì)話）、項(xiàng)目組長(zhǎng)（擴(kuò)展會(huì)話）和會(huì)計(jì)（編程會(huì)話）的關(guān)系，小職員權(quán)限最小，小職員有的權(quán)限項(xiàng)目組長(zhǎng)全有，項(xiàng)目組長(zhǎng)還多了些其他的高端權(quán)限（如寫數(shù)據(jù)、例程控制）。會(huì)計(jì)則不同，它有些自己獨(dú)有的權(quán)限（刷寫程序），但項(xiàng)目組的很多權(quán)限它沒(méi)有（讀/擦故障碼），因?yàn)樗桓蓵?huì)計(jì)相關(guān)的事，本身不參與項(xiàng)目。

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

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

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

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

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

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

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

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

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

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

進(jìn)入01會(huì)話成功，進(jìn)入02會(huì)話失敗，進(jìn)入03會(huì)話成功

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

摘自ISO 14229-1:2013 p39

我們看下上面的圖表，這個(gè)是ISO 14229定義的0x10服務(wù)應(yīng)具有的請(qǐng)求報(bào)文格式，M意為Mandatory 強(qiáng)制。可以看到0x10服務(wù)僅有兩個(gè)字節(jié)，整條報(bào)文是“服務(wù)ID+子功能”，比較簡(jiǎn)單。

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

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

$3E待機(jī)握手

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

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

$27安全訪問(wèn)

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

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

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

例子：

Tester：0227 0500 00 00 00 00 安全訪問(wèn)，05子功能

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

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

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

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

細(xì)說(shuō)下安全驗(yàn)證算法。安全驗(yàn)證算法包括1個(gè)核心，3個(gè)主體。

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

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

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

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

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

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

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

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

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

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

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

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

寫入一個(gè)VIN碼

正確的順序是10開頭的幀請(qǐng)求、30開頭的幀回復(fù)、21開頭再請(qǐng)求、22開頭繼續(xù)請(qǐng)求、03開頭回復(fù)確認(rèn)。我們一幀一幀來(lái)看。

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

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

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

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

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

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

$19 讀DTC

19服務(wù)是一套診斷服務(wù)中的重中之重。協(xié)議中篇幅長(zhǎng)達(dá)63頁(yè)，通信舉例達(dá)到了18個(gè)?？梢哉f(shuō)沒(méi)有19服務(wù)，就沒(méi)有完整的UDS。

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

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

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

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

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

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

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

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

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

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

06（讀取擴(kuò)展信息）。

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

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

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

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

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

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

Request/Response。括號(hào)標(biāo)識(shí)循環(huán)，可以讀出很多DTC

$14清除DTC

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

3個(gè)FF代表清除所有DTC。

Request：14+FF+FF+FF；

Response：54 。

14服務(wù)

$2F IO控制

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

IO控制類型分為4類，

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

01是復(fù)位為默認(rèn)值，Reset to Default。

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

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

若控制類型是00-02這三種，請(qǐng)求報(bào)文是4個(gè)字節(jié)。

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

2F服務(wù)，黃色區(qū)域?yàn)?個(gè)字節(jié)的DID

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

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

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

6種模式的配置

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

也就是說(shuō)，物理尋址+默認(rèn)會(huì)話、物理尋址+編程會(huì)話、物理尋址+擴(kuò)展會(huì)話、功能尋址+默認(rèn)會(huì)話、功能尋址+編程會(huì)話、功能尋址+擴(kuò)展會(huì)話，共6個(gè)模式。那么我們可以腦補(bǔ)一個(gè)26行、6列的表格了。

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

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

對(duì)于27服務(wù)，即安全訪問(wèn)服務(wù)，僅支持?jǐn)U展+物理、編程+物理2個(gè)模式。

對(duì)于2E、2F服務(wù)，僅支持?jǐn)U展+物理1個(gè)模式，且要求安全等級(jí)為1。

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

對(duì)于28、85服務(wù)，有些要求支持編程+擴(kuò)展會(huì)話的4個(gè)模式，有些則要求僅支持?jǐn)U展會(huì)話的2個(gè)模式。

對(duì)于31服務(wù)，要求安全等級(jí)為1，有些要求支持?jǐn)U展+物理、編程+物理2個(gè)模式，有些則要求僅支持?jǐn)U展+物理1種模式。

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

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

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

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

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

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

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

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

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

討論

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

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

四、AUTOSAR中的UDS

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

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

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

對(duì)于DCM來(lái)說(shuō)，這個(gè)模塊還是太大了，我們又將其分為3個(gè)獨(dú)立的子模塊。

DSL，全稱Diagnostic Session Layer，用于確保診斷請(qǐng)求和響應(yīng)的數(shù)據(jù)流，監(jiān)控診斷請(qǐng)求和響應(yīng)的時(shí)序，管理診斷會(huì)話和安全等級(jí)。這一層是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，實(shí)現(xiàn)每個(gè)具體的診斷服務(wù)，位于DCM的內(nèi)環(huán)，這一層事無(wú)巨細(xì)。比如22服務(wù)、27服務(wù)的callback正是源于這一層。

審核編輯：郭婷