基于ECU_TEST的ECU報文自動測試研究與應用

徐永新，朱 娟，王裕鵬

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

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

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

1 CAN報文的傳統測試

1.1 CAN通信協議介紹

CAN總線 （Controller Area Network）技術以其可靠性、實時性和靈活性強的特點，得到了諸多汽車開發商的青睞［3］。目前該技術已經成為汽車行業中的標準，CAN報文的傳輸必須遵循該協議。

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

1.2 傳統測試模式

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

圖1 報文測試環境

圖2 CANalyzer測試報文

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

2 CAN報文的自動化測試

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

ECU_TEST軟件可以按照圖1進行報文自動化測試環境的搭建，這種連接方式脫離了HIL設備，降低其使用負荷，有效地推進了自動測試用例調試工作的開展。

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

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

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

圖3 自動測試過程

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

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

因此，Bus access方法必須嚴格管理DBC數據庫。

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

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

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

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

表1 模塊庫說明

2.2.1 ByteStreamCreation模塊庫

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

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

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

圖5 ByteStreamCreation模塊庫調用

2.2.2 BitStreamCreation模塊庫

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

圖6 DEC1報文

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

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

2.2.3 CAN_Read模塊庫

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

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

3 測試執行及結果分析

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

圖9 Project

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

圖10 Report

4 結論

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

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

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

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