柴油機(jī)SCR系統(tǒng)故障診斷軟件的開發(fā)與應(yīng)用

李捷輝，袁利娜，王名傳，余 青

（江蘇大學(xué)汽車與交通工程學(xué)院，江蘇 鎮(zhèn) 江 212013）

2008年國家環(huán)境保護(hù)部發(fā)布了《車用壓燃式、氣體燃料點(diǎn)燃式發(fā)動機(jī)與汽車車載診斷系統(tǒng)（OBD）技術(shù)要求》。按規(guī)定，所有達(dá)到GB 17691中第Ⅳ階段排放水平的柴油機(jī)或裝用柴油機(jī)的汽車應(yīng)配備OBD系統(tǒng)，并按照OBD－Ⅰ／OBD－Ⅱ階段及確保NOx排放控制措施正確工作的要求來設(shè)計(jì)、安裝、生產(chǎn)發(fā)動機(jī)和車輛［1］。

選擇性催化還原（SCR）技術(shù)是目前我國重型柴油機(jī)達(dá)到國Ⅳ階段排放標(biāo)準(zhǔn)的最佳選擇。當(dāng)SCR系統(tǒng)中出現(xiàn)零部件不正常工作或失效時(shí)，排放就會惡化甚至超標(biāo)，OBD系統(tǒng)通過實(shí)時(shí)監(jiān)測與排放相關(guān)的零部件，指示出導(dǎo)致排放超標(biāo)的相關(guān)部件。

配合OBD系統(tǒng)使用的診斷類型大致有兩種：診斷儀和診斷軟件。診斷儀一般僅限于故障碼與數(shù)據(jù)的檢測提取，不具備分析和判斷故障原因與故障部位的功能；診斷軟件大都與標(biāo)定軟件集成一體，軟件系統(tǒng)龐大，價(jià)格昂貴，不適用于車輛的日常保養(yǎng)和檢修。當(dāng)前針對柴油機(jī)獨(dú)立的故障診斷系統(tǒng)并不多見，因此，本研究針對帶有OBD功能的柴油機(jī)SCR系統(tǒng)，選用Visual C＋＋6.0開發(fā)工具和Microsoft Access數(shù)據(jù)庫，自主設(shè)計(jì)一套基于對話框MFC的機(jī)外實(shí)時(shí)采集的故障診斷軟件。該軟件不僅自成體系，獨(dú)立于標(biāo)定軟件，還具有大型診斷儀的智能化優(yōu)點(diǎn)，能夠在線讀取故障，輸出故障碼、故障部位、故障原因以及故障處理建議等詳細(xì)故障信息。

1 柴油機(jī)SCR系統(tǒng)故障檢測信息

為了達(dá)到OBD法規(guī)認(rèn)證要求，在SCR系統(tǒng)基礎(chǔ)上需要新配備幾類傳感器，包括NOx智能傳感器、催化劑前后溫度傳感器、尿素液位傳感器以及檢測壓縮后空氣壓力的壓力傳感器等。同時(shí)OBD系統(tǒng)應(yīng)對以下內(nèi)容進(jìn)行檢測［1］：SCR系統(tǒng)效率的下降；系統(tǒng)完全拆除或用假系統(tǒng)代替（人為故障）；SCR系統(tǒng)中電器件故障（如傳感器的開路與短路等）；尿素水溶液的加熱系統(tǒng)；尿素水溶液定量噴射系統(tǒng)（如缺少空氣供應(yīng)，噴嘴堵塞等）；尿素水溶液缺失，尿素水溶液給料活動等。

根據(jù)以上需要檢測的信息，在設(shè)計(jì)診斷軟件時(shí)，將故障分為3類，包括傳感器故障、執(zhí)行器故障、CAN總線通信故障。

1.1 傳感器故障

1.1.1 傳感器自診斷故障

