柴油機SCR系統故障診斷軟件的開發與應用

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

（江蘇大學汽車與交通工程學院，江蘇 鎮 江 212013）

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

選擇性催化還原（SCR）技術是目前我國重型柴油機達到國Ⅳ階段排放標準的最佳選擇。當SCR系統中出現零部件不正常工作或失效時，排放就會惡化甚至超標，OBD系統通過實時監測與排放相關的零部件，指示出導致排放超標的相關部件。

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

1 柴油機SCR系統故障檢測信息

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

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

1.1 傳感器故障

1.1.1 傳感器自診斷故障

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

1.1.2 傳感器電路連接故障

發動機工作時，傳感器不斷向外發出信號，每個傳感器都預先標定了信號值范圍，OBD系統通過對傳感器輸出信號值與故障標定值進行比較，判斷傳感器的工作是否正常，超出標定限值時記錄并發出相應的報警信息。此類故障大多為傳感器處于短路或是開路狀態。

1.1.3 傳感器信號合理性故障

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

1.2 執行器故障

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

1.3 CAN總線通信故障

發動機正常工作時，ECU、尿素泵以及NOx傳感器等的數據報文會不斷地發送到CAN總線上，OBD系統會連續地接收這些報文。如果在設定時間內，OBD系統沒有接收到相關數據報文，則判定相應部件發生通信故障［3］。CAN總線的通信故障包括以下3種：ECU通信中斷故障、NOx傳感器通信中斷故障以及格蘭富計量泵通信中斷故障。

2 診斷應用軟件設計

2.1 診斷軟件的構建

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

2.2 故障診斷軟件的總體結構與工作原理

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

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

2.2.1 數據通信

PC機和CAN總線連接的硬件部分采用USBCAN智能接口卡。接口卡的一端經USB與PC機連接，另一端與ECU上CAN總線直接相連，實現故障診斷軟件和發動機之間的數據通信。

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

2.2.2 數據采集

數據采集模塊負責接收采集請求信號和應答信號，采集的信息主要是DM代碼和出現故障時發動機運行狀態的數據流。接收到的SCR系統故障診斷信息需要放入故障診斷軟件中的數據存放模塊，然后從該模塊讀取相關數據信息并送入主控程序界面。在此期間需要創建一個線程以支持后臺運行，并為該線程添加響應函數以設置相關變量；一旦CAN總線上有故障信息數據便可觸發該線程，將數據送入相關變量并存儲在數據存放模塊內，方便顯示和查詢。

2.2.3 數據分析

數據分析模塊用來分析數據采集模塊的數據信號。發動機ECU按照SAE J1939協議要求的格式將報文發送至CAN總線，數據分析模塊解析信息報文，根據解析出的故障代碼值（SPN和FMI）從數據庫中檢索出對應故障的詳細信息并顯示。

SAE J1939在標準通信中僅使用CAN2.0B中的擴展幀格式［6］，表1示出了數據信息是如何映射到擴展幀格式中的，根據報文的映射對應關系對報文信息進行解析。

表1 CAN幀與J1939幀對應格式

發動機運行過程中出現故障時，OBD系統將實時獲取的故障信息按照SAE J1939協議要求的DM1［7］（當前DTC代碼）格式發送到CAN總線，故障診斷軟件接收到DMl代碼后對其進行解析，通過分析報文獲得當前具體故障信息。DTC代碼由4個獨立域構成，這些獨立的參數不是一個單獨的數，而是一組描述故障的信息（見表2）。

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

表2 DTC代碼組成

表3 DM1的DTC表示法

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

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

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

根據故障的SPN和FMI以及車輛制造廠家設定的故障信息，就可確定故障的詳細內容。在診斷應用軟件中若要實現從數據域內解析出對應的SPN和FMI，就需要在程序中寫入相應的算法，自動實現轉換。

表4 采集到的實際報文

2.2.4 數據庫構建

數據庫為數據分析模塊解析故障碼提供故障信息查詢服務。數據庫內容是自行分析的故障信息，包括每個故障碼所對應的SPN，FMI、故障原因、故障部件以及維修建議等。車輛動力系統故障代碼已標準化，排氣后處理系統的故障是由制造商自行定義的，可根據車輛和發動機廠家提供的相關信息構建診斷軟件的數據庫。

在故障診斷軟件中建立Access桌面數據庫，通過Visual C＋＋調用標準的函數，經公用接口對數據庫的內容進行訪問。其中MFC的數據庫擴展部分對使用ODBC數據資源的細節進行了封裝，避免與數據源相聯。應用程序通過采用MFC中的數據庫擴展類，操縱ODBC驅動程序管理器訪問數據庫。開發數據庫的步驟如下：

1）創建ODBC數據源；

2）使用AppWizard創建一個數據庫應用程序；

3）實現程序的顯示、記錄功能。

隨著故障的積累與新故障的出現，可以直接對數據庫中內容進行修改；當數據庫不對外開放時，可通過VC編程間接地對數據庫進行添加、修改和刪除。圖3示出了故障數據庫的部分內容。

2.2.5 主控程序和顯示界面

主控程序主要負責各模塊的協調運作以及數據的合理流動；用戶顯示界面主要負責輸入用戶的操作命令和顯示故障信息，可以根據需要從數據存放模塊內調出發生故障時發動機運行狀態的數據流，配合故障信息進行綜合分析判斷［8］。

3 應用

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

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

首先連接故障診斷系統，將電控柴油機起動預熱至水溫80℃，工況調至2 500r／min，472kW。

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

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

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

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

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

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

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

4 結束語

采用CAN總線技術和模塊化結構，設計了柴油機SCR系統機外故障診斷軟件。診斷軟件通過數據分析模塊解析處理故障信息，通過數據庫模塊對Access數據庫存儲管理，經數據通信模塊CAN總線傳遞故障報文信息，由主控程序實現對電控柴油機SCR系統故障的準確診斷和故障定位。實機試驗結果表明：故障診斷軟件運行可靠，檢測結果和設置的故障信息一致。

［1］ 國家環境保護總局.HJ 437.2008 車用壓燃式、氣體燃料點燃式發動機與汽車車載診斷（OBD）系統技術要求［S］.北京：環境保護部，2008.

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

［3］ 陶漢國.柴油機 Urea－SCR系統控制策略研究［D］.武漢：武漢理工大學，2009.

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

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

［6］ 全國汽車標準化技術委員會.商用車控制系統局域網（CAN總線）通訊協議：第4部分（征求意見稿）［S］.

［7］ 全國汽車標準化技術委員會.商用車控制系統局域網（CAN總線）通訊協議：第6部分（征求意見稿）［S］.

［8］ 王文山.柴油發動機管理系統［M］.北京：機械工業出版社，2009.