段秀麗

（長春市醫(yī)藥化工工業(yè)技工學(xué)院，吉林長春 130025）

一、引言

目前社會對汽車安全性能的廣泛重視，引起了汽車電控系統(tǒng)的快速發(fā)展，也給汽車診斷技術(shù)帶來了新的任務(wù)。汽車診斷技術(shù)是用來發(fā)現(xiàn)和分析汽車發(fā)生故障的部件和區(qū)域，通常包含三個部分分別是故障診斷，性能測試和狀態(tài)監(jiān)測[1]。汽車故障診斷的發(fā)展由直觀法、儀表法和直觀法組成，隨著汽車電子技術(shù)的迅猛發(fā)展，對汽車進行故障檢測也取得了相應(yīng)的進步，產(chǎn)生了專業(yè)的汽車診斷儀，并且作為一門新興技術(shù)登上了汽車便攜檢測的舞臺。

現(xiàn)在汽車行業(yè)的格局，汽車的品牌和型號眾多，具有其獨立的電控點系統(tǒng)，從而產(chǎn)生一個問題，即測試不同汽車故障需要不同的診斷儀，這將產(chǎn)生巨大的人力、物力的浪費，不利于綠色工程設(shè)計標準。為解決該問題，必須有效擴展診斷儀的適應(yīng)性，即開發(fā)適合不同汽車生產(chǎn)廠家的ECU診斷程序，在診斷不同ECU時，程序自動識別相對應(yīng)診斷協(xié)議，而開發(fā)汽車診斷儀與電控單元的通信軟件是解決汽車診斷儀可擴展性的技術(shù)難點和關(guān)鍵。

二、總體方案及硬件接口單元

1、總體方案

汽車各生產(chǎn)廠家的電控單元外接硬件接口由其自身的標準，如何滿足汽車診斷儀的硬件接口一致性是方案設(shè)計的關(guān)鍵。汽車廠家在成產(chǎn)整車的過程中，采用診斷總線的不同，造成診斷接口硬件引腳定義不同，其傳輸協(xié)議也不相同。定義的硬件接口，需要兼容市場上常用的診斷協(xié)議，即K-Line和CAN BUS，K線是單線傳輸，CAN總線是雙線傳輸。因此通信配置器的硬件必須滿足上述兩種接口定義。汽車生產(chǎn)企業(yè)在開發(fā)汽車電控單元時參考ISO或SAE定義自身的診斷協(xié)議。ISO 2290提出一種基于XML描述的O D X數(shù)據(jù)庫，解決了各汽車電控生產(chǎn)廠家診斷協(xié)議上的不一致。因此該通信軟件的開發(fā)主要分為兩個部分，一是利用XML描述汽車電控單元的診斷數(shù)據(jù)是該通信軟件設(shè)計，二是上位機應(yīng)用軟件調(diào)用D-PDU API的編寫，由于配置器部分的開發(fā)是汽車診斷儀與汽車電控的連接部分，其總體設(shè)計方案如圖2.1所示。

圖2.1總體設(shè)計圖

應(yīng)用層用戶可在界面上選擇需要檢測的ECU，發(fā)送相關(guān)的診斷指令，通過診斷接口和配置器將指令數(shù)據(jù)發(fā)送至汽車控制單元。配置器的主要功能是統(tǒng)一診斷設(shè)備的進行主機與汽車電控單元的通信，并完成電平轉(zhuǎn)換，可進行通信接口的選擇如K-Line或是CAN BUS等。

2、硬件接口描述

目前，汽車診斷接頭上定義的硬件接口，能夠滿足SO9141、CAN、KWP2000、PWM、VPW協(xié) 議 。 其中General Motors使用的是是VPW，F(xiàn)ord使用的是PWM，BMW使用的是KWP2000。OBD-Ⅱ16針的診斷座在J1962協(xié)議中進行了定義，引腳定義如表2-1。對比于OBD-II診斷插頭，HD26除了兼容前16引腳外，另外定義了10個引腳如表2-2。

表2 -1O B D-I I診斷插頭引腳定義表

對比于OBD-II診斷插頭，HD26除了兼容前16引腳外，另外定義了10個引腳如表2-2。