柴油機(jī)SCR系統(tǒng)中使用的NOx傳感器［2］和格蘭富計(jì)量泵都有故障自診斷功能，可將自身診斷信息整合打包后以廣播的形式發(fā)送到CAN總線上。OBD系統(tǒng)直接采集CAN總線上兩組件報(bào)文，通過報(bào)文中的故障標(biāo)志位信息判斷故障是否發(fā)生。

1.1.2 傳感器電路連接故障

發(fā)動機(jī)工作時(shí)，傳感器不斷向外發(fā)出信號，每個(gè)傳感器都預(yù)先標(biāo)定了信號值范圍，OBD系統(tǒng)通過對傳感器輸出信號值與故障標(biāo)定值進(jìn)行比較，判斷傳感器的工作是否正常，超出標(biāo)定限值時(shí)記錄并發(fā)出相應(yīng)的報(bào)警信息。此類故障大多為傳感器處于短路或是開路狀態(tài)。

1.1.3 傳感器信號合理性故障

合理性診斷是指在傳感器電路連接正確的情況下，傳感器的輸出值雖然在標(biāo)定值范圍內(nèi)，但根據(jù)當(dāng)前發(fā)動機(jī)的運(yùn)行工況和其他傳感器信號值，不應(yīng)該出現(xiàn)該輸出值，此時(shí)的診斷即為傳感器信號合理性診斷。例如，在發(fā)動機(jī)實(shí)際運(yùn)行過程中，除了尿素溶液本身消耗外，由于震動等原因，導(dǎo)致尿素液位信號值產(chǎn)生細(xì)微的差別，連續(xù)兩次的尿素液位值不可能相等。若出現(xiàn)連續(xù)兩次尿素液位值相等，則判定尿素液位傳感器出現(xiàn)故障。

1.2 執(zhí)行器故障

在控制系統(tǒng)中，執(zhí)行器通過接收ECU控制信號執(zhí)行相應(yīng)命令，但執(zhí)行的結(jié)果并沒有反饋信號。為此對執(zhí)行器的檢測分為兩種情況：一是通過添加額外的硬件，通過反饋信號直接檢測；另外一種通過監(jiān)測其他關(guān)聯(lián)傳感器信號的間接檢測，向執(zhí)行器發(fā)送控制信號后，若關(guān)聯(lián)傳感器信號值的變化趨勢不符合規(guī)定，則判定為執(zhí)行器工作故障。由于額外的硬件反饋回路會增加系統(tǒng)的復(fù)雜程度，提高系統(tǒng)成本，所以本研究采用第二種方法實(shí)現(xiàn)對執(zhí)行器的檢測功能。

1.3 CAN總線通信故障

發(fā)動機(jī)正常工作時(shí)，ECU、尿素泵以及NOx傳感器等的數(shù)據(jù)報(bào)文會不斷地發(fā)送到CAN總線上，OBD系統(tǒng)會連續(xù)地接收這些報(bào)文。如果在設(shè)定時(shí)間內(nèi)，OBD系統(tǒng)沒有接收到相關(guān)數(shù)據(jù)報(bào)文，則判定相應(yīng)部件發(fā)生通信故障［3］。CAN總線的通信故障包括以下3種：ECU通信中斷故障、NOx傳感器通信中斷故障以及格蘭富計(jì)量泵通信中斷故障。

2 診斷應(yīng)用軟件設(shè)計(jì)

2.1 診斷軟件的構(gòu)建

在OBD－PC系統(tǒng)整體結(jié)構(gòu)中，USB CAN智能接口卡將完成OBD系統(tǒng)與診斷軟件間的信號傳輸，OBD系統(tǒng)輸出CAN總線數(shù)據(jù)經(jīng)USB接口電路輸送至PC機(jī)，同時(shí)PC機(jī)的請求信號經(jīng)變換后發(fā)送至OBD系統(tǒng)。故障診斷軟件的整體結(jié)構(gòu)見圖1。故障診斷軟件選用Visual C＋＋6.0開發(fā)工具和 Microsoft Access桌面數(shù)據(jù)庫系統(tǒng)，通過建立對話框式的MFC診斷軟件編程［4］，實(shí)現(xiàn)故障信息的自動讀取、解析以及顯示等。

