閱讀本篇文章希望達到的目的是：
UDS是干什么的，
ISO14229是如何定義規則的，
希望接下來的閱讀讓你不虛此行。
1. UDS是干什么的？
UDS全稱是Unified Diagnostic Services，即 統一診斷服務。其最重要的作用就是用來診斷汽車的故障的，當然不僅僅是這個用處，它還可以用來進行汽車的下線檢測，比如一般車輛會把VIN碼寫入汽車中的各個零部件中（ECU），比如可以矯正角度，比如可以記錄一些和產線相關的信息等等。
那么UDS是如何去診斷故障的呢？這里包含兩種方式，一種為在線診斷（OBD），一種為離線診斷，前者一般用於傳統燃油車中與排放相關的診斷，后者主要是非排放相關的。因為我主要做新能源汽車這一塊，因此對非排放相關的診斷理解更多一點，（關於OBD 可參考ISO15031）。
那么非排放相關的故障是如何診斷的呢？首先汽車中的每個ECU都按照規則存儲故障信息，例如BMS發生了欠壓故障，那么這個時候BMS就記錄發生故障時刻的DTC（故障碼），以及在故障發生時刻 便於查找故障的快照信息或凍結幀信息（例如這個時刻BMS的電壓、電流等等信息），這些信息是便於查找故障的信息。
為了便於理解，有必要解釋一下幾個名詞：
DTC：診斷故障代碼，其意思就是通過一個代碼 代表一個故障；
快照/凍結幀：指發生故障時刻的一些便於排查故障的信息；
擴展信息：這個是指除快照之外，與故障相關的一些信息，例如故障的發生次數、老化次數等等。
以上講了ECU是如何記錄故障信息的，下一步講我們如何去診斷我們的汽車發生了什么故障，我們接着以BMS發生了欠壓故障導致車輛無法行駛為例，那么故障車一般會被拖到4s店進行維修，4s店為快速定位車發生了什么故障，這個時候他們會使用診斷儀，一鍵廣播查找車上所有零部件上發生的故障信息，這樣可以很快知道是BMS發生了故障，並且發生的故障是欠壓故障，那么欠壓故障是因為什么導致的呢，這個時候就要分析快照數據了，根據快照數據，快速的找到可能是因為電池包本身的電壓過低導致。以上就講完了UDS在車上是如何使用的，也就是UDS是干什么的問題。
讀完這一段，你會想，UDS確實有點用處，因為你要想，車上的零部件都是成百上千的，要快速精確定位故障不是一件容易的事情，我希望你有興趣繼續讀下去，下面我們就要講講UDS能有這種神奇功能，他是如何去規定的。
2.ISO14229是如何定義規則的？
要快速定位車上的故障，那么就要求車上所有的ECU都遵守相同的規范，同時全世界又有各種各樣的主機廠，假設每個廠商都自己去定義規范，可想而知，到最后幾千萬上億的車到最后可能需要各種各樣的4s店。因此ISO就出台定義了一整套UDS相關的規范，這樣大家都遵守一定的規范辦事，也就便於后面的維護管理了（以上閑扯幾句，可跳過）。
首先，我們大致推斷一下ISO想干一件什么事，也就是這個規范它應對的需求是什么。
從1中提到的UDS要干的什么事，我們大致了解，這套規則需要所有的汽車廠商遵守一套協議，同時能滿足所有廠商下線檢測以及診斷的功能。
首先我們講講 一般汽車廠商下線檢測需要檢測些什么東西，首先主機廠肯定需要的一個信息就是為生產的每一輛車分配一個標識碼(VIN碼，有興趣的可百度一下)，這個VIN碼可以唯一標識這輛車，下線檢測的時候，就可以通過UDS寫入到汽車的ECU中，所以這就會用到要寫入信息的功能，但是，既然是唯一的，因此不能隨便寫入啊，所以就要分配權限，只能通過安全認證的人才能寫入。寫入之后，當然就要讀出來，要不怎么知道車里面的VIN碼呢。以上就引出了UDS的三個功能，讀數據、寫數據、以及權限檢查。
當然，下線檢測當然不僅僅是這些功能，例如需要調整電機的零位角度或者ECU自檢等，這個時候就需要UDS支持復雜的功能，UDS管這種支持復雜功能的服務叫做例程，你可以把例程理解為一段比較復雜的邏輯程序。
有時候，我們需要去控制電路上的引腳，來調試或者檢測制定的功能，例如實現一個點燈的操作，這個時候，UDS就提出了IO控制。
假如，我們想要復位一些車上的ECU，我們當然不希望還要通過擰鑰匙這種操作來完成，因此UDS中提供了各種各樣的復位操作；
假如，我們發生車上的某個ECU中的程序有個BUG導致車壞了，要升級怎么辦，我們當然不希望拆掉一個ECU換一個，那么UDS就支持燒寫程序的操作；
那么，還有一個需求就是，假如車上某個部件壞了，那么會有故障信息存儲下來，這個時候為了排查故障，我們需要快速找到壞的部件，然后為了快速定位故障，我們需要知道故障發生時刻的車的狀態，等車修好了，我們不需要這個存儲的故障信息了，我們一般需要刪掉這個故障信息，以騰出空間為后面發生的故障存儲。也就是我們需要讀取故障信息，以及清除故障信息的操作。
以上講的是常用的UDS的一些操作，當然不僅僅是這些，比如燒錄的時候，為了降低總線線路傳輸數據的負載率，一般需要控制車上各個ECU收發信息的開關，同時剛燒錄的時候，一般不能開啟故障存儲，因為這個時候地址里面的數據不是真實發生的故障。因為UDS一般都是涉及嵌入式的軟件，為了更自由的讀寫數據，還可以通過讀寫地址，當然也支持讀取多個數據（規定上限4095個），因為UDS采用的是一問一答的形式，假如我們要動態實時的知道某個值怎么辦，這個時候UDS當然支持周期讀取數據的操作等等類似的內容。
希望你能耐心讀取一下以上的需求，因為對理解14229肯定有點幫助的。
從上面對於應用場景的大致需求，我們下面一一對號入座來談談14229是如何定義規則。
10服務：
首先需要隆重介紹的一個服務是10服務，這個服務用來做什么？打個比方來說，假如有三個池塘，A池塘用來放草魚和鯰魚，B池塘用來放觀賞性的錦鯉，C池塘用來放小型鯊魚。那么我們10服務中的每個狀態對應一個池塘，而每個池塘里的魚就是14229里面對應的所有服務（所謂服務就是一套數據定義規則），里面A池塘對應10服務的默認狀態，里面的草魚和鯰魚，對應在這種默認會話狀態下支持的服務，同樣B池塘對應10服務的編程模式，里面的各種錦鯉對應在編程模式下支持的各種服務。C池塘對應擴展模式，小型鯊魚對應在該模式下支持的服務。是不是還是有點不理解，我再來簡單說一下，也就是說10服務用來切換三種或更多模式，默認模式用來支持默認狀態下支持的各個服務，編程模式用來支持與編程相關的服務，擴展模式一般用來在非默認模式下支持的一些服務。
為什么要這么做？其實就是為了管理各個服務，讓各個服務在一個池子里面，只有進入這個池子，你才有權限去訪問各個服務。
數據應答規則舉例大致說明一下：
請求:CANID 02 10 03 （02對應數據長度，10表示10服務，03表示10服務的子服務，該請求的目的就是切換到擴展模式，其他模式切換類似）
答復：CANID 06 50 03 xx xx xx xx （06對應數據長度，50表示10服務（+0x40），03表示10服務的子服務，該答復的目的就是切換到擴展模式，其他模式切換類似）
有興趣的朋友可以深入研究一下。
11服務：
對應的就是復位服務，其中包括了子服務硬件復位 01 子服務KeyOfOn復位02 子服務軟件服務03；
其中三種子服務都是通過操作軟件來進行對應的復位操作。
數據應答規則
請求：CANID 02 11 01
答復：CANID 02 52 01
14服務：
對應的就是清除故障服務
他可清除一個故障信息，也可以清除一組故障信息。
應答規則后面不講了，有興趣的朋友可支持參考14229協議。
19服務：
這個服務主要用來，查詢故障信息，這個服務非常復雜，需要費很大的力氣才能講清楚，下面我僅僅對常用的幾種子服務進行介紹，其實所有定義的服務，無非就是為了快速查找到需要的故障信息。
01子服務：通過狀態掩碼的形式去，查找該狀態掩碼匹配的故障個數，其實意思就是查找故障個數，這里稍微解釋一下狀態掩碼，在UDS規定里面，每個故障都對應8個狀態，每個狀態對應一個bit，比如狀態0對應bit0，表示當前發生的故障，狀態3對應bit3，表示已經確認的故障等等，那么狀態掩碼的意思就是用一個8bit的數去按位與，如果與的結果與的結果非0表示匹配到了，然后故障數就++。
02子服務：通過狀態掩碼的形式去，查找匹配的故障，以及故障的狀態。
04子服務：請求指定故障碼（DTC）的快照信息，意思就是說為了找到故障的原因，查找故障發生時刻的一些數據，來分析故障原因。
06子服務：請求指定故障碼（DTC）的擴展信息，就是想了解一些該故障的一些其他信息，比如發生的次數、自恢復的次數等，具體數據可自定義。
0A子服務：通過該服務科獲取所有支持的故障碼和故障狀態信息，注意是所有的故障及故障碼。
這個服務大致簡單的講到這里吧，其實這個服務里面有N多內容，需要細細挖掘掌握。
22服務：
通過數據標識符的形式讀取數據，例如我想讀電機控制器里面的電機轉速的信息，我就定義電機轉速這個變量 標識符為0x2000，（這是因為總線上基本不搞變量啊），所以我去請求電機轉速時，我只需讀該標識符的數據即可。
2E服務：
與22服務對應，表示通過數據標識符寫入數據，一般來說，一個標識符可支持讀，寫操作是根據需求可選的。
23/3D服務：
23是通過地址讀數據
3D是通過地址寫入數據，一般用的較少。
24/2A/2C/86服務：
這類服務用的較少，這里不再贅述；
27服務：
這個服務就是用來權限管理的，他的權限進入方式是：
診斷儀 電機控制器ECU
1. 請求種子 --> 計算種子
2. 接收種子 <-- 答復種子
3. 發送密鑰 --> 計算密鑰 對比密鑰
4. 獲取權限 <-- 返回權限切換狀態
比如你要向ECU寫入數據，一般人當然不能隨便寫，只有專門懂的人才能寫入，因此需要權限來保證。
28服務：
通信控制，包括對發送和接收消息的開關控制。
31服務：
例程控制，比如一些復雜的操作需要用他來實現，目前比較通用的包括燒錄時的數據完整性檢查、擦除內存等等。
2F服務：
IO控制，主要用於對一些輸入輸出口的調試控制，目前這一塊接觸較少，比如一些傳感器的開關控制。
34/35/36/37服務：
和數據傳輸有關的服務，包括請求傳輸、請求下載、數據傳輸、數據上傳、退出傳輸等，這些服務和BootLoader相關。
85服務：
用於控制故障的更新，包括開啟和關閉故障更新，比如關閉之后不允許故障、故障狀態、故障記錄等信息的更新。開啟則反之。
以上服務講的比較淺，有興趣的朋友可以對比着和14229看一下，相信會對理解有一定幫助。
---------------------
作者：AgingMoon
來源：CSDN
原文：https://blog.csdn.net/AgingMoon/article/details/77512164
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！