徐永新，朱 娟，王裕鵬

（濰柴動(dòng)力股份有限公司，山東 濰坊 261061）

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

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

1 CAN報(bào)文的傳統(tǒng)測(cè)試

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

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

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

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

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

圖1 報(bào)文測(cè)試環(huán)境

圖2 CANalyzer測(cè)試報(bào)文

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

2 CAN報(bào)文的自動(dòng)化測(cè)試

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

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

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

2.1 基于Bus access的報(bào)文自動(dòng)化測(cè)試

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

圖3 自動(dòng)測(cè)試過(guò)程

圖4 Bus access測(cè)試方法對(duì)TSC1_TE及 EEC1報(bào)文的操作

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

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

2.2 基于VECTOR-HW Jobs的報(bào)文自動(dòng)化測(cè)試

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

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

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

表1 模塊庫(kù)說(shuō)明

2.2.1 ByteStreamCreation模塊庫(kù)

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

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

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

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

2.2.2 BitStreamCreation模塊庫(kù)

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

圖6 DEC1報(bào)文

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

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

2.2.3 CAN_Read模塊庫(kù)

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

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

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

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

圖9 Project

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

圖10 Report

4 結(jié)論

1）本文提供兩種CAN報(bào)文測(cè)試方法，打破DBC文件的束縛，脫離HIL平臺(tái)的限制，使測(cè)試方法更靈活自如。

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

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

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