2.2 故障診斷軟件的總體結(jié)構(gòu)與工作原理

根據(jù)故障診斷的基本理論，對軟件進(jìn)行模塊化設(shè)計(jì)（見圖2）。故障診斷軟件包括數(shù)據(jù)通信模塊、數(shù)據(jù)采集模塊、數(shù)據(jù)庫模塊、數(shù)據(jù)分析模塊以及主控程序用戶顯示界面。其中數(shù)據(jù)分析模塊和數(shù)據(jù)庫模塊是軟件設(shè)計(jì)的核心。

故障診斷軟件是建立在數(shù)據(jù)采集處理和實(shí)時(shí)數(shù)據(jù)通信的基礎(chǔ)上。通過數(shù)據(jù)通信與采集模塊獲得CAN總線上的J1939故障報(bào)文和發(fā)動機(jī)運(yùn)行數(shù)據(jù)流；由數(shù)據(jù)分析模塊對報(bào)文進(jìn)行解析，提取故障報(bào)文中的SPN和FMI；由SPN和FMI查詢數(shù)據(jù)庫中故障的詳細(xì)信息，并在線顯示。專業(yè)人員根據(jù)故障提示信息及時(shí)處理故障，以免發(fā)動機(jī)排放進(jìn)一步惡化。此外，還可根據(jù)需要查閱由數(shù)據(jù)采集模塊獲得的發(fā)動機(jī)數(shù)據(jù)流，對嚴(yán)重故障進(jìn)行綜合分析與判定。

2.2.1 數(shù)據(jù)通信

PC機(jī)和CAN總線連接的硬件部分采用USBCAN智能接口卡。接口卡的一端經(jīng)USB與PC機(jī)連接，另一端與ECU上CAN總線直接相連，實(shí)現(xiàn)故障診斷軟件和發(fā)動機(jī)之間的數(shù)據(jù)通信。

只有診斷應(yīng)用軟件的通信設(shè)定與OBDⅡ－PC接口設(shè)備的設(shè)定保持一致，數(shù)據(jù)才能正常傳輸。所以數(shù)據(jù)通信必須首先設(shè)置故障診斷軟件的通信波特率、數(shù)據(jù)位、奇偶校驗(yàn)位以及停止位等。本研究通過Visual C＋＋6.0編寫與調(diào)用USBCAN接口卡庫函數(shù)實(shí)現(xiàn)故障診斷軟件與發(fā)動機(jī)之間的通信［5］，分別完成對各自串口的初始化。

2.2.2 數(shù)據(jù)采集

數(shù)據(jù)采集模塊負(fù)責(zé)接收采集請求信號和應(yīng)答信號，采集的信息主要是DM代碼和出現(xiàn)故障時(shí)發(fā)動機(jī)運(yùn)行狀態(tài)的數(shù)據(jù)流。接收到的SCR系統(tǒng)故障診斷信息需要放入故障診斷軟件中的數(shù)據(jù)存放模塊，然后從該模塊讀取相關(guān)數(shù)據(jù)信息并送入主控程序界面。在此期間需要?jiǎng)?chuàng)建一個(gè)線程以支持后臺運(yùn)行，并為該線程添加響應(yīng)函數(shù)以設(shè)置相關(guān)變量；一旦CAN總線上有故障信息數(shù)據(jù)便可觸發(fā)該線程，將數(shù)據(jù)送入相關(guān)變量并存儲在數(shù)據(jù)存放模塊內(nèi)，方便顯示和查詢。

2.2.3 數(shù)據(jù)分析

