曾經(jīng)看到汽車儀表出現(xiàn)故障燈時，總是很好奇想知道這個圖標是什么意思，什么時候會出現(xiàn)，又什么時候會消失。恰好這兩年接觸到了這些知識，有所了解，在此分享給感興趣的朋友。

?

本文將從系統(tǒng)，設計和實現(xiàn)3個角度來介紹汽車控制器（ECU）故障診斷系統(tǒng)：

在系統(tǒng)角度，了解為什么需要故障診斷系統(tǒng)，利用它可以做什么，以及它是什么；

在設計角度，了解故障怎么管理，怎么識別，怎么處理；

在實現(xiàn)角度，了解基于AUTOSAR架構(gòu)的故障診斷系統(tǒng)實現(xiàn)機制。

1 ECU故障診斷系統(tǒng)介紹

汽車上任何一個零件或任何零件間都可能會產(chǎn)生失效，即使失效的概率極低，但沒法保證百分之百不會失效。基于這樣的事實，我們沒辦法阻止，但是盡可能去識別到潛在的失效，這樣才能最大限度去避免傷害。所以，汽車的各個控制器都需要故障診斷系統(tǒng)，去不斷檢測系統(tǒng)、零件等的異常之處，從中找出故障，找出故障后，還希望一方面可以采取臨時補救措施，將傷害減到最小，另一方面，保存故障信息，以供后續(xù)排查和解決故障。因此，基于這樣的需求，完整的ECU故障診斷系統(tǒng)包括車內(nèi)在線診斷系統(tǒng)和車外離線診斷系統(tǒng)兩個部分，將兩者配合使用，就可以進行完整地故障診斷。

其中，車內(nèi)在線診斷系統(tǒng)用于監(jiān)測車內(nèi)部的傳感器，電子控制單元和執(zhí)行器的工作狀態(tài)，并根據(jù)這些數(shù)據(jù)信息自動檢測系統(tǒng)故障，并將以故障碼的形式保存，同時做出相應的故障處理措施，并點亮相對應的故障燈提醒駕駛?cè)藛T。

車外離線診斷系統(tǒng)用于提取已保存的故障信息，通過向車內(nèi)在線診斷系統(tǒng)發(fā)送服務請求（即使用UDS服務）的形式，可進行讀取故障碼信息、清除故障碼和刷寫軟件等操作，完成故障的調(diào)查與維修。

也就是說：當汽車出現(xiàn)故障，車內(nèi)在線診斷系統(tǒng)就應該起作用，最終提醒駕駛員有故障，那駕駛員將汽車返修。維修人員進行查因和維修，就需要使用車外離線診斷系統(tǒng)，查看故障信息、查找原因和更新軟件操作等。

2?ECU故障診斷系統(tǒng)設計的若干要點

為了實現(xiàn)上文的ECU故障診斷系統(tǒng)，同時也為鋪墊下文的ECU故障診斷系統(tǒng)ECU故障診斷系統(tǒng)實現(xiàn)，需要先介紹設計方面的幾個重要知識點，主要包括：診斷故障碼DTC，故障診斷機制和UDS服務。

2.1 診斷故障碼DTC

ECU故障診斷系統(tǒng)檢測的故障主要有五種類型：

機械/系統(tǒng)故障，以變速箱控制器所涉及的故障為例，像擋位執(zhí)行器壞了，離合器壞了等故障；

電子電器故障，比如電磁閥或傳感器短路，電源電壓不在工作范圍等故障；

硬件故障，主要指PCB上的器件故障，比如處理器故障，外圍芯片故障等；

軟件故障，比如死循環(huán)， 除零，溢出等故障；

通訊故障， 比如CAN連不上，CAN報文丟失等故障。

對于這些故障，基于管理和處理方面的考慮，采用診斷故障碼（Diagnostic Trouble Code，DTC）來表示。下面就具體了解DTC的幾個重要概念：

2.1.1 DTC定義

DTC可以說是故障類型的"身份ID"，一個DTC映射一個故障類型（診斷事件）。DTC格式是根據(jù)幾個國際標準協(xié)議來定義的，比如ISO-14229-1，SAE J2012 OBD DTC和SAE J1939-73等。總的來說，DTC分為non OBD和OBD兩種格式，如下所示：

以non OBD為例，DTC包含3個字節(jié)數(shù)據(jù)。其中HighByte和MiddleByte這2個字節(jié)表示故障內(nèi)碼，對應5位標準故障碼（第一位是字母，后四位是數(shù)字）。

