DTC基本介紹

DTC顧名思義即為診斷故障碼，一種用來記錄當某ECU發生或檢測到某種故障時所呈現在大家目前的標識碼，通過該標識碼便可以查表的方式獲得該故障信息，如故障觸發條件、故障解除條件、系統功能表現等。這是當前供應商與主機廠普遍用來監測并識別故障的基礎手段，所以也同樣存在標準，普遍使用的標準是ISO15031-6，該標準中規定了DTC的基本組成，DTC如何命名等信息。

DTC基本組成

根據上述ISO標準，DTC由以下兩個部分組成：DTC Catogory 與Failure Type，其中DTC Catogory 又可以根據Powertrain、Body、Chasis、N etwork四大子系統來進一步定義其范圍，簡稱PBCU四大子系統，如下表1-1所示：

1-1 DTC Catogory 范圍定義

在上表中可以看到每個子系統都劃分為4個子范圍，如B0-B3，C0-C3，P0-P3，U0-U3；其中值得注意的是B0、C0、P0、P2、P3、U0、U3這幾個子范圍被ISO預留以供未來使用，因此嚴格來說，現在很多供應商定義的DTC不符合規定，但一般來說不影響使用。接下來，我們就來看一下該DTC Catogory 占用的每個bi t的具體說明，如下圖1-2所示：

1-2 DTC Catogory Bit定義

圖中標號1表示后12bit大小范圍可以為000-FFF；標號2表示對于動力系統而言，如00，10都是ISO／SAE特殊定義的范圍；標號3則表示對于動力系統而言，即便定義為11，可以被供應商或主機廠自定義的范圍為P3000-P33FF，而P3400-P3FFF則已被ISO／SAE預先定義。了解了ISO對于DTC C atogory的定義之后，接下來看個具體實例1-3：

1-3 3字節DTC基本組成

正如我們經常在客戶診斷調查表見到的P（00）、C（01）、B（10）、U（11）來實現我們所說的DTC診斷顯示碼（PBCU開頭碼）與日常使用的3字節DTC轉換 關系，實際上只需要將PBCU四個子系統對應的bit組合關系替換進去，便可以得到我們常說的DTC，這點很多小伙伴可能都會有誤區，特此說明一下。 其中上圖所示的低字節就是我剛剛說到的Failure Type，該Failure Type也不是隨意填寫，ISO都有規定，如常見的timeout應該用0x87，信號無效應該為0x81等等，該字節如何定義需要參考ISO15031-6并找到對應的故障單元來選擇，值得注意的是：一般對于排放相關的ECU的DTC最低字位均為00，而對于非排放相關的ECU則需要參考ISO標準來定義。 上述四大故障基本上涵蓋了所有ECU所用到的DTC故障類型，這對于我們設計一款新的ECU產品將會有一些指導作用。 聯系：

DTC故障類型

以非排放相關的ECU為例，可以將DTC故障類型分為以下幾個部分：

硬件故障；如RAM、Flash、CPU時鐘等硬件本身失效的問題

軟件故障；如配置字故障，標定故障或客戶定義的軟件功能性故障

外部環境故障；電壓過高或者欠壓、環境溫度過高或過低等

通訊相關故障；如報文丟失、信號無效，Checksum/AliveCounter故障等

DTC與event區別與聯系 區別：

DTC是某類故障的統稱，能夠大體定位到某個模塊的故障，而event則是故障監控的基本單元，能夠定位某個模塊中的某個具體故障；

多個event可以mapping 同一個DTC；而同一個event不能mapping 多個DTC；

DTC可以直接可見，但Event需通過進一步手段才能看到，有時僅對ECU供應商可見；

DTC代表某類event集中表現，而event則是某個DTC的具體實例；

event的優先級決定了DTC的優先級；

event之間的依賴關系決定了DTC的依賴關系；

DTC的狀態位是其map的所有event的狀態位的或集；

2. DTC狀態位

