基于K總線的汽車靜態測試儀高效調試

王明非，魯統利，王天軍

（1.上海交通大學 汽車工程研究院，上海 200240；2.上海通用汽車有限公司，上海 201201）

汽車靜態測試是利用測試儀通過OBDII接口與汽車電子控制單元（Electronic Control Unit，ECU）的診斷系統進行交互式通訊，從而獲取汽車各個控制單元的狀態數據和故障信息。在此過程中，測試儀可以控制汽車各部件的工作和設定其運行狀態。此外，測試儀還具有元件測試、讀取數據流、匹配標定、代碼升級等功能。汽車靜態測試[1]是對實車進行離線測試，是對汽車動態測試[2]的簡化。目前其測試儀程序的調試工作也都是在實車上進行的。

KWP2000診斷協議是由國際標準化組織下的車載電氣電子設備分委員會制定的，是目前相對比較完善，被廣泛應用的一種診斷協議[1]。

現在世界上各大汽車制造商，在總裝線終端檢測時都要使用測試儀對汽車進行靜態測試和動態測試。而測試儀程序的調試工作卻是在實車上進行。這種調試方法存在以下幾個缺陷：（1）汽車運行達到期望狀態所用時間長。（2）故障碼設置不方便，甚至有時為了獲得故障碼，需在實車上設置實際的物理故障。（3）需要大量的車輛和人員的參與。在生產實際中以上幾個缺陷使汽車測試儀的測試程序調試過程十分繁瑣且成本高。

為解決生產實際中測試儀調試存在的這些問題，基于上述背景，本文通過對KWP2000通信協議和汽車靜態測試通信數據的研究，融合汽車診斷技術和計算機仿真技術，開發了一套汽車靜態測試儀程序調試系統（以下簡稱“調試系統”），率先實現了測試儀與汽車K總線通信數據模擬，使測試程序調試的效率大大提高，具有較高的實用價值和實際意義。

1 原理分析

1.1 調試系統功能

在調試過程中，測試系統向調試系統發送請求消息，調試系統根據請求消息（輸入）解析出響應消息（輸出）反饋給測試系統，并按照請求消息對數據庫中的數據進行動態修改；調試系統使用者在軟件界面上操作，對調試系統發送控制消息，調試系統根據使用者的控制輸入改變程序數據庫中的數據，實現對駕駛員操作和故障碼生成的模擬。調試系統原理圖如圖1所示。

1.2 KWP2000分析

KWP2000根據開放系統互連（Open Systems Interconnection，OSI）的7層基本參考模型，從整體結構上將通信系統分為3層：（1）應用層（第7層，由ISO14230-3描述）。（2）數據鏈路層（第2層，由ISO14230-2描述）。（3）物理層（第1層，由ISO14230-1描述）。

以某采用KWP2000通信的車型為研究對象，該車通信協議規定的報文結構格式見表1[3]。可以按照協議規定解析請求消息并給出符合報文結構規定的響應消息。

表1 KWP2000報文結構

1.3 調試原理

在分析KWP2000規定的數據結構的基礎上，利用英特佩斯電子控制系統公司的NeoVI FIRE通信硬件[4]和PC機（含USB接口）組成通信調試系統，可實現KWP2000協議通信的物理層和數據鏈路層。在應用層上設計軟件系統實現邏輯判斷和運算功能，就能實現汽車ECU的測試通信模擬。其中，整個系統開發的工作重點是軟件系統設計，即建立軟件模型與邏輯實現。軟件設計的重點是在邏輯上實現按照協議解析請求消息和控制消息，即解析模塊設計。

依據NeoVI FIRE的數據結構和應用函數[4]設計了：（1）通信接口模塊，實現了搭載報文消息的結構體數組的收發。（2）解析模塊流程的第1、2、5、6步，實現報文消息與結構體數組格式轉換收發。

按照該車型的KWP2000協議規定[3]和調試系統功能分析設計了：（1）解析模塊流程的3、4步，實現請求和控制消息解析與響應。（2）數據庫模塊，模擬汽車ECU數據。（3）系統主體，調用各模塊功能以實現主功能。

按照調試過程中的具體操作需要，設計了設置、顯示等模塊。

2 硬件組成設計

