基于AUTOSAR軟件架構(gòu)的故障診斷邏輯

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

?

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

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

在設(shè)計(jì)角度，了解故障怎么管理，怎么識(shí)別，怎么處理；

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

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

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

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

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

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

2?ECU故障診斷系統(tǒng)設(shè)計(jì)的若干要點(diǎn)

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

2.1 診斷故障碼DTC

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

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

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

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

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

通訊故障， 比如CAN連不上，CAN報(bào)文丟失等故障。

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

2.1.1 DTC定義

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

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

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

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

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

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

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

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

到此認(rèn)識(shí)了DTC，除此之外還需要了解它的嚴(yán)重程度，因?yàn)椴煌膰?yán)重程度將會(huì)有不同的處理方式。DTC嚴(yán)重程度采用1個(gè)字節(jié)來存儲(chǔ)，它分為A、B、 C、D四個(gè)等級(jí)。比如說A類表示立即維修車輛，B類表示及時(shí)維修車輛，C類表示影響不大，有時(shí)間再維護(hù)，D類表示沒影響。

引自ISO14229

2.1.2 DTC附屬信息

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

1> DTC 狀態(tài)

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

引自ISO14229

常聽說歷史故障和當(dāng)前故障，對(duì)應(yīng)上表，當(dāng)前故障為bit0為1的故障，歷史故障指bit0為0但是bit3為1的故障，DTCStatus = 0x09 表示當(dāng)前故障，即DTCStatus = 0x08 表示歷史故障。

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

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

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

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

張?。浩嚳刂破鳎‥CU）中DTC的狀態(tài)位

2> 快照信息

快照信息就類似照相機(jī)一樣，在故障發(fā)生的時(shí)刻，對(duì)整車信息按下快門，做個(gè)記錄，以便后續(xù)分析問題?？煺招畔⒁话惆?a target="_blank">供電電壓、里程讀數(shù)、點(diǎn)火狀態(tài)、發(fā)動(dòng)機(jī)冷卻液溫度，節(jié)氣門位置，發(fā)動(dòng)機(jī)轉(zhuǎn)速，車速等信息，如下所示。這些會(huì)按規(guī)定的方式保存下來。

引自ISO14229

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

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

引自ISO14229

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

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

2.2 ECU故障診斷機(jī)制

故障診斷包括檢測(cè)，確認(rèn)和處理3個(gè)部分。

2.2.1 故障的檢測(cè)

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

2.2.2 故障的確認(rèn)

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

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

基于時(shí)間的Debouncing算法,引自[1]

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

2.2.3 故障的處理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4 小結(jié)

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

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

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

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

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

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

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

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

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

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

診斷通訊管理模塊Dcm負(fù)責(zé)UDS或OBD服務(wù)請(qǐng)求與發(fā)送管理，即收到AUTOSAR支持的UDS或OBD服務(wù)請(qǐng)求時(shí)，通過調(diào)用Dem，應(yīng)用層軟件組件或其他基礎(chǔ)軟件模塊提供的接口，進(jìn)行相應(yīng)的操作。

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

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

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

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

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

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

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

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

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

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

編輯：黃飛