基于MDI汽車故障診斷系統(tǒng)研究與開發(fā)

袁欣

（武漢科技大學(xué)，武漢 430081）

基于MDI汽車故障診斷系統(tǒng)研究與開發(fā)

袁欣

（武漢科技大學(xué)，武漢 430081）

針對傳統(tǒng)PC式汽車故障診斷系統(tǒng)的不足，本文提出了一種標(biāo)準(zhǔn)化的PC式汽車故障診斷系統(tǒng)，由標(biāo)準(zhǔn)診斷接口設(shè)備和診斷應(yīng)用軟件組成，硬件選用滿足SAE J2534標(biāo)準(zhǔn)的MDI診斷工具，研究了MDI通信機(jī)制和SAE J2534標(biāo)準(zhǔn)內(nèi)容，優(yōu)化了系統(tǒng)數(shù)據(jù)讀取速率，采用架構(gòu)層次化、功能模塊化的思路，開發(fā)了診斷應(yīng)用軟件。經(jīng)實(shí)車測試及分析，系統(tǒng)可實(shí)現(xiàn)對整車電控系統(tǒng)的故障診斷、維修幫助、實(shí)時(shí)監(jiān)控和在線刷新，具有良好的通用性和擴(kuò)展性，對應(yīng)用標(biāo)準(zhǔn)設(shè)備開發(fā)具有借鑒意義，為車輛診斷維修提供了有利工具。

車載診斷系統(tǒng)；汽車故障診斷；多功能診斷通信接口；SAE J2534

袁欣

袁欣，女，武漢科技大學(xué)電子信息工程專業(yè)2012級本科生。

前言

PC式汽車故障診斷系統(tǒng)因?yàn)樵趯?shí)時(shí)監(jiān)控、集成處理、功能擴(kuò)展、遠(yuǎn)程診斷等方面的優(yōu)勢，替代手持式診斷設(shè)備成為目前汽車診斷的主流選擇［1］。

然而，不同廠商支持的診斷總線類型、診斷引腳定義和診斷通信協(xié)議不盡相同，為滿足各大汽車廠商車輛內(nèi)部日益增多的ECU（ElectronicControl Unit）診斷任務(wù)的要求［2］。因此，筆者提出一種基于MDI（Multiple Diagnostic Interface）的PC式汽車故障診斷系統(tǒng)。

1　系統(tǒng)方案

系統(tǒng)由標(biāo)準(zhǔn)診斷接口設(shè)備（MDI診斷工具）和故障診斷軟件兩部分組成。系統(tǒng)的構(gòu)架如圖1所示。

標(biāo)準(zhǔn)診斷接口設(shè)備通過車輛的OBD（On-Broad Diagnosis）接口接入車載網(wǎng)絡(luò)，其主要負(fù)責(zé)筆記本電腦和車輛之間不同數(shù)據(jù)幀的封裝和信號的轉(zhuǎn)換。

故障診斷軟件安裝在筆記本電腦上，通過USB線與標(biāo)準(zhǔn)診斷接口設(shè)備連接，其主要負(fù)責(zé)向車輛ECU發(fā)送請求指令，處理應(yīng)答數(shù)據(jù)；同時(shí)筆記本電腦還可以通過互聯(lián)網(wǎng)訪問服務(wù)器數(shù)據(jù)庫，完成數(shù)據(jù)的上傳下載。

2　系統(tǒng)硬件

該系統(tǒng)采用筆記本電腦和標(biāo)準(zhǔn)診斷接口設(shè)備的硬件組合。標(biāo)準(zhǔn)診斷接口設(shè)備選用通用汽車公司的MDI診斷工具。

MDI診斷工具遵循SAE J2534標(biāo)準(zhǔn)，SAE J2534是用于車輛ECU編程刷新的軟硬件標(biāo)準(zhǔn)。通過滿足SAE J2534標(biāo)準(zhǔn)的接口設(shè)備不僅可以實(shí)現(xiàn)筆記本電腦和ECU的數(shù)據(jù)通信，也可以對ECU進(jìn)行重新編程［3］。同時(shí)MDI支持多種主流的車載通信協(xié)議，包括KWP2000、CAN總線（ID為11位的標(biāo)準(zhǔn)幀）、CLASS2、UART等［4］。另外，MDI充分的兼容了ISO 22900-1、ISO 22900-2、ISO 22900-3的標(biāo)準(zhǔn)，實(shí)現(xiàn)了新興MVCI（Modular Vehicle Communication Interface）軟件構(gòu)架，具有良好的擴(kuò)展性。

