1、前言2UDS 的7種服務及肯定響應和否定響應的形式3$10診斷會話5$3E待機握手6$27安全訪問7$22讀數據8$2E寫數據8$19 讀DTC8$14清除DTC10統一診斷服務 (Unified diagnostic services ， UDS) （一）10Diagnostic request的格式：10統一診斷服務 (Unified diagnostic services ， UDS) （二）12Diagnostic Session Control (0x10)12診斷response的格式：Diagnostic Session Control13ECU Reset 診斷request的

2、格式13Security Access (0x27)13統一診斷服務 (Unified diagnostic services ， UDS) （三）14Tester Present (0x3E)15Control DTC Setting (0x85)16Response On Event (0x86)16Link Control (0x87)16統一診斷服務 (Unified diagnostic services ， UDS) （四）16Read Data By Identifier (0x22)160x23服務的請求格式0x2317統一診斷服務 (Unified diagnostic se

3、rvices ， UDS) （五）170x14:Clear Diagnostic Information170x19:Read DTC Information18統一診斷服務 (Unified diagnostic services ， UDS) （六）19Input Output Control By Identifier (0x2F)19Routine Control (0x31)20統一診斷服務 (Unified diagnostic services ， UDS) （七）21Request Download （0x34）：21Transfer Data（0x36）：22Request

4、Transfer Exit（0x37）：22基于CAN總線實現的UDS診斷（DoCAN）23前言UDS協議即ISO14229,是Unified Diagnostic Services，統一診斷服務，是診斷服務的規范化標準，比如讀取故障碼應該向ECU發什么指令，讀數據流又是發什么指令。OBD是關注車輛售后實時排放的理念形成的行業規范，而UDS是診斷服務的統一化規范，只是應用層的規范。UDS(Unified diagnostic services)，與OBD最大的區別就在于“Unified”上，UDS是面向整車所有ECU(電控單元)的，而是面向排放系統ECU的。簡單說UDS而言，它只是一個應用層協

5、議(ISO 14229-1)，所以它既可以在CAN線上實現(見下圖.1)，甚至也能在Ethernet上實現(DOIP, Diagnostic over Internet protocol 見下圖.2)。并且，UDS提供的是一個診斷服務的基本框架，主機廠和零部件供應商可以根據實際情況選擇實現其中的一部分或是自定義出一些私有化的診斷服務來，所以基于UDS協議的診斷又常常被稱為Enhanced diagnostic(增強型診斷)，UDS不是法規要求的，沒有統一實現標準，其優勢在于方便生產線檢測設備的開發，同時更大的方便了售后維修保養和車聯網的功能實現。UDS（Unified Diagnostic S

6、ervices，統一的診斷服務）診斷協議是ISO 15765 和ISO 14229 定義的一種汽車通用診斷協議，位于OSI模型中的應用層，它可在不同的汽車總線（例如CAN, LIN, Flexray, Internet 和K-line）上實現。UDS協議的應用層定義是ISO 14229-1，目前大部分汽車廠商均采用UDS on CAN的診斷協議。如下圖所示，ISO 14229-1也就是UDS協議僅對應用層做出了定義，物理層有雙絞線和光纖供用戶選擇，數據鏈路層采用CAN總線的ISO 11898-1協議，針對Classical CAN僅有8個字節的數據場與應用層可處理多幀數據的矛盾，ISO 157

7、65-2對網絡層進行了定義。CAN的8字節數據場會騰出一幀來表示網絡層的信息。下圖右側是排放相關的協議，ISO 15031-5主要針對OBD協議，為法規強制要求車廠滿足的協議。學習時，我們應在了解CAN總線基本知識的前提下，著重學習ISO 15765-2和ISO 11898-1的協議內容，并通過BootLoader作為例子，對UDS有一個大致的了解。UDS 的7種服務及肯定響應和否定響應的形式UDS本質上是一系列的服務，共包含6大類26種。每種服務都有自己獨立的ID，即SID。SID： (Service ID （Identifier）以下簡稱SID)Service，診斷服務ID。UDS本質上是

