張帆，姚勝華，顧祖飛

（湖北汽車工業(yè)學院 汽車工程學院，湖北 十堰442002）

汽車電子在車輛上的廣泛應(yīng)用，不僅促進了車輛的自動化和智能化，還使得汽車性能有較大的提升，但相應(yīng)汽車故障種類也越來越多，難以排查。當電控系統(tǒng)出現(xiàn)問題時，如何快速準確鎖定故障、縮短客戶等待時間、降低客戶損失，是汽車制造商無法回避的問題，這對故障診斷系統(tǒng)的通用性提出了更高的要求。因此建立能夠快速確定故障的診斷系統(tǒng)也是汽車制造公司提高競爭力的一種途徑。

1 SAE J1939故障診斷報文

SAE J1939 協(xié)議的故障代碼通過故障診斷報文DM（diagnostic message）傳輸，DM 由指示燈MIL和診斷故障碼DTC組成，其中指示燈位置處于DM數(shù)據(jù)場的第1～2 字節(jié)，在SAE J1939 協(xié)議中的故障診斷DM協(xié)議中已定義的故障指示燈、琥珀色警告燈、紅色停止燈、保護燈的位置分別處于第1 字節(jié)的7～8位、5～6位、3～4位、1～2位［1］；第2字節(jié)是協(xié)議預(yù)留給用戶自定義任務(wù)燈狀態(tài)。故障診斷碼DTC（diagnostic trouble code）由4個字節(jié)組成，包含可疑參數(shù)編碼SPN（suspect parameter number,19位）、故障模式標志FMI（failure mole identifier,5 位）、可疑參數(shù)碼的轉(zhuǎn)換方式CM（conversion method,1 位）及記錄故障發(fā)生次數(shù)OC（occurrence count,7位）。具體位置如圖1所示。

要實現(xiàn)基于SAE J1939 的客車故障診斷系統(tǒng)的開發(fā)，需要對診斷報文進行相應(yīng)的解析。

1）可疑參數(shù)編號SPN 是19位的值，與特定元素組件或ECU 中的相關(guān)參數(shù)對應(yīng)。SAE J1939 協(xié)議將初始的511個SPN進行了設(shè)定，并且制定編號520192～524287為用戶可自定義可疑參數(shù)。

2）故障模式標志5 位FMI 定義SPN 所識別的子系統(tǒng)中發(fā)現(xiàn)的故障類型，如表1所示，F(xiàn)MI和SPN及故障發(fā)生次數(shù)OC組成已知的故障診斷代碼。

圖1 DTC結(jié)構(gòu)圖

表1 故障模式標志定義

3）故障發(fā)生次數(shù)7 位OC 記錄某個故障發(fā)生的次數(shù)，最大值為126。當OC溢出時，其值保持為126，當OC未知時，其域所有位上的值均為1。

4）故障指示燈 故障指示燈傳達相關(guān)故障代碼信息；紅色指示燈表示車輛出現(xiàn)嚴重問題，必須停車檢修；琥珀色指示燈表示車輛系統(tǒng)出現(xiàn)問題，但不需要立即停車檢修；保護指示燈告知車輛系統(tǒng)出現(xiàn)的問題極有可能不是相關(guān)電路子系統(tǒng)引發(fā)［2］。

2 故障診斷碼通信方式

當車輛有多個電子控制單元（ECU）且各ECU檢測到故障時，會發(fā)送相應(yīng)診斷報文，而報文來源、類型、位置根據(jù)故障報文ID 來確定。如診斷報文ID為0x18FECA30，其中0x18代表優(yōu)先級為6，0x30代表報文的源地址，0xFECA 是實時故障報文DM1的可疑參數(shù)編號。實時故障采用SAE J1939 協(xié)議中DM1 報文格式發(fā)送，歷史故障采用DM2 報文格式發(fā)送，故障數(shù)據(jù)清除采用DM3報文格式發(fā)送［3］。

1）DM1 故障碼傳輸方式 故障碼有3 種情況：無故障碼、單故障碼和多故障碼。在無故障碼、單故障碼的情況下，以1 幀報文發(fā)送，報文的發(fā)送格式如圖2所示。當有多個故障碼同時發(fā)送時，則需要發(fā)送1個8字節(jié)的頭報文，信息包括后面發(fā)的報文數(shù)、指示燈狀態(tài)及故障碼的字節(jié)數(shù)，后面發(fā)的報文第1個字節(jié)都是報文序列，如果最后1個數(shù)據(jù)幀的故障報文沒有填滿，則用0xFF 來填充。多故障報文格式如圖3所示。

圖2 單故障報文格式

