基于ECU_TEST的ECU報文自動測試研究與應(yīng)用

徐永新，朱 娟，王裕鵬

（濰柴動力股份有限公司，山東 濰坊 261061）

硬件在環(huán) （Hardware-In-the-Loop，HIL）仿真設(shè)備可以在試驗室環(huán)境下完成對ECU的測試及初期匹配工作［1-2］，主要被用于模擬測試整車工況，確保ECU的安全性。HIL設(shè)備自帶的自動化測試工具，如dSPACE的AutomationDesk軟件、ETAS的LABCAR Automation軟件，能將部分測試任務(wù)轉(zhuǎn)化為自動測試用例且可以24 h無人值守并自動生成測試報告，不僅提高了測試效率還節(jié)省了人力資源。但是在使用中發(fā)現(xiàn)二者都具有一定的局限性，自動測試用例的調(diào)試及執(zhí)行離不開HIL設(shè)備，額外增加了設(shè)備的使用負(fù)擔(dān)，并且依據(jù)兩個平臺開發(fā)的自動測試用例不通用，又增加了自動測試用例開發(fā)的重復(fù)性。

經(jīng)過調(diào)研并對比了TPT、Mx-Suite、TestWeaver和ECU_TEST四款軟件的優(yōu)缺點后，ECU_TEST軟件可以兼容多HIL平臺及測量工具、糅合Python語言支持二次開發(fā)的優(yōu)勢凸顯出來。本文基于ECU_TEST軟件進(jìn)行了CAN總線報文的自動化測試實現(xiàn)，不僅使得測試方法更加靈活、增強了自動測試用例的可移植性，更降低了HIL平臺的使用負(fù)荷。

1 CAN報文的傳統(tǒng)測試

1.1 CAN通信協(xié)議介紹

CAN總線 （Controller Area Network）技術(shù)以其可靠性、實時性和靈活性強的特點，得到了諸多汽車開發(fā)商的青睞［3］。目前該技術(shù)已經(jīng)成為汽車行業(yè)中的標(biāo)準(zhǔn)，CAN報文的傳輸必須遵循該協(xié)議。

DBC數(shù)據(jù)庫協(xié)議定義了一個單獨的CAN網(wǎng)絡(luò)的車載數(shù)據(jù)通信協(xié)議，德國Vector公司的CANdb++Editor是一個專門解析和編輯這個協(xié)議的專業(yè)化工具，這些信息是監(jiān)測和分析網(wǎng)絡(luò)的基礎(chǔ)，為報文的測試提供了方便。文件包含CAN網(wǎng)絡(luò)的三大主要組成部分，即總線上的ECU或節(jié)點 （Node）、消息 （Message）、信號 （signal）。每個節(jié)點中顯示從這個節(jié)點的發(fā)送 （TX）和接收 （RX）的報文、發(fā)送 （TX）和接收（RX）的信號，即定義了節(jié)點之間信息的交換規(guī)則；在消息當(dāng)中，集成了這個 CAN網(wǎng)絡(luò)上所有消息和每個消息下包含的所有信號；最后就是最基本的組成單位即信號，信號通過自身屬性能在Message下解析成十進(jìn)制值，它有6個最關(guān)鍵的參數(shù)即字節(jié)序列 （ByteOrder）、位解析值類型 （Value－Type）、位起始 （StartBit）、位長 （Length）、因子系數(shù) （Factor）、偏移量 （Offset）［4］。

1.2 傳統(tǒng)測試模式

CAN模塊的黑盒測試主要測試報文信號是否被控制器正確地接收和發(fā)送，包括其接收信息的準(zhǔn)確性，是否具有溢出保護(hù)，超時故障及長度故障是否能正確報出，周期的準(zhǔn)確性，負(fù)荷率及錯誤幀的測試。傳統(tǒng)的測試模式如圖1所示，將控制器、臺架、電腦、Vector工具連接在一起，然后通過報文專業(yè)測試軟件Vector CANalyzer對報文進(jìn)行逐條測試，如圖2所示。傳統(tǒng)測試模式對DBC數(shù)據(jù)庫的應(yīng)用有一定的依賴性，如果DBC數(shù)據(jù)庫沒有包含被測報文，那接收或模擬發(fā)送報文的可讀性極差，需要測試人員自己根據(jù)CAN通信協(xié)議進(jìn)行換算。

圖1 報文測試環(huán)境

圖2 CANalyzer測試報文

