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

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

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

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

1 系統(tǒng)總體架構(gòu)

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

圖1 故障診斷系統(tǒng)結(jié)構(gòu)示意圖

2 通信模塊設計

2.1 通信結(jié)構(gòu)

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

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

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

2.2 通信子VI的設置

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

圖2 庫函數(shù)調(diào)用VI圖

診斷系統(tǒng)CAN通信的配置信息可以自由調(diào)節(jié)，調(diào)節(jié)方式為調(diào)用VCI_CANINIT函數(shù)，在VCI_INIT_CONFIG結(jié)構(gòu)中定義了初始化CAN的配置，其具體結(jié)構(gòu)如下所示。

DWORD AccCode

DWORD AccMask

DWORD Reserved

CHAR Filter

CHAR Timing0

CHAR Timing1

CHAR Mode

診斷系統(tǒng)的波特率可以通過VCI_INIT_CONFIG結(jié)構(gòu)中的兩個定時器進行調(diào)節(jié)。在初始化界面上選擇合適的波特率，系統(tǒng)將自動分配相應的數(shù)據(jù)給定時器。從而實現(xiàn)波特率的調(diào)節(jié)，常用的波特率調(diào)節(jié)參照表如表1所示。

表1 波特率調(diào)節(jié)參照表(16 MHz晶振)[9]

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

2.3 通信數(shù)據(jù)流的處理策略

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

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

3.1 解析模塊的基本架構(gòu)

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

3.2 源程序的設計

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

圖3 解析流程圖

3.3 指令的解析

ECU返回的數(shù)據(jù)需要經(jīng)過解析并組成數(shù)組形式，具體示例如表2所示。

表2 解析示例表格

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

表3 故障碼轉(zhuǎn)換表[8]

3.4 Structure文件設計

Structure文件分為配置文件與PCODE碼文件。配置文件主要定義了與指令發(fā)送相關(guān)的內(nèi)容。

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

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

4 系統(tǒng)實驗

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

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

圖4 軟件界面圖

圖5 模擬驗證

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

圖6 實車驗證

5 結(jié)論

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

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

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

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

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