UDS由ISO-14229系列標(biāo)準(zhǔn)定義，ISO 14229-1 定義了診斷服務(wù)，不涉及網(wǎng)絡(luò)及實(shí)現(xiàn)，只有應(yīng)用層的內(nèi)容。而ISO 14229-3則定義了UDS在CAN總線(xiàn)上的實(shí)現(xiàn)。

診斷通信的過(guò)程從用戶(hù)角度來(lái)看非常容易理解，診斷儀發(fā)送診斷請(qǐng)求(request)，ECU給出診斷響應(yīng)（response），而UDS就是為不同的診斷功能的request和response定義了統(tǒng)一的內(nèi)容和格式。

最近關(guān)于UDS的一系列專(zhuān)欄文章只關(guān)注應(yīng)用層的診斷服務(wù)，忽略下層的通信機(jī)制。

Diagnostic request的格式：

Diagnostic request的格式可以分為兩類(lèi)：一類(lèi)是擁有sub-function的，另一類(lèi)是沒(méi)有sub-function的，如下面兩張圖所示。Service ID(以下簡(jiǎn)稱(chēng)SID)的長(zhǎng)度固定為1個(gè)字節(jié)，代表了這條診斷命令執(zhí)行的什么功能。sub-function的長(zhǎng)度也是1個(gè)字節(jié)，它通常表示對(duì)這個(gè)診斷服務(wù)的具體操作，比如是啟動(dòng)、停止還是查詢(xún)這個(gè)診斷服務(wù)。而后面的parameter則根據(jù)各個(gè)診斷服務(wù)的不同具有不同的內(nèi)容，長(zhǎng)度和格式并沒(méi)有統(tǒng)一規(guī)格，它用于限定診斷服務(wù)執(zhí)行的條件，比如某個(gè)診斷服務(wù)執(zhí)行的時(shí)間等。parameter的一個(gè)重要應(yīng)用是作為標(biāo)識(shí)符，標(biāo)識(shí)診斷請(qǐng)求要讀出的數(shù)據(jù)內(nèi)容，我會(huì)在后續(xù)的文章里詳細(xì)講述各個(gè)診斷服務(wù)的應(yīng)用。

擁有sub-function的診斷請(qǐng)求

無(wú)sub-function的診斷請(qǐng)求

有一點(diǎn)要補(bǔ)充的是，其實(shí)sub-function嚴(yán)格來(lái)說(shuō)是7個(gè)bit，而不是1個(gè)byte，因?yàn)樗淖罡呶籦it被用于抑制正響應(yīng)（suppress positive response,SPR），如果這個(gè)bit被置1，則ECU不會(huì)給出正響應(yīng)（positive response）； 如果這個(gè)bit被置0，則ECU會(huì)給出正響應(yīng)。這樣做的目的是可以告訴ECU不要發(fā)不必要的response，從而節(jié)約通信資源。

Diagnostic response的格式：

Diagnostic response分為positive和negative兩類(lèi)。positive response意味著診斷儀發(fā)過(guò)來(lái)的診斷請(qǐng)求被執(zhí)行了，而negative response則意味著ECU因?yàn)槟撤N原因無(wú)法執(zhí)行診斷儀發(fā)過(guò)來(lái)的診斷請(qǐng)求，而無(wú)法執(zhí)行的原因則存在于negative response的報(bào)文中。

positive response

positive response的格式如上圖所示，也基本上是由三部分組成，其中的response SID這個(gè)字節(jié)作為診斷請(qǐng)求的echo，它等于SID + 0X40。后面的兩個(gè)部分則視具體的診斷服務(wù)而定。

negative response

negative response的格式固定為3個(gè)字節(jié)，第一個(gè)字節(jié)為0x7F，第二個(gè)字節(jié)是被拒絕掉的SID，第三個(gè)字節(jié)是這個(gè)診斷服務(wù)無(wú)法被執(zhí)行的原因。下面這張圖列舉了部分原因代碼，比如，如果ECU給出7F 22 13這個(gè)negative response，則說(shuō)明22這個(gè)服務(wù)因?yàn)樵\斷請(qǐng)求數(shù)據(jù)長(zhǎng)度不對(duì)的原因無(wú)法執(zhí)行。

Negative Response Code

總結(jié)：診斷通信的過(guò)程就是診斷儀和ECU交換數(shù)據(jù)，前者發(fā)的是request，后者發(fā)的是response，而UDS最重要的作用就是定義了這些request和response的格式和內(nèi)容。今天這篇文章對(duì)request和response進(jìn)行了簡(jiǎn)要介紹，在后面描述各種診斷服務(wù)的文章中我會(huì)通過(guò)更多的示例來(lái)說(shuō)明這兩個(gè)基本概念。

UDS定義的診斷服務(wù)從邏輯來(lái)說(shuō)分為以下幾類(lèi)：

Diagnostic and Communication Management （診斷和通信管理）
Data Transmission （數(shù)據(jù)傳輸）
Stored Data Transmission （存儲(chǔ)數(shù)據(jù)傳輸，用于操作DTC）
InputOutput Control （IO控制）
Routine Control （不知如何翻譯好，作用是調(diào)用ECU內(nèi)部的預(yù)置函數(shù)）
Upload Download （上傳下載）

UDS規(guī)定使用1個(gè)byte來(lái)表示診斷服務(wù)，即所謂的Service ID,簡(jiǎn)稱(chēng)SID。本文介紹一下Diagnostic and Communication Management 這一類(lèi)診斷服務(wù)中的一部分。