8、一種定向的通信，是一種交互協議（Request/Response），即診斷方給ECU發送指定的請求數據（Request），這條數據中需要包含SID。如果是肯定的響應（Positive Response），回復SID+0x40，就是請求10，響應50；請求22，響應62，回復的是一組數據。如果是否定的響應（Negative Response），回復7F+SID+NRC，回復的是一個聲明。肯定響應和否定響應的形式一定要熟記。UDS的26種服務中，有7種很重要。它們分別是：$10Diagnostic Session Control（診斷會話），$14 Clear Diagnostic Informa

9、tion（清除診斷信息），$19Read DTC Information，$22Read Data By Identifier（通過ID讀數據），$27Security Access（安全訪問），$2E Write Data By Identifier（通過ID寫數據），$3ETester Present（待機握手）。下面對這7個服務進行解讀。$10診斷會話Diagnostic Session Control (0x10)Diagnostic Session Control診斷request的格式Diagnostic Session Control這個服務的SID是0x10，request固定

10、為2個byte，第一個byte是SID，第二個byte的低7bit是sub-function，用于指示ECU將進入的session。UDS定義的session包括：0x00 ISOSAE Reserved（保留）0x01 default Session0x02 Programming Session0x03 extended Diagnostic Session0x04 safety System Diagnostic Session0x05 0x3F ISOSAE Reserved（保留）0x40 0x5F vehicle Manufacturer Specific（由整車廠自定義使用）0x

11、60 0x7E system Supplier Specific（由ECU供應商自定義使用）0x7F ISOSAE Reserved（保留）Diagnostic Session Control用于控制ECU在不同的session之間進行轉換，session可以看作是ECU所處的一種軟件狀態，在不同的session中診斷服務執行的權限不同。 ECU上電之后，默認處在default Session中，在這個session中很多診斷服務不可以執行，很多診斷相關的數據不能讀取或寫入。一般的診斷儀啟動之后，會給ECU發送10 03，即讓ECU進入 extended Diagnostic Session中

12、，在這個session中可執行的診斷服務就很多了。而如果要讓ECU保持在non-default Session中，則需要診斷儀每隔固定的時間發送0x3E服務，ECU才會知道診斷儀有和自己通信的需求，從而保持在non-default Session中。另一個常用的session是Programming Session，在這個session中可以進行軟件刷寫的一系列診斷服務。0x40 0x5F 這個范圍中的session由整車廠自定義使用，比如，某些診斷服務或診斷數據的操作需要在生產線上執行，即所謂的End-Of-Line，整車廠可以從這個范圍中選擇一個值來表示EOL session；又或者在開發

13、階段需要某種“超級”session，則也可以從這里選一個值用來使ECU進入開發模式的session。Diagnostic Session Control這個服務非常簡單，但是它卻是ECU和診斷通信的第一條診斷命令。$10包含3個子功能，01 Default，02 Programming，03 Extended，ECU上電時，進入的是默認會話（Default）。如果您進入了一個非默認會話的狀態，一個定時器會運轉，如果一段時間內沒有請求，那么到時間后，診斷退回到默認會話01。當然，我們有一個$3E的服務，可以使診斷保持在非默認的狀態。UDS包含4種類型，即SID，SID+SF（Sub-functi

14、on），SID+DID（Data Identifier）（讀寫用），SID+SF+DID。NRC：Negative Response Code（否定響應碼）。如果ECU拒絕了一個請求，它會回應一個NRC。不同的NRC有不同的含義。14229-1協議第329頁單詞：Consult（查閱） Session（會話） DTC （diagnostic trouble code）故障碼Handling（處理） Conditions（條件） restricted（受限的） Concept（概念）SA（source address 源地址） TA（目標地址）例子：以CAN總線網絡舉例。八個幀數據字節，第一字節

15、被網絡層占用。請求（Request）:02 10 02 xx xx xx xx xx ; 02中的0代表網絡層單幀SF，2代表 數據域有2個字節；SF，數據域有2個字節，10是SID，02是子功能。肯定響應:02 50 02 xx xx xx xx xx；02同上，10+40表示對SID的肯定回復，02是子功能。否定響應:03 7F 10 22 xx xx xx xx；03同上，7F表示否定響應，10是SID，22是NRC。$3E待機握手Tester Present (0x3E)這個診斷服務的用處可以通過它的名字很明顯地得知，即告知ECU診斷儀還在連接著。在上一篇文章中我說到了關于sessio

