作者 | 李偉 上?？匕舶踩珳y評中心安全測評部總監(jiān)

來源 | 鑒源實驗室

01DTC-Diagnostic Trouble Code(診斷故障代碼)

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

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

1.1 DTC的分類

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

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

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

1.2 UDS DTC

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

圖 1

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

圖 2

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

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

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

1.3 DTC狀態(tài)

DTC status狀態(tài)碼是用來表明故障在指定時間上是否存在，以及故障測試狀態(tài)情況的?？偣?個字節(jié)表示8種不同的判斷條件。ISO14229附錄D有詳細描述。

從bit0-bit7分別為：

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

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

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

· confirmedDTC 確認存儲故障狀態(tài)，0表示沒有達到存儲觸發(fā)條件故障，1表示有。

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

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

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

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

02$19服務

本文開篇時提到過$19服務是專門用來配合DTC進行讀取相關操作的。相對于其他服務，$19服務的結構要復雜得多。

2.1 $19服務發(fā)送報文

服務發(fā)送報文第1部分為SID即$19;第2部分為subfunction子功能段，ISO14229規(guī)范定義中$19服務是比較復雜的，其subfunction項有31種不同定義，包含了ISO組織預留字段，因此$19服務的發(fā)送報文幀結構比之前我們分享的其他服務要復雜的多;第3和第4段參數(shù)部分對應于報文第2段subfunction的不同而各不一樣，發(fā)送報文總體結構如下圖：

圖 3

對應于標準規(guī)范定義發(fā)送報文第2字段子功能分類，配合第3和第4段，$19服務的發(fā)送報文從總體上在規(guī)范中有13種不同格式。在具體項目中均是根據(jù)實際需要選取幾種進行設計，因此測試過程中對于項目診斷規(guī)范的熟悉非常重要。

我們前文講述的DTCStatusMask即在參數(shù)字段中，還包括DTCMaskRecord、DTCSeverityMask，以及快照相關的其他參數(shù)項，規(guī)范大約定義了9種不同參數(shù)來配套不同的子功能項實現(xiàn)不同功能。

我們舉例使用$19 01 01，第2字段子功能01，該subfunction功能為根據(jù)DTC掩碼上報檢測的DTC故障數(shù)量。對應于第2段子功能為01，第3段標準定義要求DTC狀態(tài)和DTC掩碼對應狀態(tài)全為“1”時進行匹配，即當前周期的故障檢測狀態(tài)。綜合上面的描述我們可以知道$19 01 01讀取了當前周期內DTC故障的數(shù)量個數(shù)。

跟子功能01類似要求的需要DTC狀態(tài)掩碼配合使用的子功能還有0x02、0x0F、0x11等，其服務發(fā)送報文架構如下圖所示：

圖 4

其他子功能還有參數(shù)配合使用的情況，我們需要根據(jù)診斷規(guī)范定義具體情況具體分析。

2.2 $19服務響應報文

$19服務的響應報文格式總體與第三篇文檔的描述一致。正響應報文的服務號為$59，第2字節(jié)對應請求報文的子功能號。第3字段開始跟其他服務有所區(qū)別，本段響應報文的參數(shù)跟請求報文的邏輯一樣，字段參數(shù)跟第2字段的子功能是對應的。響應幀的總體結構圖如下所示：

圖 5

舉例上文$19服務的響應報文為：$59 01 01 01 00 01，響應報文第1、2字段對應請求報文SID19和子功能01;對于第2字段子功能為01，響應報文第3字段為參數(shù)DTCStatusAvailabilityMask;第4字段為參數(shù)DTCFormatIdentifier，這個參數(shù)即前文我們提到的DTCFID;第5、6字段為請求報文要求的上報DTC本周期故障數(shù)量為1個。對于每個參數(shù)的預置值定義，產品診斷規(guī)范中在每個子功能的參數(shù)定義中均有詳細描述。

對應于請求報文的不同子服務格式有十幾種，也會有每種分類的響應報文進行對應。

$19服務的負響應跟第三篇文檔的描述一致，這里不再重復。

03$14服務

$14服務跟$19服務是配套進行使用的，本服務的作用是清除診斷信息。在進行DTC相關測試時，會使用本服務執(zhí)行清除工作，確保DTC的狀態(tài)不影響測試結果。

3.1 $14 服務請求報文

$14服務請求報文相對比較簡單，本服務的請求報文無子功能，只有唯一參數(shù)為groupOfDTC，對于參數(shù)的定義，可以參考ISO14229的附錄相關內容，對于項目中的實際定義大家一定要仔細閱讀項目診斷規(guī)范。發(fā)送報文幀結構如下圖：

圖 6

在實際測試過程中我們用的比較多的是全部清除，舉例$14服務的全部清除請求報文為：$14 FF FF FF。

3.2 $14 服務響應報文

$14服務的正響應報文格式非常簡單，就一個字節(jié)SID服務自己$54。響應報文幀的結構圖如下所示：

圖 7

舉例$14的正響應報文格式為：$54。

負響應的報文格式可以參考第三篇的相關章節(jié)，負響應NRC代碼表一般在項目中是通用的。

04總結

DTC是配合$19和$14服務來使用的，DTC故障代碼表的所有故障代碼我們要進行遍歷測試，所以環(huán)境的搭建會花費大量的時間，需要準備其他的測試配合零部件。每個故障測試前都需要使用$14服務將已存儲的DTC清除并確認已清除成功，才能制造DTC對應的故障，并通過$19服務來讀取來確認制造的故障被設備識別，并遵循記錄規(guī)則進行了對應的存儲。

05測試要點

在執(zhí)行DTC的測試前必須和診斷設計系統(tǒng)工程師和DRE確認，DTC表中的所有故障如何在測試環(huán)境制造出來，且可以被設備檢測出來。設備檢測上報DTC有一定的過濾條件，即使是同一個故障，哪怕我們在試驗環(huán)境下制造并觀察到故障已出現(xiàn)，在觸發(fā)條件沒有達到時，設備也檢測不到，讀取不到對應的DTC。

在制造一些短路故障前一定要跟DRE或者硬件工程師確認，測試操作不會燒毀相關電路或電容。

審核編輯：湯梓紅