前兩位用來區(qū)分故障來自的控制系統(tǒng), 是系統(tǒng)代碼，比如B0-B3 是用在車身控制系統(tǒng)，C0-C3 是用在底盤控制系統(tǒng)，P0-P3是用在發(fā)動機控制系統(tǒng)，U0-U3 是用在通訊故障；

第三位是數(shù)字，表示表示故障所屬的子系統(tǒng)碼；

最后兩位數(shù)字提供故障的對象和類型。

比如"P080081"這個故障碼中，故障內(nèi)碼為"P0800"，其中“P08”代表動力系統(tǒng)的傳動系統(tǒng)控制故障，“00”代表傳感器。

LowByte這個字節(jié)表示Failure Type，包含F(xiàn)ailure category和Failure Sub Type兩個部分，具體可參考SAE J2012-DA，比如常見的timeout應該用0x87，信號無效應該為0x81等等；而對于OBD相關(guān)的ECU的DTC最低字位均為0x00。

接著"P080081"這個故障碼，“P08”代表動力系統(tǒng)的傳動系統(tǒng)控制故障，“00”代表傳感器，“81”代表信號無效，所以這個DTC代表就是動力系統(tǒng)的傳動系統(tǒng)控制的傳感器信號無效。

到此認識了DTC，除此之外還需要了解它的嚴重程度，因為不同的嚴重程度將會有不同的處理方式。DTC嚴重程度采用1個字節(jié)來存儲，它分為A、B、 C、D四個等級。比如說A類表示立即維修車輛，B類表示及時維修車輛，C類表示影響不大，有時間再維護，D類表示沒影響。

引自ISO14229

2.1.2 DTC附屬信息

根據(jù)上述DTC的定義，我們可以知道是什么故障以及故障是否嚴重，但這不能清晰得知故障什么時候發(fā)生的，什么原因?qū)е掳l(fā)生的，因此還需要DTC的關(guān)鍵信息，比如DTC狀態(tài)（DTC status）、DTC快照信息（Snapshot）和DTC擴展數(shù)據(jù)信息(Extended data)。只有存儲下了這些關(guān)鍵信息，才能助于故障的解決。

1> DTC 狀態(tài)

先看DTC狀態(tài)，用1個字節(jié)來存儲，其8個bit分別代表為：

引自ISO14229

常聽說歷史故障和當前故障，對應上表，當前故障為bit0為1的故障，歷史故障指bit0為0但是bit3為1的故障，DTCStatus = 0x09 表示當前故障，即DTCStatus = 0x08 表示歷史故障。

歷史故障是過去發(fā)生但當前還沒有清除的故障碼。歷史故障產(chǎn)生的原因有兩種情況，一種是故障己經(jīng)排除，只是未清除故障碼，此代碼清除后，故障就不會再次發(fā)生；另一種是故障并未排除，只是當前沒有發(fā)生，此代碼清除后，當故障再次發(fā)生時，故障還會出現(xiàn)。

當前故障是正發(fā)生的故障產(chǎn)生的故障碼。當前故障是確實存在的故障引起的，它屬于持續(xù)性故障產(chǎn)生的故障碼，它不會被清除。

當前故障是當前確實存在的故障，比較容易判斷。而歷史故障比較難于判斷，因為它是曾經(jīng)發(fā)生的故障而現(xiàn)在沒有，重現(xiàn)故障產(chǎn)生的狀態(tài)，可能需要很長時間來捕捉歷史故障碼的重現(xiàn)，或者需要人為的創(chuàng)造可重現(xiàn)故障的條件，如加熱、振動等，同時需要較好的設備來捕捉故障出現(xiàn)瞬間各種數(shù)據(jù)參數(shù)的變化才行。因此，一般先解決當前故障，而對于歷史故障暫時作為故障診斷的參考。

以上就是通常當前故障和歷史故障對DTC狀態(tài)的說明，關(guān)于8個bit對應的具體狀態(tài)解析，可參考ISO14229 或

張丁：汽車控制器（ECU）中DTC的狀態(tài)位

2> 快照信息

快照信息就類似照相機一樣，在故障發(fā)生的時刻，對整車信息按下快門，做個記錄，以便后續(xù)分析問題。快照信息一般包括供電電壓、里程讀數(shù)、點火狀態(tài)、發(fā)動機冷卻液溫度，節(jié)氣門位置，發(fā)動機轉(zhuǎn)速，車速等信息，如下所示。這些會按規(guī)定的方式保存下來。

引自ISO14229

3> 擴展數(shù)據(jù)