DiagnosticSessionControl (0x10)

DiagnosticSessionControl診斷request的格式

DiagnosticSessionControl這個(gè)服務(wù)的SID是0x10，request固定為2個(gè)byte，第一個(gè)byte是SID，第二個(gè)byte的低7bit是sub-function，用于指示ECU將進(jìn)入的session。UDS定義的session包括：

0x00 ISOSAEReserved（保留）

0x01 defaultSession

0x02 ProgrammingSession

0x03 extendedDiagnosticSession

0x04 safetySystemDiagnosticSession

0x05 – 0x3F ISOSAEReserved（保留）

0x40 – 0x5F vehicleManufacturerSpecific（由整車(chē)廠自定義使用）

0x60 – 0x7E systemSupplierSpecific（由ECU供應(yīng)商自定義使用）

0x7F ISOSAEReserved（保留）

DiagnosticSessionControl用于控制ECU在不同的session之間進(jìn)行轉(zhuǎn)換，session可以看作是ECU所處的一種軟件狀態(tài)，在不同的session中診斷服務(wù)執(zhí)行的權(quán)限不同。 ECU上電之后，默認(rèn)處在defaultSession中，在這個(gè)session中很多診斷服務(wù)不可以執(zhí)行，很多診斷相關(guān)的數(shù)據(jù)不能讀取或?qū)懭搿Ｒ话愕脑\斷儀啟動(dòng)之后，會(huì)給ECU發(fā)送10 03，即讓ECU進(jìn)入 extendedDiagnosticSession中，在這個(gè)session中可執(zhí)行的診斷服務(wù)就很多了。而如果要讓ECU保持在non-defaultSession中，則需要診斷儀每隔固定的時(shí)間發(fā)送0x3E服務(wù)，ECU才會(huì)知道診斷儀有和自己通信的需求，從而保持在non-defaultSession中。另一個(gè)常用的session是ProgrammingSession，在這個(gè)session中可以進(jìn)行軟件刷寫(xiě)的一系列診斷服務(wù)。0x40 – 0x5F 這個(gè)范圍中的session由整車(chē)廠自定義使用，比如，某些診斷服務(wù)或診斷數(shù)據(jù)的操作需要在生產(chǎn)線(xiàn)上執(zhí)行，即所謂的End-Of-Line，整車(chē)廠可以從這個(gè)范圍中選擇一個(gè)值來(lái)表示EOL session；又或者在開(kāi)發(fā)階段需要某種“超級(jí)”session，則也可以從這里選一個(gè)值用來(lái)使ECU進(jìn)入開(kāi)發(fā)模式的session。DiagnosticSessionControl這個(gè)服務(wù)非常簡(jiǎn)單，但是它卻是ECU和診斷通信的第一條診斷命令。

DiagnosticSessionControl診斷response的格式

這個(gè)診斷服務(wù)的response分為三部分，第一部分是0x50，作為SID的echo；第二部分是進(jìn)入的session，作為sub-function的echo；第三部分是4個(gè)字節(jié)，前兩個(gè)字節(jié)代表P2Server_max，即ECU在應(yīng)用層上對(duì)診斷命令的響應(yīng)時(shí)間，后兩個(gè)字節(jié)代表P2*Server_max

，即ECU在暫時(shí)無(wú)法處理當(dāng)前診斷命令（具體表現(xiàn)為發(fā)送了NRC 0X78），在應(yīng)用層上對(duì)診斷命令響應(yīng)的最長(zhǎng)時(shí)間。

ECUReset (0x11)

ECUReset 這條指令的用途是通過(guò)診斷請(qǐng)求使ECU重啟。

ECUReset 診斷request的格式

ECUReset 這個(gè)服務(wù)的SID是0x11，request固定為2個(gè)byte，第一個(gè)byte是SID，第二個(gè)byte的低7bit是sub-function，用于指示ECU將模擬哪種方式進(jìn)行重啟。

常用的sub-function包括（只舉2個(gè)例子，UDS還定義了很多其他的值）

0x01hardReset 模擬KL30的重啟

0x02keyOffOnReset 模擬KL15的重啟

當(dāng)我們通過(guò)診斷命令改寫(xiě)了ECU的某些數(shù)據(jù)，或者對(duì)ECU進(jìn)行了某些設(shè)置，只有將ECU重啟才能將這些配置生效，所以就有了這個(gè)診斷命令。在ECUReset 執(zhí)行之后，ECU會(huì)從Non-defaultsession回退到defaultsession中。

SecurityAccess (0x27)

廠家可能會(huì)為ECU定義某些安全級(jí)別稍微高一些的診斷服務(wù)，在執(zhí)行此類(lèi)服務(wù)之前，就需要執(zhí)行SecurityAccess 這個(gè)診斷命令，進(jìn)行一個(gè)簡(jiǎn)單的身份驗(yàn)證。

完成SecurityAccess 有以下步驟：

診斷儀向ECU請(qǐng)求“Seed”（通常是一個(gè)與時(shí)間相關(guān)的偽隨機(jī)數(shù)）,
ECU向診斷儀發(fā)送“Seed”,
診斷儀向ECU發(fā)送“Key” (根據(jù)請(qǐng)求得到的Seed和一個(gè)本地的密碼進(jìn)行計(jì)算得來(lái))
ECU判斷診斷儀發(fā)來(lái)的“Key”是否有效