數(shù)據(jù)分析模塊用來分析數(shù)據(jù)采集模塊的數(shù)據(jù)信號。發(fā)動機(jī)ECU按照SAE J1939協(xié)議要求的格式將報(bào)文發(fā)送至CAN總線，數(shù)據(jù)分析模塊解析信息報(bào)文，根據(jù)解析出的故障代碼值（SPN和FMI）從數(shù)據(jù)庫中檢索出對應(yīng)故障的詳細(xì)信息并顯示。

SAE J1939在標(biāo)準(zhǔn)通信中僅使用CAN2.0B中的擴(kuò)展幀格式［6］，表1示出了數(shù)據(jù)信息是如何映射到擴(kuò)展幀格式中的，根據(jù)報(bào)文的映射對應(yīng)關(guān)系對報(bào)文信息進(jìn)行解析。

表1 CAN幀與J1939幀對應(yīng)格式

發(fā)動機(jī)運(yùn)行過程中出現(xiàn)故障時(shí)，OBD系統(tǒng)將實(shí)時(shí)獲取的故障信息按照SAE J1939協(xié)議要求的DM1［7］（當(dāng)前DTC代碼）格式發(fā)送到CAN總線，故障診斷軟件接收到DMl代碼后對其進(jìn)行解析，通過分析報(bào)文獲得當(dāng)前具體故障信息。DTC代碼由4個(gè)獨(dú)立域構(gòu)成，這些獨(dú)立的參數(shù)不是一個(gè)單獨(dú)的數(shù)，而是一組描述故障的信息（見表2）。

J1939協(xié)議采用單幀DM1和多幀DM1兩種方式傳送數(shù)據(jù)幀（故障信息服務(wù)數(shù)據(jù)），兩種數(shù)據(jù)幀均符合SAE J 1 9 3 9協(xié)議的CAN報(bào)文格式。如果故障信息可以放置在1個(gè)CAN數(shù)據(jù)幀中時(shí)，就采用單幀模式傳送；否則采用多幀模式傳送。DM1的DTC表示法見表3。

表2 DTC代碼組成

表3 DM1的DTC表示法

表4示出在2 500r／min，472kW工況下采集的第145幀數(shù)據(jù)，以1個(gè)控制幀數(shù)據(jù)為例說明解析過程。

已知：參數(shù)組編號PGN（0xEC00），表示數(shù)據(jù)傳輸—連接管理；源地址SA（0x0），表示是由發(fā)動機(jī)ECU發(fā)出的數(shù)據(jù)；數(shù)據(jù)域Data Field（0x20 1A00 04FF CA FE 00）。

解析數(shù)據(jù)域可知有4組后續(xù)幀，后續(xù)幀的PGN為0xEB00，源地址為0x0，并且數(shù)據(jù)域的第1字節(jié)為01，02，03，04。在此工況下實(shí)際采集的后續(xù)幀分別為第168，185，209，226幀。將這四組后續(xù)幀的數(shù)據(jù)整合解析，得出每個(gè)故障的SPN和FMI。

根據(jù)故障的SPN和FMI以及車輛制造廠家設(shè)定的故障信息，就可確定故障的詳細(xì)內(nèi)容。在診斷應(yīng)用軟件中若要實(shí)現(xiàn)從數(shù)據(jù)域內(nèi)解析出對應(yīng)的SPN和FMI，就需要在程序中寫入相應(yīng)的算法，自動實(shí)現(xiàn)轉(zhuǎn)換。

表4 采集到的實(shí)際報(bào)文

2.2.4 數(shù)據(jù)庫構(gòu)建

數(shù)據(jù)庫為數(shù)據(jù)分析模塊解析故障碼提供故障信息查詢服務(wù)。數(shù)據(jù)庫內(nèi)容是自行分析的故障信息，包括每個(gè)故障碼所對應(yīng)的SPN，F(xiàn)MI、故障原因、故障部件以及維修建議等。車輛動力系統(tǒng)故障代碼已標(biāo)準(zhǔn)化，排氣后處理系統(tǒng)的故障是由制造商自行定義的，可根據(jù)車輛和發(fā)動機(jī)廠家提供的相關(guān)信息構(gòu)建診斷軟件的數(shù)據(jù)庫。