圖3 多故障報文格式

2）DM2 故障代碼傳輸方式 故障診斷系統(tǒng)需要1個請求歷史故障報文，控制器才能發(fā)送DM2報文。DM2故障報文發(fā)送方式和DM1相同。

3）DM3 故障代碼傳輸方式 故障診斷系統(tǒng)需要診斷儀向控制器發(fā)送1 個請求歷史故障碼清除報文，清除歷史故障報文DM2，若控制器清除完畢會發(fā)送1個肯定報文DM3，若失敗則會發(fā)送1個否定報文DM3［4］。

3 故障診斷系統(tǒng)設(shè)計

3.1 故障診斷系統(tǒng)的功能

文中基于CANoe 平臺開發(fā)故障診斷系統(tǒng)，以客車控制器為診斷對象，通過CAN網(wǎng)絡(luò)進行通訊，從而將診斷信息通過診斷儀顯示出來。利用CANoe的Panel Designer 來設(shè)計診斷儀的面板，故障面板如圖4所示。系統(tǒng)功能如下：1）接收和發(fā)送DM1報文，并將報文內(nèi)容顯示在診斷儀上；2）發(fā)送DM2請求報文和清除報文，并將DM2 報文內(nèi)容及其是否清除報文顯示在診斷儀上；3）發(fā)送軟硬件請求報文，并將其信息顯示在診斷儀上。

3.2 DBC數(shù)據(jù)庫和系統(tǒng)變量建立

完成診斷儀功能的基礎(chǔ)是建立相應(yīng)的數(shù)據(jù)庫，DBC 數(shù)據(jù)庫是故障診斷系統(tǒng)進行報文發(fā)送和報文解析的基礎(chǔ)。根據(jù)功能需求及項目提供的信息建立相應(yīng)的報文，建立的報文如表2所示。在CANoe中建立相應(yīng)的系統(tǒng)變量，將系統(tǒng)變量與后續(xù)故障診斷面板的相關(guān)控件相互關(guān)聯(lián)，方便在腳本文件中完成控件的信息交互。

3.3 故障診斷系統(tǒng)的CAPL程序設(shè)計

1）單故障診斷報文接收 用數(shù)組DTC 來存放故障信息，當接收到DM1 時，利用DTC 將DM1 和FMI、SPN 對應(yīng)，從而確定DM1 類型；然后將1 和故障報文OC值分別賦給DTC和OC［5］；最后將DTC和OC 值賦給相關(guān)的系統(tǒng)變量。對于單故障報文來講，診斷儀對DM1 和DM2 的接收方式是相同的。具體單故障報文接收流程如圖5所示。

圖4 故障面板的設(shè)計

表2 報文信息

圖5 單故障報文接收邏輯圖

2）多故障診斷報文接收 DM1 和DM2 的多故障診斷報文ID 相同，所以用是否需要發(fā)送請求故障碼才能接收故障報文來區(qū)分DM1和DM2。由于多故障報文的故障數(shù)不確定，所以要先確定故障個數(shù)，根據(jù)頭報文獲得的故障碼字節(jié)數(shù)和原始數(shù)據(jù)字節(jié)包括2 個字節(jié)的指示燈狀態(tài)。具體多故障診斷報文接收流程如圖6所示。

3）請求報文發(fā)送 在CANoe 設(shè)計的故障面板中，請求報文的發(fā)送由按鈕控件來控制。按下按鈕控件時，控件所連接的環(huán)境變量Request 的值為1，釋放時值為0，這個動作觸發(fā)2次環(huán)境事件，因此在發(fā)送報文請求報文時，第1次觸發(fā)環(huán)境事件診斷儀發(fā)送請求報文，第2次觸發(fā)則不發(fā)送。

4）故障報文發(fā)送 發(fā)送報文采用DM1_mul 格式進行發(fā)送，CANoe 根據(jù)SAE J1939協(xié)議將其拆分成多包報文。報文需要根據(jù)診斷儀界面上選擇的故障周期性發(fā)送，因為DM1的報文發(fā)送周期為1 s，所以設(shè)置時間事件的觸發(fā)周期為1 s，并在事件中再次設(shè)置時間事件，使其循環(huán)觸發(fā)從而達到周期發(fā)送的目的。進入時間事件后先將診斷儀界面上選擇的故障記錄下來，判斷當前故障數(shù)，進行不同處理，發(fā)送處理后的報文，具體流程如圖7所示。

圖6 多故障診斷報文接收邏輯圖

圖7 發(fā)送故障報文邏輯圖

4 基于C#的診斷界面生成