16、n的部分，如果沒有診斷命令的發送和接收，ECU將從non-default session中回退到default session， 0x3E就是用于使ECU保持在當前session。這應該是UDS中最簡單的一個診斷服務了，它永遠只有兩個byte，格式如下：0x3E診斷服務的格式當sub-function是0x00時，ECU要給出response；當sub-function是0x80時，ECU不需要要給出response。一般來說主機廠會為這個服務定義兩個時間參數，一個參數用于規定自己的診斷儀發送0x3E服務的間隔，另一個參數用于定義ECU收不到0x3E服務的timeout時間。$3E服務用于向服

17、務器指示診斷儀仍然連接在網絡上，之前已經激活的診斷服務功能可以仍然保持激活狀態。0x3E就是用于使ECU保持在當前session。這應該是UDS中最簡單的一個診斷服務了，它永遠只有兩個byte，格式如下：例子：023E80 00 00 00 00 00，發送一個3E服務的報文，保持非默認會話狀態。80表示無需回復。$27安全訪問Security Access (0x27)廠家可能會為ECU定義某些安全級別稍微高一些的診斷服務，在執行此類服務之前，就需要執行Security Access 這個診斷命令，進行一個簡單的身份驗證。完成Security Access 有以下步驟：診斷儀向ECU請求“S

18、eed”（通常是一個與時間相關的偽隨機數）,ECU向診斷儀發送“Seed”診斷儀向ECU發送“Key” (根據請求得到的Seed和一個本地的密碼進行計算得來)ECU判斷診斷儀發來的“Key”是否有效根據UDS的定義，0x03, 0x05, 0x07 0x41 這個范圍留給用于request Seed的sub-function；0x04, 0x06, 0x08 0x42這個范圍留給用于send Key的sub-function。具體選擇哪對值，由整車廠自己定義。整車廠也可以選擇多對sub-function，用于不同等級的安全訪問。下面我舉一個完成Security Access的診斷命令的例子，假

19、設0x05用于request Seed，0x06用于send Key。診斷儀發送 27 05ECU響應 67 05 01 01 01（seed是 01 01 01）診斷儀發送 27 06 02 03 04（key值是02 03 04，seed是 01 01 01，假設本地密碼為01 02 03，而算法就是將密碼與seed相加）ECU驗證成功 67 06此時ECU就處于unlocked的狀態了，那些被保護起來的診斷服務和診斷數據可以被操作了。通常來說，如果ECU重啟，或者回到了default session，unlocked狀態就失效了，如果要執行相關診斷服務，則需要再次執行上面描述的過程。$2

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

21、）成功。$27安全訪問服務的否定響應服務ID也是7F。還記得剛才否定響應的格式嗎？7F+27+NRCRx： 0227 0500 00 00 00 00 安全訪問，05子功能Tx： 0767 0508 27 11 F0 77 肯定響應，回復了對應安全級別的種子Rx： 0627 06FF FF FF FF 00 發送密鑰，4個FF。注意06是與05成對使用的。Tx： 037F 27 7800 00 00 00 否定響應，7F+27+NRCTx： 0267 0600 00 00 00 00 肯定響應，通過安全校驗$22讀數據$22讀數據，Request（請求）：22+DID（Data Identif

22、ier，通常是兩個字節）Response（響應）：62+DID+DataDID有一部分已經被ISO 14229-1規定了。比如0xF186就是當前診斷會話數據標識符，0xF187就是車廠備件號數據標識符，0xF188就是車廠ECU軟件號碼數據ID，0xF189就是車廠ECU軟件版本號數據標識符。$2E寫數據$22寫數據，Request（請求）：2E+DID+DataResponse（響應）：6E+DID注意，比如0xF186這個DID不支持直接寫入數據，需要用$10來進行會話轉換。也就是說，對于寫數據的請求，一般來說需要在一個非默認會話，和解鎖的狀態下才能進行。$19 讀DTCDTC（diag

23、nostic 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的狀態。前兩個字節是我們熟知的類似P0047的故障碼。LowByte暫不清楚。$19擁有28個子服