采用NeoVI FIRE通信硬件[4]做二次開發，搭建調試系統物理通信線路。硬件系統組成和連接如圖2所示。

3 軟件設計與開發

3.1 軟件系統結構設計

整個軟件系統的開發采用VC++/ MFC平臺。軟件系統功能由模塊化設計實現——對話框模塊、接口模塊、解析模塊、數據庫以及系統主體；對話框模塊分設置、顯示、控制分模塊。設置模塊具有設置數據庫的功能；接口模塊實現NeoVI FIRE結構體數組的收發功能；控制模塊可從用戶界面接收控制指令并通過系統主體傳遞給解析模塊，實現數據庫數據修改；解析模塊從結構體數組中識別出請求消息，解析請求消息和控制命令，給出符合NeoVI FIRE結構體數組格式的響應消息，并按照請求消息、控制消息修改數據庫數據；顯示模塊可以實現通信數據的實時顯示和動畫模擬。其中對話框模塊、接口模塊和解析模塊通過動態連接庫編程實現；系統主體調用各模塊動態連接庫的導出函數調用該模塊的功能；由于ECU數據占用PC機空間很小，采用程序運行時的內存即可實現數據庫功能。調試系統軟件結構和數據流示意圖如圖3所示。

3.2 接口模塊設計

使用NeoVI FIRE通信硬件提供給用戶的應用函數可調用通信硬件的功能，實現通信接口的打開、關閉和搭載報文的結構體的接收、發送。接口模塊流程圖如圖4所示。

3.3 解析模塊設計

解析模塊的功能是根據協議解析請求命令和控制命令，通過運算得出響應消息，再將響應消息封裝在結構體數組中發送給系統主體，并修改數據庫數據。這些過程模擬了汽車ECU數據的調用和改變，從而實現對實車K總線通信數據的模擬。

請求命令解析過程如圖5所示，解析模塊從系統讀取結構體數組，并從中解析出請求消息的頭和數據（第1、2步）。然后根據請求消息的數據運算出響應消息的數據，根據請求消息的頭和響應消息數據運算出響應消息的頭（第3、4步）。最后設置封裝響應消息的結構體數組并發送給系統主體。

其中第3步，根據請求消息中的ECU、 SID(Service Identification，服務號)以及其它數據信息解析出響應消息數據的過程，是實現汽車診斷通信數據模擬的關鍵。根據SID的不同（汽車靜態測試中常用的SID共計17種），調試系統對請求消息的響應動作大致可分為4大類。

（1)直接一次響應。按照協議要求和測試儀的測試通過期望值，對以下服務號：SID=10（開啟診斷會話）/ 11（ECU重設）/ 2C（動態定義本地標識符）/ 31（本地標識符開啟程序）/ 3E（測試儀參與）/ 81（開啟通信）/ 82（結束通信），調試系統只需給測試儀發送1條正響應消息。按照協議規定，測試儀收到這條響應消息就會認為本次請求測試通過。例如，某請求消息中SID=81，表示測試儀請求開啟與汽車ECU的通信，這時調試系統只需在響應消息中給出正響應標識符C1，測試儀就會認為其與汽車ECU的通信已經開啟，下一步就可以發出其它服務的請求。

（2）數據庫一次響應。以下服務號：SID=13（讀診斷故障碼）/ 18（根據狀態讀診斷故障碼）/ 19（根據狀態讀診斷故障碼狀態）/ 1A（讀ECU身份）/ 21（根據本地標識符讀狀態）/ 22（根據公共標識符讀狀態）/ 27（安全進入），是測試儀在請求獲得汽車ECU數據。測試儀發出這個請求后不僅期望得到正響應標識符，還需要得到期望的數據，這類數據包括ECU身份（汽車VIN號）、故障碼、汽車各單元狀態（如發動機轉速、油溫、元件電壓，自動變速器擋位、安全氣囊狀態等），安全進入種子數據等等。對包含這些服務號的請求，調試系統要對其做出正響應并在數據庫中檢索測試儀需要的數據，然后將正響應標識符和檢索到的數據組合成響應消息并發給測試儀。測試儀收到這樣的響應消息后，會認為是汽車ECU發送了這些數據，根據這些數據獲知并分析汽車各單元的狀態或故障信息。如果有異常狀態或故障碼，測試儀界面就顯示測試失敗。數據庫數值的格式和數值精度要靠系統使用者人工設定。例如，某請求消息中SID=21，要求讀取PID=01（某車發動機全部狀態數據）的狀態（見數據庫設計），則調試系統將數據庫中的相應數據打包成響應消息，反饋給測試儀。測試儀收到這些數據就會進行判斷所讀取的元件狀態是否滿足測試要求，若滿足測試要求則可進行接下來的測試項目。又如SID=18，測試儀期望讀取ECU的故障碼，則調試系統將數據庫中設置的故障碼發給測試儀，測試儀收到故障碼后，會在界面上顯示故障，并在最終的測試報告中記錄這個故障。