在故障診斷軟件中建立Access桌面數(shù)據(jù)庫，通過Visual C＋＋調(diào)用標(biāo)準(zhǔn)的函數(shù)，經(jīng)公用接口對數(shù)據(jù)庫的內(nèi)容進(jìn)行訪問。其中MFC的數(shù)據(jù)庫擴(kuò)展部分對使用ODBC數(shù)據(jù)資源的細(xì)節(jié)進(jìn)行了封裝，避免與數(shù)據(jù)源相聯(lián)。應(yīng)用程序通過采用MFC中的數(shù)據(jù)庫擴(kuò)展類，操縱ODBC驅(qū)動程序管理器訪問數(shù)據(jù)庫。開發(fā)數(shù)據(jù)庫的步驟如下：

1）創(chuàng)建ODBC數(shù)據(jù)源；

2）使用AppWizard創(chuàng)建一個(gè)數(shù)據(jù)庫應(yīng)用程序；

3）實(shí)現(xiàn)程序的顯示、記錄功能。

隨著故障的積累與新故障的出現(xiàn)，可以直接對數(shù)據(jù)庫中內(nèi)容進(jìn)行修改；當(dāng)數(shù)據(jù)庫不對外開放時(shí)，可通過VC編程間接地對數(shù)據(jù)庫進(jìn)行添加、修改和刪除。圖3示出了故障數(shù)據(jù)庫的部分內(nèi)容。

2.2.5 主控程序和顯示界面

主控程序主要負(fù)責(zé)各模塊的協(xié)調(diào)運(yùn)作以及數(shù)據(jù)的合理流動；用戶顯示界面主要負(fù)責(zé)輸入用戶的操作命令和顯示故障信息，可以根據(jù)需要從數(shù)據(jù)存放模塊內(nèi)調(diào)出發(fā)生故障時(shí)發(fā)動機(jī)運(yùn)行狀態(tài)的數(shù)據(jù)流，配合故障信息進(jìn)行綜合分析判斷［8］。

3 應(yīng)用

通過檢測實(shí)車發(fā)動機(jī)產(chǎn)生的相關(guān)排放故障可以對OBD系統(tǒng)故障診斷軟件的功能進(jìn)行驗(yàn)證和完善。本研究中的試驗(yàn)樣機(jī)是在1臺4缸電控高壓共軌柴油機(jī)的基礎(chǔ)上改裝而成，安裝了SCR系統(tǒng)所需的各種傳感器。

分別以尿素溶液液位過低故障、催化器前后溫度傳感器合理性故障以及NOx傳感器與ECU之間通信中斷故障為例，觀測故障診斷軟件的運(yùn)行。

首先連接故障診斷系統(tǒng)，將電控柴油機(jī)起動預(yù)熱至水溫80℃，工況調(diào)至2 500r／min，472kW。

1）尿素溶液液位過低故障檢測

向尿素罐中加入不多于5%尿素罐標(biāo)稱容積的尿素水溶液來設(shè)置故障。軟件界面顯示尿素溶液液位過低的故障信息，SPN為1673，F(xiàn)MI為1，故障原因是尿素溶液液位過低，傳感器信號值小于閾值（見圖4）。當(dāng)重新加入足夠的尿素溶液至尿素罐，故障消失，故障燈熄滅，界面顯示無故障。

2）催化器前后溫度傳感器合理性故障檢測

通過擰松催化器的前溫度傳感器使其信號值低于后溫度傳感器的信號值。完成故障設(shè)置后界面顯示催化器前后溫度傳感器合理性故障信息，SPN為3144，F(xiàn)MI為2，故障原因是在一定的時(shí)間內(nèi)，催化器前后溫度傳感器的溫差超過一個(gè)限值（見圖5）。當(dāng)再次擰緊催化器前溫度傳感器時(shí)故障仍不消失，之后使用廠家專業(yè)設(shè)備方恢復(fù)。