目前整車上每個控制系統(tǒng)都需要配備單獨的診斷儀，診斷儀分為通用類和專用類。在Visual Studio 2013 環(huán)境運用C#語言設(shè)計開發(fā)故障面板、系統(tǒng)變量文件和對應(yīng)的CAPL 文件、cfg 文件、stcfg文件和BPM 文件生成工具，通過讀取DTC 信息來生成相應(yīng)的故障面板和對應(yīng)的CAPL文件、系統(tǒng)變量文件、cfg 文件、stcfg 文件及BPM 文件，從而實現(xiàn)一鍵生成故障診斷系統(tǒng)的功能。

由于需要通過讀取DTC 的Excel 獲取故障名稱、SPN、FMI、故障類別、控制器地址等信息，Excel格式如表3所示，讀取DTC信息流程如圖8所示。

表3 控制器故障碼信息

圖8 Excel讀取流程圖

根據(jù)現(xiàn)有DTC 信息改變故障面板的故障名稱，在現(xiàn)有CAPL程序中修改SPN、FMI及OC，產(chǎn)生新的故障面板、對應(yīng)的CAPL程序、DBC文件、系統(tǒng)變量文件、cfg文件、stcfg文件及BMP文件。這些文件的生成邏輯大致相同，文中僅介紹CAPL文件和面板文件的生成。

1）CAPL 文件生成 在設(shè)計故障診斷程序之前考慮了故障診斷的通用性問題，所以將與故障診斷碼相關(guān)的常量都用變量來表示，可根據(jù)CAPL程序的格式和內(nèi)容將新的DTC 信息的SPN、FMI、OC 等轉(zhuǎn)換為CAPL中的變量進行定義，從而完成相應(yīng)的CAPL 程序替換，新生成的CAPL 程序以CAN 文件的格式產(chǎn)生。在其相關(guān)轉(zhuǎn)換生成過程中，如何劃分SPN的低、中、高位成為難點，流程圖如圖9所示。

圖9 SPN高、中、低位劃分流程圖

2）Panel 文件的生成 為控制Panel上各控件的屬性，建立各控件的類，其中的屬性以變量形式進行定義，以上述故障面板為模板，根據(jù)模板來定義各控件的大小和屬性。按照上述故障面板來做此故障診斷面板，根據(jù)現(xiàn)有DTC 信息改變故障面板static text中的內(nèi)容，改變控件與環(huán)境變量之間的鏈接。生成的故障面板文件以xvp格式保存，故障面板文件通過CANoe的Panel Designer進行編輯。

5 故障診斷系統(tǒng)的測試

圖10 測試現(xiàn)場圖

通過VN1640A將2臺電腦相連，其中1臺用來發(fā)送故障報文，另外1 臺負責接收故障報文，對故障診斷系統(tǒng)進行測試工作，驗證生成故障診斷系統(tǒng)在CANoe中的功能。圖10為測試現(xiàn)場。將DTC信息導(dǎo)入故障診斷系統(tǒng)生成工具生成相應(yīng)的故障面板文件、CAPL 文件、系統(tǒng)變量文件及DBC 文件。將4個文件關(guān)聯(lián)在CANoe中運行，并通過發(fā)送故障報文的電腦將表3中的故障碼發(fā)送出去，讓接收故障報文的電腦進行接收，從而完成故障診斷系統(tǒng)的測試工作。收發(fā)報文驗證效果如圖11～12所示。

圖11 生成文件關(guān)聯(lián)后在CANoe中的運行

圖12 收發(fā)報文測試

6 結(jié)論

根據(jù)SAE J1939 協(xié)議簡要分析了DM 故障報文，根據(jù)相應(yīng)的功能需求，利用CANoe 平臺編寫了CAPL 程序、制作了故障面板。為滿足故障面板的通用性，以Visual Studio 2013 集成開發(fā)環(huán)境，利用C#語言編寫了故障診斷生成程序，方便讀取以固定格式儲存DTC 信息的Excel 表格，生成相應(yīng)的CAPL 文件、DBC 文件、面板文件及系統(tǒng)變量文件、BMP文件，重新搭建類似的診斷系統(tǒng)。

故障診斷系統(tǒng)生成工具根據(jù)存儲DTC 信息的Excel 表一鍵生成所需的故障診斷系統(tǒng)，縮短了故障診斷系統(tǒng)的開發(fā)時間，降低了故障系統(tǒng)的開發(fā)門檻。自動生成的故障診斷系統(tǒng)減少了人為因素產(chǎn)生的錯誤，提高了運行可靠性；因其獲悉對應(yīng)車輛的故障診斷信息就可運行，同樣適用于其他車型。