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

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

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

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

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

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

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

根據(jù)以上需要檢測(cè)的信息，在設(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)文，通過(guò)報(bào)文中的故障標(biāo)志位信息判斷故障是否發(fā)生。

1.1.2 傳感器電路連接故障

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

1.1.3 傳感器信號(hào)合理性故障

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

1.2 執(zhí)行器故障

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

1.3 CAN總線通信故障

發(fā)動(dòng)機(jī)正常工作時(shí)，ECU、尿素泵以及NOx傳感器等的數(shù)據(jù)報(bào)文會(huì)不斷地發(fā)送到CAN總線上，OBD系統(tǒng)會(huì)連續(xù)地接收這些報(bào)文。如果在設(shè)定時(shí)間內(nèi)，OBD系統(tǒng)沒(méi)有接收到相關(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)與診斷軟件間的信號(hào)傳輸，OBD系統(tǒng)輸出CAN總線數(shù)據(jù)經(jīng)USB接口電路輸送至PC機(jī)，同時(shí)PC機(jī)的請(qǐng)求信號(hào)經(jīng)變換后發(fā)送至OBD系統(tǒng)。故障診斷軟件的整體結(jié)構(gòu)見(jiàn)圖1。故障診斷軟件選用Visual C＋＋6.0開發(fā)工具和 Microsoft Access桌面數(shù)據(jù)庫(kù)系統(tǒng)，通過(guò)建立對(duì)話框式的MFC診斷軟件編程［4］，實(shí)現(xiàn)故障信息的自動(dòng)讀取、解析以及顯示等。

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

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

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

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

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

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

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

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

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

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

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

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

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

表2 DTC代碼組成

表3 DM1的DTC表示法

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

已知：參數(shù)組編號(hào)PGN（0xEC00），表示數(shù)據(jù)傳輸—連接管理；源地址SA（0x0），表示是由發(fā)動(dòng)機(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)解析出對(duì)應(yīng)的SPN和FMI，就需要在程序中寫入相應(yīng)的算法，自動(dòng)實(shí)現(xiàn)轉(zhuǎn)換。

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

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

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

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

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

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

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

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

2.2.5 主控程序和顯示界面

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

3 應(yīng)用

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

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

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

1）尿素溶液液位過(guò)低故障檢測(cè)

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

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

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

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

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

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

4 結(jié)束語(yǔ)

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

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

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

［3］ 陶漢國(guó).柴油機(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］ 全國(guó)汽車標(biāo)準(zhǔn)化技術(shù)委員會(huì).商用車控制系統(tǒng)局域網(wǎng)（CAN總線）通訊協(xié)議：第4部分（征求意見(jiàn)稿）［S］.

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

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