一篇易懂的ECU故障診斷指南

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

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

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

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

• 在實現角度，了解基于AUTOSAR架構的故障診斷系統實現機制。

1、ECU故障診斷系統介紹

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

其中，車內在線診斷系統用于監測車內部的傳感器，電子控制單元和執行器的工作狀態，并根據這些數據信息自動檢測系統故障，并將以故障碼的形式保存，同時做出相應的故障處理措施，并點亮相對應的故障燈提醒駕駛人員。

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

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

2、ECU故障診斷系統設計的若干要點

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

2.1 診斷故障碼DTC

ECU故障診斷系統檢測的故障主要有五種類型：

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

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

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

• 軟件故障，比如死循環，除零，溢出等故障；

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

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

2.1.1 DTC定義

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

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

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

• 第三位是數字，表示表示故障所屬的子系統碼；

• 最后兩位數字提供故障的對象和類型。

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

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

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

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

引自ISO14229

2.1.2 DTC附屬信息

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

1> DTC 狀態

先看DTC狀態，用1個字節來存儲，其8個bit分別代表為：

引自ISO14229

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

• 歷史故障是過去發生但當前還沒有清除的故障碼。歷史故障產生的原因有兩種情況，一種是故障己經排除，只是未清除故障碼，此代碼清除后，故障就不會再次發生；另一種是故障并未排除，只是當前沒有發生，此代碼清除后，當故障再次發生時，故障還會出現。

• 當前故障是正發生的故障產生的故障碼。當前故障是確實存在的故障引起的，它屬于持續性故障產生的故障碼，它不會被清除。

當前故障是當前確實存在的故障，比較容易判斷。而歷史故障比較難于判斷，因為它是曾經發生的故障而現在沒有，重現故障產生的狀態，可能需要很長時間來捕捉歷史故障碼的重現，或者需要人為的創造可重現故障的條件，如加熱、振動等，同時需要較好的設備來捕捉故障出現瞬間各種數據參數的變化才行。因此，一般先解決當前故障，而對于歷史故障暫時作為故障診斷的參考。 以上就是通常當前故障和歷史故障對DTC狀態的說明。

2> 快照信息

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

引自ISO14229

3> 擴展數據

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

引自ISO14229

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

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

2.2 ECU故障診斷機制

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

2.2.1 故障的檢測

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

2.2.2 故障的確認

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

基于計數器的Debouncing算法，引自[1]

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

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

2.2.3 故障的處理

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

車輛行駛過程中，通過上述機制就可以由車內診斷診斷系統實時監控ECU各部分的工作狀態，從而檢測出故障。

2.3 統一診斷服務UDS

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

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

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

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

• 數據傳輸功能單元，包括22，23，24，2A，2C，2E，3D共7種服務；

• 存儲數據傳輸功能單元，包括14，19共2種服務；

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

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

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

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

2.4 小結

車內在線診斷系統負責故障的檢測、確認、處理以及存儲故障信息到ECU的非易失性存儲器。車外離線診斷系統則通過UDS服務查詢DTC及其相關信息，消除故障和更新軟件。

3、基于AUTOSAR的ECU故障診斷系統

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

基于AUTOSAR的軟件架構

3.1 基于AUTOSAR架構的故障診斷系統介紹

下面來了解下基于AUTOSAR架構的故障診斷系統，如下所示：

基于AUTOSAR架構的故障診斷系統，引自[1]

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

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

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

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

NvM是指非易失性存儲管理模塊，管理非易失性數據的存儲和維護。當Dem確認到故障，Dem調用NvM的寫函數，把故障信息和發生故障時的環境數據寫入到NvM。當Dem要查詢故障信息，Dem調用NvM的讀函數，從NvM中，讀取故障信息和發生故障時的環境數據。

EcuM模塊負責調用相關函數對Dem初始化，包括初始化每個故障的debounce狀態，Dem存儲的故障數據。

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

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

3.2 基于AUTOSAR架構的故障診斷系統運行邏輯實例

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

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

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

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

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

以上就是一個非常非常簡化的基于AUTOSAR軟件架構的故障診斷邏輯，若想更深入地從代碼函數層面了解，可進一步參考AUTOSAR官方提供的相關文檔。

參考資料:

[1] Specification of Diagnostic Event Manager

[2] AUTOSAR_SRS_FunctionInhibitionManager

[3] AUTOSAR_SWS_NVRAMManager

[4] AUTOSAR_SWS_SAEJ1939 DiagnosticCommunicationManager

[5] 基于AUTOSAR的汽車故障診斷系統的設計與實現，碩士論文

來自糊涂振 北京市高級別自動駕駛示范區公眾號