3）NOx傳感器與ECU之間通信中斷故障檢測

通過拔掉線束上連接插件設(shè)置故障。界面顯示NOx傳感器與ECU之間通信中斷故障信息，SPN為2771，F(xiàn)MI為9；故障原因是NOx傳感器與ECU之間通信有故障，即通信丟失（見圖6）。同時(shí)伴隨著電控柴油機(jī)轉(zhuǎn)速下降，出現(xiàn)限扭現(xiàn)象?，F(xiàn)場連上連接插件恢復(fù)無效，故障仍不消失。重新起動后故障消失，降扭被撤銷。

由試驗(yàn)結(jié)果可見，故障診斷軟件能夠從CAN總線上獲取故障信息，后臺分析提取故障報(bào)文SPN和FMI，并有效地顯示故障原因和處理方法。故障診斷軟件的運(yùn)行結(jié)果和設(shè)置的故障完全一致。同時(shí)也反映出當(dāng)前電控發(fā)動機(jī)OBD系統(tǒng)的3類故障處理策略，即在線恢復(fù)、重起恢復(fù)和廠家恢復(fù)。由此表明該故障診斷軟件能夠準(zhǔn)確快捷地診斷故障和實(shí)時(shí)無誤地給出信息，且軟件操作簡便、使用靈活。

4 結(jié)束語

采用CAN總線技術(shù)和模塊化結(jié)構(gòu)，設(shè)計(jì)了柴油機(jī)SCR系統(tǒng)機(jī)外故障診斷軟件。診斷軟件通過數(shù)據(jù)分析模塊解析處理故障信息，通過數(shù)據(jù)庫模塊對Access數(shù)據(jù)庫存儲管理，經(jīng)數(shù)據(jù)通信模塊CAN總線傳遞故障報(bào)文信息，由主控程序?qū)崿F(xiàn)對電控柴油機(jī)SCR系統(tǒng)故障的準(zhǔn)確診斷和故障定位。實(shí)機(jī)試驗(yàn)結(jié)果表明：故障診斷軟件運(yùn)行可靠，檢測結(jié)果和設(shè)置的故障信息一致。

［1］ 國家環(huán)境保護(hù)總局.HJ 437.2008 車用壓燃式、氣體燃料點(diǎn)燃式發(fā)動機(jī)與汽車車載診斷（OBD）系統(tǒng)技術(shù)要求［S］.北京：環(huán)境保護(hù)部，2008.

［2］ NOxSpecification AAS Generic 2.5［M］.［S.l.］：GRUNDFOS，2007.

［3］ 陶漢國.柴油機(jī) Urea－SCR系統(tǒng)控制策略研究［D］.武漢：武漢理工大學(xué)，2009.

［4］ 曹德勝.Visual C＋＋ 實(shí)踐指導(dǎo)教程［M］.北京：北京航空航天出版社，2008.

［5］ 韓 瀟，許小榮，武瑞峰，等.刨煤機(jī)工作面液壓支架電液控制系統(tǒng)［J］.微計(jì)算機(jī)信息，2007（25）：1－5.

［6］ 全國汽車標(biāo)準(zhǔn)化技術(shù)委員會.商用車控制系統(tǒng)局域網(wǎng)（CAN總線）通訊協(xié)議：第4部分（征求意見稿）［S］.

［7］ 全國汽車標(biāo)準(zhǔn)化技術(shù)委員會.商用車控制系統(tǒng)局域網(wǎng)（CAN總線）通訊協(xié)議：第6部分（征求意見稿）［S］.

［8］ 王文山.柴油發(fā)動機(jī)管理系統(tǒng)［M］.北京：機(jī)械工業(yè)出版社，2009.