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

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

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

1 引言

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

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

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

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

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

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

● 測(cè)試環(huán)境復(fù)雜

● 手動(dòng)測(cè)試時(shí)間參數(shù)控制困難

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

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

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

2 系統(tǒng)概述

2.1 測(cè)試工具

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

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

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

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

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

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

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

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

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

2.4 測(cè)試配置軟件

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

● 變量化設(shè)計(jì)

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

● 通用化設(shè)計(jì)

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

● 模塊化設(shè)計(jì)

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

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

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

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

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

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

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

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

3 測(cè)試流程

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

3.1 電氣故障碼測(cè)試

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

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

（1）

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

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

（2）

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

（3）

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

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

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

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

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

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

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

3.3 診斷刷寫測(cè)試

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

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

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

3.4 診斷協(xié)議測(cè)試

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

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

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

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

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

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

4 測(cè)試結(jié)果分析

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

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

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

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

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

5 結(jié)語(yǔ)

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

參考文獻(xiàn)：

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

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

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

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

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

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

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

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

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