UDS诊断
寫在前面：UDS實(shí)踐性強(qiáng)，邏輯復(fù)雜，很多服務(wù)非要體驗(yàn)過(guò)一次才能理解，導(dǎo)致包括我在內(nèi)的初學(xué)者感覺晦澀難懂，不明覺厲，因此將自己的理解寫下來(lái)、整理下來(lái)，與君共勉。
0.UDS診斷命令備忘錄
1.UDS簡(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)的。“統(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)移步：
心機(jī)之花：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é)議不沖突。小伙伴們有沒有發(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)科技公開資料2.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ù)。
???????通常，在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的消息。
3.UDS的26種服務(wù)
???????UDS的服務(wù)分為6大類，但常用的服務(wù)是加背景色的15種。這15種服務(wù)又可粗略地劃分為權(quán)限控制、讀取數(shù)據(jù)/信息、寫入數(shù)據(jù)/信息、通信控制、功能控制這幾類（注：這幾類是我自己劃分的）。
???????本文重點(diǎn)介紹以下幾個(gè)服務(wù)：$10 Diagnostic Session Control（診斷會(huì)話），$14 Clear Diagnostic Information（清除診斷信息），$19 Read DTC Information，$22 Read Data By Identifier（通過(guò)ID讀數(shù)據(jù)），$27 Security Access（安全訪問(wèn)），$2E Write Data By Identifier（通過(guò)ID寫數(shù)據(jù)），$3E Tester Present（待機(jī)握手）。
26種服務(wù)，其中15種較為常用(少了0x83和0x38)
（1）$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ù)，即程序燒錄。
這里來(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)沒有請(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有不同的含義。后文中我會(huì)補(bǔ)一個(gè)NRC的中文版本鏈接。
這里提一下一個(gè)特殊的NRC——0x78，requestCorrectlyReceived-ResponsePending（RCRRP，請(qǐng)求已被正確接收-回復(fù)待定）。這個(gè)NRC表明請(qǐng)求消息被正確地接收，請(qǐng)求消息中的所有參數(shù)都是有效的，但是要執(zhí)行的操作還沒有完成，Server端還沒有準(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值或NRCs SNS、SFNS、SNSIAS、SFNSIAS和ROOR對(duì)功能上處理請(qǐng)求的響應(yīng)抑制要求無(wú)關(guān)。
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)碼）。
（2）$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ù)（3）$19 讀DTC
19服務(wù)是一套診斷服務(wù)中的重中之重。協(xié)議中篇幅長(zhǎng)達(dá)63頁(yè)，通信舉例達(dá)到了18個(gè)。可以說(shuō)沒有19服務(wù)，就沒有完整的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)前故障和歷史故障都想讀。
在肯定回復(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)掩碼（4）$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è)（5）$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ù)，通過(guò)首輪種子的請(qǐng)求，首輪ECU會(huì)返回67+01+AA+BB+CC+DD，AA~DD就是種子了。之后第二輪，診斷端會(huì)利用種子進(jìn)行運(yùn)算（利用整車廠的算法），生成k1（不一定是1個(gè)字節(jié)），那么發(fā)送請(qǐng)求，27+02+[k1]。ECU同樣也會(huì)通過(guò)種子算出k2。當(dāng)k1和k2匹配時(shí)，解鎖（Unlocked）成功。
$27安全訪問(wèn)服務(wù)的否定響應(yīng)服務(wù)ID也是7F。還記得剛才否定響應(yīng)的格式嗎？7F+27+NRC（否定響應(yīng)碼）。
實(shí)際通信的截圖，黃色位置是密鑰區(qū)域例子：
Tester： 02 27 05 00 00 00 00 00 安全訪問(wèn)，05子功能
ECU： 06 67 05 08 27 11 F0 00 肯定響應(yīng)，回復(fù)了對(duì)應(yīng)安全級(jí)別的種子
Tester： 06 27 06 FF FF FF FF 00 發(fā)送密鑰，4個(gè)FF。注意06是與05成對(duì)使用的。
ECU： 03 7F 27 78 00 00 00 00 若為否定響應(yīng)，7F+27+NRC
ECU： 02 67 06 00 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ú)法再嘗試解鎖，防止人為的破解。
（6）$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 14是TP層（傳輸層）的信息，表示這是一個(gè)流控幀，ECU發(fā)出的，表示可以一直連續(xù)發(fā)，但連續(xù)幀最短的間隔時(shí)間要求是20ms。
- 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)行。
（7）$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é)是子功能，IO控制類型。
IO控制類型分為4類，
00是控制權(quán)還給ECU，Return Control To ECU。
01是復(fù)位為默認(rèn)值，Reset to Default。
02是凍結(jié)當(dāng)前的狀態(tài)，Freeze 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)"。
（8）$3E待機(jī)握手
$3E服務(wù)用于向服務(wù)器指示診斷儀仍然連接在網(wǎng)絡(luò)上，之前已經(jīng)激活的診斷服務(wù)功能可以仍然保持激活狀態(tài)。
例子：02 3E 80 00 00 00 00 00，發(fā)送一個(gè)3E服務(wù)的報(bào)文，保持非默認(rèn)會(huì)話狀態(tài)。80表示無(wú)需回復(fù)。4.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ù)部分廠家也是要求支持的。
5.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 產(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ā)。
6.學(xué)習(xí)資料
1.（全系列推薦）統(tǒng)一診斷服務(wù) (Unified diagnostic services ， UDS) （一）
2.統(tǒng)一診斷服務(wù) (Unified diagnostic services ， UDS) （二）
3.統(tǒng)一診斷服務(wù) (Unified diagnostic services ， UDS) （三）
4.統(tǒng)一診斷服務(wù) (Unified diagnostic services ， UDS) （四）
5.統(tǒng)一診斷服務(wù) (Unified diagnostic services ， UDS) （五）
6.統(tǒng)一診斷服務(wù) (Unified diagnostic services ， UDS) （六）
7.統(tǒng)一診斷服務(wù) (Unified diagnostic services ， UDS) （七）
8.基于CAN總線實(shí)現(xiàn)的UDS診斷（DoCAN）
9.【圖文】UDS診斷服務(wù)_百度文庫(kù)
10.CAN診斷基礎(chǔ)-上部分_圖文_百度文庫(kù)
11.CAN診斷-下_已讀_圖文_百度文庫(kù)
12.（推薦）ISO 14229+統(tǒng)一診斷服務(wù)
13.FlashBootloader_圖文_百度文庫(kù)
14.帳號(hào)登錄
15.ISO 15031-5-2015
16.ISO 15765-3車載診斷標(biāo)準(zhǔn)-詳細(xì)中文版
17.吉利汽車基于CAN線診斷技術(shù)規(guī)范_百度文庫(kù)
18.UDS(ISO14229-2006) 漢譯（No.7 應(yīng)用層協(xié)議）
19.基于UDS標(biāo)準(zhǔn)的Flash Boot Loader 設(shè)計(jì)淺析
20.[圖文]UDS診斷詳解 - 百度文庫(kù)
21.UDS診斷服務(wù)在車載ECU中的應(yīng)用分析 - 百度文庫(kù)
22.https://mp.weixin.qq.com/s?__biz=MzUyODgyMDI0OQ==&mid=2247483717&idx=2&sn=55e317acf1268f413f082c12b2cfa119&chksm=fa6b3033cd1cb925d9ead4bbb2dade0f9717e38b5818ceda53598d9f41b9f6469dfb8722b950&mpshare=1&scene=1&srcid=0529MTVAi9sTNyQA862pqGHf&pass_ticket=fXKprCqzX9p9OZ9nJFyHAS%2F9MqiG8sEkIcD5esPpqLN3MWs6fob6jp9mteazPgiW#rd
22*.張丁：汽車控制器（ECU）中DTC的狀態(tài)位
23.UDS_Wikipedia
24.（推薦）關(guān)于Autosar中DCM（14229UDS）模塊的理解
代碼參考：
1.SAE J1939 協(xié)議源代碼分析(一)-程序結(jié)構(gòu)框架
2.基于CAN總線的汽車診斷協(xié)議UDS(上位機(jī)開發(fā)網(wǎng)絡(luò)層及錯(cuò)誤代碼解析) - CSDN博客
3.基于CAN總線的汽車診斷協(xié)議UDS(ECU底層模塊移植開發(fā)) - CSDN博客
4.（推薦）基于CAN總線的汽車診斷協(xié)議UDS (網(wǎng)絡(luò)層 ISO 15765)
5.（推薦）github上的UDS協(xié)議棧源碼：ukign/UDSDemo
總結(jié)
- 上一篇： 数据结构与算法笔记——用Go语言描述
- 下一篇： 偏函数 匿名函数 高阶函数 map fi