24、務（Sub-Function）。常用的子服務有02（通過DTC狀態掩碼讀取DTC），04（讀取快照信息），06（讀取擴展信息），0A（讀ECU支持的所有DTC數據）。剛才提到，一個DTC除了它自己的3個字節，還有一個字節專門用于表達DTC的狀態。這個狀態字節每個位的含義可以查詢ISO 14229-1。注意，并不是所有的DTC狀態都是支持的。下圖是Request/Response。括號標識循環，可以讀出很多DTC。$14清除DTC清除（復位）DTC格式，它可以改變DTC的狀態。3個FF代表清除所有DTC。Request：14+FF+FF+FF；Response：54 。我們剛才學完了7種重要的服

25、務，SID。除此之外，在CAN總線中，Addressing information尋址信息通過CAN幀ID體現出來。通訊的模式分兩種，一種是物理尋址（點對點），根據物理地址的不同進行訪問，但只能訪問單個ECU節點，Test為SA源地址，ECUX作為TA目標地址；對應的，另一種是功能尋址（廣播），根據功能的不同進行訪問，它能訪問多個ECU節點。每一個ECU都有2個CAN幀ID，分別對應收和發的物理尋址。以上只是一些粗淺的理解。對26種服務更詳細的解讀請拉到屏幕下方參考張老師的8篇文章。張老師也開通了，可以了解一下。UDS應用的設備：在UDS 診斷產品中知名度最高，應用最廣泛的是德國Vector公

26、司的CAN case 配合其CANoe軟件，Vector 產品功能齊全，適合系統級汽車總線開發，被大部分汽車廠商采用。Vector 產品因不開放API，不能做二次開發且價格昂貴，不適用于硬件開發團隊和生產線的自動化測試。目前市面上有很多CAN 廠商（如Kvaser, ZLG 等）能提供低成本、體積小、驅動簡單、開放API 的設備，很適合進行二次開發。雜記變速器控制單元TCU和ABS是CAN車載網絡上的兩大電子控制單元， 這2個ECU要通過CAN網絡進行大量的信息交互。但是由于電磁干擾、串擾、靜電等外界干擾或電控單元本身控制策略引起的通信停止等原因， 2個控制單元之間可能會出現通信丟失的現象。控

27、制系統需要將故障信息（例如通信丟失故障信息） 診斷出來， 以處理通信被破壞時出現丟失幀的故障現象， 并記錄為DTC （diagnostic trouble code）。ECU的輸入信號主要有4種形式： 模擬信號（水溫、油壓、蓄電池電壓等）； 數字信號（各種開關信號等）； PWM信號（脈沖信號、頻率信號等）； 網絡信號（CAN、LIN上傳輸的信號）。微控制器可以通過監測這些信號來判別輸入電路的工作狀況。輸出的信號往往用作控制電磁閥、指示燈、步進電機等， 大多數為數字信號。統一診斷服務 (Unified diagnostic services ， UDS) （一）UDS由ISO-14229系列標準

28、定義，ISO 14229-1 定義了診斷服務，不涉及網絡及實現，只有應用層的內容。而ISO 14229-3則定義了UDS在CAN總線上的實現。診斷通信的過程從用戶角度來看非常容易理解，診斷儀發送診斷請求(request)，ECU給出診斷響應（response），而UDS就是為不同的診斷功能的request和response定義了統一的內容和格式。Diagnostic request的格式：Diagnostic request的格式可以分為兩類：一類是擁有sub-function的，一類是沒有sub-function的，如下面兩張圖所示。Service ID(以下簡稱SID)的長度固定為1個字節

29、，代表了這條診斷命令執行的什么功能。Sub-function的長度也是1個字節，它通常表示對這個診斷服務的具體操作，比如是啟動、停止還是查詢這個診斷服務。Parameter則根據各個診斷服務的不同具有不同的內容，長度和格式并沒有統一規格，它用于限定診斷服務執行的條件，比如某個診斷服務執行的時間等。parameter的一個重要應用是作為標識符，標識診斷請求要讀出的數據內容。有一點要補充的是，其實sub-function嚴格來說是7個bit，而不是1個byte，因為它的最高位bit被用于抑制正響應（suppress positive response, SPR），如果這個bit被置1，則ECU不會

