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

來源 | 鑒源實(shí)驗(yàn)室

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

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

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

1.1 DTC的分類

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

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

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

1.2 UDS DTC

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

圖 1

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

圖 2

實(shí)際上在主機(jī)廠設(shè)計(jì)DTC時具體的故障定義還會參考《SAE J2012DA：2013車輛診斷故障碼定義》。在這個標(biāo)準(zhǔn)定義中將4個系統(tǒng)的故障碼使用范圍進(jìn)行了劃分，大體劃分如下：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進(jìn)制轉(zhuǎn)換為2進(jìn)制后，我們就可以發(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如果主機(jī)廠未使用一般置零。

1.3 DTC狀態(tài)

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

從bit0-bit7分別為：

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

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

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

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

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

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

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

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

02$19服務(wù)

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

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

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

圖 3

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

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

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

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

圖 4

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

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

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

圖 5

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

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

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

03$14服務(wù)

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

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

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

圖 6

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

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

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

圖 7

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

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

04總結(jié)

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

05測試要點(diǎn)

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

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

審核編輯：湯梓紅