表2 -2H D 2617－26引腳說明

三、診斷協(xié)議比較分析

當今汽車故障檢測領(lǐng)域中，經(jīng)常使用三種協(xié)議分別是SAE J1939，ISO 14230 和ISO 1576, 三者都是以ISO/IEC10731 和ISO/IEC7498標準下的Open Systems Interconnection

七層協(xié)議為依據(jù)。ISO14230稱為KWP 2000具有獨立的物理層，14230－1表示物理層、14230－2表示數(shù)據(jù)鏈接層、14230－3表示應(yīng)用層。ISO 15765協(xié)議不包含物理層和數(shù)據(jù)連接層。ISO 15765協(xié)議沒有定義自己的物理層和數(shù)據(jù)鏈路層；SAE(美國汽車工程師協(xié)會)J 1939協(xié)議包括物理層、數(shù)據(jù)鏈接層、網(wǎng)絡(luò)層和應(yīng)用層。以上三種協(xié)議及Open Systems Interconnection七層協(xié)議詳見表3-1。

表3-1 三種協(xié)議與OSI七層協(xié)議對比列表

四、軟件開發(fā)程序舉例

本文以軟件平臺中的“讀故障碼（Read DTC）”為例，程序代碼開發(fā)流程圖，如圖4.1所示。程序主要運行步驟為:診斷接口硬件初始化、用戶指令輸入、點擊汽車故障診斷碼、程序調(diào)用讀故障函數(shù)ReadDTC()、產(chǎn)生相關(guān)參數(shù)、函數(shù)內(nèi)部解析XML、查詢讀故障服務(wù)號、配置相關(guān)參數(shù)文件，顯示汽車故障信息。

圖4.1 程序流程圖

五、軟件實驗

1、實驗內(nèi)容:應(yīng)用層用戶選擇讀取汽車故障碼，MDF中查找故障碼數(shù)據(jù)，利用CDF選取相關(guān)發(fā)送函數(shù)，形成 CAN數(shù)據(jù)幀，依據(jù)返回值判斷發(fā)送是否成功，調(diào)用接收函數(shù)，查詢CAN數(shù)據(jù)幀，如果超時時間接受收到有效數(shù)據(jù)，則再次查詢MDF文檔，翻譯數(shù)據(jù)，刷新屏幕顯示，顯示故障代碼和名稱。

2、數(shù)據(jù)顯示

汽車故障診斷SOFTING DTS顯示相關(guān)數(shù)據(jù):

用戶按下讀取故障診斷碼，程序自動發(fā)送0x13 0x01，汽車電控單元響應(yīng)信號，由于響應(yīng)信號長度超過8個字節(jié)，因此需要分包傳輸。汽車診斷儀根據(jù)電控單元的響應(yīng)，產(chǎn)生相應(yīng)的數(shù)據(jù)流控制幀，同時電控單元依據(jù)控制幀發(fā)送余下的數(shù)據(jù)包，上位機顯示界面，如圖5.1所示。

圖5.1故障診斷結(jié)果顯示

六、結(jié)論

該軟件已經(jīng)在相關(guān)車型的電控單元通過測試，可以實現(xiàn)相應(yīng)電控單元的故障報告，同時由于選取的相關(guān)車型，涵蓋國內(nèi)常見的幾種診斷協(xié)議，也在相應(yīng)的物理總線上經(jīng)過測試，驗證汽車故障診斷儀與電控單元的通信軟件開發(fā)的有效性。

[1]喬美昀,王印.汽車診斷系統(tǒng)的通訊開發(fā)與研究[J].裝備制造技術(shù).2010(11)

[2]曹興舉.當前汽車檢測診斷設(shè)備的特點與發(fā)展趨勢.汽車維護與修理[J].2012(09)

[3]卞光榮,丁興運,陳洪林.現(xiàn)代汽車故障診斷思路淺談.2005(02)

[4]黃麗芳.UDS診斷服務(wù)在車載ECU中的應(yīng)用分析[J].汽車電器.2012(06)

[5]張杰,蘇建成.汽車故障診斷分析方法與發(fā)展[J].汽車零部件.2012(10)