01

 DTC-Diagnostic Trouble Code（診斷故障代碼）

車輛在運行的過程當中，控制器會監控狀態，特定故障發生時控制器會記錄這些故障。車輛送4S店進行維修保養時，工作人員會通過智能終端（實際就是診斷儀）來讀取這些故障，以配合問題定位，方便維修和保養。這里工作人員讀取的故障信息是一系列的字符代號，即DTC診斷故障代碼。主機廠預先設定好故障跟代碼的映射關系（類似于DID與數據內容間的映射），根據取得的代碼號可以很快從故障代碼表中定位到與之映射的實際故障內容（診斷儀程序中這些工作都是自動完成的，無需人工查找）。

在這里讀取故障代碼的服務不是我們之前介紹的$22服務，而是專用的$19服務。工程師根據各種信息完成車輛修復之后，確認DTC上報的故障消除，會使用智能終端清除ECU記錄的故障信息，清除操作使用了$14服務來實現。 

1.1 DTC的分類

對于UDS DTC的詳細分類在ISO14229的附錄中有具體的描述，本篇的目的是為了方便初學者入門，就不做過于深入的分析，隨著在相關領域內的工作深入，今后可以進一步學習，入門后的工程師會更加容易理解規范的定義。

通過上一章節的敘述我們可以理解，車輛零部件可以記錄的故障很多，主機廠設計DTC有兩種選擇，分別按照ISO15031和ISO14229進行，在主流的乘用車和商用車上，主機廠使用ISO14229相對多一點。

無論按照哪種設計，主機廠通常將DTC的故障分為4類，通過PCBU來表示，P是powertrain動力系統，C是Chassis底盤，B是Body車身，U是network通信系統，這里我們又一次見到了車身、動力、底盤這三大件分類的強大，也證明了分類的經典和實用。

1.2 UDS DTC

對于各主機廠遵循的DTC Format Identifier具體定義在ISO14229標準附錄部分有表格說明。我們舉例了基于ISO14229的DTCFID-0x01格式的情況，這也是主機廠使用比較多的一種格式（如果這段內容不是很理解的話，繼續往下看吧，后面會有對應的知識分享與這段進行呼應）。數據部分長度為3字節，格式如下圖所示：

圖 1

DTC的代碼長度為7個字符，如：B1525_11實際在診斷中對應的16進制數顯示為0x952511，各字符對應的bit位關系如下圖所示：

圖 2

實際上在主機廠設計DTC時具體的故障定義還會參考《SAE J2012DA：2013車輛診斷故障碼定義》。在這個標準定義中將4個系統的故障碼使用范圍進行了劃分，大體劃分如下：0x0xxx-0x3xxx 劃分P動力系統使用；0x4xxx-0x7xxx 劃分C底盤系統使用；0x8xxx-0xBxxx 劃分B車身系統使用；0xCxxx-0xFxxx 劃分U網絡系統使用。

將上文中0x952511，從16進制轉換為2進制后，我們就可以發現，分類方式和第1位字符可以對應的系統，跟我們上文說的PCBU是一致的，通常對應關系為00：P、01：C、10：B、11：U。

第二位字符故障分類的定義大體如下：0XXX ISO/SAE控制定義、1XXX制造商自定義、2XXX制造商自定義、3XXX預留。對于DTC low byte如果主機廠未使用一般置零。

1.3 DTC狀態

DTC status狀態碼是用來表明故障在指定時間上是否存在，以及故障測試狀態情況的。總共1個字節表示8種不同的判斷條件。ISO14229附錄D有詳細描述。

從bit0-bit7分別為：

· testFailed 當前時間點故障狀態，0表示沒有檢測到故障，1表示檢測故障。

· testFailedThisOperationCycle 當前操作周期故障狀態，0表示本周期（從本次被喚醒，到進入休眠，一般情況下也可以用車輛上電啟動，到熄火休眠為周期）未檢測到故障，1表示本周期內檢測到故障。

· pendingDTC 當前及上個操作周期故障狀態，0表示上個周期或本周期沒有故障，1表示有。

· confirmedDTC 確認存儲故障狀態，0表示沒有達到存儲觸發條件故障，1表示有。

· testNotCompletedSinceLastClear 上次清除開始故障檢測未完成，0表示完成檢查，1表示未完成。

· testFailedSinceLastClear 上次清除以來檢測已完成，且檢測到故障失敗。0表示未運行檢測或檢測完成但未發現故障。1表示檢測已運行且發現失敗。

· testNotCompletedThisOperationCycle 本操作周期測試未完成，0表示本周期測試完成，1表示本周期測試未完成。

· warningIndicatorRequested 警告指示請求，0表示沒有警告指示，1表示有警告指示。