30、給出正響應（positive response）； 如果這個bit被置0，則ECU會給出正響應。這樣做的目的是可以告訴ECU不要發不必要的response，從而節約通信資源。Diagnostic response的格式：Diagnostic response分為positive和negative兩類。positive response意味著診斷儀發過來的診斷請求被執行了negative response則意味著ECU因為某種原因無法執行診斷儀發過來的診斷請求，而無法執行的原因則存在于negative response的報文中。positive responsepositive response

31、的格式如上圖所示，也基本上是由三部分組成，其中的response SID這個字節作為診斷請求的echo，它等于SID + 0X40。后面的兩個部分則視具體的診斷服務而定。negative responsenegative response的格式固定為3個字節，第一個字節為0x7F，第二個字節是被拒絕掉的SID，第三個字節是這個診斷服務無法被執行的原因。下面這張圖列舉了部分原因代碼，比如，如果ECU給出7F 22 13這個negative response，則說明22這個服務因為診斷請求數據長度不對的原因無法執行。總結：診斷通信的過程就是診斷儀和ECU交換數據，前者發的是request，后者發的

32、是response，而UDS最重要的作用就是定義了這些request和response的格式和內容。統一診斷服務 (Unified diagnostic services ， UDS) （二）UDS定義的診斷服務從邏輯來說分為以下幾類：Diagnostic and Communication Management （診斷和通信管理）Data Transmission （數據傳輸）Stored Data Transmission （存儲數據傳輸，用于操作DTC）Input Output Control （IO控制）Routine Control （不知如何翻譯好，作用是調用ECU內部的預置函數）

33、Upload Download （上傳下載）UDS規定使用1個byte來表示診斷服務，即所謂的Service ID,簡稱SID。本文介紹一下Diagnostic and Communication Management 這一類診斷服務中的一部分。Diagnostic Session Control (0x10)Diagnostic Session Control診斷request的格式Diagnostic Session Control這個服務的SID是0x10，request固定為2個byte，第一個byte是SID，第二個byte的低7bit是sub-function，用于指示ECU將進入

34、的session。UDS定義的session包括：0x00 ISOSAE Reserved（保留）0x01 default Session0x02 Programming Session0x03 extended Diagnostic Session0x04 safety System Diagnostic Session0x05 0x3F ISOSAE Reserved（保留）0x40 0x5F vehicle Manufacturer Specific（由整車廠自定義使用）0x60 0x7E system Supplier Specific（由ECU供應商自定義使用）0x7F ISOSAE

35、 Reserved（保留）Diagnostic Session Control用于控制ECU在不同的session之間進行轉換，session可以看作是ECU所處的一種軟件狀態，在不同的session中診斷服務執行的權限不同。 ECU上電之后，默認處在default Session中，在這個session中很多診斷服務不可以執行，很多診斷相關的數據不能讀取或寫入。一般的診斷儀啟動之后，會給ECU發送10 03，即讓ECU進入 extended Diagnostic Session中，在這個session中可執行的診斷服務就很多了。而如果要讓ECU保持在non-default Session中，

36、則需要診斷儀每隔固定的時間發送0x3E服務，ECU才會知道診斷儀有和自己通信的需求，從而保持在non-default Session中。另一個常用的session是Programming Session，在這個session中可以進行軟件刷寫的一系列診斷服務。0x40 0x5F 這個范圍中的session由整車廠自定義使用，比如，某些診斷服務或診斷數據的操作需要在生產線上執行，即所謂的End-Of-Line，整車廠可以從這個范圍中選擇一個值來表示EOL session；又或者在開發階段需要某種“超級”session，則也可以從這里選一個值用來使ECU進入開發模式的session。Diagnos

37、tic Session Control這個服務非常簡單，但是它卻是ECU和診斷通信的第一條診斷命令。診斷response的格式：Diagnostic Session Control這個診斷服務的response分為三部分，第一部分是0x50，作為SID的echo；第二部分是進入的session，作為sub-function的echo；第三部分是4個字節，前兩個字節代表P2 Server_max，即ECU在應用層上對診斷命令的響應時間，后兩個字節代表P2*Server_max，即ECU在暫時無法處理當前診斷命令（具體表現為發送了NRC 0X78），在應用層上對診斷命令響應的最長時間。ECU Re

