汽車電控單元自動化診斷測試系統設計

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

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

關鍵詞：診斷 VT System 自動化測試 柔性設計

1 引言

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

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

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

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

● 定制化測試邏輯開發

● 差異化參數配置

● 測試環境復雜

● 手動測試時間參數控制困難

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

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

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

2 系統概述

2.1 測試工具

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

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

2.2 測試系統硬件搭建

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

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

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

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

2.3 測試系統軟件搭建

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

2.4 測試配置軟件

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

● 變量化設計

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

● 通用化設計

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

● 模塊化設計

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

● 高適應性設計

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

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

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

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

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

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

3 測試流程

診斷測試通信，也是基于CAN協議的ISO定義7層參考模型。診斷的實現是通過軟件控制，由協議解析模塊實現ECU對總線數據的解析[9]。本測試系統主要是用于電氣故障碼測試和網絡故障碼測試，滿足總線通信環境，通過集成Diva軟件或二次開發軟件等，可以實現相應的測試內容，因此具有較高的可擴展性。

3.1 電氣故障碼測試

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

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

（1）

式中α和β為主機廠定義參數。

假設溫度F=F1，則反解R為：

（2）

體現在ECU端口上為反饋電壓值U

（3）

其中δ為比例系數，R1為上拉電阻阻值

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

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

3.2 網絡故障碼測試

網絡故障碼測試流程如圖5。

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

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

3.3 診斷刷寫測試

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

對于刷寫測試，除正常刷寫流程外，還應檢測刷寫可靠性，如擦除內存中斷電測試、數據傳輸中斷電測試、無效應用程序下載測試等。

對于應用vFlash軟件或定制開發的BT測試，本文這里不做贅述。

3.4 診斷協議測試

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

● 診斷協議中定義的診斷服務肯定響應測試;

● 診斷協議中定義的診斷服務否定響應測試;

● 診斷協議中定義的具有超時機制診斷服務超時測試;

● Transport Layer參數測試等。

對于診斷協議測試，除使用成熟的Diva產品之外，也可以根據測試內容定制開發測試腳本程序，本文這里不做贅述。

4 測試結果分析

對于電氣故障碼測試，結果主要關注兩點：一是硬線信號是否正確，二是總線故障碼數據是否正確。硬線信號的檢測通過VT板卡實現，反饋當前硬線信號狀態。總線故障碼數據讀取由CANoe的通信模型實現，可以實時請求并分析總線診斷數據信息。

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

對于信號無效值故障，測試流程與評價與報文丟失故障碼類似，同樣主要關注時間參數，標準定義為連續接收N幀信號值為無效的信號時記錄當前故障碼，連續恢復M幀非無效值信號后，變為歷史故障碼，對于存在老化機制的信號無效值DTC，一般定義無故障狀態下點火循環L次，故障碼老化清除。

對于Busoff故障碼測試，只關注故障碼是否產生，標準定義為連續N次進入Busoff時記錄當前故障碼，恢復報文正常發送變為歷史故障碼，因此在讀取時一般只能讀到歷史故障碼。

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

5 結語

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

參考文獻：

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

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

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

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

[4]侯軍興.汽車故障診斷技術的現狀與發展趨勢[J].農業裝備與車輛工程.2006.（6）：22-24.

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

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

[7]何長偉.車聯網中車載網絡負載與線束優化[C].2014中國汽車工程學會年會優秀論文（選登）.2014，9：1-4.

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