擴展數(shù)據(jù)信息是一組提供DTC相關(guān)擴展狀態(tài)信息的數(shù)據(jù)組，包括故障出現(xiàn)計數(shù)器、故障待定計數(shù)器、已老去計數(shù)器和老化計數(shù)器等，這些信息的具體內(nèi)容一般都由客戶來定義。如下示意：

引自ISO14229

以上就是DTC相關(guān)的幾個重要概念，這樣就可以知道故障是什么，也可以得到該故障的附件信息。

DTC的這些內(nèi)容設計要么是根據(jù)標準協(xié)議，要么是根據(jù)客戶的特定需求，不管是哪種形式，一般都是以需求形式要求實現(xiàn)方實現(xiàn)。當然，除了這些內(nèi)容會作為需求的一部分，接下來要介紹的故障診斷機制內(nèi)容也會作為需求的另一部分。

2.2 ECU故障診斷機制

故障診斷包括檢測，確認和處理3個部分。

2.2.1 故障的檢測

故障的檢測是由車內(nèi)在線診斷系統(tǒng)來執(zhí)行，先通過ECU內(nèi)部軟硬件功能模塊實現(xiàn)自我診斷，對故障的檢測分兩步：先看檢測故障的前提條件，即什么時候或情況需要去檢測某一種故障。比如電磁閥關(guān)閉時，若檢測電磁閥有無堵塞故障，是不合理也不需要的，但電磁閥已開啟，則檢測有必要。再看檢測故障的判斷條件，即通過怎樣的邏輯去識別某一種故障。比如電磁閥已打開，但監(jiān)測通過電磁閥的流量非常小，那么懷疑是電磁閥堵塞故障。

2.2.2 故障的確認

故障的確認是指上述檢測到“故障”出現(xiàn)多少次或多長時間才算是真正的故障。因為有時可能只是某個信號極其偶爾波動一下，而這種波動對汽車沒有影響，這時如果識別為故障，那么就過敏感了，反而會給駕駛員帶來困擾。因此，為了規(guī)避這樣的情況也被識別為故障，那么就提出了debouncing的概念，即通過一次次數(shù)或時間的累加，才能確認是否出現(xiàn)了真正的故障。只有當“故障”出現(xiàn)次數(shù)或時間累加到一定的值，才確認故障。當前常用Debouncing算法有基于計數(shù)器和基于時間兩類，如下所示：

基于計數(shù)器的Debouncing算法，引自[1]

基于時間的Debouncing算法,引自[1]

總的來說，Debouncing算法原理是：根據(jù)檢測到“故障”狀態(tài)（PREFAILED, FAILED, PREPASSED, PASSED）來增減計數(shù)器或定時器，只有次數(shù)或時間達到閾值，才能確認或消除故障。如上圖所示，當報告的狀態(tài)是PREFAILED時，計數(shù)器或定時器就累加一次；當累加次數(shù)或時間到Failed的域值，那么“故障”就被確認。這里會涉及的一些參數(shù)需要定義清楚，因此為這些參數(shù)將會決定故障需要多長時間確認或恢復，像圖中所示的步長和閾值等。比如對于某個故障的確認時間為200ms，計數(shù)器每5ms計數(shù)一次，假設設定閾值為40，報告狀態(tài)切換時，計數(shù)器總是從0開始計數(shù)，那么這時針對故障確認的固定步長設置為1。總之，不同Debouncing算法的細節(jié)處理會不同，可根據(jù)實際診斷需求選擇適合的Debouncing算法。

2.2.3 故障的處理

當故障被確認，那么車內(nèi)在線診斷系統(tǒng)一方面將故障碼DTC及相關(guān)數(shù)據(jù)存入ECU內(nèi)部的非易失存儲器內(nèi)；另一方面將對故障進行處理，主要包括點燈策略和故障處理策略。其中，點燈策略是指根據(jù)故障的嚴重程度決定是否點亮故障指示燈以及點亮何種顏色，以此警示駕駛員故障的存在，而故障處理策略是指根據(jù)故障的嚴重程度決定做怎樣的臨時處理措施。比如出現(xiàn)了變速箱高檔位損壞故障，那么這時點黃燈，顯示變速箱故障，同時限制汽車行駛速度，采用跛行回家模式；或者出現(xiàn)了車窗無法下降故障，那么這時不點燈，此時也不會對汽車行駛有任何限制。

車輛行駛過程中，通過上述機制就可以由車內(nèi)診斷診斷系統(tǒng)實時監(jiān)控ECU各部分的工作狀態(tài)，從而檢測出故障。

2.3 統(tǒng)一診斷服務UDS

