【圖解UDS】UDS汽車診斷標準協議（ISO 14229）帶你入門到精通
目錄
爲了便於學習ISO 14229 UDS診斷協議，提供三個資源鏈接：
爲了便於學習ISO 14229 UDS診斷協議，提供三個資源鏈接：
a)【圖解UDS】UDS汽車診斷開發流程及Vector解決方案工具鏈介紹
b)ISO 14229 -Part1，2，3，4，5，6，7 UDS最新標準文件獲取路徑
c)ISO 14229 Road vehicles — Unified diagnostic services (UDS)標準各Part部分修訂和發佈狀態彙總
0 前言
診斷的概念來源於醫學，醫生通過詢問、觀察病人，或者通過儀器檢測，利用數據對病症做出判斷。
而車輛診斷的目的也有類似的地方，爲了能夠快速準確的判斷車輛或者某個控制器的故障以及故障原因，從而爲維修提供可靠的依據。
內容大致分爲三個部分，首先介紹診斷的基本概念，再爲大家講解UDS診斷協議，以及協議中常用到的診斷服務，最後對今天的內容做一個小結。
1 診斷的基本概念
車輛的診斷需要有Tester端和ECU端，Tester端和ECU端通過一問一答的形式進行通信，因而Tester端和ECU端都需要遵循同樣的診斷通信協議，常用的診斷協議有ISO 14230，ISO 15031，ISO 15765，還有我們熟悉的ISO 14229就是UDS協議，在協議裏面定義了診斷的請求，診斷響應的報文格式，以及ECU怎樣處理診斷請求報文，以及診斷服務的應用。
UDS是Unified Diagnostic Services的縮寫，在國際標準ISO 14229-1中定義，UDS標準中除了定義服務的用法，以及服務的格式以外，還定義了一些標準化的數據，而到OEM要使用UDS協議時，除了要使用標準定義的服務以及標準數據以外，還要依據自身的情況，定義屬於OEM的特定數據，比如說，定義所要遵循的服務，需要支持的DID，需要支持的DTC等這些內容，這樣形成的符合某OEM的診斷規範才能用於ECU診斷功能的開發以及驗證。
隨着車輛ECU的增多，車輛網絡拓撲結構也越來越負責，比如說一輛車需要有多種總線（CAN總線，LIN，以太網，FlexRay），
所以在2013年釋放的UDS協議中，除了對通用診斷服務的定義以外，還增加了關於UDS在各個總線中應用的定義
這張圖就描述了UDS在OSI七層模型中的應用，OSI七層模型，第一層第二層分別定義了物理層和數據鏈路層，第三層第四層定義了網絡層和傳輸層，第七層是應用層。
比如說我們熟悉CAN總線，物理層和數據鏈路層遵循的是ISO 11898，而它的傳輸層遵循的是ISO 15765-2，在ISO 14229-3中定義了UDS基於CAN總線的應用，而現在比較火的以太網，它的物理層和數據鏈路層遵循的是ISO 13400-3，它的傳輸層也就是DoIP遵循的是ISO 13400-2, 它的UDS基於以太網的應用是ISO 14229-5
下面我們來看下，關於診斷服務的一些知識，
2 UDS診斷診斷協議
2.1 診斷服務的概念
首先來看服務請求和響應格式，“請求”由Tester端發送給ECU，請求報文裏帶有SID，根據具體的服務內容後面加具體的數據。肯定響應格式由“SID+40+具體的數據”。否定響應格式是一個固定的格式“7F+請求報文裏的SID+一個字節的NRC”
看兩個名詞，一個叫做Subfunction，一個叫做ID，UDS服務支持Subfunction的請求和響應格式，“請求”爲“SID+一個字節Subfunction+具體的數據”，肯定響應爲“SID+40+Subfunction+具體的數據”，而有的UDS服務裏面是不支持Subfunction，是支持DID的，DID是“數據ID”的意思，那麼它的請求格式爲“SID+具體的DID+數據內容”，肯定響應“SID+40+DID+具體的數據”，這裏舉出兩個例子，一個是 “31例程控制服務”，還有一個是“2F IO控制服務”，31就是它的請求報文裏面，帶一個字節的Subfunction和兩個字節的Routine ID，後面的這個數據是跟具體的數據內容，也可以沒有具體的數據。2F是它的SID+兩個字節的DID+一個字節的輸入輸出控制參數（這裏注意這一個字節的數據類似於Subfunction，但是他不是Subfunction）+後面加具體的數據內容。
下面爲大家介紹一個概念，爲肯定響應抑制位。肯定響應抑制位是在Subfunction裏的這個字節的最高位，我們把它叫做肯定響應抑制位。只有這個服務支持Subfunction的時候，纔有可能支持肯定響應抑制位，當肯定響應抑制位置1的時候，要求所有的肯定響應的抑制將不再發送。當肯定響應抑制位爲0的時候，肯定響應是不被抑制的。這裏要注意的是它只是抑制肯定響應，而否定響應是不被抑制的。
Tester發送的請求報文格式錯誤，或者請求發送的條件處於錯誤，ECU將發送否定響應，否定響應的格式是“7F+SID+NRC”，常用到的NRC在這裏羅列了。
11表示服務不支持；
12 subfunction不支持；
13 請求的長度不正確，或者格式不正確
31 是請求超出範圍；
7E 是在當前會話下subfunction不支持
7F 是在當前會話下服務不支持
來看兩個時間參數，一個是叫做P2Sever，一個是叫做P2Sever*。當Tester給ECU發送請求過後，ECU需要在P2Sever時間內給出相應的響應，如果ECU當前正在處理別的任務，處理別的事情，而不能在P2Sever的時間內給出相應的響應，那麼它先在P2Sever時間內給出一個NRC爲78的Pending報文，告訴Tester“ECU正在忙”，之後會在P2Sever*的時間內給出其它的響應報文，如果P2Sever*的時間內還是不能給出相應的肯定響應和否定響應，將繼續給出Pending報文，直到能夠正確處理請求報文之後，會給出正確的響應報文。
今天會着重介紹26個UDS服務裏的6個，分別是10診斷會話控制，14清除診斷信息，19讀取診斷信息，22由DID讀取數據，27安全解鎖服務，2E由DID寫入數據。
下面我們來看診斷會話控制就是10服務
2.2 診斷會話控制0x10服務
ECU會有不同的會話控制，所以ECU在不同的階段，比如說開發，生產，售後階段也會用到不同的會話模式，因爲每個服務功能的不同，也會在診斷規範裏定義這些服務所支持的診斷會話模式
這張表是14229裏面，對各個診斷服務，對會話控制的支持情況，比如說通信控制28服務，要求在默認會話下不支持；27安全解鎖服務，在默認會話模式下不支持；和刷寫相關的34,36,37服務，在默認會話下也是不支持的。
我們來看更會話控制有關的3個NRC，首先來看NRC 7F:NRC 7F是指在當前會話下服務不支持。28通信控制服務，要求在默認會話下是不支持的，在擴展會話下能支持。而當ECU處於默認會話的時候，我們上位機發送了28這個服務，ECU收到之後，會回覆7F NRC的否定響應。
NRC 7E和NRC 7F 不同的是：NRC 7E是在當前會話下Subfunction不支持。一個用的比較多的用法是，編程會話是不能夠由默認會話跳轉到編程會話的，只能由擴展會話跳轉到編程會話。但ECU處於默認會話的時候，執行了10 02 編程會話的請求，ECU會回覆7E NRC的否定響應。
再來看NRC 31，NRC 31常用的用法是請求超出範圍，比如說22服務，發送的DID，是ECU不支持的，比如說發送的請求22 01 01 ，因爲ECU不支持01 01這個DID，會發送NRC 31的否定響應，還有一個用法是：22在3個會話（默認，編程，擴展下都是支持的），22後面所跟的DID來讀取數據的DID對各個會話等級是有要求的，比如說讀取硬件版本號在編程會話模式下是支持的，讀取車速在編程會話下是不支持的，當ECU處於編程會話的時候，來通過 C0 01來讀取車速，那麼ECU會回覆NRC 31的否定響應。
這個是會話狀態的一個狀態機，狀態機之間可以互相跳轉，狀態機自身也能跳轉，我們把除了默認會話之外的會話狀態，都叫做非默認會話狀態。當ECU一上電的時候是處於默認會話的，我們通過10，比如說10 03,10 02來將會話狀態由默認會話跳轉到非默認會話。由非默認會話執行10 01跳轉至默認會話。當ECU處於非默認會話的時候，S3 time這個時間超時，ECU也會從非默認會話跳轉到默認會話。爲了防止ECU從非默認會話跳轉至默認會話，我們要求Tester端週期發送3E服務Tester present，讓ECU一直維持在非默認會話。那麼S3 time這個時間怎麼用呢？我們來看下面這張圖
Tester端會利用S3Client週期發送Tester present給ECU，ECU收到Tester present比如說3E 00，3E 80的服務請求，會讓ECU維持在非默認會話，如果Tester端S3server這個時間內，比如說5000毫秒時間內，都沒有給ECU發送任何診斷請求報文，那麼ECU就會從非默認會話跳轉到默認會話；如果ECU處於解鎖狀態，也會從解鎖狀態跳轉到鎖定狀態。通常S3cleint時間小於S3server的時間，比如說網關延時的一些情況。
這個是10服務的請求和響應格式。SID+一個字節的Subfunction（常用的有01默認會話，02編程會話，03擴展會話），它的肯定響應格式是50（就是10+40）+一個字節的Subfunction（就是診斷會話類型）+4個字節的會話參數。
支持的NRC有3個，12 subfunction不支持；13請求格式或者長度錯誤；22條件不支持。
下面我們來看下，安全解鎖27服務。
2.3 會話訪問0x27服務
常用到的服務：2E服務通過DID來寫入數據；2F通過DID來控制輸入輸出端口的數值；還有ECU刷寫有關的編程服務。這些服務都會改變和影響一些內存裏的數據，或者輸入輸出端口的一些值，所以這些服務是一個被保護的服務。這些服務只有ECU處於解鎖狀態下才能夠執行，而ECU一上電處於鎖定狀態，那麼ECU如何從鎖定狀態跳轉到解鎖狀態呢？
是要求Tester端和ECU端進行27解鎖服務之後，ECU才能夠處於解鎖狀態，那麼這個解鎖的過程是一個固定的：首先由Tester端給ECU發送請求報文來請求種子，ECU收到這個報文後，回覆肯定響應，肯定響應裏帶有種子數；Tester端收到這個種子數，根據自己安全算法算出來一個K1發送給ECU，ECU也有自己對應的安全算法，他由這個Seed算出來一個密鑰K2，當ECU收到這個K1後和自身計算的K2進行比較，如果兩者是一致的，那麼ECU發送肯定響應給Tester端，告訴Tester端ECU已經解鎖。
我們剛纔也提到了ECU一上電處於鎖定狀態，只有執行了安全解鎖的流程後才能跳轉到解鎖狀態，一個ECU可以同時擁有多個安全等級，多個安全等級之間可以是相互獨立的，也可以是有依賴關係的，比如說要求先解鎖安全等級1才能解鎖安全等級2，那麼當ECU處於解鎖狀態的時候，會有幾種情況會使ECU由解鎖狀態跳轉至鎖定狀態，比如說執行了11復位服務，比如說有了重新上下電，還比如說有了執行10會話切換，也會讓ECU由解鎖狀態跳轉到鎖定狀態。
當ECU處於解鎖狀態的時候Tester端再去請求種子的時候，回覆的種子全爲0。
這個是請求種子的請求報文和肯定響應報文。請求報文爲“27+01”；肯定響應“67+01+四個字節的種子”。
當Tester端計算得到了一個密鑰，它會發送“27+02+4個字節的密鑰”給ECU。當ECU將兩者密鑰比較後，它認爲比較的結果是一致的，ECU會給Tester端發送“67+02”，認爲ECU已經處於解鎖狀態。
那麼當ECU已經處於解鎖狀態的時候，Tester端又一次請求了種子，發送了請求種子的請求報文給ECU，那麼ECU就會回覆“種子數全爲0的肯定響應”報文給Tester端。表明ECU現在處於解鎖狀態。
這個是27服務支持的所有NRC是在14229-1裏定義，比如說我們常用的12；13；這裏注意24是一個請求順序錯誤，比如說我們要求的安全解鎖狀態過程必須是先請求Seed再發送key，如果你沒有執行請求seed的請求報文，直接發送了key，就會回覆24 NRC；比如說35是非法Key，如果Tester發送了非法的密鑰給ECU，ECU就會回覆35 NRC；36是嘗試次數超限，比如說這是要看具體的診斷規範定義，有的定義請求嘗試次數不能超過3次，那麼Tester端發送給ECU的Key連續3次錯誤的時候，ECU就會回覆36 NRC；37指延時還沒有到，因爲在有的診斷規範裏定義請求的嘗試次數達到最大值的時候，ECU會鎖定一段的時間，在這個時間之內，你的Tester端是不能夠再次請求種子的，所以在這個時間之內，比如說有的整車廠用到10秒延時，Tester端再一次發送了請求種子的請求報文給ECU，那麼ECU就會回覆37 NRC的否定響應報文。
下面我們來看通過DID來讀取和寫入數據，就是22和2E服務
2.4 用於讀/寫的DID的0x22/0x2E服務
首先來看22服務的請求和響應格式，請求格式“22+兩個字節的DID”；它的肯定響應“62+DID+所讀取的數據”。這裏舉出了一個例子，比如說現在的DID是F1 86來讀取當前的診斷會話狀態，它的肯定響應格式“62+ F1 86+02”讀取當前處於編程會話狀態。
在14229-1 2013版附錄C裏面列出一些推薦使用的DID和這些DID的功能，大家也可以去看一下這個附錄C
22服務支持的NRC。13是請求格式不正確；14讀取的數據已經超過了傳輸的最大值，就是超限了；31我們剛纔也已經提到過了，比如說請求的DID不支持，請求的DID在當前會話下不支持；33要求在解鎖狀態下，而現在沒有處於解鎖狀態執行了響應的請求。
看一下由DID寫入數據：2E服務。他的請求格式“2E+2個字節的DID+需要寫入的數值”；肯定響應的格式“6E + DID”。這裏舉出來一個例子，由F1 90來寫入VIN碼，寫入一個17字節的VIN碼，這裏簡化，就打了省略號。當寫入成功後，ECU回覆肯定響應“6E +F1 90”
2E服務支持的NRC。31；3E；33；72和編程有關的，比如說在Bootloader刷寫的過程中，需要對Flash進行操作，而寫入數據沒有寫成功的時候，會回覆72 NRC
下面我們來看和故障存儲有關的服務。
2.5 故障存儲相關的0x19和0x14服務
什麼是故障呢？當系統檢測到了一個錯誤或者是一個故障發生的時候，會將相對應的數值故障碼進行存儲，那麼這個對應的數值故障碼，我們稱之爲故障碼，就是DTC。
一個DTC可以反應出一個故障發生的具體位置，和這個故障發生原因和類型，我們通過讀取的DTC信息，可以爲維修提供一些依據。除此以外還有與法律有關的故障，比如說排放有關的，在未來還會有安全相關的故障
通過這個故障可以反應出在ECU具體的哪一個位置，和產生的故障類型，在很多國際標準裏面都定義了DTC的格式。比如說UDS裏定義DTC由3個字節組成，而ISO 15031-6裏定義了DTC格式由“兩個字節根基+一個字節的故障類型”組成。那麼我們常用的UDS服務裏面DTC格式用的是哪一種呢？有95%用到的DTC格式都是ISO 15031-6裏定義的DTC的故障類型和格式
ISO 15031-6定義的DTC格式什麼樣的呢？
兩個字節的根字節來定義DTC，
左邊前兩位能反應DTC到底是哪一個系統：
00表示Powertrain;
01表示底盤；
10表示車身；
11是網絡相關的。
左邊第3~4位反應的是，DTC到底是由ISO，SAE，這些標準組織所定義的故障，還是由整車廠來定義命名的故障；
左邊第5~8反應的是車輛系統的區域；
右邊8位，這個字節具體的編碼，就是DTC的編碼。
在14229-1中定義的19服務讀取DTC信息裏，定義28個Subfunction，根據不同的Subfunction來獲取不同的診斷信息，在這裏我們介紹4個不同的Subfunction，這4個Subfunction也是在規範中常用的，他們分別是02；04；06；0A。
- 19 02由DTC的狀態碼獲取DTC；
- 19 04讀取DTC的快照數據。在14229裏定義的數據叫做快照數據；在Autosar裏定義的數據叫做凍結幀，其實他們指的是一類數據。快照數據是指當這個錯誤發生，或者當這個DTC存儲的時候，記錄的一些環境數據，比如說車速，水溫，發動機轉數等這些數據，從而我們讀取這些數據之後，能夠更好的判斷DTC產生的原因以及發生故障原因。
- 19 06是來獲取DTC存儲的時候一些擴展數據，這個數據常用的比如說有一些計數器，比如說老化計數器，這樣的數據。
- 19 0A是來讀取這個ECU所支持的全部的DTC，ECU支持的哪些DTC是在ECU診斷規範的時候已經定義好的，所以我們通過19 0A讀取的DTC是這個ECU應該支持的所有的DTC，即使這個DTC沒有產生，也能夠被讀取的
剛纔我們提到了DTC狀態字節，這個DTC狀態由8個位組成的一個字節。這8個位分別代表不同的含義，具體這8個位代表的含義，包括這8個位初始值是什麼，它什麼時候被置1，什麼時候又被清0，它在什麼情況下用，怎樣用，在14229-1 2013版附錄D有詳細的定義。大家如果想具體瞭解這8個位的定義，可以參看附錄D。
這裏要提醒大家的是除了Bit4和Bit6以外，其它所有位的初始值都應該爲0，而Bit4和Bit6的初始值位1。
常用的有比如說Bit0和Bit3.
Bit0當檢測到這個故障，發生錯誤的時候被置1；
Bit3 ConfirmedDTC根據具體DTC的應用邏輯，這個DTC被檢測到了多次，這個次數由具體的ECU規範定義，那麼這一位也應該被置1。
我們通過19 02讀取DTC的時候，會用到3個不同類型的DTC Status，那麼這3個不同的DTC有什麼區別呢：
- 在請求報文裏有一個字節的DTC Status Mask，這個是被Test用來讀取DTC數據的，這個值可以是00到FF之間的任意值，根據所要讀取的DTC內容決定。如果你想讀取這個ECU產生的所有DTC，你可以用 0xFF.
- 在肯定響應中，也有一個字節DTC Status Availability Mask，這個字節的DTC Status，是ECU診斷規範裏定義的
- 在肯定響應中，讀取的DTC後面還有一個字節，是反應的這個DTC，所產生時，對應的狀態信息。
我們來看具體的請求和響應格式，首先看19 02。19 02後面跟一個字節的Status Mask，第0位和第3位被置1，而這一個字節Mask，是在ECU診斷規範定義的，所以 59 02 +一個字節的Mask+具體的DTC+DTC後面的跟的DTC Status。
如果有多個DTC，後面會重複DTC的格式：3個字節的DTC+DTC Status。
通過19 0A讀取ECU支持的所有DTC，請求格式是兩個字節“19 + 0A”；肯定響應格式“59 + 0A+一個字節的Mask+後面跟ECU支持的所有DTC”
當診斷故障信息被存儲了以後，我還需要，問題我們已經通過維修的方式解決了，我們用什麼樣的方法將這個DTC清除呢？
用到14服務清除診斷信息，14服務格式很簡單，請求格式是“14 + 3個字節數值”，這3個字節的數值可以是針對單個DTC清除，也可以是按組來清除DTC，也可以是清除全部DTC。當3個字節都爲FF時，表示將ECU裏產生的所有DTC清除。
那我能不能按照組來清除DTC，比如說清除和車身有關的DTC，就按照車身這個組的數值，將它添加到請求報文格式裏；
那我能不能單獨清除，只針對某一個DTC，清除這個DTC，也是可以的。只需將這個DTC的具體數值放在請求報文，那麼的肯定響應格式是一個字節54。
這個表格在14229中也有描述，大家可以具體參看。
3 結尾
歡迎大家給我留言，如果覺得好，動動你的手指，“點贊”+“收藏”
獲取更多汽車行業資訊，以及工具鏈的使用，可以關注微信公衆號“汽車電子助手”
或者掃描下方二維碼進行關注
END