UDS診斷入門

兼聽則明，謹言慎行。崇尚科學，實事求是。

275 人贊同了該文章

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

零、UDS診斷命令備忘錄

一、簡介

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）的解讀zhuanlan.zhihu.com

排放相關的診斷內容，即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

摘自恆潤科技公開資料

二、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

本文重點介紹以下幾個服務：$10 Diagnostic Session Control（診斷會話），$14 Clear Diagnostic Information（清除診斷信息），$19 Read DTC Information，$22 Read Data By Identifier（通過ID讀數據），$27 Security Access（安全訪問），$2E Write Data By Identifier（通過ID寫數據），$3E Tester 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的中文版本鏈接。

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服務用於向服務器指示診斷儀仍然連接在網絡上，之前已經激活的診斷服務功能可以仍然保持激活狀態。

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

$27安全訪問

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

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

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

例子：

Tester： 02 27 05 00 00 00 00 00 安全訪問，05子功能

ECU： 06 67 05 08 27 11 F0 00 肯定響應，回覆了對應安全級別的種子

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

ECU： 03 7F 27 78 00 00 00 00 若爲否定響應，7F+27+NRC

ECU： 02 67 06 00 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

寫入一個17字節的VIN碼，模擬的不好，第四條應該在第二條的位置上方

上面這個例子的發送接收順序是有問題的，是會產生誤解的，我有時間更換一下。

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

10 14根據ISO15765-2代表這是一組多幀中的首幀（屬於傳輸層的信息），一會要發0x14=20個字節的有效數據。之後是2E+F190（代表這是VIN碼）+VIN碼的前3個字節。意思是作爲外部工具，想寫入一個VIN碼數據。這件事情正常是發生在車輛下線時。
30 00 14是TP層（傳輸層）的信息，表示這是一個流控幀，ECU發出的，表示可以一直連續發，但連續幀最短的間隔時間要求是20ms。
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狀態掩碼

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，其中第二字節是高位。第四字節是子功能，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

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

文不對題的例子

變速器控制單元TCU和防抱死系統ABS是CAN車載網絡上的兩大電子控制單元，這2個ECU要通過CAN網絡進行大量的信息交互。但是由於電磁干擾、串擾、靜電等外界干擾或電控單元本身控制策略引起的通信停止等原因， 2個控制單元之間可能會出現通信丟失的現象。控制系統需要將故障信息（例如通信丟失故障信息）診斷出來，以處理通信被破壞時出現丟失幀的故障現象，並記錄爲DTC （diagnostic trouble code）。當然，這些DTC也可以用於售後的維修保養。

ECU的輸入信號主要有4種形式： ①模擬信號（水溫、油壓、蓄電池電壓等）； ②數字信號（各種開關信號等）； ③PWM信號（脈衝信號、頻率信號等）； ④網絡信號（CAN、LIN上傳輸的信號）。ECU可以通過監測這些信號來判別輸入電路的工作狀況。輸出的信號往往用作控制電磁閥、指示燈、步進電機等，大多數爲數字信號。

大家可以加入公衆號：汽車ECU網絡診斷技術，瞭解更多ECU診斷知識。

大家可以加入公衆號：汽車ECU開發，瞭解更多汽車電子知識。

大家可以加入公衆號：汽車電子expert成長之路，學習汽車電子知識（NXP爲主）。

如果您對我的文章感興趣歡迎點贊或留言，大家有什麼關於車輛診斷/CAN總線的問題都可以留言給我，閒下來的時候我會針對熱點問題寫新的文章。謝謝大家！

學習資料:

2.統一診斷服務 (Unified diagnostic services ， UDS) （二）

3.統一診斷服務 (Unified diagnostic services ， UDS) （三）

4.統一診斷服務 (Unified diagnostic services ， UDS) （四）

5.統一診斷服務 (Unified diagnostic services ， UDS) （五）

6.統一診斷服務 (Unified diagnostic services ， UDS) （六）

7.統一診斷服務 (Unified diagnostic services ， UDS) （七）

8.基於CAN總線實現的UDS診斷（DoCAN）