（3）直接一次響應+數據庫操作。符合這種情形的服務是SID=14（清除診斷信息）/ 3B（根據本地標識符寫數據）。測試儀不僅能從汽車ECU讀數據，還可以向ECU寫數據，比如汽車VIN碼（17位數字或字母，相當于汽車“身份證號”，俗稱車輛17位碼，每輛車的VIN碼是唯一的）。如果通過請求得到的VIN號是“錯誤”的（與測試儀測試程序中設定VIN號不一致），則會為汽車ECU寫一個的“正確”的VIN號（測試儀設定值）。在模擬測試中，調試系統要能模擬錯誤的VIN碼被測試儀改正的過程。第1步，調試系統儲存在數據庫中的VIN碼是錯誤的；第2步，測試儀發出請求得到錯誤的VIN號，并識別了錯誤 ；第3步，測試儀會發送SID=3B的請求，給ECU寫一個正確的VIN號；第4步，調試系統根據測試儀的請求消息將“正確”的VIN碼寫入數據庫中的相應位置；第5步，測試儀再次發出讀取VIN號的請求；第6步，調試系統將寫“正確”了的VIN號發給測試儀。到此，測試儀判斷汽車VIN碼正確，從而可以進入接下來的測試內容。

（4)數據庫一次響應+數據庫操作。對于SID=30（根據本地標識符輸入輸出流控制），系統要解析請求消息，根據數據庫數據給出響應；并根據請求消息的內容和預先設定的數據庫向導數據修改數據庫目標數據。例如，某車測試中請求消息為84 11 F1 30 24 07 96 77，調試系統對其進行解析可知ECU為11（發動機），SID=30（流控制）控制項目為24（怠速控制），控制方式為07（短期調整），控制數值為96（按協議換算后為1 500 r/min），校驗碼77正確，則下一步就根據數據庫中的向導數據IOControlTarget_24 07 96=PID_01將發動機的轉速數值（表2中PID_01等號后面的值第29、30字節）改為1 500 r/min [把0B B8（表示750 r/min[3])改為1 770（表示1 500 r/min[3]）]；并從數據庫中找到該請求消息的正響應消息84 F1 11 70 24 07 96 B7發給測試系統，表示發動機轉速已經調整至測試儀要求的1 500 r/min ；隨后測試儀再次發出請求消息讀取發動機ECU的狀態數據；調試系統再次給出發動機狀態數據響應，測試儀就會讀到發動機轉速為17 70（1 500 r/min[3]），則該項測試通過，可進入下一項測試。

除了對請求輸入進行解析之外，調試系統還可以通過解析控制輸入對數據庫中的所有數據進行設定和修改。這樣就可以實現對各個單元的身份數據、狀態數據、故障碼等數據內容進行人為設置，驗證測試程序讀狀態數據和故障碼的功能，即測試程序調試。控制命令解析過程如圖6所示。

3.4 數據庫設計

數據庫的功能可利用Windows的應用程序初始化功能和PC機內存實現。利用Windows應用程序初始化功能需編寫ini格式文件，并在軟件程序中使用Windows 應用函數（API）對ini文件進行讀寫操作。

ini文件是windows的系統配置文件，統管Windows的各項配置，這里可以利用其為調試系統程序的內存數據初始化，實現虛擬數據庫的作用。Windows應用程序初始化文件（ini文件）由節、鍵、值組成，其數據格式如下[5]：

對象車型某ECU的ini格式模擬內存數據見表2。

