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最為核心的功能。
為什么我們要設計UDS這樣的診斷協議呢？在汽車診斷協議誕生之前，修車只能靠師傅的經驗，因為汽車零部件不會告訴你它哪里出了問題。但有了診斷協議之后，一旦零部件出了問題或者出過問題，它們會把故障信息保存在內存里面，維修師傅就可以通過通信總線讀取這些故障信息，比如一個ECU經歷欠壓故障之后，它會將欠壓故障代表的DTC（診斷故障碼）存儲起來，可選擇性保存的還有發生故障時的快照信息（比如此時的車速、讀到的電壓值等）。快照信息有助於測試工程師和售后技師查找發生故障的原因。
除了CAN總線以外，UDS也可在不同的汽車總線（例如 LIN, Flexray, Internet 和K-line）上實現。
應用層服務
UDS本質上是一系列的服務，共包含6大類26種。每種服務都有自己獨立的ID，即SID。
SID：Service Identifier，診斷服務ID。UDS本質上是一種定向的通信，是一種交互協議（Request/Response），即診斷方給ECU發送指定的請求數據（Request），這條數據中需要包含SID。如果是肯定的響應（Positive Response），回復 [SID+0x40]，就是請求10，響應50；請求22，響應62，回復的是一組數據。如果是否定的響應（Negative Response），回復7F+SID+NRC，回復的是一個聲明。肯定響應和否定響應的形式一定要熟記。
0x10診斷會話
0x10包含3個子功能:
- 01 :默認會話(權限最小,操作服務少)
- 02 :編程會話(用於解鎖bootloader相關)
- 03 :擴展會話(解鎖高權限服務:寫入數據和診斷碼)
ECU上電時，進入的是默認會話.如果您進入了一個非默認會話的狀態，一個定時器會運轉，如果一段時間內沒有請求，那么到時間后，診斷退回到默認會話01(最低權限)。當然，我們有一個0x3E的服務，可以使診斷保持在非默認的狀態。
0x10服務否定響應碼:
- 0x12:不支持請求服務的功能
- 0x13:請求報文的數據長度或者格式不合法
- 0x22:條件不滿足
- 0x31:請求超出范圍
| 02 | 10 | 01 | 00 | 00 | 00 | 00 | 00 | 發送 |
|---|---|---|---|---|---|---|---|---|
| 06 | 50 | 01 | 00 | 32 | 00 | C8 | AA | 接收 |
| 02 | 10 | 02 | 00 | 00 | 00 | 00 | 00 | 發送 |
| 03 | 7F | 10 | 22 | AA | AA | AA | AA | 失敗 |
0x3E待機握手
0x3E服務用於向服務器指示診斷儀仍然連接在網絡上，之前已經激活的診斷服務功能可以仍然保持激活狀態。
0x3E否定碼:
- 0x12:不支持請求服務的功能
- 0x13:請求報文的數據長度或者格式不合法
發送一個3E服務的報文，保持非默認會話狀態。80表示無需回復。
| 02 | 3E | 00 | 55 | 55 | 55 | 55 | 55 | 發送 |
|---|---|---|---|---|---|---|---|---|
| 02 | 7E | 00 | xx | xx | xx | xx | xx | 否定 |
| 02 | 3E | 80 | xx | xx | xx | xx | xx | 接收 |
0x27安全訪問
0x27安全訪問：ECU當中有很多數據是整車廠獨有的，並不希望開放給所有客戶，它需要做一個保密的設定。我們在讀取一些特殊數據的時候，要先進行一個安全解鎖。ECU上電之后是一個鎖定的狀態（Locked），我們通過0x27服務，加上一個子服務，再加上一個鑰匙，這樣的服務請求可以進行解鎖。
比如下面的例子，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）成功。
0x27否定碼:
- 0x12:不支持請求服務的功能
- 0x13:請求報文的數據長度或者格式不合法
- 0x22:條件不滿足
- 0x24:請求順序錯誤
- 0x31:請求超出范圍
- 0x35:無效密鑰
- 0x36:嘗試次數超限
- 0x37:延時數據未到
例子：
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，結束。安全驗證就是一把鎖，算法越復雜，短時間解開的成本越高，越不易被破解掉。如果失敗次數過多還會觸發懲罰機制，一段時間內都無法再嘗試解鎖，防止人為的破解。
0x22讀數據
0x22讀數據，Request（請求）：22+DID（數據標識符，通常是兩個字節）
Response（響應）：62+DID+Data
DID有一部分已經被ISO 14229-1規定：
- 0xF186就是當前診斷會話數據標識符
- 0xF187就是車廠備件號數據標識符
- 0xF188就是車廠ECU軟件號碼數據ID
- 0xF189就是車廠ECU軟件版本號數據標識符
0x21寫數據
0x2E寫數據，Request（請求）：2E+DID+Data
Response（響應）：6E+DID
由上圖可知，請求格式分為三部分
第一部分：請求SID：0x2E，占用一個字節
第二部分：dataIdentifier（DID），需要寫入數據對應的DID標識符值。占用兩個字節
第三部分：dataRecord，需要寫入的數據
由上圖可知，響應格式分為兩個部分
第一部分：response SID：0x6E
第二部分：dataIdentifier（DID），請求DID的echo
0x19讀DTC
19服務是一套診斷服務中的重中之重
DTC：如果系統檢測到了一個錯誤，它將存儲為DTC。DTC可表現為：一個顯而易見的故障；通訊信號的丟失（不會使故障燈亮起）；排放相關的故障；安全相關的錯誤等。DTC可以揭示錯誤的位置和錯誤類型。通常DTC占用3個字節
故障碼包括四個大類，分別是PCBU，P是動力系統，C是底盤，B是車身，U是通信系統。一個DTC信息占用4個字節。最后一個字節是DTC的狀態。一個DTC除了它自己的3個字節，還有一個字節專門用於表達DTC的狀態，這個字節我們叫它DTC狀態掩碼 .
第一個字節在乘用車中，前兩個bit代表P/C/B/U（動力/底盤/車身/網絡）中的一個，之后六個bit是數字，合在一起的樣子形如“C01”。第一個字節的前2個bit中，用00/01/10/11分別表示P/C/B/U。
0x19擁有28個子服務。常用的子服務有：
-
01 (讀取符合掩碼條件的DTC數量)（必須支持）,后面的參數是DTC狀態掩碼，若為01表示我想讀當前故障，若為08表示我想讀歷史故障，若為09表示當前故障和歷史故障都想讀。
在肯定回復時，組合應該是59(19+40) - 01 （子功能） - 09 （本ECU所支持的掩碼條件）-01 DTC的格式 - 00 01 （目前滿足條件的DTC有一個）
-
02（讀取符合掩碼條件的DTC列表及其狀態）（必須支持），后面的參數是DTC狀態掩碼，解讀同上。
在肯定回復是，59 - 02（子功能）- 09（本ECU所支持的掩碼條件） - XX XX XX ( DTC,車廠定義 ) - 01
-
04（讀取快照信息），也叫凍結幀。
-
06（讀取擴展信息）
-
0A（讀取ECU支持的所有DTC列表及其狀態）（必須支持）。這個就不必發DTC狀態掩碼了。所有支持的DTC列表及其狀態都會打印出來。
0x14清除DTC
清除（復位）DTC格式，它可以改變DTC的狀態。DTC狀態中的八個位，除bit4和bit6外均會被清零，包含當前故障和歷史故障。bit4和bit6這兩個testNotCompleted開頭的會被強制置1。
3個FF代表清除所有DTC。
由上圖可知請求格式分為兩個部分
第一部分：請求SID：0x14，占用一個字節
第二部分：groupOfDTC，由廠家自定義，占用三個字節
由上圖可知響應格式只有response SID：0x54，占用一個字節
groupOfDTC為3個FF代表清除所有DTC
0x2F IO控制
該服務可以通過DID(數據標識符)來進行輸入信號的替換和控制零部件負載輸出。這是一個用在產線上較多的服務。該報文的請求至少由4個字節組成。第一個字節是2F，第二第三字節是DID
IO控制類型分為4類，
- 00是控制權還給ECU
- 01是復位為默認值
- 02是凍結當前的狀態
- 03是短暫接管控制權
若控制類型是00-02這三種，請求報文是4個字節。
若控制類型是03，請求報文的第5字節是控制代碼，可以是數字量，比如01是開，00是關；也可以是模擬量，比如空調風門的開度。
0x2F否定碼:
- 0x13:請求報文的數據長度或者格式不合法
- 0x22:條件不滿足
- 0x31:請求超出范圍
- 0x33:安全訪問拒絕