3　系統(tǒng)通信機(jī)制研究

MDI是基于SAE J2534標(biāo)準(zhǔn)設(shè)計(jì)的診斷工具。其數(shù)據(jù)處理、鏈路控制和流程控制是由MDI下位機(jī)軟件和SAE J2534規(guī)定的標(biāo)準(zhǔn)接口函數(shù)共同完成。

表1所示為SAE J2534定義的標(biāo)準(zhǔn)接口函數(shù)［5］。

表1　SAE J2534定義的標(biāo)準(zhǔn)接口函數(shù)

3.1通信過程建立

目前車輛上的電控模塊絕大多數(shù)選用K線或CAN總線通信協(xié)議，因此汽車故障診斷系統(tǒng)主要針對K線和CAN總線通信協(xié)議進(jìn)行開發(fā)，同時(shí)保留其他通信協(xié)議的接口，易于今后擴(kuò)展。圖2為調(diào)用標(biāo)準(zhǔn)接口函數(shù)實(shí)現(xiàn)通信過程的流程。

a. 與MDI建立連接：連接成功將返回設(shè)備ID。

b. 設(shè)置通信協(xié)議ID和相應(yīng)波特率：其中K線的協(xié)議ID設(shè)置為0x04，波特率設(shè)置為10 400kbps；CAN總線的協(xié)議ID設(shè)置為0x06，波特率設(shè)置為50 000kbps。設(shè)置成功將返回通道ID。

c. 過濾設(shè)置：對于K線，超過一定時(shí)間沒有數(shù)據(jù)交互，則會(huì)自動(dòng)斷開通信。因此需要每3s循環(huán)發(fā)送測試在線指令“3E”，以保持K線通信在線，同時(shí)過濾掉ECU正反饋指令“7E”，避免上位機(jī)對反饋數(shù)據(jù)的頻繁操作，節(jié)約資源；對于CAN總線，總線上傳輸著大量數(shù)據(jù)，通過CANID的過濾，篩選出需要的數(shù)據(jù)給上位機(jī)。

d. 通信初始化：對于K線的ECU，在開始通信之前還需要對其進(jìn)行初始化。這里選擇快速初始化方式，對應(yīng)接口函數(shù)PassThruIoctl的參數(shù)loctlID為0x05。

e. 數(shù)據(jù)收發(fā)：在上述設(shè)置成功后，便可直接調(diào)用PassThruWriteMsgs和PassThruReadMsgs進(jìn)行數(shù)據(jù)的收發(fā)。

f. 與MDI斷開連接：在結(jié)束診斷后，需要斷開指定協(xié)議的通信通道以及與MDI的連接，釋放資源。

3.2通信機(jī)制優(yōu)化

基于KWP2000協(xié)議的診斷服務(wù)必須遵循一定的時(shí)序來進(jìn)行，ISO 14230-2給出了診斷服務(wù)請求響應(yīng)過程的時(shí)序圖以及時(shí)序參數(shù)P1、P2、P3、P4的嚴(yán)格規(guī)定［6］。

P1、P2、P3、P4以及診斷系統(tǒng)的通信機(jī)制是影響數(shù)據(jù)讀取實(shí)時(shí)性的主要因素。協(xié)議已經(jīng)對P1、P2、P3、P4有著嚴(yán)格的規(guī)定，因此優(yōu)化診斷系統(tǒng)的通信機(jī)制是提高讀取數(shù)據(jù)實(shí)時(shí)性的唯一途徑。

不同的診斷服務(wù)對通信過程的實(shí)時(shí)性要求也不同。對于讀取故障碼，清除故障碼，讀取凍結(jié)幀，動(dòng)作測試和讀取模塊信息這些服務(wù)，完成診斷服務(wù)只需要一次請求應(yīng)答，對實(shí)時(shí)性的要求不高；而對于讀數(shù)據(jù)流服務(wù)，需要短時(shí)間內(nèi)連續(xù)的請求應(yīng)答。一次請求應(yīng)答的時(shí)間越短，每次請求時(shí)間間隔越小，車輛和發(fā)動(dòng)機(jī)運(yùn)行中各種參數(shù)的變化情況反映的就越真實(shí)。數(shù)據(jù)流讀取的實(shí)時(shí)性對于車輛故障診斷，車輛運(yùn)行狀態(tài)監(jiān)控有著極為重要的影響。因此，根據(jù)不同服務(wù)對實(shí)時(shí)性的要求，需要制定了不同的通信機(jī)制。