38、set 診斷request的格式ECU Reset (0x11) ECU Reset 這條指令的用途是通過診斷請求使ECU重啟。ECU Reset 這個服務的SID是0x11，request固定為2個byte，第一個byte是SID，第二個byte的低7bit是sub-function，用于指示ECU將模擬哪種方式進行重啟。常用的sub-function包括（只舉2個例子，UDS還定義了很多其他的值）0x01hard Reset 模擬KL30的重啟0x02key Off On Reset 模擬KL15的重啟當我們通過診斷命令改寫了ECU的某些數據，或者對ECU進行了某些設置，只有將ECU重啟才

39、能將這些配置生效，所以就有了這個診斷命令。在ECU Reset 執行之后，ECU會從Non-default session回退到default session中。Security Access (0x27)廠家可能會為ECU定義某些安全級別稍微高一些的診斷服務，在執行此類服務之前，就需要執行Security Access 這個診斷命令，進行一個簡單的身份驗證。完成Security Access 有以下步驟：診斷儀向ECU請求“Seed”（通常是一個與時間相關的偽隨機數）,ECU向診斷儀發送“Seed”診斷儀向ECU發送“Key” (根據請求得到的Seed和一個本地的密碼進行計算得來)ECU判斷

40、診斷儀發來的“Key”是否有效根據UDS的定義，0x03, 0x05, 0x07 0x41 這個范圍留給用于request Seed的sub-function；0x04, 0x06, 0x08 0x42這個范圍留給用于send Key的sub-function。具體選擇哪對值，由整車廠自己定義。整車廠也可以選擇多對sub-function，用于不同等級的安全訪問。下面我舉一個完成Security Access的診斷命令的例子，假設0x05用于request Seed，0x06用于send Key。診斷儀發送 27 05ECU響應 67 05 01 01 01（seed是 01 01 01）診斷

41、儀發送 27 06 02 03 04（key值是02 03 04，seed是 01 01 01，假設本地密碼為01 02 03，而算法就是將密碼與seed相加）ECU驗證成功 67 06此時ECU就處于unlocked的狀態了，那些被保護起來的診斷服務和診斷數據可以被操作了。通常來說，如果ECU重啟，或者回到了default session，unlocked狀態就失效了，如果要執行相關診斷服務，則需要再次執行上面描述的過程。統一診斷服務 (Unified diagnostic services ， UDS) （三）在上一篇文章中我寫了Diagnostic and Communication M

42、anagement （診斷和通信管理）這一類診斷服務中的0x10 , 0x11 , 0x27，在這篇文章中繼續這一大類診斷服務中的其他內容。Communication Control (0x28)該服務用于打開/關閉某些類別的報文的發送/接收。它通常在刷寫軟件或大量數據的時候使用，因為在刷軟件或參數的時候并不需要ECU進行與通信相關的功能，將通信關閉之后可以把所有通信資源都留給軟件或參數的下載，當下載過程完成之后再利用該服務將通信恢復即可。0x28服務的格式如下圖所示0x28服務的格式第一部分即SID，一個byte，值為0x28；第二部分是sub-function，表明要對ECU的通信進行哪種

43、控制，具體包括 ：0x00 enable Rx And Tx （激活接收和發送）0x01 enable Rx And Disable Tx（激活接收和關閉發送）0x02 disable Rx And Enable Tx（激活發送和關閉接收）0x03 disable Rx And Tx（關閉接收和發送）0x04 enable Rx And Disable Tx With Enhanced Address Information（激活接收和關閉發送，針對特定的地址）0x05 enable Rx And Tx With Enhanced Address Information（激活接收和發送，針對特

44、定的地址）0x06 - 0x7F都是保留或者留給廠商自定義的。第三部分 communication Type的定義表明這條診斷請求要對哪種報文進行控制，長度為1個byte，這個byte中最常用的就是低2 bit，0x1代表普通應用報文，0x2代表網絡管理報文，0x3代表普通應用報文和網絡管理報文。第四部分 是optional的，只有當sub-functional等于0x04或0x05時才需要使用。定義如下表所示：舉個完整的診斷服務例子：28 01 01 表示激活應用報文的接收并關閉應用報文的發送（網絡管理報文不受影響）。28 00 01 表示激活應用報文的接收和發送（網絡管理報文不受影響）。T

