UDS 定義的診斷服務從邏輯來說分為以下幾類：

1. Diagnostic and Communication Management （診斷和通信管理）

2. Data Transmission （數(shù)據(jù)傳輸）

3. Stored Data Transmission （存儲數(shù)據(jù)傳輸，用于操作 DTC）

4. InputOutput Control （IO 控制）

5. Routine Control （不知如何翻譯好，作用是調(diào)用 ECU 內(nèi)部的預置函數(shù)）

6. Upload Download （上傳下載）

UDS 規(guī)定使用 1 個 byte 來表示診斷服務，即所謂的 Service ID,簡稱 SID。本文介紹一下

Diagnostic and Communication Management 這一類診斷服務中的一部分。

DiagnosticSessionControl (0x10)

DiagnosticSessionControl 這個服務的 SID 是 0x10，request 固定為 2 個 byte，第一個

byte 是 SID，第二個 byte 的低 7bit 是 sub-function，用于指示 ECU 將進入的 session。

UDS 定義的 session 包括：

0x00 ISOSAEReserved（保留）

0x01 defaultSession

0x02 ProgrammingSession

0x03 extendedDiagnosticSession

0x04 safetySystemDiagnosticSession

0x05 – 0x3F ISOSAEReserved（保留）

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

0x60 – 0x7E systemSupplierSpecific（由 ECU 供應商自定義使用）

0x7F ISOSAEReserved（保留）

DiagnosticSessionControl 用于控制 ECU 在不同的 session 之間進行轉換，session 可以

看作是 ECU 所處的一種軟件狀態(tài)，在不同的 session 中診斷服務執(zhí)行的權限不同。 ECU

上電之后，默認處在 defaultSession 中，在這個 session 中很多診斷服務不可以執(zhí)行，很

多診斷相關的數(shù)據(jù)不能讀取或?qū)懭?。一般的診斷儀啟動之后，會給 ECU 發(fā)送 10 03，即

讓 ECU 進入 extendedDiagnosticSession 中，在這個 session 中可執(zhí)行的診斷服務就很

多了。而如果要讓 ECU 保持在 non-defaultSession 中，則需要診斷儀每隔固定的時間發(fā)

送 0x3E 服務，ECU 才會知道診斷儀有和自己通信的需求，從而保持在 non-

defaultSession 中。另一個常用的 session 是 ProgrammingSession，在這個 session 中

可以進行軟件刷寫的一系列診斷服務。0x40 – 0x5F 這個范圍中的 session 由整車廠自定

義使用，比如，某些診斷服務或診斷數(shù)據(jù)的操作需要在生產(chǎn)線上執(zhí)行，即所謂的 End-Of-

Line，整車廠可以從這個范圍中選擇一個值來表示 EOL session；又或者在開發(fā)階段需要

某種“超級”session，則也可以從這里選一個值用來使 ECU 進入開發(fā)模式的 session。

DiagnosticSessionControl 這個服務非常簡單，但是它卻是 ECU 和診斷通信的第一條診斷

命令。

這個診斷服務的 response 分為三部分，第一部分是 0x50，作為 SID 的 echo；第二部分

是進入的 session，作為 sub-function 的 echo；第三部分是 4 個字節(jié)，前兩個字節(jié)代表

P2Server_max，即 ECU 在應用層上對診斷命令的響應時間，后兩個字節(jié)代表

P2*Server_max

，即 ECU 在暫時無法處理當前診斷命令（具體表現(xiàn)為發(fā)送了 NRC 0X78），在應用層上

對診斷命令響應的最長時間。

ECUReset (0x11)

ECUReset 這條指令的用途是通過診斷請求使 ECU 重啟。

ECUReset 這個服務的 SID 是 0x11，request 固定為 2 個 byte，第一個 byte 是 SID，第

二個 byte 的低 7bit 是 sub-function，用于指示 ECU 將模擬哪種方式進行重啟。

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

0x01 hardReset 模擬 KL30 的重啟

0x02 keyOffOnReset 模擬 KL15 的重啟

當我們通過診斷命令改寫了 ECU 的某些數(shù)據(jù)，或者對 ECU 進行了某些設置，只有將

ECU 重啟才能將這些配置生效，所以就有了這個診斷命令。在 ECUReset 執(zhí)行之后，

ECU 會從 Non-defaultsession 回退到 defaultsession 中。

SecurityAccess (0x27)

廠家可能會為 ECU 定義某些安全級別稍微高一些的診斷服務，在執(zhí)行此類服務之前，就

需要執(zhí)行 SecurityAccess 這個診斷命令，進行一個簡單的身份驗證。

完成 SecurityAccess 有以下步驟：

1. 診斷儀向 ECU 請求“Seed”（通常是一個與時間相關的偽隨機數(shù)）,

2. ECU 向診斷儀發(fā)送“Seed”,

3. 診斷儀向 ECU 發(fā)送“Key” (根據(jù)請求得到的 Seed 和一個本地的密碼進行計算得來)

4. ECU 判斷診斷儀發(fā)來的“Key”是否有效

根據(jù) UDS 的定義，0x03, 0x05, 0x07 – 0x41 這個范圍留給用于 requestSeed 的 sub-

function；0x04, 0x06, 0x08 – 0x42 這個范圍留給用于 sendKey 的 sub-function。具體選

擇哪對值，由整車廠自己定義。整車廠也可以選擇多對 sub-function，用于不同等級的安

全訪問。

下面我舉一個完成 SecurityAccess 的診斷命令的例子，假設 0x05 用于 requestSeed，

0x06 用于 sendKey。

診斷儀發(fā)送 27 05

ECU 響應 67 05 01 01 01（seed 是 01 01 01）

診斷儀發(fā)送 27 06 02 03 04（key 值是 02 03 04，seed 是 01 01 01，假設本地密碼為 01

02 03，而算法就是將密碼與 seed 相加）

ECU 驗證成功 67 06

此時 ECU 就處于 unlocked 的狀態(tài)了，那些被保護起來的診斷服務和診斷數(shù)據(jù)可以被操作

了。通常來說，如果 ECU 重啟，或者回到了 default session，unlocked 狀態(tài)就失效了，

如果要執(zhí)行相關診斷服務，則需要再次執(zhí)行上面描述的過程。

時間有限，這篇文章里就介紹這三個診斷服務，即 0x10, 0x11, 0x27，后續(xù)有時間我再補

充其他的服務。