本文將汽車故障診斷系統(tǒng)的通信過程分為兩種情況來處理。對于實(shí)時(shí)性要求不高的非數(shù)據(jù)流服務(wù)請求，使用上位機(jī)的發(fā)送接收函數(shù)，一次請求應(yīng)答即可，如圖3所示；對于實(shí)時(shí)性要求較高的數(shù)據(jù)流服務(wù)請求，在兩個(gè)方面優(yōu)化了讀數(shù)據(jù)流的實(shí)時(shí)性，如圖4所示。

第一，在請求方式上，采用動(dòng)態(tài)定義讀數(shù)據(jù)流。傳統(tǒng)的讀數(shù)據(jù)流方式，每條數(shù)據(jù)流需要一次請求，當(dāng)選擇的數(shù)據(jù)流條目較多時(shí)，每次讀取需要多次請求，數(shù)據(jù)響應(yīng)將會(huì)滯后。而采用動(dòng)態(tài)定義讀數(shù)據(jù)流，將分配的動(dòng)態(tài)ID和所選的數(shù)據(jù)流PID組合成一個(gè)動(dòng)態(tài)定義請求指令（如2C、FE、00 05，其中2C為動(dòng)態(tài)定義服務(wù)指令，F(xiàn)E為動(dòng)態(tài)ID，0005為PID），肯定響應(yīng)后，便可用服務(wù)指令“AA01+所分配的動(dòng)態(tài)ID”來讀取數(shù)據(jù)流，這樣將要讀取的數(shù)據(jù)流動(dòng)態(tài)組合在一起，當(dāng)動(dòng)態(tài)定義請求成功后，每次讀取只需要一次請求即可。

第二，在通信過程上，采用循環(huán)發(fā)送請求。相比于每次都由上位機(jī)的發(fā)送函數(shù)來發(fā)送請求，采用MDI循環(huán)發(fā)送請求，將節(jié)省從上位機(jī)到MDI的傳輸時(shí)間。對于需要反復(fù)請求的數(shù)據(jù)流指令來說，每次請求應(yīng)答需要的時(shí)間縮短，將明顯提高了讀取數(shù)據(jù)流的實(shí)時(shí)性。

通過在數(shù)據(jù)流服務(wù)通信過程采用了周期循環(huán)發(fā)送和動(dòng)態(tài)定義相結(jié)合的方法，合理設(shè)置循環(huán)發(fā)送請求周期（T1）和循環(huán)接收數(shù)據(jù)周期（T2），對系統(tǒng)通信機(jī)制進(jìn)行了優(yōu)化。對某款采用K線通信協(xié)議的ECU進(jìn)行了通信測試，使用示波器檢測到K線讀取數(shù)據(jù)流時(shí)的波形圖。如圖5所示，循環(huán)發(fā)送的周期約為150ms，發(fā)送數(shù)據(jù)流請求與得到反饋的時(shí)間間隔約為45ms，完全滿足對讀取數(shù)據(jù)流實(shí)時(shí)性的要求。

4　系統(tǒng)軟件

診斷系統(tǒng)軟件選用Visual Studio 2008平臺(tái)，采用C#編寫。使用Microsoft SQL Server數(shù)據(jù)庫。

根據(jù)診斷系統(tǒng)硬件選型和需求分析，采用分層的設(shè)計(jì)思路，將軟件架構(gòu)從下到上分為四層：MDI驅(qū)動(dòng)層，數(shù)據(jù)訪問層，業(yè)務(wù)邏輯層，表示層。診斷軟件構(gòu)架如圖6所示。

4.1MDI驅(qū)動(dòng)層

MDI驅(qū)動(dòng)層主要負(fù)責(zé)標(biāo)準(zhǔn)接口函數(shù)的調(diào)用，將標(biāo)準(zhǔn)接口函數(shù)封裝成18個(gè)功能函數(shù)，供數(shù)據(jù)訪問層調(diào)用。驅(qū)動(dòng)層實(shí)現(xiàn)了數(shù)據(jù)訪問層和MDI接口函數(shù)的隔離。功能函數(shù)及描述如表2所示：

表2　MDI功能函數(shù)