45、ester Present (0x3E)這個診斷服務的用處可以通過它的名字很明顯地得知，即告知ECU診斷儀還在連接著。在上一篇文章中我說到了關于session的部分，如果沒有診斷命令的發送和接收，ECU將從non-default session中回退到default session， 0x3E就是用于使ECU保持在當前session。這應該是UDS中最簡單的一個診斷服務了，它永遠只有兩個byte，格式如下：0x3E診斷服務的格式當sub-function是0x00時，ECU要給出response；當sub-function是0x80時，ECU不需要要給出response。一般來說主機廠會為這個

46、服務定義兩個時間參數，一個參數用于規定自己的診斷儀發送0x3E服務的間隔，另一個參數用于定義ECU收不到0x3E服務的timeout時間。Control DTC Setting (0x85)該服務用于控制ECU的DTC存儲，這個服務常常和前面提到的OX 28服務一起使用，比如，在開始寫參數之前，為了獲得更快的傳輸速度，我們用OX 28服務把所有ECU的通信關閉了，但此時因為收到不到相關的報文，ECU會沒有必要地存儲很多DTC，這時如果我們使用85服務把ECU存儲DTC的功能暫時性地禁止掉，則不會造成這種麻煩。0x85服務的格式第一部分即SID，一個byte，值為0x85；第二部分是sub-fu

47、nction，表明是打開還是關閉ECU的DTC存儲，具體包括 ：0x01 on0x02 off第三部分是optional的，由各家自己定義，比如，可以用FF FF FF 來表示這條診斷命令針對所有的DTC。Response On Event (0x86)我在以前的文章里說，診斷通信過程是問答式的，診斷儀發請求，ECU給響應。0x86服務算是一個例外，在ECU收到這條0x86服務之后，當DTC產生時，它會自動地上報DTC及相關環境數據，直到用另一條0x86服務來關閉ECU的這個行為。該功能主要用于ECU的前期開發階段，在售后和生產中是不會用到的，而且該服務的格式復雜（即可變的參數很多），執行它還

48、分為好幾個步驟，我就不詳細寫了。Link Control (0x87)這個服務用于轉化ECU數據鏈路層和物理層的狀態，比如，在高速CAN上的ECU正常通信速率是500 kbit/s，但它同時也支持1M bit/s的波特率，如果需要刷寫大量數據，便可以利用這條診斷服務讓ECU以1M bit/s的波特率進行通信。這個診斷服務的執行分為兩個步驟：（1）驗證ECU是否支持要調整到的目標波特率（2）讓ECU的數據鏈路層和物理層轉到目標波特率的通信狀態。只有當第一個步驟驗證通過了，第二個步驟才可以成功執行。統一診斷服務 (Unified diagnostic services ， UDS) （四）這篇文章

49、介紹一下UDS的第二類診斷服務，即Data Transmission （數據傳輸）。這類診斷服務包括以下SID：Read Data By Identifier (0x22)Read Memory By Address (0x23)Read Scaling Data By Identifier (0x24)Read Data By Periodic Identifier (0x2A)Dynamically Define Data Identifier (0x2C)Write Data By Identifier (0x2E)Write Memory By Address (0x3D)通常，0x2

50、2和0x2E成對使用，0x23和0x3D成對使用，這幾個服務用于診斷數據的基本讀寫操作。0x24，0x2A，0x2C是一些特殊操作。0x22和0x2E這兩個服務是對以標識符(identifier)標記的數據的操作，前者是讀，后者是寫。UDS規定，診斷數據使用兩個byte的標識符來標記，比如，0xF187用來標記ECU的零件號，0xF19E用于標記該ECU所使用的診斷文件的名字，UDS還規定了廠家可以自定義的標識符范圍。這兩個服務的用法很簡單，下面我以讀取ECU的零件號為例說明：22 F1 87 （讀取零件號）62 F1 87 XX YY ZZ KK MM NN（給出零件號）具體每次可以使用22

