作者 | 李偉 上海控安安全測評中心安全測評部總監(jiān)

來源 | 鑒源實驗室

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

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

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

1.1 DTC的分類

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

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

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

1.2 UDS DTC

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

圖 1

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

圖 2

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

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

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

1.3 DTC狀態(tài)

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

從bit0-bit7分別為：

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

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

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

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

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

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

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

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

02$19服務(wù)

本文開篇時提到過$19服務(wù)是專門用來配合DTC進行讀取相關(guān)操作的。相對于其他服務(wù)，$19服務(wù)的結(jié)構(gòu)要復(fù)雜得多。

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

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

圖 3

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

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

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

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

圖 4

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

2.2 $19服務(wù)響應(yīng)報文

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

圖 5

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

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

$19服務(wù)的負(fù)響應(yīng)跟第三篇文檔的描述一致，這里不再重復(fù)。

03$14服務(wù)

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

3.1 $14 服務(wù)請求報文

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

圖 6

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

3.2 $14 服務(wù)響應(yīng)報文

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

圖 7

舉例$14的正響應(yīng)報文格式為：$54。

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

04總結(jié)

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

05測試要點

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

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

審核編輯：湯梓紅