李璐　蔡永祥　史延雷　王煒　唐鵬

摘 要：汽車診斷需求隨著電子技術(shù)的發(fā)展而不斷提高，手動測試及單個ECU專用測試系統(tǒng)已經(jīng)很難滿足測試需求，因此有必要設(shè)計一種靈活性及通用性高的診斷自動測試系統(tǒng)。設(shè)計的測試系統(tǒng)基于VT System開發(fā)，硬件使用Vector工具鏈的VT板卡及VH6501配置測試環(huán)境。系統(tǒng)通過vTESTstudio編寫測試腳本，在CANoe環(huán)境下進行測試，通過參數(shù)變量化、函數(shù)模塊化的方式，使系統(tǒng)具有很強的柔性，適應(yīng)多種車型和ECU。

關(guān)鍵詞：診斷 VT System 自動化測試 柔性設(shè)計

1 引言

汽車技術(shù)在朝著電子化和智能化發(fā)展的過程中，汽車故障診斷技術(shù)也隨之快速發(fā)展，ECU（Electronic Control Unit，電子控制單元）內(nèi)部已經(jīng)實現(xiàn)了故障識別和故障碼存儲[1]。隨著CAN總線的廣泛使用和ISO標準的制定，汽車故障診斷逐漸由分散走向統(tǒng)一[2]。

汽車診斷協(xié)議也隨著汽車技術(shù)的發(fā)展而發(fā)展，當前應(yīng)用廣泛的UDS（Unified Diagnostic Services）診斷協(xié)議，由ISO 14229、ISO 15765標準定義。KWP2000及LIN線診斷基本已處于退出診斷市場的狀態(tài)，OBD（On Board Diagnostics）診斷由SAE標準定義，主要定義排放與動力相關(guān)診斷，OBD接口也可作為診斷接口實現(xiàn)實車與外界設(shè)備互聯(lián)[3]，且該接口同樣支持UDS協(xié)議。本文主要面對UDS診斷協(xié)議相關(guān)測試內(nèi)容，開發(fā)一套車載電控單元柔性自動化診斷測試系統(tǒng)。

柔性控制是現(xiàn)代控制理念中新發(fā)展出來的一種先進控制概念，追求更少的時間周期、高適應(yīng)性、開放式及分布式的控制系統(tǒng)[4]。參照控制理念，自動測試系統(tǒng)也應(yīng)具有相當?shù)娜嵝砸詽M足測試需求。本文中，柔性可以理解為一種設(shè)計理念，使用較少的變動即可滿足同一網(wǎng)段所有ECU，乃至整車所有網(wǎng)段ECU的診斷測試。通過柔性理念設(shè)計的測試系統(tǒng)，可以應(yīng)用到不同的汽車網(wǎng)絡(luò)架構(gòu)，使測試系統(tǒng)開發(fā)周期縮短、靈活性更高。這也符合汽車診斷多功能化、智能化及資源共享的發(fā)展趨勢[5]。

車載電控單元診斷測試主要分為三部分：診斷協(xié)議測試、診斷刷寫測試、診斷DTC（診斷故障碼）測試。其中診斷協(xié)議測試、診斷刷新測試兩部分，在當前市面上已有成熟的測試軟件進行測試，如Diva、vFlash等軟件，且這兩部分對硬件的依賴程度較低。而診斷DTC測試則不同，它分為兩中測試類型：網(wǎng)絡(luò)通信相關(guān)DTC測試、電氣相關(guān)DTC測試。診斷DTC測試具有以下特點：

● 定制化測試邏輯開發(fā)

● 差異化參數(shù)配置

● 測試環(huán)境復雜

● 手動測試時間參數(shù)控制困難

在ECU總線數(shù)據(jù)中，DTC由4個字節(jié)數(shù)據(jù)組成，前三個字節(jié)數(shù)據(jù)為故障代碼，最后一個字節(jié)數(shù)據(jù)表示該故障代碼的狀態(tài)掩碼。其中故障代碼由主機廠定義在診斷調(diào)查表中，如0x910401表示近光燈繼電器故障，0xD80297表示某節(jié)點通信丟失故障，等。狀態(tài)掩碼的使用說明如下表1，狀態(tài)掩碼代表該故障的狀態(tài)。

對于診斷DTC測試，主要關(guān)注兩種DTC狀態(tài)：當前故障碼狀態(tài)和歷史故障碼狀態(tài)。如果為當前故障碼狀態(tài)，則bit（0）=1，如果為歷史故障碼狀態(tài)，則bit（3）=1。

