基于CAN總線的故障診斷模塊設計

(1.江蘇大學 汽車與交通工程學院，江蘇 鎮江 212013； 2.浙江福愛電子有限公司，浙江 杭州 311100)

隨著汽車行業的不斷發展，汽車上電子元件日益增多，這使得車輛變得更加安全舒適，但也對車輛故障診斷提出了更高的要求[1]。近年來在車載診斷系統的研究方面，趙靜等人基于標準RS232串行通信對故障診斷儀的開發進行了研究[2]；汪玲燕等人將OBD技術與RMI、GPRS和GPS技術相結合，研發了OBD物聯網控制系統[3]；屠雨等人也對汽車OBD車聯網的軟硬件架構進行了相關研究[4]；謝江浩等人基于藍牙技術用Android手機終端采集了故障數據[5]。

這些研究將OBD技術與目前一些較先進的通信技術相結合，優化了車載故障診斷系統。但這些研究都基于一種型號的機型進行設計且通信質量受到環境限制，而標定實驗需要在各種極端環境下進行測試，因此這些技術在用于標定時穩定性較差。而CAN總線作為一種現場總線,由于其能夠實現信息共享、通信速率高、適應能力強、穩定性好、關聯控制等優點,在汽車上的應用越來越廣泛[6]。目前各個廠家的電控系統中集成的故障診斷系統所使用的PCODE碼各不相同[7-8]，不同廠家的設備往往不能通用，且大部分設備只會預留一個CAN通信接口，這也導致了故障診斷與標定數據采集難以同時進行，這對于標定工程師來說是極為不便的。

因此為了提高標定工作的效率，基于CAN通信開發了一款搭載于標定軟件內部的實時故障診斷系統。其在不影響數據讀取的前提下,實時診斷不同廠家的故障碼,并具有一定的擴展性與兼容性，這樣以便標定工程師在標定工作的同時讀取故障碼，從而提高標定效率。

1 系統總體架構

故障診斷系統總體分為三大部分，分別是通信模塊，解析模塊及Structure文件,系統結構如圖1所示。Structure文件分為兩個部分，分別為配置文件和PCODE碼文件。通信模塊負責與下位機建立CAN通信，結合配置文件為解析模塊收發數據。解析模塊對數據按照對應模式進行分類解析并對照PCODE碼文件得到最終結果，然后將結果顯示到程序界面上。Structure文件中的配置文件定義了CAN通信的相關屬性與通信代碼，以TXT文件的格式存儲。PCODE文件按照不同的模式以表格的形式存儲了故障碼內容和計算公式。Structure文件可以同時存在多份并在軟件運行時自由選擇，以便于不同系統間的切換。

圖1 故障診斷系統結構示意圖

2 通信模塊設計

2.1 通信結構

通信驗證以FAI公司的一款ECU為基礎，其選用的單片機型號為飛思卡爾的MC9S12G128，這款芯片自帶MSCAN模塊，能夠實施CAN協議2.0A/2.0B。MSCAN的兩個信號引腳分別是發送和接收，其輸出為TTL電平，而CAN總線上的通信信號需要通過差分電路來傳輸[9]，因此需加上一個英飛凌的TLE6250G高速收發器[10]。

通過使用周立功USBCAN來實現ECU和上位機軟件實時通信。上位機軟件以LabVIEW作為開發平臺。LabVIEW支持直接調用dll庫函數，因此可以直接調用與周立功CAN卡相匹配的CONTROLCAN.dll文件進行通信[11]。

通信模塊相對獨立，按照配置文件中定義ID將收到的信息進行篩選存儲。同時，由于兩個模塊相對獨立，因此在嵌入標定軟件時也較為靈活，若標定軟件已有CAN通信模塊則可以直接將數據輸入到通信模塊中進行篩選存儲，若沒有則可以將通信模塊與解析模塊封入一個子VI內，作為一個整體使用。

2.2 通信子VI的設置

上位機軟件通過調用庫函數實現CAN的打開、設置、初始化，以及指令收發和關閉。ZLGCAN提供了在PC端上使用的應用接口函數——VCI庫函數。VCI函數庫中定義了常用的數據結構，比如VCI_BOARD_INFO、VCI_CAN_OBJ、VCI_INIT_CONFIG等。可以通過這些事先定義好的數據結構進行數據傳輸。調用庫函數的子VI如圖2所示。

圖2 庫函數調用VI圖

診斷系統CAN通信的配置信息可以自由調節，調節方式為調用VCI_CANINIT函數，在VCI_INIT_CONFIG結構中定義了初始化CAN的配置，其具體結構如下所示。

DWORD AccCode

DWORD AccMask

DWORD Reserved

CHAR Filter

CHAR Timing0

CHAR Timing1

CHAR Mode

診斷系統的波特率可以通過VCI_INIT_CONFIG結構中的兩個定時器進行調節。在初始化界面上選擇合適的波特率，系統將自動分配相應的數據給定時器。從而實現波特率的調節，常用的波特率調節參照表如表1所示。

表1 波特率調節參照表(16 MHz晶振)[9]

為了便于在連接CAN卡的同時可以使用CAN Monitor進行調試，將序列號的選擇也加入到了初始化模塊中，這樣可以方便在同一臺電腦上連接多個CAN設備，避免因為占位沖突而導致無法接入CAN總線。

2.3 通信數據流的處理策略

由于CAN通信數據流中包含其他的數據，診斷系統由于實時性要求相對較低，因此需要診斷系統在保證正常診斷功能的前提下，盡可能少占用資源。由于診斷數據符合單進單出的特性，因此將篩選后的數據以隊列的形式存入到一組全局變量中，并同時將數據記錄。解析模塊調用全局變量即可接收數據，這樣既保證了數據的實時性，也降低了對系統資源的占用。