4.2 數(shù)據(jù)訪問層

數(shù)據(jù)訪問層主要負(fù)責(zé)對MDI數(shù)據(jù)的發(fā)送和接收、數(shù)據(jù)庫的數(shù)據(jù)交互以及對服務(wù)器數(shù)據(jù)的上傳和下載。數(shù)據(jù)訪問層建立在MDI驅(qū)動(dòng)層之上，通過使用MDI驅(qū)動(dòng)層封裝的函數(shù)，設(shè)計(jì)了7個(gè)函數(shù)接口，供業(yè)務(wù)邏輯層調(diào)用。主要包括：

表3　數(shù)據(jù)訪問層接口函數(shù)

4.3業(yè)務(wù)邏輯層

業(yè)務(wù)邏輯層主要負(fù)責(zé)OBD指令生成，反饋數(shù)據(jù)解析和診斷數(shù)據(jù)管理。當(dāng)用戶通過操作接口給出診斷請求時(shí)，業(yè)務(wù)邏輯層會(huì)根據(jù)協(xié)議規(guī)定將請求封裝成標(biāo)準(zhǔn)的OBD數(shù)據(jù)幀傳遞給數(shù)據(jù)訪問層；當(dāng)數(shù)據(jù)訪問層接收到ECU的反饋數(shù)據(jù)時(shí)，業(yè)務(wù)邏輯層將從反饋數(shù)據(jù)中提取有效數(shù)據(jù)，根據(jù)協(xié)議規(guī)定解析成實(shí)際值，通過表示層顯示給用戶。

同時(shí)，業(yè)務(wù)邏輯層負(fù)責(zé)診斷系統(tǒng)功能的實(shí)現(xiàn)，主要包括常規(guī)故障診斷功能、維修診斷幫助功能、ECU在線刷新功能、軟件附屬功能四個(gè)部分。

常規(guī)故障診斷功能包括讀故障碼，清除故障碼，讀凍結(jié)幀，讀數(shù)據(jù)流，動(dòng)作測試等。通過數(shù)據(jù)訪問層的發(fā)送接收函數(shù)完成和ECU的數(shù)據(jù)交互。

維修診斷幫助功能是通過數(shù)據(jù)訪問層的MdbRead訪問診斷數(shù)據(jù)庫，從診斷數(shù)據(jù)庫中查詢相應(yīng)的維修幫助手冊內(nèi)容并顯示。

ECU在線刷新功能是通過數(shù)據(jù)訪問層的WebUpload和WebDownload完成與服務(wù)器的數(shù)據(jù)上傳下載，通過SendCommand完成對被刷新ECU數(shù)據(jù)的寫入，在線刷新的流程如圖7所示：

軟件附屬功能包括軟件激活，用戶認(rèn)證，密碼修改，軟件升級，診斷報(bào)告生成等。

4.4表示層

表示層主要負(fù)責(zé)數(shù)據(jù)的顯示和用戶操作接口的提供。如圖8所示，用戶界面主要包括狀態(tài)顯示區(qū)，主工作區(qū)和導(dǎo)航區(qū)三部分。狀態(tài)顯示區(qū)負(fù)責(zé)所選診斷功能、車型模塊及MDI連接狀態(tài)等狀態(tài)的顯示；主工作區(qū)負(fù)責(zé)用戶操作和結(jié)果顯示；導(dǎo)航區(qū)可以實(shí)現(xiàn)不同界面之間的切換和軟件的退出。

5　系統(tǒng)測試及結(jié)果分析

以某車輛（其電控模塊包括ECU，BCM，ABS，SDM，EPS，IPC等六個(gè)核心電控模塊）為測試對象，MDI診斷工具通過車輛OBD接口連入車載網(wǎng)絡(luò)，測試人員通過PC端的診斷軟件進(jìn)行故障診斷功能測試和模塊刷新功能測試。

5.1故障診斷功能測試

車輛故障燈常亮，讀到故障碼P0031，描述為上游氧傳感器加熱電路對地短路，初步判斷為上游氧傳感器故障，如圖9所示；讀取上游氧傳感器電壓數(shù)據(jù)流，發(fā)現(xiàn)電壓值曲線不變，意味著上游氧傳感器并未工作。根據(jù)軟件的維修診斷幫助逐步排查，更換上游氧傳感器后，重新讀取上游氧傳感器電壓數(shù)據(jù)流，電壓值在正常范圍波動(dòng)，恢復(fù)正常，如圖10所示。清除故障碼，故障燈熄滅，故障排除。