根據(jù)UDS的定義，0x03, 0x05, 0x07 – 0x41 這個(gè)范圍留給用于requestSeed的sub-function；0x04, 0x06, 0x08 – 0x42這個(gè)范圍留給用于sendKey的sub-function。具體選擇哪對(duì)值，由整車(chē)廠自己定義。整車(chē)廠也可以選擇多對(duì)sub-function，用于不同等級(jí)的安全訪(fǎng)問(wèn)。

下面我舉一個(gè)完成SecurityAccess的診斷命令的例子，假設(shè)0x05用于requestSeed，0x06用于sendKey。

診斷儀發(fā)送 27 05

ECU響應(yīng) 67 05 01 01 01（seed是 01 01 01）

診斷儀發(fā)送 27 06 02 03 04（key值是02 03 04，seed是 01 01 01，假設(shè)本地密碼為01 02 03，而算法就是將密碼與seed相加）

ECU驗(yàn)證成功 67 06

此時(shí)ECU就處于unlocked的狀態(tài)了，那些被保護(hù)起來(lái)的診斷服務(wù)和診斷數(shù)據(jù)可以被操作了。通常來(lái)說(shuō)，如果ECU重啟，或者回到了default session，unlocked狀態(tài)就失效了，如果要執(zhí)行相關(guān)診斷服務(wù)，則需要再次執(zhí)行上面描述的過(guò)程。

CommunicationControl (0x28)

該服務(wù)用于打開(kāi)/關(guān)閉某些類(lèi)別的報(bào)文的發(fā)送/接收。它通常在刷寫(xiě)軟件或大量數(shù)據(jù)的時(shí)候使用，因?yàn)樵谒④浖騾?shù)的時(shí)候并不需要ECU進(jìn)行與通信相關(guān)的功能，將通信關(guān)閉之后可以把所有通信資源都留給軟件或參數(shù)的下載，當(dāng)下載過(guò)程完成之后再利用該服務(wù)將通信恢復(fù)即可。

0x28服務(wù)的格式如下圖所示

0x28服務(wù)的格式

第一部分即SID，一個(gè)byte，值為0x28；

第二部分是sub-function，表明要對(duì)ECU的通信進(jìn)行哪種控制，具體包括 ：

0x00 enableRxAndTx （激活接收和發(fā)送）

0x01 enableRxAndDisableTx（激活接收和關(guān)閉發(fā)送）

0x02 disableRxAndEnableTx（激活發(fā)送和關(guān)閉接收）

0x03 disableRxAndTx（關(guān)閉接收和發(fā)送）

0x04 enableRxAndDisableTxWithEnhancedAddressInformation（激活接收和關(guān)閉發(fā)送，針對(duì)特定的地址）

0x05 enableRxAndTxWithEnhancedAddressInformation（激活接收和發(fā)送，針對(duì)特定的地址）

0x06 - 0x7F都是保留或者留給廠商自定義的。

第三部分表明這條診斷請(qǐng)求要對(duì)哪種報(bào)文進(jìn)行控制，長(zhǎng)度為1個(gè)byte，定義如下表所示：

communicationType的定義

這個(gè)byte中最常用的就是低2 bit，0x1代表普通應(yīng)用報(bào)文，0x2代表網(wǎng)絡(luò)管理報(bào)文，0x3代表普通應(yīng)用報(bào)文和網(wǎng)絡(luò)管理報(bào)文。

第四部分是optional的，只有當(dāng)sub-functional等于0x04或0x05時(shí)才需要使用。

舉個(gè)完整的診斷服務(wù)例子：

28 01 01 表示激活應(yīng)用報(bào)文的接收并關(guān)閉應(yīng)用報(bào)文的發(fā)送（網(wǎng)絡(luò)管理報(bào)文不受影響）。

28 00 01 表示激活應(yīng)用報(bào)文的接收和發(fā)送（網(wǎng)絡(luò)管理報(bào)文不受影響）。

TesterPresent (0x3E)

這個(gè)診斷服務(wù)的用處可以通過(guò)它的名字很明顯地得知，即告知ECU診斷儀還在連接著。在上一篇文章中我說(shuō)到了關(guān)于session的部分，如果沒(méi)有診斷命令的發(fā)送和接收，ECU將從non-default session中回退到default session， 0x3E就是用于使ECU保持在當(dāng)前session。

這應(yīng)該是UDS中最簡(jiǎn)單的一個(gè)診斷服務(wù)了，它永遠(yuǎn)只有兩個(gè)byte，格式如下：

0x3E診斷服務(wù)的格式

當(dāng)sub-function是0x00時(shí)，ECU要給出response；當(dāng)sub-function是0x80時(shí)，ECU不需要要給出response。

一般來(lái)說(shuō)主機(jī)廠會(huì)為這個(gè)服務(wù)定義兩個(gè)時(shí)間參數(shù)，一個(gè)參數(shù)用于規(guī)定自己的診斷儀發(fā)送0x3E服務(wù)的間隔，另一個(gè)參數(shù)用于定義ECU收不到0x3E服務(wù)的timeout時(shí)間。

ControlDTCSetting (0x85)

該服務(wù)用于控制ECU的DTC存儲(chǔ)，這個(gè)服務(wù)常常和前面提到的28服務(wù)一起使用，比如，在開(kāi)始寫(xiě)參數(shù)之前，為了獲得更快的傳輸速度，我們用28服務(wù)把所有ECU的通信關(guān)閉了，但此時(shí)因?yàn)槭盏讲坏较嚓P(guān)的報(bào)文，ECU會(huì)沒(méi)有必要地存儲(chǔ)很多DTC，這時(shí)如果我們使用85服務(wù)把ECU存儲(chǔ)DTC的功能暫時(shí)性地禁止掉，則不會(huì)造成這種麻煩。