由于以上特點及需求，導致診斷DTC測試難以手動進行，為解決診斷DTC測試困難的問題，需要設(shè)計一套自動化測試系統(tǒng)。本文以VT System為硬件基礎(chǔ)，輔以中汽研（天津）汽車工程研究院有限公司自研的測試電路配置板卡，以CANoe為軟件平臺，以柔性設(shè)計作為理念，設(shè)計了一種新的汽車電控單元診斷自動測試系統(tǒng)，較手動測試而言，該系統(tǒng)具有自動化程度高、通用性強、靈活性高等優(yōu)點，能覆蓋電氣故障碼及網(wǎng)絡(luò)故障碼測試，且能夠擴展支持診斷協(xié)議測試、診斷刷新測試，測試內(nèi)容全面。

2 系統(tǒng)概述

2.1 測試工具

測試系統(tǒng)包含的工具有軟件和硬件兩部分：軟件部分包括CANoe、vTESTstudio、測試管理軟件;硬件部分包括VT System、程控電源、測試電路配置板卡等。

CANoe是德國Vector公司開發(fā)的分布式系統(tǒng)設(shè)計、仿真、測試、評估的工具軟件，功能強大，本測試系統(tǒng)主要應(yīng)用它的仿真和測試功能，另外，CANoe自帶功能強大的數(shù)據(jù)管理工具CANdb++，可以創(chuàng)建和修改數(shù)據(jù)庫[6]，該功能可以實現(xiàn)將變量加載入測試工程，變量化參數(shù)對于提高系統(tǒng)的柔性有很大的幫助。系統(tǒng)的測試腳本由vTESTstudio軟件編寫，vTESTstudio是Vector公司開發(fā)的測試開發(fā)軟件，由于其支持CAPL編程、C#編程、表格和流程圖編程等多種編程方式，又能無縫加載到CANoe測試環(huán)境進行測試執(zhí)行，因此優(yōu)化了測試腳本編程過程。VT System板卡從屬于Vector產(chǎn)品體系，用于測試硬件配置。VT板卡有總線模塊、電源管理模塊、仿真模塊、負載及測量模塊等，常用數(shù)/模IO模塊等[7]，能實現(xiàn)大多數(shù)診斷所需功能。

2.2 測試系統(tǒng)硬件搭建

系統(tǒng)硬件主要由VT板卡、測試電路配置板卡、供電電源、PC機等組成，連接方式如圖1所示。

其中CAN總線采用實車雙絞線束，提高總線抗干擾能力[8]。對于其它有特殊要求的線路，例如SDM模塊的傳感器接線要雙絞線加屏蔽，EPS與助力電機供電線要加粗等，按實際需求連接，以保證測試結(jié)果的可靠性。

需要指出的是，網(wǎng)關(guān)樣件網(wǎng)絡(luò)故障碼的測試較為特殊，因網(wǎng)關(guān)樣件的診斷CAN與產(chǎn)生DTC的其他CAN總線為分開的網(wǎng)段，無法做到一路總線通道完成測試，因此需要將總線干擾儀VH6501切換到不同的網(wǎng)段中分別進行干擾測試。例如，某網(wǎng)關(guān)樣件共有5路CAN通道，分別為CAN1、CAN2、CAN3、CAN4和診斷CAN，則該網(wǎng)關(guān)樣件的Busoff故障碼共4個，分別通過VH6501在CAN1、CAN2、CAN3、CAN4網(wǎng)段上進行干擾產(chǎn)生故障碼，所以需要設(shè)計測試電路配置板卡來滿足上述情況的測試，測試電路配置板卡的通道切換功能示意如圖2。

另外，測試電路配置板卡還包括終端電阻配置，總線通斷及短路控制等功能，以滿足不同的測試環(huán)境配置需求。該測試電路配置板卡由中汽研（天津）汽車工程研究院有限公司自主研發(fā)，以滿足市場需求。

2.3 測試系統(tǒng)軟件搭建

測試系統(tǒng)軟件包括Vector測試工具軟件系列CANoe、vTESTstudio，測試管理軟件，測試腳本工程等。CANoe提供多種變量定義的途徑，包括系統(tǒng)變量定義、DBC環(huán)境變量加載等，為系統(tǒng)柔性的增強提供了可能。每個測試樣件所需配置VT板卡的資源是不同的，需要將被測ECU的引腳與各個相應(yīng)功能的VT板卡通道一一對應(yīng)連接，最大程度的模擬ECU實車狀態(tài)，以避免在測試的過程中某些DTC（診斷故障碼）對其它DTC的記錄及恢復機制產(chǎn)生影響。CANoe和vTESTstudio是比較成熟的軟件，這里不再贅述，測試管理軟件為中汽研（天津）汽車工程研究院有限公司自主開發(fā)的測試執(zhí)行端軟件，下面闡述其主要設(shè)計理念及功能。

