文獻標識碼： A
文章編號： 0258-7998(2014)09-0014-03
目前，針對中重型車用柴油機尾氣的排放，主要有兩種技術路線，一是EGR（廢氣再循環）+DPF（柴油顆粒捕捉）或DOC（氧化催化轉化）；二是優化燃燒+SCR（選擇催化還原）。SCR技術具有對硫不敏感、油耗低、技術可持續性好等優點[1]，我國普遍采用的是SCR技術。為了及時發現SCR系統存在的故障并提醒駕駛員，根據國家法規HJ437中規定，滿足國IV階段排放要求的車輛必須配備OBD（車載診斷）系統，所以對OBD系統的研究具有實際應用價值。
1 OBD診斷策略制定
汽車正常運行時，ECU的輸入、輸出信號的電壓值都有一定的變化范圍。當某一信號超出了這一范圍，并且這一現象在一段時間內不會消失時，ECU便判斷為這一部分出現故障[2]。本文設計的OBD模塊主要監測對象有傳感器、執行器、CAN通訊及NOX排放監測等。
1.1 傳感器的診斷策略
傳感器包括尿素箱溫度及液位傳感器、添藍計量泵蓄壓腔和混合腔壓力傳感器、催化器前后溫度傳感器、NOX傳感器。
當尿素箱內的溫度低于-11 ℃，需對尿素進行加熱化冰處理。在OBD診斷過程中，若循環監測傳感器輸出的電壓信號超出標定的上限值，報告溫度傳感器對電源短路故障；反之，報告對地短路故障。若兩次輸出的電壓信號差值大于標定值時，認為溫度傳感器存在信號不可信故障。
液位傳感器與溫度傳感器的診斷策略相似，不同之處在于若液位傳感器兩次輸出的電壓信號相等時，報告液位傳感器存在停滯故障。同時液位傳感器在OBD診斷過程中還要監測尿素存量，當液位低于10%時，點亮MIL（故障指示燈），發出尿素存量不足警告。
壓力傳感器用于監測蓄壓腔和混合腔內的壓力變化。催化器前后溫度傳感器用來測定催化器前后兩端溫度，確保催化器的反應始終保持在合適的溫度范圍內。其診斷策略跟尿素溫度傳感器類似，不再贅述。
NOX傳感器同樣安裝在催化器前后，主要用來測定排放的NOX濃度是否超過排放限值，也可以作為催化器是否老化，是否需要拆除的依據。本文所使用的NOX傳感器帶有自診斷的功能, NOX傳感器的故障都是通過CAN總線傳來的報文信息來辨別的。OBD系統對NOX傳感器的信號不合理故障的檢測貫穿于整個加熱過程中。在NOX傳感器自檢并確定無故障后,DCU便發送對NOX傳感器加熱的指令。在加熱的過程中，若沒有收到溫度信號但是已經超過了加熱的最大時間限值，則報告NOX傳感器加熱信號不合理故障。
1.2 執行器的診斷策略
執行器包括尿素噴射閥和冷卻液加熱控制閥。
SCR系統在進行初始化后，計量泵進行建壓，若一段時間后檢測的壓力仍達不到標定值，需重復建壓，當重建次數超過最大標定值，壓力仍達不到，則報告尿素噴射閥有常開故障。若壓力正常建立后，則噴射閥的占空比為標定值，若一段時間后監測到壓力值高于標定值，則報告噴射閥有常閉故障。
化冰處理加熱至7℃停止，加熱過程中，若在標定時間內檢測溫度仍低于下限溫度，則報告冷卻水加熱控制閥有常開故障；若加熱一段時間后溫度持續高于上限溫度，則報告冷卻水加熱控制閥有常閉故障。
1.3 CAN通訊診斷及NOX排放監測診斷策略
OBD模塊實時檢測CAN總線通訊故障，若發生故障，則由CAN總線的硬件報出。OBD模塊還會周期性地檢測EEC1（發動機電控信息1）和AMB（環境狀態）等相關的CAN總線信息，一旦檢測到錯誤，系統就會自動報錯。
OBD法規要求，與排放控制有關的發動機系統異常運轉應通過對NOX排放水平進行監測來確定。根據要求，NOX排放控制的限值分別為5.0 g/kwh和7.0 g/kwh。當NOX排放量超過5.0 g/kwh時，激活MIL；當NOX排放量超過7.0 g/kwh時，扭矩限制器起作用。
2 OBD模塊的整體設計
本文開發的OBD模塊是基于飛思卡爾MC9S12XET256單片機開發平臺[3]，編程軟件采用的是Code Warrior IDE軟件。所設計的OBD模塊是嵌入到SCR電控單元（DCU）中的，其與發動機控制單元（ECU）上的OBD模塊分別控制各自的故障診斷。DCU將診斷的結果通過CAN總線廣播到網絡里，ECU根據接收到的故障情況和發動機實際運行狀況綜合判斷，來控制MIL或者扭矩限制器的激活與否[4]。OBD總體方案設計如圖1所示。
OBD模塊在SCR系統中完成的主要功能有信息采集、信息轉換、故障診斷、故障碼存儲及故障碼傳送。OBD模塊的基本框架如圖2所示。
圖2 OBD模塊的基本框架圖
3 基于CAN總線OBD模塊程序設計
根據J1939協議的規定，CAN報文信息主要在數據幀中，OBD監測到系統出現故障要及時向CAN總線發送當前故障信息，以通知總線上其他節點，故障信息都包含在DM1（當前故障診斷代碼）中[5]。DM1包含的故障診斷信息僅僅是當前情況下處于激活狀態并且可以改變故障指示燈狀態的故障代碼，所以DM1被傳輸的前提就是要有DTC（故障診斷碼）成為激活的故障碼。每個DM1的更新周期為1 s，如果故障激活的時間大于1 s，然后又變為不激活狀態，則應傳輸DM1消息來反應這種狀態的改變，DM1的SPN為0xFECA。
DTC由四部分組成：SPN，可疑參數編號，是用以識別特定的元素組件或與ECU相關的參數；FMI，故障模式標志，定義了為SPN所識別的子系統中發現的故障類型；OC，發生次數，包括了一個故障從先前激活狀態到激活狀態的變化次數，最大值為126；CM，SPN的轉化方式，一般來說，CM=0。
本文針對監測對象定義了以下故障信息，如表1所示，現舉例說明DM1的組成。假設一個尿素箱溫度傳感器發生對地短路故障，在表1中可以看出SPN=3031，FMI=4；此時假設故障發生了一次，則OC=1，CM=0，點亮故障指示燈為0x40，則根據表2可得DTC=0xD70B0401，DM1報文內容則為0x4000D70B0401FFFF。
若需發送的故障信息小于8 B，則DM1在一幀CAN數據中傳送時采用單包模式，更新周期為1 s，若需要發送包含兩個以上故障的當前故障信息時，單幀CAN報文就不足以容納全部的信息了，此時需要采用多包發送模式。
當使用多包模式發送DM1時，就不能像單幀DM1那樣發送，而需要遵循J1939協議[6]。按照規定的傳輸協議進行發送，發送分為兩個步驟：
(1)發送一條連接管理消息（PGN=0xEC00），公告要發送一條廣播消息（BAM），目標地址為全局目標地址，作為一個長消息預告發送給網絡上的節點。BAM消息包含了即將廣播的長消息的參數組編號、消息大小和它被拆裝的數據包的數目，具體格式如表2所示。
(2)將數據拆分打包，并通過數條數據傳送消息(PGN=0xEB00)發送，發送周期為50 ms。每一數據包的第一字節內容為數據包序列號和燈的狀態信息，所有的DTC依次排列在后續的字節當中。當最后一個數據包不足8 B數據時，沒使用的字節均以0xFF填充，多包DM1中DTC解析方法與單包DM1一致。
4 CANoe-MATLAB/Simulink聯合仿真驗證
為了驗證所開發的OBD模塊是否滿足要求并完善OBD模塊的程序設計，必須進行試驗驗證。而一般的試驗驗證不可能人為地制造出所有的故障，因為有些傳感器是集成在計量泵內部的，如果加以破壞，勢必影響計量泵本身的性能，而且增加了試驗成本。針對這種情況，本文設計了基于CANoe-MATLAB/Simulink聯合仿真驗證[7]，充分結合了CANoe中的總線仿真優勢和MATLAB/Simulink構建復雜功能模型的優勢。
4.1 仿真模型建立
利用CANoe建立總線網絡，并在總線網絡上建立相關的節點。為了配合所設計的OBD模塊仿真，本文建立了EMS(發動機控制單元)、UDS(計量泵單元)、DCU(SCR電子控制單元)、Control Panel(監控面板)4個節點，如圖3所示。
建立完網絡節點后，利用CANdb++進行整個系統數據庫的建立，包括信號、環境變量、報文的建立等并關聯。然后利用PanelEditor對控制面板進行設計，并和剛剛創建的數據庫進行關聯。創建的OBD控制面板如圖4所示。之后用CAPL語言對節點和測試環境進行編程設計，用來控制節點動作。最后根據仿真需要修改系統參數。
4.2 OBD仿真分析
故障分單個故障和多個故障，基于CANoe的Diagnostic和DTC Monitor工具跟蹤和觀察了發生單個和多個故障時的情形。圖5為單個故障發生的仿真過程。單擊OBD控制面板上溫度傳感器短路后的OK鍵，單個故障發生，從DTC Monitor上可以看出UDS節點上出現了紅點閃爍，UDS節點向CAN總線發送單包故障信息DM1(PGN=0xFECA)，通知其他節點發生故障的節點及類型。下面列出出現錯誤的節點為UDS：SPN=0x7F5FD、OC=1、FMI為“Voltage below normal（電壓低于正常值）”故障。此時，車上的OBD系統監測到有故障發生，點亮MIL。
圖6為多個故障的仿真過程，依次點擊OBD控制面板上液位傳感器開路和催化器后溫度后的OK鍵，同時產生兩個故障，DCU和UDS節點同時出現紅點閃爍。兩個節點向CAN總線發送多包故障信息，首先發送一條連接管理消息(PGN=0xEC00)，公告要發送一條廣播消息(BAM)，預告其他的節點。然后將數據拆分打包，分多條消息進行傳送（PGN=0xEB00）。然后通知其他節點發生故障的節點及類型，車上的OBD系統監測到故障，點亮MIL。
由以上的仿真過程可以看出，該模型很好地模擬了OBD的診斷過程，從而說明了制定的OBD診斷策略及設計的程序的正確性，可以對SCR系統中所出現的故障進行診斷并能及時地把診斷的結果通過CAN總線發給DCU，控制點亮MIL。該仿真結果對程序設計的完善也具有指導意義。
對OBD模塊制定了診斷策略并進行了總體的設計，基于飛思卡爾MC9S12XET256單片機對OBD進行了程序設計，為了驗證制定的診斷策略及程序設計的合理性，基于Simulink建立了OBD仿真模型，對SCR系統中OBD的工作過程進行了聯合仿真，結果表明建立的模型可以模擬OBD診斷過程，驗證了制定的OBD診斷策略及程序設計的正確性，并根據仿真結果完善了程序設計。
參考文獻
[1] SITSHEBO S，TSOLAKIS A，THEINNOI K.Promoting hydrocarbon-SCR of NOx in diesel engine exhaust by hydrogen and fuel reforming[J].International Journal of Hydrogen Energy，2009，34(18)：7842-7850.
[2] 戴耀輝，于建國．汽車檢測與故障診斷[M]．北京：機械工業出版社，2007.
[3] MC9S12XET256開發平臺實驗指導手冊[EB/OL](2011-10)[2014-05].http：//fxfreefly.taobao.com.
[4] 張偉，徐正飛，鄧成林，等.柴油機SCR系統OBD功能的診斷策略研究[J].汽車工程，2011，33(1)：23-25.
[5] 代妮娜，蔡黎，邱剛，等.一種新型汽車OBD信息無線發射機設計[J].電子技術應用，2012，38(11)：97-99.
[6] SAE J1939/73，SAE J1939 protocol part 7-3：application layer-diagnostics[S].2006，9.
[7] 李頂根，曹晶，張杰.基于CANoe_Matlab的車輛CAN總線的聯合仿真[J].計算機原理，2009(11)：57-61.