當出現DTC時，我們只知道有故障發生了這一個基本事實，但是并不知道該故障什么時候發生，現在是否已經恢復、發生過幾次，恢復過幾次等細節性信息，因此國際標準組織ISO發布14229-1來引入DTC狀態位這一概念來得到上述細節性信息，使我們對該故障的生前生后有個清晰的認識，便于我們快速定位問題所在。每一個DTC均有對應的DTC狀態位，該DTC狀態位由一個字節表示，每個bit都有其重要含義，具體解釋如下圖2所示：

圖2 DTC Status bit 具體解釋如下：

Bit0： 請求時刻測試結果為失敗；

Bit1： 在當前點火循環至少失敗過1次；

Bit2： 在當前或者上一個點火循環測試結果不為失敗；

Bit3： 請求時刻DTC被確認，一般確認是在一個點火周期內發生錯誤1次；

Bit4： 自上次清除DTC之后測試結果已完成，即測試結果為PASS或者FAIL結果；

Bit5： 自上次清除DTC后測試結果都不是FAIL;

Bit6： 在當前點火周期內測試結果已完成，即為PASS或FAIL狀態；

Bit7： ECU沒有得到點亮警示燈請求；

相應的為了讓大家對每一個bit的動態變化有個更為深刻的理解，結合最新版ISO14229-1 2020分別對每個bit的動態變化展示如下：Bit 0：

Bit 1：

Bit 2：

Bit 3：

Bit 4：

Bit 5：

Bit 6：

Bit 7

對于上述每一個Bit變化的前提條件大家可以參考官方文檔細細評味，這樣才能印象深刻，在這里就不贅述了。 3. DTC信息存儲 事實上當DTC產生時，并不會直接存儲在NVM中，而是直接存儲故障e event的方式，然后間接通過event-DTC的mapping關系來存儲DTC，而DTC的狀態位則是由其mapping的所有event的狀態位的或集，如下圖3-1所示。大多數情況下光有DTC號以及狀態位信息往往不能一步到位定位root cause，需要引入環境信息才能夠進一步確定問題所在，因此ISO組織便引入了以下兩個基本概念：快照數據（Snapshot Data）、擴展數據（Extended Data）。

If Event 1 -》 DTC A; Event 2 -》 DTC A; 。.. Event N -》 DTC A;

Then DTC A Status = Event 1 Status | Event2 Status | 。..| Event N;

DTC A 同時Map了Event 1 ～ Event N，則DTC A Status即為上述map的或集，但是具體是哪個event先報，則取決于event之間的優先級以及上報策略來綜合判斷。 Snapshot Data：顧名思義快照信息即為故障發生時刻存下來的瞬態的環境數據，一般是指電源模式、溫度、時間戳、車速等信息。 Extended Data：即為在故障發生時其他的輔助故障信息，如aging counter、aged counter 、Fault Counter以及event id等。 另外，對于DTC信息存儲一般簡單理解可以分為兩部分存儲空間，該劃分更多的是邏輯意義上的定義，這樣區分的意義在于能夠更好的實現主機廠與供應商的信息隔離，防止出現不必要的誤解與多余信息的討論。 Primary Memory：對主機廠以及ECU供應商可見的DTC信息空間，如DTC Status、Snapshot Data、Extended Data等； Second Memory：僅ECU供應商內部可見的信息，如event ID、ITC等信息。 限于主題，所以NVM信息存儲點到為止，后續關于NVM信息存儲的機制會通過專題與大家一起分享學習。 4. DTC信息及狀態讀取 DTC會在ECU運行過程中產生、變化并被實時記錄下來，對于ECU供應商或者主機廠則可以通過診斷服務的方式來實現DTC信息及狀態位的讀取，如下圖4所示，通過以下幾種方式便可以得到ECU支持的DTC、當前或歷史DTC、Snapshot Data、Extended Data ，DTC status等信息。

圖4 DTC信息診斷獲取方式

審核編輯：郭婷