0x85服務(wù)的格式

第一部分即SID，一個(gè)byte，值為0x85；

第二部分是sub-function，表明是打開(kāi)還是關(guān)閉ECU的DTC存儲(chǔ)，具體包括 ：

0x01 on

0x02 off

第三部分是optional的，由各家自己定義，比如，可以用FF FF FF 來(lái)表示這條診斷命令針對(duì)所有的DTC。

ResponseOnEvent (0x86)

我在以前的文章里說(shuō)，診斷通信過(guò)程是問(wèn)答式的，診斷儀發(fā)請(qǐng)求，ECU給響應(yīng)。0x86服務(wù)算是一個(gè)例外，在ECU收到這條0x86服務(wù)之后，當(dāng)DTC產(chǎn)生時(shí)，它會(huì)自動(dòng)地上報(bào)DTC及相關(guān)環(huán)境數(shù)據(jù)，直到用另一條0x86服務(wù)來(lái)關(guān)閉ECU的這個(gè)行為。

該功能主要用于ECU的前期開(kāi)發(fā)階段，在售后和生產(chǎn)中是不會(huì)用到的，而且該服務(wù)的格式復(fù)雜（即可變的參數(shù)很多），執(zhí)行它還分為好幾個(gè)步驟，我就不詳細(xì)寫(xiě)了。

LinkControl (0x87)

這個(gè)服務(wù)用于轉(zhuǎn)化ECU數(shù)據(jù)鏈路層和物理層的狀態(tài)，比如，在高速CAN上的ECU正常通信速率是500 kbit/s，但它同時(shí)也支持1M bit/s的波特率，如果需要刷寫(xiě)大量數(shù)據(jù)，便可以利用這條診斷服務(wù)讓ECU以1M bit/s的波特率進(jìn)行通信。

這個(gè)診斷服務(wù)的執(zhí)行分為兩個(gè)步驟：

驗(yàn)證ECU是否支持要調(diào)整到的目標(biāo)波特率
讓ECU的數(shù)據(jù)鏈路層和物理層轉(zhuǎn)到目標(biāo)波特率的通信狀態(tài)

只有當(dāng)?shù)谝粋€(gè)步驟驗(yàn)證通過(guò)了，第二個(gè)步驟才可以成功執(zhí)行。

這篇文章介紹一下UDS的第二類(lèi)診斷服務(wù)，即Data Transmission （數(shù)據(jù)傳輸）。這類(lèi)診斷服務(wù)包括以下SID：

ReadDataByIdentifier (0x22)

ReadMemoryByAddress (0x23)

ReadScalingDataByIdentifier (0x24)

ReadDataByPeriodicIdentifier (0x2A)

DynamicallyDefineDataIdentifier (0x2C)

WriteDataByIdentifier (0x2E)

WriteMemoryByAddress (0x3D)

通常，0x22和0x2E成對(duì)使用，0x23和0x3D成對(duì)使用，這幾個(gè)服務(wù)用于診斷數(shù)據(jù)的基本讀寫(xiě)操作。0x24，0x2A，0x2C是一些特殊操作。

0x22和0x2E這兩個(gè)服務(wù)是對(duì)以標(biāo)識(shí)符(identifier)標(biāo)記的數(shù)據(jù)的操作，前者是讀，后者是寫(xiě)。UDS規(guī)定，診斷數(shù)據(jù)使用兩個(gè)byte的標(biāo)識(shí)符來(lái)標(biāo)記，比如，0xF187用來(lái)標(biāo)記ECU的零件號(hào)，0xF19E用于標(biāo)記該ECU所使用的診斷文件的名字，UDS還規(guī)定了廠家可以自定義的標(biāo)識(shí)符范圍。這兩個(gè)服務(wù)的用法很簡(jiǎn)單，下面我以讀取ECU的零件號(hào)為例說(shuō)明：

22 F1 87 （讀取零件號(hào)）

62 F1 87 XX YY ZZ KK MM NN（給出零件號(hào)）

具體每次可以使用22服務(wù)讀取幾個(gè)ID，每個(gè)ID的讀寫(xiě)權(quán)限（比如在哪些session中可以讀寫(xiě)，是否需要安全訪(fǎng)問(wèn)操作等），由廠家自定義。假設(shè)零件號(hào)這個(gè)ID是可以寫(xiě)入的話(huà)，則寫(xiě)零件號(hào)的診斷命令是：

2E F1 87 XX YY ZZ KK MM NN（寫(xiě)入零件號(hào)）

6E F1 87（給出positive response）

0x23和0x3D這兩個(gè)服務(wù)是對(duì)以地址信息（memoryAddress ）標(biāo)記的數(shù)據(jù)的操作，前者是讀，后者是寫(xiě)。這個(gè)命令的格式稍微復(fù)雜一點(diǎn)。以0x23為例，它的診斷請(qǐng)求格式是：

0x23服務(wù)的請(qǐng)求格式0x23

第一部分固定為1個(gè)byte, 0x23；

第二部分是格式信息，長(zhǎng)度為1個(gè)byte，高4 bits用于指示memorySize的長(zhǎng)度（字節(jié)數(shù)），低4 bits用于指示memoryAddress的長(zhǎng)度（字節(jié)數(shù)）。比如，如果這個(gè)值為0x46，則后面的memorySize為6個(gè)byte，memoryAddress為4個(gè)byte。

