UDS診斷入門
寫在前面：UDS實踐性強，邏輯複雜，很多服務非要體驗過一次才能理解，導致包括我在內的初學者感覺晦澀難懂，不明覺厲，因此將自己的理解寫下來、整理下來，與君共勉。
零、UDS診斷命令備忘錄
常見的UDS報文
常見的20個NRC
一、簡介
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網路層的知識，請移步：
排放相關的診斷內容，即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
摘自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種服務進行了解釋，英文原文連結如下。學習時如果遇到困惑可以找標準中的相關語句進行翻譯，協議是所有學習材料的根本。
本文重點介紹以下幾個服務：
$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的圖，當然完整版請參照ISO14229附錄A。
這裡提一下一個特殊的NRC——0x78，requestCorrectlyReceived-ResponsePending（RCRRP，
請求已被正確接收-回覆待定
）。這個NRC表明請求訊息被正確地接收，請求訊息中的所有引數都是有效的，但是要執行的操作還沒有完成，Server端還沒有準備好接收另一個請求。一旦請求的服務已經完成，伺服器應該傳送一個積極的響應或消極的響應，響應程式碼應與此不同。這個NRC的消極響應可以被Server端重複，直到被請求的服務完成並且最終的響應訊息被髮送。
當使用此NRC時，伺服器應始終傳送最終響應（不管正響應還是負響應），
與suppress-PosRspMsgIndicationBit值或NRCs SNS、SFNS、SNSIAS、SFNSIAS和ROOR對功能上處理請求的響應抑制要求無關
。
NRC 0x78壞了規矩的例子
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
寫入一個VIN碼
正確的順序是10開頭的幀請求、30開頭的幀回覆、21開頭再請求、22開頭繼續請求、03開頭回復確認。我們一幀一幀來看。
10 14根據ISO15765-2代表這是一組多幀中的首幀（屬於傳輸層的資訊），一會要發0x14=20個位元組的有效資料。之後是2E+F190（代表這是VIN碼）+VIN碼的前3個位元組。意思是作為外部工具，想寫入一個VIN碼資料。這件事情正常是發生在車輛下線時。
30 00 0A是TP層（傳輸層）的資訊，表示這是一個流控幀，ECU發出的，表示可以一直連續發，但連續幀最短的間隔時間要求是10ms。
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程式碼生成軟體。
Vector 產品很好用，節省開發時間，但價格昂貴，不適用於小廠或規模性採購。目前市面上有很多CAN 廠商（如Kvaser， ZLG 等）能提供低成本、體積小、驅動簡單、開放API 的裝置，很適合進行UDS相關的二次開發。
文不對題的例子
變速器控制單元TCU和防抱死系統ABS是CAN車載網路上的兩大電子控制單元， 這2個ECU要透過CAN網路進行大量的資訊互動。但是由於電磁干擾、串擾、靜電等外界干擾或電控單元本身控制策略引起的通訊停止等原因， 2個控制單元之間可能會出現通訊丟失的現象。控制系統需要將故障資訊（例如通訊丟失故障資訊） 診斷出來， 以處理通訊被破壞時出現丟失幀的故障現象， 並記錄為DTC （diagnostic trouble code）。當然，這些DTC也可以用於售後的維修保養。
ECU的輸入訊號主要有4種形式： ①
模擬訊號
（水溫、油壓、蓄電池電壓等）； ②
數字訊號
（各種開關訊號等）； ③
PWM訊號
（脈衝訊號、頻率訊號等）； ④
網路訊號
（CAN、LIN上傳輸的訊號）。ECU可以透過監測這些訊號來判別輸入電路的工作狀況。輸出的訊號往往用作控制
電磁閥、指示燈、步進電機
等， 大多數為數字訊號。
討論
問題：
如果出現了UDS請求併發的情況，比如2E服務，正在寫入、正在處理時，突然有11服務請求闖入，此時ECU會如何處理呢？
觀點：
此時應繼續執行完2E的寫入服務，11服務的請求將會被丟棄，不會有任何回覆。
大家可以加入公眾號：
汽車ECU網路診斷技術
，瞭解更多ECU診斷知識。
大家可以加入公眾號：
汽車ECU開發
，瞭解更多汽車電子知識。
大家可以加入公眾號：
汽車電子expert成長之路
，學習汽車電子知識（NXP為主）。
如果您對我的文章感興趣歡迎點贊或留言，大家有什麼關於車輛診斷/CAN匯流排的問題都可以留言給我，閒下來的時候我會針對熱點問題寫新的文章。謝謝大家！
影片教程：
1。【【官方自制】UDS Protocol_嗶哩嗶哩_bilibili】【官方自制】UDS Protocol_嗶哩嗶哩_bilibili
2。【汽車匯流排技術】UDS診斷基礎講解合集_嗶哩嗶哩_bilibili
學習資料:
1。（
全系列推薦
）統一診斷服務 （Unified diagnostic services ， UDS） （一）
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）
9。【圖文】UDS診斷服務_百度文庫
10。CAN診斷基礎-上部分_圖文_百度文庫
11。CAN診斷-下_已讀_圖文_百度文庫
12。（
推薦
）ISO 14229+統一診斷服務
13。FlashBootloader_圖文_百度文庫
14。帳號登入
15。ISO 15031-5-2015
16。ISO 15765-3車載診斷標準-詳細中文版
17。吉利汽車基於CAN線診斷技術規範_百度文庫
18。UDS（ISO14229-2006） 漢譯（No。7 應用層協議）
19。基於UDS標準的Flash Boot Loader 設計淺析
20。［圖文］UDS診斷詳解 - 百度文庫
21。UDS診斷服務在車載ECU中的應用分析 - 百度文庫
22。
https：//
mp。weixin。qq。com/s？
__biz=MzUyODgyMDI0OQ==&mid=2247483717&idx=2&sn=55e317acf1268f413f082c12b2cfa119&chksm=fa6b3033cd1cb925d9ead4bbb2dade0f9717e38b5818ceda53598d9f41b9f6469dfb8722b950&mpshare=1&scene=1&srcid=0529MTVAi9sTNyQA862pqGHf&pass_ticket=fXKprCqzX9p9OZ9nJFyHAS%2F9MqiG8sEkIcD5esPpqLN3MWs6fob6jp9mteazPgiW#rd
22*。張丁：汽車控制器（ECU）中DTC的狀態位
23。UDS_Wikipedia
24。（推薦）關於Autosar中DCM（14229UDS）模組的理解
程式碼參考：
1。SAE J1939 協議原始碼分析（一）-程式結構框架
2。基於CAN匯流排的汽車診斷協議UDS（上位機開發網路層及錯誤程式碼解析） - CSDN部落格
3。基於CAN匯流排的汽車診斷協議UDS（ECU底層模組移植開發） - CSDN部落格
4。（推薦）基於CAN匯流排的汽車診斷協議UDS （網路層 ISO 15765）
5。（推薦）github上的UDS協議棧原始碼：ukign/UDSDemo
更新歷史：
2019。7。3 更新文章結構，重寫開頭和0x10服務。