2.4 測試配置軟件

測試配置軟件包含與用戶交互的UI界面、參數(shù)配置模塊、報告生成模塊等。其柔性設(shè)計理念的應(yīng)用如下：

● 變量化設(shè)計

在本文測試結(jié)果分析中有具體體現(xiàn)，如報文丟失數(shù)量N，報文恢復數(shù)量M等，但不局限于文章描述的形式。變量化設(shè)計能夠通過定義參數(shù)，使程序適用不同的測試邏輯。

● 通用化設(shè)計

通用化設(shè)計是將每一個單獨DTC的測試內(nèi)容，歸納整理出一種通用的測試流程，通過適配相應(yīng)的測試邏輯腳本及變量，使其能夠適用不同ECU乃至不同車型的診斷DTC測試。

● 模塊化設(shè)計

模塊化設(shè)計指將通用化流程中，測試重復使用的步驟，封裝成子函數(shù)或動態(tài)鏈接庫dll函數(shù)，縮短代碼量的同時，又能靈活運用。

● 高適應(yīng)性設(shè)計

適配多種測試場景，如單件級單通道測試、多樣件單通道測試、網(wǎng)關(guān)樣件多通道測試等，測試程序也可以部署到機柜式測試系統(tǒng)或便攜式測試系統(tǒng)，使用場景比較靈活。

根據(jù)上述設(shè)計理念，結(jié)合車載電控單元診斷測試的需求，測試管理軟件被設(shè)計具有測試配置功能、測試腳本工程調(diào)用功能、自動生成測試報告功能。

針對測試配置功能，在配置所需測試的車型和樣件基本信息后，針對每個ECU進入其故障碼配置界面，界面中可以填入變量具體的值、測試信息等。示例如圖3所示。

測試車型和樣件配置的基本信息包括：車型名稱及測試階段、ECU節(jié)點名稱、ECU是否有終端電阻、ECU診斷請求ID和診斷響應(yīng)ID等。而更深一層的針對每個ECU配置故障碼信息時，則體現(xiàn)了每個ECU的差異性。

對于通信相關(guān)故障碼測試，差異性配置內(nèi)容如下：故障類型及DTC、節(jié)點超時周期倍數(shù)、超時恢復周期倍數(shù)、節(jié)點丟失伙伴ID及周期、Busoff記錄故障碼次數(shù)、診斷欠壓值、診斷過壓值等參數(shù)等。

對于電氣故障碼測試，在通用配置信息之外，還需要故障類型及DTC、故障產(chǎn)生條件、故障恢復條件等，并需要進行資源映射表Map配置，如表2所示，分別從ECU端口、VT System端口、連接件端口進行映射配置，實際接入樣件時，需按照表中內(nèi)容匹配接線。

3 測試流程

診斷測試通信，也是基于CAN協(xié)議的ISO定義7層參考模型。診斷的實現(xiàn)是通過軟件控制，由協(xié)議解析模塊實現(xiàn)ECU對總線數(shù)據(jù)的解析[9]。本測試系統(tǒng)主要是用于電氣故障碼測試和網(wǎng)絡(luò)故障碼測試，滿足總線通信環(huán)境，通過集成Diva軟件或二次開發(fā)軟件等，可以實現(xiàn)相應(yīng)的測試內(nèi)容，因此具有較高的可擴展性。

3.1 電氣故障碼測試

電氣故障碼測試主要驗證ECU所處的電氣環(huán)境出現(xiàn)異常及恢復時，ECU能否正常記錄DTC，并正確調(diào)整狀態(tài)掩碼的值。電氣故障碼測試流程如圖4。

需求分析在電氣故障碼測試中占有至關(guān)重要的作用，影響到整個測試的可行性。由于電氣故障碼測試時，需要使用VT板卡模擬DUT（被測樣件）的實車電氣工作狀態(tài)，因此，每個測試的ECU都需要單獨配置VT板卡資源，配置資源的依據(jù)，包括DUT接頭引腳定義、DUT所帶負載參數(shù)、物理信號參數(shù)等。例如，蒸發(fā)器溫度信號輸入為電阻值R，其蒸發(fā)器溫度F與阻值R按定義的插值運算規(guī)則可相互轉(zhuǎn)換，若要滿足ECU在某種蒸發(fā)器溫度狀態(tài)下進行測試，需按逆向計算得到頻率R，再通過調(diào)整VT板卡對應(yīng)輸出通道的電阻值，來模擬某種蒸發(fā)器溫度狀態(tài)。插值算法：設(shè)函數(shù)。