第三部分是memoryAddress信息，它的長(zhǎng)度由第二部分的AddressAndLengthFormatIdentifier指示。

第四部分是memorySize信息，它的長(zhǎng)度由第二部分的AddressAndLengthFormatIdentifier指示。

如果這條命令的格式是 23 22 xx yy aa bb，則它的含義就是，讀取xx yy地址的長(zhǎng)度為aa bb的數(shù)據(jù)。

了解了0x23的用法，0x3D的用法就很好理解了，它標(biāo)識(shí)memoryAddress和memorySize的方法與0x23相同，只是在診斷命令最后再加上一段需要寫(xiě)入的數(shù)據(jù)。

這篇文章介紹Stored Data Transmission （存儲(chǔ)數(shù)據(jù)傳輸，用于操作DTC）這一類(lèi)診斷服務(wù)，涉及到兩條診斷命令，分別是：

0x14:ClearDiagnosticInformation

0x19:ReadDTCInformation

這兩條服務(wù)用于操作存儲(chǔ)在ECU中的DTC，使用頻率很高，而且它們比較好地體現(xiàn)了“診斷”兩個(gè)字的含義。

0x14:ClearDiagnosticInformation

這條診斷命令的格式比較簡(jiǎn)單，用法也很好理解，即刪除存儲(chǔ)在ECU中的DTC。

0x14診斷命令請(qǐng)求的格式

第一個(gè)字節(jié)就是SID了，后邊的三個(gè)字節(jié)用于標(biāo)識(shí)將要被刪除的DTC種類(lèi)，UDS規(guī)定用FF FF FF表示所有種類(lèi)的DTC，由廠家自定義代表Powertrain、Chassis、、Body、Network Communication等種類(lèi)DTC的值。

比如，14 FF FF FF這條指令表示的就是刪除掉ECU中的所有DTC。ECU只需要返回一個(gè)0x54表示成功執(zhí)行即可。

0x19:ReadDTCInformation

這條指令用于讀取存儲(chǔ)在ECU中的DTC，它的格式如下

0x19診斷命令請(qǐng)求的格式0x14診斷命令請(qǐng)求的格式

0x19服務(wù)的sub-function代表了各式各樣讀取DTC的方法，UDS給19服務(wù)的sub-function從0x00到0x19進(jìn)行了明確定義，我只使用過(guò)其中4種，下面對(duì)我用過(guò)的這些進(jìn)行介紹，如果大家對(duì)其他的感興趣，可以查閱ISO 14229的定義。

sub-function = 0x01 （reportNumberOfDTCByStatusMask）

sub-function = 0x01用于讀取符合特定條件的DTC數(shù)量，此時(shí)parameter為一個(gè)byte的Mask，用于與DTC的Status進(jìn)行“與”運(yùn)算，而ECU返回的則是"與"運(yùn)算之后結(jié)果不為0的DTC的數(shù)量。DTC的Status用一個(gè)byte表示，其中的8個(gè)bit分別代表DTC的不同狀態(tài)，比如，bit 0 表示這個(gè)DTC是active的還是passive的，bit 4表示這個(gè)DTC是否已經(jīng)被confirm了，如果DTC的狀態(tài)是confirm，則說(shuō)明該DTC已經(jīng)被ECU存儲(chǔ)下來(lái)了。

比如：19 01 08這個(gè)命令的用途，就是讀取所有狀態(tài)為confirm的DTC的數(shù)量。

sub-function = 0x02 （reportDTCByStatusMask）

sub-function = 0x02用于讀取符合特定條件的DTC列表，此時(shí)parameter仍然為一個(gè)byte的Mask，用于與DTC的Status進(jìn)行“與”運(yùn)算，而ECU返回的則是"與"運(yùn)算之后結(jié)果不為0的DTC列表。

比如19 02 01這個(gè)命令的用途，就是讀取所有狀態(tài)為active的DTC的數(shù)量。此時(shí)ECU返回的格式應(yīng)該是59 02 01 XX XX XX 01 YY YY YY 09......。返回的DTC列表中的每個(gè)條目為4個(gè)字節(jié)，前三個(gè)字節(jié)用于標(biāo)識(shí)DTC，比如 XX XX XX，最后一個(gè)字節(jié)用于標(biāo)識(shí)DTC狀態(tài)，比如01，表示DTC是active的，09表示DTC是active且confirm的。

sub-function = 0x06 （reportDTCExtDataRecordByDTCNumber）

sub-function = 0x06用于讀取某個(gè)DTC及其相關(guān)的環(huán)境數(shù)據(jù)，此時(shí)parameter為4個(gè)byte，前三個(gè)byte用于標(biāo)識(shí)我們要讀取的DTC，第四個(gè)byte用于標(biāo)識(shí)要讀取的環(huán)境數(shù)據(jù)的范圍，UDS規(guī)定使用FF來(lái)表示讀取所有的環(huán)境數(shù)據(jù)，各廠家可以要根據(jù)自己的需求定義其他的值來(lái)代表要讀取的環(huán)境數(shù)據(jù)的范圍。環(huán)境數(shù)據(jù)包括DTC狀態(tài)，優(yōu)先級(jí)，發(fā)生次數(shù)，老化計(jì)數(shù)器，時(shí)間戳，里程等，廠家還可以根據(jù)自己的需求定義一些此DTC產(chǎn)生時(shí)的測(cè)量數(shù)據(jù)。