上述的故障碼DTC及相關(guān)數(shù)據(jù)存入ECU內(nèi)部的非易失存儲器后，要怎么獲取呢？這就涉及到車外離線診斷系統(tǒng)，需要使用到統(tǒng)一診斷服務（Unified Diagnostic Services，UDS），當然涉及排放會使用到OBD服務，這里僅介紹UDS服務。UDS服務是診斷服務的規(guī)范化標準，規(guī)定了讀取DTC的指令，讀診斷數(shù)據(jù)流的指令等。

先看一個使用UDS服務的例子：假如車窗系統(tǒng)出現(xiàn)故障，則維修人員需要先使用UDS讀寫服務去獲取軟、硬件版本號，供電電壓等，以獲取一些最基本的信息；再使用UDS服務查看DTC相關(guān)信息，了解具體出現(xiàn)了什么故障，比如出現(xiàn)電機故障，那可以使用UDS例程控制服務去控制開啟電機。當發(fā)現(xiàn)這個故障在舊版本的軟件都存在，新版本的軟件已經(jīng)修復了這些故障，那么使用UDS刷寫服務更新軟件。當然這個過程所使用的這些UDS服務都是通過診斷設備發(fā)送的，所使用到的服務如下示意。

總的來說，按功能劃分，UDS服務可分為6類，共26種服務，分別是：

1）診斷和通信管理功能單元，包括10，11，27，28，3E，83，84，85，86，87共10種服務；

2）數(shù)據(jù)傳輸功能單元，包括22，23，24，2A，2C，2E，3D共7種服務；

3）存儲數(shù)據(jù)傳輸功能單元，包括14，19共2種服務；

4）輸入輸出控制功能單元，包括2F服務；

5）例行程序功能單元，包括31服務；

6）上傳下載控制功能單元，包括34，35，36，37，38共5種服務。

這些UDS服務的層次關(guān)系是：首先是確定在什么診斷會話模式（$10），即是默認會話，還是擴展會話，還是編程會話；在此基礎上，再明確是否需要使用安全訪問服務（$27）解鎖，有些功能服務需要通過該服務解鎖才能使用，有些則不需要考慮該服務；最后才能實現(xiàn)具體的服務控制。

關(guān)于UDS服務的具體介紹，可參考我的專欄：汽車ECU軟件開發(fā)的UDS協(xié)議詳解系列（點擊進入）。

2.4 小結(jié)

回顧上述本節(jié)內(nèi)容的介紹可知，車內(nèi)在線診斷系統(tǒng)負責故障的檢測，確認和處理，以及存儲故障信息到ECU的非易失性存儲器。車外離線診斷系統(tǒng)則通過UDS服務查詢DTC及其相關(guān)信息，消除故障和更新軟件。

3 基于AUTOSAR的ECU故障診斷系統(tǒng)

為了進一步了解ECU故障診斷系統(tǒng)，可在軟件層面進一步了解其如何實現(xiàn)。對于AUTOSAR軟件架構(gòu)，故障診斷既會在底層軟件BSW實施，也會在應用層軟件ASW實施，具體看如何定義兩者的邊界。

基于AUTOSAR的軟件架構(gòu)

3.1 基于AUTOSAR架構(gòu)的故障診斷系統(tǒng)介紹

下面來了解下基于AUTOSAR架構(gòu)的故障診斷系統(tǒng)，如下所示：

基于AUTOSAR架構(gòu)的故障診斷系統(tǒng)，，引自[1]

診斷事件管理模塊Dem負責對故障診斷、處理、保存和管理。比如Dem通過NvM提供的接口訪問非易失存儲器，讀取和保存故障信息。同時Dem向Dcm提供訪問故障數(shù)據(jù)的接口，如讀故障碼，清楚故障碼等操作。

應用層SW-C監(jiān)控函數(shù)Monitor負責故障的檢測，也可能包括確認，SW-C通過接口函數(shù)Dem_SetEventStatus將診斷結(jié)果報告給Dem。如果監(jiān)控函數(shù)Monitor包含Debouncing算法，即應用層能確認故障，那么SW-C給Dem報告診斷結(jié)果是DEM_EVENT_STATUS_PASSED或DEM_EVENT_STATUS_FALIED，即Dem接收確認故障。否則SW-C傳遞給Dem的診斷結(jié)果為DEM_EVENT_STATUS_PREPASSED或DEM_EVENT_STATUS_PREFALIED，即需要在底層軟件確認故障。