（1）

式中α和β為主機廠定義參數(shù)。

假設(shè)溫度F=F1，則反解R為：

（2）

體現(xiàn)在ECU端口上為反饋電壓值U

（3）

其中δ為比例系數(shù)，R1為上拉電阻阻值

因此，VT板卡可以使用電阻器模擬電阻值的方式，也可以使用回饋電壓的方式模擬蒸發(fā)器溫度狀態(tài)。其他信號如PWM波等參數(shù)，根據(jù)ECU需求具體分配。

VT板卡的另一個作用便是模擬ECU電氣環(huán)境故障狀態(tài)，使ECU滿足電氣故障碼記錄條件。舉例說明，例如某DTC記錄條件為傳感器短接到電源，通過控制VT板卡傳感器模擬通道的繼電器動作，使傳感器輸出端短接到電源正極，則滿足了該DTC成熟條件。當然，VT板卡同樣能夠控制該故障狀態(tài)的恢復。

3.2 網(wǎng)絡(luò)故障碼測試

網(wǎng)絡(luò)故障碼測試流程如圖5。

網(wǎng)絡(luò)故障碼主要分為報文丟失故障碼、信號無效值故障碼及Busoff故障碼。當然對于存在Checksum（校驗和）與Alivecounter（計數(shù)器）的報文，可能還存在關(guān)于Checksum錯誤DTC和Alivecounter錯誤DTC。對于網(wǎng)絡(luò)故障碼測試，本系統(tǒng)可以實現(xiàn)在測試某一個DTC（診斷故障碼）時，不會額外產(chǎn)生其它DTC，也就彌補了一般診斷測試系統(tǒng)不能判斷是否產(chǎn)生誤報DTC的漏洞。而實現(xiàn)該功能主要工作在于測試模型的建立，使用CANoe建立測試模型時，根據(jù)加載的DBC（車型數(shù)據(jù)庫）文件，對每一個導入的虛擬節(jié)點單獨編寫控制程序，設(shè)置正確的工程參數(shù)，就可以通過CAPL程序的邏輯控制，實現(xiàn)對某一幀報文的發(fā)送與停止控制。同時，通過系統(tǒng)變量的映射，可以精準控制模擬報文的信號值，例如模擬Checksum信號值錯誤狀態(tài)、Alivecounter信號值錯誤狀態(tài)、接收電源信號狀態(tài)等。CANoe提供的IL控制及系統(tǒng)變量控制模式，為網(wǎng)絡(luò)故障碼診斷測試提供了可行性和便捷的操作方式?？刂瞥绦蚴疽馊鐖D6。

例如，在虛擬節(jié)點程序中，使用Environment variables控制整個節(jié)點的發(fā)送與停止，可以使用ILControlStart（）;與ILControlStop（）;進行控制，主程序與虛擬節(jié)點程序之間，通過System variables可以進行單幀報文的發(fā)送與停止控制。因此，CANoe自有函數(shù)，加上診斷通信模型的開發(fā)，使測試的自動化程度更高。

3.3 診斷刷寫測試

本系統(tǒng)支持診斷刷寫（Bootloader）測試，簡稱BT測試，針對不同主機廠的不同刷寫流程，需要進行定制化程序開發(fā)。系統(tǒng)支持.s19或.hex格式的刷寫文件，且支持多個App文件刷寫的需求。

對于刷寫測試，除正常刷寫流程外，還應(yīng)檢測刷寫可靠性，如擦除內(nèi)存中斷電測試、數(shù)據(jù)傳輸中斷電測試、無效應(yīng)用程序下載測試等。

對于應(yīng)用vFlash軟件或定制開發(fā)的BT測試，本文這里不做贅述。

3.4 診斷協(xié)議測試

CANoe Option.Diva為診斷協(xié)議測試專用軟件，加載診斷數(shù)據(jù)庫CDD文件后，支持自主配置測試內(nèi)容，并生成自動化測試執(zhí)行序列，加載到CANoe運行環(huán)境下進行測試。診斷協(xié)議測試的測試內(nèi)容主要包括以下幾點：

● 診斷協(xié)議中定義的診斷服務(wù)肯定響應(yīng)測試;

● 診斷協(xié)議中定義的診斷服務(wù)否定響應(yīng)測試;

● 診斷協(xié)議中定義的具有超時機制診斷服務(wù)超時測試;

