轉載：https://www.cnblogs.com/still-smile/p/12022080.html
UDS（Unified Diagnostic Services，統一的診斷服務）診斷協議是ISO 15765 和ISO 14229 定義的一種汽車通用診斷協議，位於OSI模型中的應用層，它可在不同的汽車總線（例如CAN, LIN, Flexray, Ethernet 和 K-line）上實現。UDS協議的應用層定義是ISO 14229-1，目前大部分汽車廠商均采用UDS on CAN的診斷協議。
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，回復的是一個聲明。
肯定響應和否定響應的形式一定要熟記。
UDS的26種服務中，有7種很重要。它們分別是：
- $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（待機握手）。
下面對這7個服務進行解讀。
1 $10診斷會話
$10包含3個子功能，
- 01 Default，
- 02 Programming，
- 03 Extended，
ECU上電時，進入的是默認會話（Default）。如果您進入了一個非默認會話的狀態，一個定時器會運轉，如果一段時間內沒有請求，那么到時間后，診斷退回到默認會話01。當然，我們有一個$3E的服務，可以使診斷保持在非默認的狀態。
報文包含4種類型，即
- SID，
- SID+SF（Sub-function），
- SID+DID（Data Identifier）（讀寫用），
- SID+SF+DID。
NRC：Negative Response Code（否定響應碼)。如果ECU拒絕了一個請求，它會回應一個NRC。不同的NRC有不同的含義。
舉例子前首先看下網絡層幀：
- 第一個字節的高位是0的為單幀信息；
- 第一個字節的高位是1的為多幀中的首幀；
- 第一個字節的高位是2的為多幀中的后續幀；
- 第一個字節的高位是3的為流控幀；
舉例1：以can總線為例子
八個數據字節，第一字節被網絡層占用。
- 請求（Request）:
02 10 02 xx xx xx xx xx
02中的0代表網絡層單幀SF，2代表 數據域有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。
3.$19 讀DTC
DTC（diagnostic trouble code）：如果系統檢測到了一個錯誤，它將其存儲為DTC。DTC可表現為：一個顯而易見的故障:通訊信號的丟失（不會使故障燈亮起）；排放相關的故障；安全相關的錯誤等。DTC可以揭示錯誤的位置和錯誤類型。通常DTC占用3個字節，OBD II占用兩個字節。
故障碼包括四個大類，分別是PCBU，P是powertrain動力系統，C是Chassis底盤，B是Body車身，U是network通信系統。一個DTC信息占用4個字節。最后一個字節是DTC的狀態。前兩個字節是我們熟知的類似P0047的故障碼。
| DTCHighByte | DTCMiddleByte | DTCLowByte | DTCStatus |
|---|---|---|---|
| Byte 1 | Byte 2 | Byte 3 | Byte 4 |
$19 擁有28個子服務（Sub-Function）。常用的子服務有02（通過DTC狀態掩碼讀取DTC），04（讀取快照信息），06（讀取擴展信息），0A（讀ECU支持的所有DTC數據）。
3.$14清除DTC
清除（復位）DTC格式，它可以改變DTC的狀態。3個FF代表清除所有DTC。
Request：14+FF+FF+FF；
Response：54 。
2診斷報文解析
UDS 的診斷數據的發送與接收都是基於CAN，所以每個數據流都包含基本的CAN Message 的架構
CAN Message =CAN ID + CAN DATA
根據上篇UDS文章的敘述，每一個PDU 包含控制信息PCI,數據信息Data.
網絡層 PDU（協議數據單元）PCI（協議控制信息）格式：具體如下圖所示：
| 幀類型 | bit7-4 | bit3-0 | Byte 2 | Byte 3 |
|---|---|---|---|---|
| 單幀 | PCItype=0 | SF_DL | N/A | N/A |
| 首幀 | PCItype=1 | FF_DL | FF_DL | N/A |
| 連續幀 | PCItype=2 | SN | N/A | N/A |
| 流控幀 | PCItype=3 | FS | BS | ST_min |
綜上所述，N_PDU =N_PCI+N_DATA, N_PCI的值主要集中的前三個字節，N_DATA值主要集中在后面7位字節。其中，
SF_DL代表單幀中數據字節數（取值0-7），FF_DL代表 連續幀中的數據字節數(12bit可表四8~4095)，SN代表此幀為連續幀中的第幾幀，（0、1、2...E、F、0、1...）FS流控制幀，有三種狀態：繼續發送0、保持等待1、數據溢出2BS規定發送端允許持續傳輸連續幀數目的最大值（0~255），STmin限定連續幀相互之間所允許的最小時間間隔。
先面用連個例子進行說明，請參考！
2|1例子 1--- 單幀的數據傳輸與接收
[圖片上傳失敗...(image-b66bab-1538824826939)]
數據發送： 02 27 09
數據反饋： 03 7F 27 7E ---==否定的響應==（Negative Response），回復==7F+SID+NRC==，回復的是一個聲明
數據發送： 02 10 40
數據反饋： 06 50 40 00 32 01 F4 ---==肯定的響應==（Positive Response），回復[==SID+0x40==]，就是請求10，響應40；回復的是一組數據
由於這個數據發送與接收都是單幀傳輸，所以第一個數據的高四位均為0，四個數據流中的第一個字節的低四位，02，03，02，06代表的為此幀數據含有幾個字節，多余的數據位都用 00或者AA行填充。
2|2例子2 --- 多幀的數據接收與傳輸
[圖片上傳失敗...(image-b5e84b-1538824826939)]
數據發送：
- 06 19 04 00 01 00 00 00
數據反饋：
- 10 1E 59 04 00 01 00 27
- 30 00 00 00 00 00 00 00
- 21 00 0B FF FF FF FF FF
- 22 FF FF FF FF FF FF FF
- 23 FF FF FF FF FF FF FF
- 24 FF FF FF AA AA AA AA
數據發送為單幀，所以06代表發送的數據中含有6個字節，
回復為Positive Response，為連續幀。
- 10中的1代表連續幀的首幀，==01E代表此連續幀含有30個字節==，
- 30代表此連續幀的流控制幀，
- 21，22，23，24代表連續幀中的第幾幀，21代表第一幀，22代表第二幀，依此類推，其中AA為填充位。