比如 19 06 XX XX XX FF就表示讀取 XX XX XX這個(gè)DTC的所有環(huán)境數(shù)據(jù)，ECU的返回值應(yīng)該是59 06 XX XX XX AA BB CC DD.....，其中AA BB CC DD...代表的就是XX XX XX這個(gè)DTC產(chǎn)生時(shí)所一起存儲(chǔ)的環(huán)境數(shù)據(jù)。

sub-function = 0x0E（reportMostRecentConfirmedDTC）

sub-function = 0x0E時(shí)，不需要parameter。0x0E表示，要求ECU上報(bào)最近的一條被置為confirm的DTC。我在《統(tǒng)一診斷服務(wù) (Unified diagnostic services ， UDS) （三）》一文中介紹過(guò)0x86服務(wù)，sub-function = 0x0E的19服務(wù)通常被作為參數(shù)傳遞給86指令，要求ECU在發(fā)生DTC存儲(chǔ)的時(shí)候進(jìn)行自動(dòng)上報(bào)，即19 0E這兩個(gè)字節(jié)的指令被嵌入到86服務(wù)的命令中。這條命令在開(kāi)發(fā)階段會(huì)用到，比如驗(yàn)證某個(gè)故障路徑是否生效。

這篇文章將介紹InputOutputControlByIdentifier (0x2F) 和RoutineControl (0x31) 這兩個(gè)診斷服務(wù)的用途和用法。它倆的作用有點(diǎn)類(lèi)似，都是調(diào)用ECU內(nèi)部一些預(yù)定義的操作序列，相當(dāng)于是我們從外部利用診斷手段控制ECU的接口。

InputOutputControlByIdentifier (0x2F)

ECU簡(jiǎn)單來(lái)說(shuō)就是一個(gè)對(duì)輸入(sensor)進(jìn)行計(jì)算再產(chǎn)生輸出（actuator）的系統(tǒng)。2F這個(gè)服務(wù)就是對(duì)ECU的輸入和輸出進(jìn)行控制。這個(gè)服務(wù)在生產(chǎn)線(xiàn)上會(huì)需要使用，比如，在總裝階段，工人需要驗(yàn)證車(chē)上的各種功能是否正常，例如四個(gè)車(chē)窗的升降是否正常，如果挨個(gè)開(kāi)關(guān)去按，那效率很低，如果通過(guò)一個(gè)診斷命令就能夠觀察到車(chē)窗升降的情況，效率則高得多。

ECU就是一個(gè)處理輸入信息、輸出控制的系統(tǒng)

比如，ECU接收一個(gè)輸入信號(hào)A，我們就可以利用2F給這個(gè)A賦個(gè)我們需要的值；ECU對(duì)某個(gè)執(zhí)行器B進(jìn)行控制，我們就可以利用2F服務(wù)再配上某些特定的參數(shù)來(lái)實(shí)現(xiàn)對(duì)B的控制，例如門(mén)控對(duì)車(chē)窗升降、后視鏡折疊等的控制。

2F命令的格式

2F服務(wù)的request由4部分組成

SID
dataIdentifier，用于標(biāo)識(shí)被控制的IO對(duì)象
controlOptionRecord，用于標(biāo)識(shí)控制方式，比如是啟動(dòng)、停止控制，還可以有一些自定義的參數(shù)來(lái)進(jìn)行更精準(zhǔn)的控制，比如讓某個(gè)執(zhí)行器的動(dòng)作持續(xù)多長(zhǎng)時(shí)間。controlOptionRecord又分為兩部分，分別是1個(gè)byte的inputOutputControlParameter，以及若干byte由廠家自定義使用的controlState。
controlEnableMaskRecord，這是一個(gè)可選參數(shù)，用于標(biāo)識(shí)controlOptionRecord中的哪些parameter被使用。

UDS明確定義了四種inputOutputControlParameter

0x00 returnControlToECU （將控制權(quán)還給ECU，即結(jié)束控制）

0x01 resetToDefault （將dataIdentifier所引用的輸入信號(hào)、內(nèi)部參數(shù)、輸出信號(hào)等設(shè)為默認(rèn)值）

0x02 freezeCurrentState（將dataIdentifier所引用的輸入信號(hào)、內(nèi)部參數(shù)、輸出信號(hào)等凍結(jié)住）

0x03 shortTermAdjustment （將dataIdentifier所引用的輸入信號(hào)、內(nèi)部參數(shù)、輸出信號(hào)進(jìn)行設(shè)置，其實(shí)就相當(dāng)于開(kāi)始了對(duì)ECU的控制）

另外，UDS定義可以用22服務(wù)讀取2F服務(wù)中使用的dataIdentifier，返回值是狀態(tài)信息，具體的狀態(tài)信息是什么，則由使用者自定義了。

我們以14229中舉的一個(gè)例子來(lái)感受一下2F服務(wù)：

這個(gè)例子是使用2F控制Air Inlet Door Position （進(jìn)氣口門(mén)位置），用標(biāo)識(shí)符0x9B00來(lái)標(biāo)識(shí)進(jìn)氣口門(mén)的位置。Air Inlet Door Position [%] = decimal(Hex) * 1 [%] ，即用一個(gè)百分比來(lái)表示這個(gè)位置。

step1:

　　tester 發(fā)送22 9B 00讀取當(dāng)前進(jìn)氣口門(mén)的位置

　　ECU返回62 9B 00 0A ， 0x0A = 10（dec），表示當(dāng)前位置是10%

step2:

　　tester 發(fā)送2F 9B 00 03 3C ，表示要將進(jìn)氣口門(mén)的位置調(diào)整到60%，0x3C = 60（dec）

　　ECU返回6F 9B 00 03 0C，表示接受控制，當(dāng)前進(jìn)氣口門(mén)的位置為12%。因?yàn)镋CU收到請(qǐng)求后是立刻響應(yīng)的，而門(mén)的位置調(diào)節(jié)需要時(shí)間，所以還沒(méi)有達(dá)到60%。

step3:

　　過(guò)一段時(shí)間后tester 發(fā)送22 9B 00讀取當(dāng)前進(jìn)氣口門(mén)的位置

　　ECU返回62 9B 00 3C ， 0x3C = 60（dec），表示當(dāng)前位置已經(jīng)到了60%

step4:

　　tester 發(fā)送2F 9B 00 00，將控制權(quán)交還給ECU

　　ECU返回6F 9B 00 00 3A，表示接受請(qǐng)求，當(dāng)前位置為58%

step5:

　　tester 發(fā)送2F 9B 00 02，凍結(jié)9B 00這個(gè)ID所代表的進(jìn)氣口門(mén)位置這個(gè)狀態(tài)

　　ECU返回6F 9B 00 02 32，表示接受請(qǐng)求，當(dāng)前位置保持在50%

RoutineControl (0x31)

31服務(wù)是調(diào)用ECU內(nèi)置的一些操作序列的接口，這個(gè)服務(wù)的應(yīng)用很靈活，因?yàn)閺S家可以根據(jù)自己的需要為ECU定義各種各樣的內(nèi)部操作，而要執(zhí)行這些操作只需要調(diào)用31服務(wù)就好了。典型的用途包括檢查邊界條件、清除閃存、對(duì)數(shù)據(jù)進(jìn)行較驗(yàn)、對(duì)軟硬件依賴(lài)性進(jìn)行校驗(yàn)等，甚至有需要的話(huà)可以進(jìn)行恢復(fù)出廠設(shè)置的操作，還有很多與ECU自身邏輯功能相關(guān)的操作也可以定義。

31命令的格式2F命令的格式

31服務(wù)的request由4部分組成

SID
sub-function，用于標(biāo)識(shí)要執(zhí)行什么動(dòng)作，啟動(dòng)（0x01）、停止（0x02）、查詢(xún)結(jié)果（0x03）
routineIdentifier，用于標(biāo)識(shí)要執(zhí)行的routine
routineControlOptionRecord，這是一個(gè)可選參數(shù)，用于標(biāo)識(shí)routine執(zhí)行時(shí)所需要的參數(shù)，由各家自定義它的內(nèi)容

舉個(gè)例子，假設(shè)用0x0809這個(gè)ID來(lái)代表檢查ECU是否滿(mǎn)足軟件刷寫(xiě)條件（比如車(chē)速、轉(zhuǎn)速為0，KL15接通等）的routine。

tester發(fā)送31 01 08 09來(lái)啟動(dòng)0x0809這個(gè)routine

如果所有條件都滿(mǎn)足，則ECU返回71 01 08 09作為echo即可，如果條件不滿(mǎn)足，則ECU返回71 01 08 09 XX YY ZZ，后邊的XX YY ZZ則表明哪些條件不滿(mǎn)足，具體的內(nèi)容就由廠家自己定義了。

在關(guān)于UDS的第二篇文章中，我提到過(guò)UDS定義的服務(wù)從邏輯上分為6類(lèi)，在第二至第六篇中已經(jīng)講解了前五類(lèi)，在本文中將介紹最后一類(lèi)UDS服務(wù)，即Upload Download functional unit ，數(shù)據(jù)的上傳下載。

從成本等角度考慮，汽車(chē)ECU中用于緩存診斷服務(wù)數(shù)據(jù)的buffer大小有限，所以當(dāng)我們需要讀取或?qū)懭氤^(guò)buffer大小的數(shù)據(jù)時(shí)，就無(wú)法簡(jiǎn)單地使用2E和22服務(wù)了，UDS據(jù)此定義了幾個(gè)將大塊數(shù)據(jù)寫(xiě)入或讀出的服務(wù)，即數(shù)據(jù)下載和上傳。

Upload Download functional unit總共定義了5個(gè)診斷服務(wù)，分別是：

RequestDownload （0x34）：客戶(hù)端向服務(wù)器請(qǐng)求下載數(shù)據(jù)
RequestUpload （0x35）客戶(hù)端向服務(wù)器請(qǐng)求上傳數(shù)據(jù)
TransferData（0x36） 客戶(hù)端向服務(wù)器傳數(shù)據(jù)（下載），或者服務(wù)器向客戶(hù)端傳數(shù)據(jù)（上傳）
RequestTransferExit（0x37）數(shù)據(jù)傳輸完成，請(qǐng)求退出
RequestFileTransfer（0x38） 傳輸文件的操作，可以用于替代上傳下載的服務(wù)。

下圖是數(shù)據(jù)下載的簡(jiǎn)略過(guò)程，用到了34，36，37這三個(gè)服務(wù)，如果是上傳的話(huà)，34服務(wù)被35服務(wù)替換，數(shù)據(jù)傳輸方向變一下，就可以了。

Tester向ECU刷寫(xiě)數(shù)據(jù)的大概過(guò)程

RequestDownload （0x34）

