本篇文章主要介紹基於ISO14229的DCM模組的理解。

閱讀本篇文章希望達到的目的是：

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看一下，相信會對理解有一定幫助。