● Transport Layer參數(shù)測試等。

對于診斷協(xié)議測試，除使用成熟的Diva產(chǎn)品之外，也可以根據(jù)測試內(nèi)容定制開發(fā)測試腳本程序，本文這里不做贅述。

4 測試結(jié)果分析

對于電氣故障碼測試，結(jié)果主要關(guān)注兩點：一是硬線信號是否正確，二是總線故障碼數(shù)據(jù)是否正確。硬線信號的檢測通過VT板卡實現(xiàn)，反饋當前硬線信號狀態(tài)?？偩€故障碼數(shù)據(jù)讀取由CANoe的通信模型實現(xiàn)，可以實時請求并分析總線診斷數(shù)據(jù)信息。

對于報文丟失故障碼，主要關(guān)注時間參數(shù)，標準定義為丟失N幀報文記錄當前故障碼，連續(xù)恢復M幀，變?yōu)闅v史故障碼，對于存在老化機制的DTC，一般定義無故障狀態(tài)下點火循環(huán)L次，故障碼老化清除。經(jīng)過試驗測試，CAPL程序發(fā)送報文存在0～±1ms的誤差，考慮實際ECU的發(fā)送也存在誤差，因此檢測丟失時間時，以等待N-1倍報文周期時間和N+1倍報文周期時間作為測試時間檢測，若丟失N-1幀時間不記錄故障碼，而丟失N+1幀時間記錄故障碼，則認為測試結(jié)果正確。同理，若恢復M-1幀時間故障碼仍為當前故障碼，而恢復M+1幀時間故障碼變?yōu)闅v史故障，則認為測試結(jié)果正確。N、M、L變量即為柔性化設(shè)計的一種體現(xiàn)，能夠適應(yīng)不同車型或不同ECU的不同測試標準。

對于信號無效值故障，測試流程與評價與報文丟失故障碼類似，同樣主要關(guān)注時間參數(shù)，標準定義為連續(xù)接收N幀信號值為無效的信號時記錄當前故障碼，連續(xù)恢復M幀非無效值信號后，變?yōu)闅v史故障碼，對于存在老化機制的信號無效值DTC，一般定義無故障狀態(tài)下點火循環(huán)L次，故障碼老化清除。

對于Busoff故障碼測試，只關(guān)注故障碼是否產(chǎn)生，標準定義為連續(xù)N次進入Busoff時記錄當前故障碼，恢復報文正常發(fā)送變?yōu)闅v史故障碼，因此在讀取時一般只能讀到歷史故障碼。

通過對以上多種測試內(nèi)容的多次驗證，得到的測試結(jié)果與ECU真實狀態(tài)相符，測試結(jié)果滿足正確性和準確性。

5 結(jié)語

基于VT System的汽車電控單元柔性自動化測試系統(tǒng)，通過變量化、模塊化和通用化的柔性設(shè)計理念，使系統(tǒng)對于診斷DTC測試的兼容性達到了較高層次，不再局限于為車型或ECU定制程序，而是能夠以較小的時間及人力消耗，實現(xiàn)對于診斷DTC的測試，極大提高了測試系統(tǒng)的整體測試效率。

參考文獻：

[1]張永剛.汽車ECU診斷自動化測試系統(tǒng)[J].電子測試.2015.3：105-107.

[2]張宏.基于CAN總線的汽車故障診斷系統(tǒng)研究與設(shè)計[J].汽車工程.2008.30（10）：934-937.

[3]盛銘，陳凌珊等.基于單分類支持向量機的CAN總線異常檢測方法[J].汽車技術(shù).2020.（5）：21-25.

[3] 劉英姿.柔性（Flexibility）的概念及其控制模型[J].機械與電子.2002.（1）：46-48

[4]侯軍興.汽車故障診斷技術(shù)的現(xiàn)狀與發(fā)展趨勢[J].農(nóng)業(yè)裝備與車輛工程.2006.（6）：22-24.

[5]丁志華.基于CANoe的汽車故障診斷系統(tǒng)研制[J].汽車工程.2007，29（5）：449-452.

[6]裴軍偉.基于VT系統(tǒng)下自動化診斷的實現(xiàn)[J].汽車電器.2015.（7）：49-51.

[7]何長偉.車聯(lián)網(wǎng)中車載網(wǎng)絡(luò)負載與線束優(yōu)化[C].2014中國汽車工程學會年會優(yōu)秀論文（選登）.2014，9：1-4.

[8]楊會.基于GMLAN的汽車診斷通信仿真[J].汽車工程.2010.32（10）：902-904.