0x34服務(wù)用于啟動(dòng)下載傳輸，作用是告知ECU準(zhǔn)備接受數(shù)據(jù)，ECU則通過(guò)0x74 response告訴診斷儀自己是否允許傳輸，以及自己的接受能力是多大。

0x34服務(wù)的請(qǐng)求格式

0x34服務(wù)的請(qǐng)求格式包括5個(gè)部分

第一部分：1個(gè)byte的SID

第二部分：1個(gè)byte的dataFormatIdentifier，這里面標(biāo)識(shí)了數(shù)據(jù)格式相關(guān)的信息，比如數(shù)據(jù)是否有壓縮，是否有加密，用的什么算法加密等，應(yīng)該由主機(jī)廠與供應(yīng)商約定好，用哪個(gè)bit來(lái)表示壓縮、加密等信息。

第三部分：1個(gè)字節(jié)的addressAndLengthFormatIdentifier，用于指示后面兩個(gè)部分所占用的字節(jié)，高4bit表示memorySize所占的字節(jié)長(zhǎng)度，低4bit表示memoryAddress

所占的字節(jié)長(zhǎng)度。在這個(gè)例子中我將這兩個(gè)值分別設(shè)置為n和m。

第四部分：m個(gè)字節(jié)的memoryAddress，由addressAndLengthFormatIdentifier中的低4bit指示。含義是要寫(xiě)入數(shù)據(jù)在ECU中的邏輯地址。

第五部分：n個(gè)字節(jié)的memorySize，由addressAndLengthFormatIdentifier中的高4bit指示。含義是要寫(xiě)入數(shù)據(jù)的字節(jié)數(shù)。

ECU收到請(qǐng)求之后，如果允許傳輸?shù)脑?huà)，會(huì)給出如下response

0x34服務(wù)的響應(yīng)格式

第一部分：1個(gè)byte的 Response SID

第二部分：1個(gè)byte的dataFormatIdentifier作為echo

第三部分：maxNumberOfBlockLength，長(zhǎng)度不定，表示可以通過(guò)0x36服務(wù)一次傳輸?shù)淖畲髷?shù)據(jù)量。

TransferData（0x36）：

如果34服務(wù)得到了正確響應(yīng)，tester就要啟動(dòng)數(shù)據(jù)傳輸過(guò)程了，使用的就是36服務(wù)。36服務(wù)的格式如下。

0x36服務(wù)的請(qǐng)求格式

第一部分：1個(gè)byte的 SID

第二部分：1個(gè)byte的blockSequenceCounter，標(biāo)識(shí)當(dāng)前傳輸?shù)氖堑趲讉€(gè)數(shù)據(jù)塊，或者簡(jiǎn)單地說(shuō)就是第幾次調(diào)用36服務(wù)。

第三部分：transferRequestParameterRecord，傳輸?shù)臄?shù)據(jù)。第次傳輸數(shù)據(jù)量的上限就是34服務(wù)響應(yīng)中的maxNumberOfBlockLength。

舉例：如果ECU告知tester,maxNumberOfBlockLength = 20，也就是說(shuō)tester每次通過(guò)36服務(wù)只能發(fā)送最多20個(gè)字節(jié)，其中還包括了SID和blockSequenceCounter，所以實(shí)際上每次可傳的數(shù)據(jù)信息只有18個(gè)字節(jié)。如果tester要傳的數(shù)據(jù)為50個(gè)字節(jié)，則需要傳輸三次，每次分別傳輸18，18，14個(gè)字節(jié)，即調(diào)用3次36服務(wù)。

36的響應(yīng)很簡(jiǎn)單，就是一個(gè)字節(jié)的Response SID再加一個(gè)字節(jié)的blockSequenceCounter作為echo。

RequestTransferExit（0x37）：

37服務(wù)用于退出上傳下載，如果之前的34和36服務(wù)都順利執(zhí)行完成，那么37服務(wù)就可以得到ECU的positive response。

格式很簡(jiǎn)單，請(qǐng)求就是37，正確響應(yīng)就是77，都是一個(gè)字節(jié)。

如果前面的36服務(wù)沒(méi)有執(zhí)行完成，以我前面舉的例子來(lái)說(shuō)，比如這個(gè)數(shù)據(jù)塊有50個(gè)字節(jié)，但是tester只發(fā)了兩次36服務(wù)傳了36個(gè)字節(jié)，那么這次傳輸對(duì)于ECU來(lái)說(shuō)是失敗的，所以ECU應(yīng)該給出NRC 0x7F 37 24，表示診斷序列執(zhí)行有錯(cuò)誤。

關(guān)于UDS所定義的診斷服務(wù)到這里就寫(xiě)完了。接下來(lái)我會(huì)寫(xiě)兩篇文章補(bǔ)充一下UDS系列，分別介紹一下DTC的8個(gè)狀態(tài)位的邏輯關(guān)系以及向ECU刷寫(xiě)數(shù)據(jù)或軟件的完整流程。在此之后我會(huì)寫(xiě)幾篇文章來(lái)講述UDS在CAN總線(xiàn)上的實(shí)現(xiàn)，即所謂的UDSonCAN，涉及到TP層的分包、流控制、錯(cuò)誤識(shí)別等內(nèi)容，還有基于CAN實(shí)現(xiàn)的UDS中涉及到的各種時(shí)間參數(shù)。感興趣的話(huà)可以繼續(xù)關(guān)注。

https://zhuanlan.zhihu.com/c_153808584

總結(jié)

以上是生活随笔為你收集整理的统一诊断服务 (Unified diagnostic services ， UDS)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。