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

零、UDS診斷命令備忘錄

常見的UDS報文

常見的20個NRC

一、簡介

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

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

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

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

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

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

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

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

如果希望深入學習下UDS網絡層的知識，請移步：

UDS網絡層/TP層（ISO 15765-2）的解讀

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

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

摘自ISO 14229-1-2013

摘自ISO 14229-1-2013

摘自恒潤科技公開資料

摘自恒潤科技公開資料

二、UDS的服務

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

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

肯定響應和否定響應的形式一定要熟悉。

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

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

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

UDS的26種服務

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

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

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

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

26種服務，其中15種較為常用

少了0x38

$10診斷會話 Diagnostic Session Control

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

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

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

這里來一張權限表格。帶顏色的區域代表需要解鎖操作。

15個服務在不同會話中的權限情況（本表僅作參考）

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

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

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

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

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

NRC 0x78壞了規矩的例子

14229-1協議第329頁

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

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

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

摘自ISO 14229-1:2013 p39

我們看下上面的圖表，這個是ISO 14229定義的0x10服務應具有的請求報文格式，M意為Mandatory 強制。可以看到0x10服務僅有兩個字節，整條報文是“服務ID+子功能”，比較簡單。

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

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

$3E待機握手

$3E服務用于向服務器指示診斷儀仍然連接在網絡上，之前已經激活的診斷服務功能可以仍然保持激活狀態。

例子：023E80 00 00 00 00 00，發送一個3E服務的報文，保持非默認會話狀態。80表示無需回復。

$27安全訪問

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

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

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

例子：

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

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

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

ECU：03 7F 27 7800 00 00 00 若為否定響應，7F+27+NRC

ECU：0267 0600 00 00 00 00 若為肯定響應，通過安全校驗

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

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

第二個主體seed，通常與ECU的運行時間有關系，是主料，在27服務發送奇數子功能時回復。seed通常一直在發生變化，無法發現其規律。

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

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

$22讀數據

$22讀數據，Request（請求）：22+DID（Data Identifier，通常是兩個字節）

Response（響應）：62+DID+Data

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

14229-1協議第339頁

$2E寫數據

$2E寫數據，Request（請求）：2E+DID+Data

Response（響應）：6E+DID

寫入一個VIN碼

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

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

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

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

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

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

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

$19 讀DTC

19服務是一套診斷服務中的重中之重。協議中篇幅長達63頁，通信舉例達到了18個。可以說沒有19服務，就沒有完整的UDS。

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

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

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

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

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

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

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

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

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

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

06（讀取擴展信息）。

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

黃色框是DTC，緊跟著的是DTC狀態

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

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

關于DTC狀態掩碼更詳細的解釋參見文末的學習資料22，張老師有詳細的解答。

DTC狀態掩碼，默認值0x50

Request/Response。括號標識循環，可以讀出很多DTC

$14清除DTC

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

3個FF代表清除所有DTC。

Request：14+FF+FF+FF；

Response：54 。

14服務

$2F IO控制

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

IO控制類型分為4類，

00是控制權還給ECU，Return Control To ECU。

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

02是凍結當前的狀態，Freeze Current State。

03是短暫接管控制權，Short Term Adjustment。

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

若控制類型是03，請求報文的第五字節是控制代碼，可以是數字量，比如01是開，00是關；也可以是模擬量，比如空調風門的開度。

2F服務，黃色區域為2個字節的DID

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

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

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

6種模式的配置

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

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

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

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

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

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

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

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

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

抑制肯定響應指示位的配置

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

比如SID是0x10，子服務是0x01，如果是抑制肯定響應的話，子服務這個字節要改成0x81。這樣發下去ECU就不會回復肯定響應了。

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

以上只是一些粗淺的理解。對26種服務更詳細的解讀請拉到屏幕下方參考張老師的8篇文章。張老師也開通了微信公眾號，"汽車ECU網絡診斷技術"。可以去關注一下。

UDS應用的設備

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

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

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

討論

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

觀點：此時應繼續執行完2E的寫入服務，11服務的請求將會被丟棄，不會有任何回復。

四、AUTOSAR中的UDS

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

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

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

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

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

DSD，全稱Diagnostic Service Dispatcher，用于處理診斷數據流。它位于DCM的中環，夾在DSL和DSP的中間。

DSP，全稱Diagnostic Service Processing，實現每個具體的診斷服務，位于DCM的內環，這一層事無巨細。比如22服務、27服務的callback正是源于這一層。

審核編輯：郭婷