傳統(tǒng)測試模式需要逐條測試，耗時耗力。目前一個普通車輛控制器接收和發(fā)送的報文總數(shù)已經(jīng)多達(dá)90多條，智能化更強的控制器所收發(fā)的報文總數(shù)多達(dá)上百條，每條message、每條signal的測試及Bug的回歸測試都將是一個艱巨的任務(wù)。

2 CAN報文的自動化測試

自動測試用例的開發(fā)過程一般如圖3所示，從測試需求開始提取Feature，通過Ecxel進(jìn)行管理并形成測試管理矩陣，然后使用自動測試用例軟件進(jìn)行開發(fā)及執(zhí)行，并形成測試報告。

ECU_TEST軟件可以按照圖1進(jìn)行報文自動化測試環(huán)境的搭建，這種連接方式脫離了HIL設(shè)備，降低其使用負(fù)荷，有效地推進(jìn)了自動測試用例調(diào)試工作的開展。

基于ECU_TEST軟件可以使用Bus access和VECTOR-HW Jobs兩種方法進(jìn)行CAN報文自動測試用例的設(shè)計及執(zhí)行。

2.1 基于Bus access的報文自動化測試

Bus access測試方法依賴DBC數(shù)據(jù)庫，可以對任意message、任意Signal的周期設(shè)定、循環(huán)發(fā)送、讀取、停發(fā)的操作。如圖4a所示，是對TSC1_TE報文的使能及周期設(shè)定、循環(huán)發(fā)送及停發(fā)；如圖4b所示，是對EEC1報文的讀取及判斷。

圖3 自動測試過程

圖4 Bus access測試方法對TSC1_TE及 EEC1報文的操作

Bus access對Signal值設(shè)定的形式非常靈活，可以是按照CAN通信協(xié)議轉(zhuǎn)換后的物理值 （PHY），可以是各種模式的文本模式 （TEXT），也可以是DBC文件中的Raw Value。這種測試方法將DBC數(shù)據(jù)庫的優(yōu)點完全繼承過來，增強了報文的可讀性。但是這種方法對DBC的依賴性不容忽視，如果某條報文沒有及時被添加至DBC數(shù)據(jù)庫中，那么這類報文的自動化測試我們將束手無策；如果在報文自動測試用例開發(fā)的過程中使用的DBC文件不一致，那么所有的自動測試用例將無法放在同一個測試環(huán)境下合并測試。

因此，Bus access方法必須嚴(yán)格管理DBC數(shù)據(jù)庫。

2.2 基于VECTOR-HW Jobs的報文自動化測試

VECTOR-HW Jobs的報文自動化測試方法則可以完美地解決上述問題，脫離DBC的限制。ECU_TEST軟件通過調(diào)用Vector API函數(shù)來實現(xiàn)報文的讀取和發(fā)送。

但是VECTOR-HW Jobs現(xiàn)有的操作方法不管是報文返回值還是發(fā)送值都是ECU_TEST軟件中特定的ByteStream格式，如7D：00：2C：03：FF：FF：FF：FF，其可用性較差，不能直接與控制器中的變量進(jìn)行判斷。如何將ByteStream類型數(shù)據(jù)與發(fā)動機(jī)轉(zhuǎn)速、車速之類的物理值進(jìn)行互相轉(zhuǎn)化則成為VECTOR-HW Jobs方法的使用關(guān)鍵。

基于ECU_TEST軟件自帶的ByteStream、BitStream操作方法并結(jié)合Python語言進(jìn)行不同測試需求的二次開發(fā)。目前已經(jīng)完成如表1所示的模塊庫，以支撐VECTOR-HW Jobs方法的應(yīng)用。

表1 模塊庫說明

2.2.1 ByteStreamCreation模塊庫

ByteStreamCreation模塊庫通過調(diào)用Python對List的處理方法和ByteStream方法實現(xiàn)了指定物理值的循環(huán)發(fā)送。ByteStreamCreation模塊庫的主要作用不局限于此，還會將控制器中經(jīng)過CAN總線解析后的變量與其進(jìn)行判斷，確定報文已經(jīng)發(fā)送至CAN總線并被控制器正確接收。被寫入的Byte可以是單個，也可以是多個，最多可同時寫4個Byte。ByteStreamCreation模塊庫的循環(huán)次數(shù)同List的元素個數(shù)。