底層SW-C監(jiān)控函數(shù)Monitor負責診斷像NvM讀寫失敗，或排隊任務數(shù)溢出，或校驗錯誤等類型故障，該類故障通常不需要使用Debouncing算法進行確認，故障狀態(tài)只有2種，即DEM_EVENT_STATUS_FAILED或DEM_EVENT_STATUS_PASSED，SW-C也是通過接口函數(shù)Dem_ReportErrorStatus將診斷結(jié)果報告給Dem。

診斷通訊管理模塊Dcm負責UDS或OBD服務請求與發(fā)送管理，即收到AUTOSAR支持的UDS或OBD服務請求時，通過調(diào)用Dem，應用層軟件組件或其他基礎軟件模塊提供的接口，進行相應的操作。

NvM是指非易失性存儲管理模塊，管理非易失性數(shù)據(jù)的存儲和維護。當Dem確認到故障，Dem調(diào)用NvM的寫函數(shù)，把故障信息和發(fā)生故障時的環(huán)境數(shù)據(jù)寫入到NvM。當Dem要查詢故障信息，Dem調(diào)用NvM的讀函數(shù)，從NvM中，讀取故障信息和發(fā)生故障時的環(huán)境數(shù)據(jù)。

EcuM模塊負責調(diào)用相關(guān)函數(shù)對Dem初始化，包括初始化每個故障的debounce狀態(tài)，Dem存儲的故障數(shù)據(jù)。

FiM模塊是為SW-C提供一個控制機制，即使能或抑制SW-C功能。比如當故障確認后，可以通過FiM抑制一些與此故障相關(guān)的SW-C功能，像抑制了檢測速度的SW-C功能，那就意味著基于速度來檢測故障的前提條件就無法滿意，相應地此類故障都將無法診斷。

SW-C除了監(jiān)控函數(shù)，還有針對故障發(fā)生后的臨時故障處理函數(shù)，比如以變速箱控制器來說，檢測到某個檔位無法使用，可能決定采用跛行回家，或者打開離合器中斷動力等處理方式；也有故障指示燈的控制函數(shù)，一方面故障出現(xiàn)時點亮故障指示燈的控制，另一方面是故障被維修處理或因故障自愈而進行消去故障指示燈的控制。

3.2 基于AUTOSAR架構(gòu)的故障診斷系統(tǒng)運行邏輯實例

假設有這樣一個案例：駕駛員在行駛過程中看到儀表出現(xiàn)了發(fā)動機方面的故障，然后導致車輛動力中斷，進而不能繼續(xù)行駛。經(jīng)查該故障為控制節(jié)氣門的電磁閥短路到地，導致該電磁閥無法開啟，而這個電磁閥采用高邊驅(qū)動的控制方式，高邊驅(qū)動有反饋電流到控制器，開啟工作時會反饋高電平，短路到地則會反饋低電平。

這里對于該故障的檢測定義在ASW的SW-C模塊，如下圖所示。也就是說，在這里的Monitor模塊將先有函數(shù)去判斷是否需要檢測節(jié)氣門的電磁閥故障，比如發(fā)動機熄火的時候可能就不需要檢測，而發(fā)動機啟動則需要；當需要檢測時，就有函數(shù)去判斷是否出現(xiàn)節(jié)氣門的電磁閥故障，對于短路到地故障，就會通過條件之一的反饋電流來判斷，如果反饋電流為高電平，則不會檢測到短路到地，否則，就有可能。當有可能但還不足以確認時，那么可以采用debouncing算法，通過基于計數(shù)或計時的方法來確認。

一旦故障確認，Monitor調(diào)用接口函數(shù)Dem_ReportErrorStatus向Dem報告DEM_EVENT_STATUS_FAILED。接著Dem模塊就會與相關(guān)功能模塊交互，像上文提到存儲故障數(shù)據(jù)信息，傳遞故障信息給ASW故障處理SW-C模塊等操作。

對于控制節(jié)氣門的電磁閥短路到地，電磁閥無法開啟，這意味著供油中斷，那么一方面SW-C模塊的相關(guān)函數(shù)將給出發(fā)動機熄火命令，同時通知其他控制器中斷動力，比如請求變速箱打開離合，掛空擋操作等處理措施；另一方面SW-C模塊的相關(guān)函數(shù)發(fā)出點亮發(fā)動機故障燈命令，要求靠邊停車提醒。

當故障車輛到維修車間，維修人員將使用測試儀器，查詢故障信息。比如，使用19服務獲取電磁閥短路得到這個DTC相關(guān)信息，這時Dcm模塊的19服務映射的函數(shù)將調(diào)用Dem提供的接口函數(shù)，通過這些函數(shù)獲取DTC相關(guān)信息。類似的邏輯，可以通過14服務清楚故障。

編輯：黃飛