3 解析模塊與Structure文件的設計

3.1 解析模塊的基本架構

解析模塊以LabVIEW作為軟件開發平臺。LabVIEW是一款圖形化編程軟件，它編程效率高、擁有大量適用于測控領域的工具包、具有良好的平臺一致性[12]。解析模塊的運行需要兩個部分，分別是源程序與PCODE文件，源程序主要負責后臺解析與發送命令，PCODE文件存儲指令的內容等相關信息。PCODE文件可以按照不同廠家的協議自行制定，當需要對不同廠家的發動機進行診斷時，無需更換程序，只要選擇相應的PCODE文件即可。

3.2 源程序的設計

考慮到平臺的通用性，源程序只依照框架運行，框架內容保存于PCODE文件中。源程序通過調用PCODE文件中的數據實現對指令的解析。系統需要滿足OBD相關法規的要求，其應用層遵循ISO15031協議，底層遵循ISO15765-4。系統采用一問一答的機制，即上位機發出請求指令，ECU進行答復并進行相應動作，然后由上位機軟件依照ECU的答復進行后續操作。具體的邏輯框圖如圖3所示。

圖3 解析流程圖

3.3 指令的解析

ECU返回的數據需要經過解析并組成數組形式，具體示例如表2所示。

表2 解析示例表格

表格中的數據，以負反饋為例進行說明：03表示后面共有3個數據段，7F表示負反饋SID，04表示對SID4的應答，22表示負反饋(清除條件不足)。每個故障的代碼由兩個字節組成，依據OBD故障碼解析協議，經解析的故障碼方能與PCODE對照表中故障相對應。高字節的前四位可以對照表3進行轉換。高字節的后四位以及低字節相應轉換為十六進制數。完成解析后，對照PCODE碼文件將得到的結果返回到主界面上。

表3 故障碼轉換表[8]

3.4 Structure文件設計

Structure文件分為配置文件與PCODE碼文件。配置文件主要定義了與指令發送相關的內容。

以如下具體指令為例：PID(00h) 支持的PID(00h) XXXXXXXX 1 0 1 200 02010000000000000；(文中具體ID號由X代替)指令分別是指令名稱、指令描述、ID、幀類型、幀格式、發送次數、發送間隔、指令內容。依據ISO15031協議，軟件的主要功能模塊包括MODE1請求當前動力總成數據，MODE2請求動力總成凍結數據，MODE3請求已確認的排放診斷信息，MODE4清除相關診斷信息，MODE5請求氧傳感器檢測結果，MODE6請求非連續檢測系統OBD結果，MODE7請求當前或者前一駕駛循環識別到但還未確認的相關故障代碼，MODE8請求在線測試和控制，MODE9請求車輛控制器相關信息。因此，配置文件和PCODE文件的內容也分為九塊，各模塊相互獨立，在需要時可以單獨使用其中幾個模塊。

PCODE碼對照文件包含故障描述、PCODE碼以及轉換公式(沒有轉換公式的項可以不填)。由于各個廠商的PCODE碼各不相同，因此當針對不同的發動機進行測試時，可以在程序界面上自由切換不同的PCODE文件。

4 系統實驗

診斷程序界面如圖4所示，將程序嵌入到FAI公司的標定軟件DataView中進行測試。左側為指令發送窗口，右側為返回結果窗口。左側的指令從Structure文件中讀取。

實驗驗證分為模擬驗證和實車驗證。模擬驗證中，用CANMonitor來模擬故障代碼，檢測程序能否解析故障碼以及對不同廠家間故障碼診斷進行切換。模擬驗證如圖5所示，上半部分為使用CANMonitor手動發送申請指令，下半部分為過濾ID后ECU返回的指令。當模擬發送的信號發出后，軟件可以準確識別出返回信息。

圖4 軟件界面圖

圖5 模擬驗證

實際應用中，以FAI公司的標定軟件DataView為基礎，將模塊嵌入DataView中進行實車測試。驗證的方法是將軟件接入車輛的CAN總線，檢查能否實現通信。通過人為斷開一些接插件形成開路故障，以此檢測是否能夠順利讀出故障。最終，診斷模塊成功接入車輛的CAN通信網絡，同步完成標定數據的讀取和故障的解析。實車驗證如圖6所示。

圖6 實車驗證

5 結論

以LabVIEW為開發平臺，設計了基于CAN總線的新型故障診斷系統，完成了以下工作。

① 通過利用LabVIEW庫函數及工具包實現與周立功CAN卡的連接，并最終完成與ECU間的CAN通信。通信模塊基于ISO 15765-4協議開發，在此基礎上完成Structure文件的設計，實現通信數據的自由設置，以滿足不同機型的需求。

② 診斷模塊不僅適用于LabVIEW開發平臺，亦可通過LabVIEW C Generator將其轉換為C代碼，因此具有較高的通用性。將診斷模塊嵌入到FAI公司的標定軟件DataView中，證明該模塊具有良好的適用性。

③ 通過CANMonitor模擬發送故障代碼以及實車驗證兩種方法，對程序進行了驗證。在配置相應PCODE碼文件的情況下，該模塊能夠對不同廠家的發動機進行故障診斷。最終在東風凱普特車型以及其他車型上成功驗證了程序的可靠性。

④ 診斷模塊可以作為一個子模塊嵌入到標定軟件中，共享同一個通信道，在進行數據采集的同時實現實時診斷。通過更換相應的文件，可以實現對不同廠家發動機的故障診斷，從而提高發動機標定的工作效率。