ByteStreamCreation模塊庫的實現(xiàn)是先使用Python語言將被寫入的物理值 （ListA）按照CAN通信協(xié)議進(jìn)行轉(zhuǎn)化并生成新的列表 （ListB），再將ListB中的元素轉(zhuǎn)化為十六進(jìn)制寫入指定Byte；測試工程師可以根據(jù)需求選擇寫入幾個Byte；最后將生成的ByteStreamA寫入指定的報文進(jìn)行多次發(fā)送，并與控制器中的變量進(jìn)行判斷。

該模塊庫的調(diào)用如圖5所示，只需填寫報文的ID（FrameID）、周期 （Period）、發(fā)送次數(shù) （Counter）、內(nèi)容（ListA）、因子 （Factor）、偏移 （OffSet）、Byte索引值 （Index）、控制器變量 （VALUE_ECU）、Byte個數(shù) （Num），便可獲知報文發(fā)送及接收的結(jié)果。

圖5 ByteStreamCreation模塊庫調(diào)用

2.2.2 BitStreamCreation模塊庫

ByteStreamCreation模塊庫可以完成一個或多個Byte的寫入，但是如圖6所示的報文需求 （僅使用一個Byte中的幾個Bit）卻無法實現(xiàn)。針對該問題開發(fā)了BitStreamCreation模塊庫。

圖6 DEC1報文

BitStreamCreation模塊庫的主要作用是循環(huán)將表格中的數(shù)據(jù)發(fā)送到報文指定Byte的指定Bit（任意長度）中，并與ECU中總線解析后的變量進(jìn)行判斷；僅限于寫入同一個Byte中Bit；循環(huán)次數(shù)同表格的元素個數(shù)。BitStreamCreation模塊庫的實現(xiàn)先使用Python語言將被寫入的物理值 （ListA）按照CAN通信協(xié)議進(jìn)行轉(zhuǎn)化并生成新的列表 （ListB），再將ListB中的元素左移后轉(zhuǎn)化為十六進(jìn)制寫入指定Byte，最后將生成的ByteStreamA寫入指定的報文進(jìn)行多次發(fā)送，并與控制器中的變量進(jìn)行判斷。

該模塊庫的調(diào)用同ByteStreamCreation類似，如圖7所示，需進(jìn)行參數(shù)化的變量有：報文的ID （FrameID）、周期 （Period）、發(fā)送次數(shù) （Counter）、內(nèi)容 （ListA）、因子 （Factor）、偏移 （OffSet）、Byte索引值 （Index）、控制器變量 （Variable_ECU）、Bit開始的位置 （StartBit）。

2.2.3 CAN_Read模塊庫

CAN_Read模塊庫是ByteStreamCreation、BitStreamCreation兩個模塊庫的逆操作，它可以獲取報文的一個Byte、多個Byte及任意長度的Bit內(nèi)容。CAN_Read模塊庫的返回值有兩種形式，分別是十六進(jìn)制與ByteStream類型，十六進(jìn)制返回值使用Python語言取整后即可獲得十進(jìn)制數(shù)值，而ByteStream類型返回值則需要使用ByteConvertToNumber模塊庫，將其轉(zhuǎn)化為十進(jìn)制。

CAN_Read模塊庫是先根據(jù)報文ID讀取CAN總線上的報文內(nèi)容，然后對返回值 （ByteStream類型）進(jìn)行不同需求的取片處理。在調(diào)用該模塊庫時根據(jù)測試需求可進(jìn)行選擇性參數(shù)化，如圖8所示。

3 測試執(zhí)行及結(jié)果分析

目前我們使用上述兩種方法已完成控制器85條收發(fā)報文的自動測試用例編寫及調(diào)試。報文自動測試用例的放行測試如圖9所示，將所有自動測試用例放在同一個Project中即可逐條運行并自動生成測試報告。

圖9 Project

如圖10所示，執(zhí)行112條自動測試用例耗時1h16min，其中有93條自動測試用例PASS，占比82.3%，19條自動測試用例FAIL，占比16.81%。這相對于傳統(tǒng)測試模式，已經(jīng)大大提高了測試效率。

圖10 Report

4 結(jié)論

1）本文提供兩種CAN報文測試方法，打破DBC文件的束縛，脫離HIL平臺的限制，使測試方法更靈活自如。

2）模塊庫的開發(fā)及應(yīng)用保證了自動測試用例的一致性、重復(fù)性，降低人為因素的干擾。

3）自動化測試在控制器軟件的開發(fā)及Bug修復(fù)的過程中，保證了測試用例的通用性、可移植性，更重要的是節(jié)省大量時間、提高測試效率。

該方法已在我們的工作中實際應(yīng)用并取得了較好的效果。