在仿真開始時，將ECU數據按照ini文件的格式初始化到程序內存中。調試過程中，系統讀到請求消息，解析請求消息的ECU、SID等信息，根據解析到的關鍵字檢索數據庫（內存數據）中的鍵，然后讀取對應的值，根據讀到的值生成響應消息。

4 實際應用結果與分析

4.1 調試系統應用

通過功能測試和可靠性測試后，調試系統應用于上海通用汽車整車制造總裝終檢線的汽車靜態測試程序調試中。圖7為調試系統實物圖；圖8為調試系統軟件界面圖。

4.2 應用結果與分析

狀態數據模擬方面，調試系統的ECU狀態數據可以通過人工快速設定，達到并精確地穩定在測試要求的理想值，如發動機轉速無誤差地穩定在750 r/min 、1 500 r/min 等數值上。利用這一點可以快速精確地標定和驗證測試儀程序的參數。圖7和圖9為調試系統通過某次測試時的實物圖和測試儀界面。圖7顯示發動機轉速可人為精確達到并穩定在1 500 r/min 。圖10為在另一次模擬測試中發動機轉速精確地達到并穩定在2 000 r/min 。

故障碼設置方面，調試系統可以輕易設置在實車上不易設置的各種故障。利用這一點可以檢驗測試儀能否及時、正確地讀取并識別故障。圖10為測試儀讀到用調試系統人為設置的故障碼時，顯示故障信息的界面。

從實際應用結果可以看出：（1）調試系統可快速地模擬設置汽車各種狀態數據（實車達到期望狀態時間長）。（2）調試系統可全面設置汽車靜態測試中各種故障碼（有些故障在實車上難以設置）。（3）調試系統使測試程序調試減少對實車環境的依賴。

5 結論

針對生產中K總線汽車靜態測試程序采用實車調試存在的缺陷，提出了一種模擬實車總線通信的測試儀高效調試方法，并開發了汽車靜態測試儀調試系統。調試系統與實車相比，狀態數據設置快速、精確，故障碼設置快速、全面，并且減少對實車和場地的依賴。這種模擬通信的調試方法比實車調試速度快、功能強、成本低，彌補了后者的不足，大大提高了汽車靜態測試程序調試的效率。

在實踐中，該調試系統已廣泛應用于上海通用汽車整車制造終檢線靜態測試程序的調試，在最新幾款車型中該系統均得到高度利用，節省了大量人力、物力、時間成本，大大提高了測試程序的調試效率和可靠性。

該調試系統為日后下一代汽車測試系統和診斷系統的開發提供了方便。該調試方法是基于K總線汽車靜態測試進行的研究，其成果為其它總線和協議的測試儀調試提供了參考。進一步探索，由于汽車動態測試的車載ECU診斷通信模式與汽車靜態測試基本相同，同時轉鼓試驗臺工控機的串口通信也可以采用類似方法進行模擬，因此本文的工作為將來實現汽車動態測試系統（測試儀+汽車+轉鼓）的測試儀高效調試打下了重要基礎。

[1]呂奕曄.汽車診斷協議KWP2000的實現與應用[D].哈爾濱：哈爾濱工業大學，2007.Lü Yiye. The Implementation and Application of Vehicle Diagnostic Protocol 2000 [D]. Harbin： Harbin Institute of Technology，2007. (in Chinese)

[2]孫永佳，張睿.汽車動態測試—DVT [J].沈陽航空工業學院學報，2004，21(2)： 34-36.Sun Yongjia，Zhang Rui. Vehicle Dynamic Test— the DVT[J]. Journal of Shenyang Institute of Aeronautical Engineering，2004，21(2)： 34-36. (in Chinese)

[3]Keyword Protocol 2000 Implementation of Diagnostic Services Recommended Practice[S]. [S.l.]：United Automotive Electronic Systems Co. Ltd，2007.

[5]Intrepid Control Systems. Intrepidcs API Documentation[EB/OL]. http：//intrepidcs.com/support/ICS Documentation/neo VI DLL/neo Frame Main. htm，2008-11-11.

[6]宋坤，劉銳寧，李偉明.MFC程序開發參考大全[M].北京：人民郵電出版社，2007.Song Kun，Liu Ruining，Li Weiming. MFC Application Development Reference Books [M]. Beijing：The People's Posts and Telecommunications Press，2007. (in Chinese)