51、服務讀取幾個ID，每個ID的讀寫權限（比如在哪些session中可以讀寫，是否需要安全訪問操作等），由廠家自定義。假設零件號這個ID是可以寫入的話，則寫零件號的診斷命令是：2E F1 87 XX YY ZZ KK MM NN（寫入零件號）6E F1 87（給出positive response）0x23服務的請求格式0x230x23和0x3D這兩個服務是對以地址信息（memory Address ）標記的數據的操作，前者是讀，后者是寫。這個命令的格式稍微復雜一點。以0x23為例，它的診斷請求格式是：第一部分固定為1個byte, 0x23；第二部分是格式信息，長度為1個byte，高4 bits用

52、于指示memory Size的長度（字節數），低4 bits用于指示memory Address的長度（字節數）。比如，如果這個值為0x46（十進制為70），則后面的memory Address（第三部分）為4個byte， memory Size（第四部分）為6個byte，。第三部分是memory Address信息，它的長度由第二部分的Address And Length Format Identifier指示。第四部分是memory Size信息，它的長度由第二部分的Address And Length Format Identifier指示。如果這條命令的格式是 23 22 xx yy

53、aa bb，則它的含義就是，讀取xx yy地址的長度為aa bb的數據。了解了0x23的用法，0x3D的用法就很好理解了，它標識memory Address和memory Size的方法與0x23相同，只是在診斷命令最后再加上一段需要寫入的數據。0x24，0x2A，0x2C這幾個特殊操作，使用場景不多，我組織組織語言，在下篇文章里簡要介紹一下。統一診斷服務 (Unified diagnostic services ， UDS) （五）這篇文章介紹Stored Data Transmission （存儲數據傳輸，用于操作DTC）這一類診斷服務，涉及到兩條診斷命令，分別是：0x14: Clear

54、Diagnostic Information0x19: Read DTC Information這兩條服務用于操作存儲在ECU中的DTC，使用頻率很高，而且它們比較好地體現了“診斷”兩個字的含義。0x14:Clear Diagnostic Information這條診斷命令的格式比較簡單，用法也很好理解，即刪除存儲在ECU中的DTC。0x14診斷命令請求的格式第一個字節就是SID了，后邊的三個字節用于標識將要被刪除的DTC種類，UDS規定用FF FF FF表示所有種類的DTC，由廠家自定義代表Powertrain、Chassis、Body、Network Communication等種類DTC

55、的值。比如，14 FF FF FF這條指令表示的就是刪除掉ECU中的所有DTC。ECU只需要返回一個0x54表示成功執行即可。0x19:Read DTC Information這條指令用于讀取存儲在ECU中的DTC，它的格式如下0x19診斷命令請求的格式0x14診斷命令請求的格式0x19服務的sub-function代表了各式各樣讀取DTC的方法，UDS給19服務的sub-function從0x00到0x19進行了明確定義，我只使用過其中4種，下面對我用過的這些進行介紹，如果大家對其他的感興趣，可以查閱ISO 14229的定義。sub-function = 0x01 （report Numbe

56、r Of DTC By Status Mask）sub-function = 0x01用于讀取符合特定條件的DTC數量，此時parameter為1個byte的Mask，用于與DTC的Status進行“與”運算，而ECU返回的則是與運算之后結果不為0的DTC的數量。DTC的Status用一個byte表示，其中的8個bit分別代表DTC的不同狀態，比如，bit 0 表示這個DTC是active的還是passive的，bit 4表示這個DTC是否已經被confirm了，如果DTC的狀態是confirm，則說明該DTC已經被ECU存儲下來了。比如：19 01 08這個命令的用途，就是讀取所有狀態為co

57、nfirm的DTC的數量。sub-function = 0x02 （report DTC By Status Mask）sub-function = 0x02用于讀取符合特定條件的DTC列表，此時parameter仍然為1個byte的Mask，用于與DTC的Status進行“與”運算，而ECU返回的則是與運算之后結果不為0的DTC列表。比如19 02 01這個命令的用途，就是讀取所有狀態為active的DTC的數量。此時ECU返回的格式應該是59 02 01 XX XX XX 01 YY YY YY 09.。返回的DTC列表中的每個條目為4個字節，前三個字節用于標識DTC，比如 XX XX XX，最后一個字節用于標識DTC狀態，比如01，表示DTC是active的，09表示DTC是active且confirm的。sub-function = 0x06 （report DTC Ext Data Record By DTC Number）sub-function =