5.2在線刷新功能測試

車輛的發(fā)動(dòng)機(jī)控制模塊標(biāo)定數(shù)據(jù)需要更新時(shí)，使用軟件的在線刷新功能，可在ECU不拆卸的情況，將更新的標(biāo)定數(shù)據(jù)寫入發(fā)動(dòng)機(jī)控制模塊。刷新功能測試界面如圖11所示。整個(gè)刷新過程僅用時(shí)約15分鐘，相比傳統(tǒng)的更換電控模塊和拆卸回廠更新，大大節(jié)約了時(shí)間和成本。

6　結(jié)論

基于MDI的汽車故障診斷系統(tǒng)硬件選用滿足SAE J2534標(biāo)準(zhǔn)的診斷接口工具，兼容主流的車載網(wǎng)絡(luò)通信協(xié)議，具有良好的通用性；軟件采用架構(gòu)層次化、功能模塊化的開發(fā)思路，具有良好的擴(kuò)展性；對系統(tǒng)通信機(jī)制進(jìn)行了研究和優(yōu)化，實(shí)現(xiàn)了基于通用診斷通信接口裝置的PC式汽車故障診斷系統(tǒng)的開發(fā)，對應(yīng)用標(biāo)準(zhǔn)設(shè)備開發(fā)具有一定借鑒意義。

通過測試分析可知，該汽車故障診斷系統(tǒng)的數(shù)據(jù)讀取頻率高，響應(yīng)速度快，不僅能夠滿足診斷任務(wù)，還可以實(shí)時(shí)監(jiān)控車輛及發(fā)動(dòng)機(jī)的運(yùn)行狀況，此外還具備維修診斷幫助和電控模塊在線刷新功能，為車輛的診斷維修提供了有利的工具。

［1］顏伏伍， 王攀， 胡杰， 等. 基于車載總線的PC式汽車故障診斷系統(tǒng)［J］. 武漢理工大學(xué)學(xué)報(bào)， 2011，33（5）：758-762.

［2］郭剛， 王勵(lì)明， 盧明.基于MVCI、ODX的診斷標(biāo)準(zhǔn)研究［J］. 制造業(yè)自動(dòng)化， 2010， 32（12）：15-16.

［3］胡杰， 盛祥政， 李洪飛， 等. 基于智能手機(jī)的汽車故障診斷系統(tǒng)的研究與開發(fā)［J］.汽車技術(shù)， 2011，9：4-10.

［4］蔡浩， 汽車故障診斷系統(tǒng)的設(shè)計(jì)與開發(fā)［M］.上海：上海交通大學(xué)， 2009.

［5］SAE J2534-1， Surface Vehicle Recommended Practice［S］. 2004.

［6］ISO/WD14230-2， Road vehicles diagnostic system keyword protocol 2000 data Link［S］.1997.

專家推薦

周躍鋼：

基于MDI和SAE J2534協(xié)議的車載診斷系統(tǒng)的研究，實(shí)現(xiàn)乘用車電控系統(tǒng)故障診斷、維修診斷、實(shí)時(shí)監(jiān)控和ECU在線刷新，對整車故障診斷系統(tǒng)的開發(fā)具有參考意義。

The Research and Development of Vehicle Fault Diagnostic System Based on MDI

YUAN Xin
（Wuhan University of Science and Technology， Wuhan， 430081， China）

For the deficiencies of traditional PC-based vehicle fault diagnostic system， this paper proposes a kind of standardized PC-based vehicle fault diagnostic system which by the standardized diagnostic interface device and diagnostic application software， selects the MDI diagnostic device which conformed to SAE J2534 standard， studies the communication mechanism of MDI and SAE J2534 standard content， optimizes the data read rate， develops the diagnostic application software using the ideas of hierarchical architecture and function modularization. Through vehicle testing and analysis， this system allows the fault diagnosis， maintenance help， real-time monitoring and online refresh for vehicle electronic control system， has a good versatility and scalability， has a reference for developing standardized diagnostic device and provides the favorable tools for Vehicle Diagnosis and Maintenance.

On-Broad Diagnostic System； Vehicle Fault Detection； Multiple Diagnostic Interface；SAE J2534

U472.9

A

1005-2550（2015）03-0017-06

10.3969/j.issn.1005-2550.2015.03.004

2015-01-12