整車CAN總線數據測試系統的研究

劉瑤秋， 季金強， 趙苗苗， 劉 靜

(揚州亞星客車股份有限公司， 江蘇 揚州 225116)

CAN總線數據測試是車企整車下線調試中的重要環節，為了確保CAN通訊正常，以及整車各ECU(Electronic Control Unit)控制邏輯符合要求，需要對通信報文進行采集和測試。測試內容主要為檢測信號狀態的正確性和報文發送時序邏輯的正確性[1]。

目前汽車通信及相關行業內，主流的CAN總線報文分析工具功能成熟、專業性強，但價格昂貴且操作復雜，不便于整車下線的批量檢測使用。部分定制化整車下線測試工具可以實現一鍵檢測功能，但系統龐大，且只能面向靜止車輛進行檢測。同時，定制化的系統不利于后期維護和功能修改，且伴隨二次收費的可能。

對此，本文設計一種便攜的CAN總線數據測試系統，可覆蓋動態、靜態各種工況。通過自主設計的數據采集設備和Android端測試軟件，低價取代昂貴的商業測試產品，通過自動測試序列的理念，在PC客戶端軟件自由編制測試文本，導入Android客戶端實現自動測試，從而為測試工程師快速定位并解決問題提供有利條件[2]。

1 系統的設計和實現

1.1 系統的架構與功能

綜合考慮整車CAN總線數據測試系統的功能性和實用性要求，構建其整體架構，方案如圖1所示。

圖1 系統整體架構方案

其中，數據采集設備通過車輛的OBD接口實時采集CAN通訊報文，并將CAN數據轉換為串口數據，并通過無線通信模塊發送給Android客戶端；Android客戶端負責接收和處理外部數據，從而實現報文數據的無線接收、在線解析、自動序列測試、UI頁面展示、記錄導出的功能[3-4]。

1.2 數據采集設備

數據采集設備包括STM32F407系列微處理器、CAN通信單元、串口通信單元等外圍電路，主要實現整車CAN數據的采集、轉換和傳輸。

在初始化階段，通過輪循的方式配置CAN總線波特率，從而實現自動配置。CAN數據接收部分采用DMA(Direct Memory Access)中斷的傳輸方式，當微處理器檢測到CAN數據時觸發DMA中斷，在中斷內讀取CAN數據，并按照制定好的通訊協議完成數據編碼。串口通信單元和至無線傳輸模塊之間通過AT指令規則進行數據傳輸，系統在程序中設計并封裝了指令解析子函數，用于數據傳輸調用。

數據采集設備的無線傳輸通過無線通信模塊完成，無線通信模塊的主芯片為ESP8266。本系統利用該模塊的串口無線模式，將模塊設置為WIFI熱點，允許其他設備連接到本模塊，使數據采集設備與客戶端處于相同局域網，實現數據的無線互傳[5]。

1.3 序列生成軟件

序列生成軟件是本系統基于JAVA語言設計實現的獨立PC端軟件，用于編制和生成測試序列文本。軟件框架如圖2所示。

圖2 序列生成客戶端軟件設計

測試序列文本是將需要執行的測試以設計好的格式保存的文本，包括一系列對報文信號運算和判斷要求的組合集。序列的編制是基于DBC數據庫文件，從DBC中選擇需要測試的報文及信號，并依次為各測試項選擇運算條件以及增加判定邏輯等。為了保證測試文本的編輯錯誤，分別檢查各測試項的完整性和測試項之間的邏輯正確性。對于有誤的語句提示修改，直到修改正確才可以生成序列文本。

該軟件設計了包含5個功能鍵的工具欄，功能鍵分別是導入DBC、添加測試項、刪除測試項、語法檢測和導出序列。導入DBC用于導入用戶目前所測試車輛的DBC文件；添加、刪除測試項用于編輯和修改測試序列項；語法檢測為用戶提示當前的測試語法錯誤；導出序列用于將用戶設定的測試內容編碼成序列文本。同時，考慮到序列編輯的靈活性，每個測試項依次由測試指令、測試對象、運算符、運算數、測試延時、備注信息各元素組成，序列生成軟件將用戶組合好的測試序列以特定格式導出為文本，Android客戶端根據相應的格式規則讀取序列文本，從而快速解析測試內容,實現自動測試。

1.4 Android客戶端

Android客戶端軟件由輸入模塊、功能模塊和輸出模塊組成，其框架如圖3所示。

圖3 APP客戶端軟件框架

輸入模塊負責提供接口接收外部數據，例如接收網絡通信數據和導入的文件數據；功能模塊是客戶端的核心模塊，軟件的無線通信、報文解析、自動測試功能在此模塊內實現；輸出模塊包括人機交互界面的處理，即將報文內容及測試結果輸出并展示給用戶，以及對數據進行記錄和導出。

考慮到Android客戶端功能的流暢性，將網絡通信、自動測試等具有延時性的工作放在子線程中完成，如圖4所示。

圖4 Android客戶端工作原理

客戶端開啟并完成初始化后，創建子線程發起服務端的連接請求，建立TCP長連接，從而可以持續穩定地接收數據采集設備無線發送的報文信息。為了確保數據不丟失，客戶端會將接收到的數據先寫入數據緩存流，再從緩存流中依次拆解報文并校驗，將校驗通過的報文發送至主線程。報文的解析和界面更新工作在主線程中完成。

客戶端對報文的解析基于DBC文件，將DBC底層文件中的報文ID、信號變量等信息按照程序設計好的規則存儲在容器中，從而在解析過程中進行檢索、解析數據。解析過程中，客戶端查找容器中是否存在當前報文ID。如果存在便開始讀取解析，不存在則直接返回。解析得到各信號變量值后，查找各信號值是否有對應的含義解釋，有則輸出含義，沒有則直接輸出信號值。

自動序列測試基于實時報文解析數據和測試序列集完成，客戶端讀取測試序列指令，并前往輸出數據集中查詢相應的信號狀態，從而判斷測試是否通過[6-7]。

1.5 序列測試算法

圖3中的“自動序列測試”中的序列測試算法是實現系統自動測試功能的核心。在安卓客戶端實現。

由于測試語句中判斷或循環邏輯是由多條語句及判斷分支組成的，為了便于測試過程中定位測試項，設計了序列測試算法，流程如下：首先客戶端讀取導入的測試序列文本，將測試序列文本轉化為便于程序讀取的測試序列集。測試序列集處理完后，根據不同的指令類型進入不同的測試邏輯。在各測試項后添加標記數，即每個測試項距離邏輯結束的倒計數，這樣便于在測試過程中，測試邏輯已滿足條件時，可以準確地定位到邏輯外的語句，不需要進行邏輯內剩下的測試語句。當達到結束邏輯的條件后，根據標記數跳出當前邏輯，再進入下一輪的測試，直到測試結束[8-9]。

2 試驗驗證

2.1 試驗方案及準備工作

本文設計的系統功能試驗方案如圖5所示。系統通過整車OBD接口采集CAN報文，從而驗證無線通信和報文的解析功能。同時，使用CANoe工具采集實時CAN數據信號，查看本系統的自動測試結果是否符合原數據變化狀態，驗證系統測試結果的準確性[10]。

圖5 系統試驗方案

系統在實車試驗之前，首先進行試驗室模擬試驗，CAN報文發送軟件模擬實車發送報文，與系統建立通信并測試功能，初步驗證系統設計方案的可行性。

在試驗室模擬試驗通過的基礎上，完成試驗車測試，驗證系統設計方案的可行性。系統實車試驗如圖6所示。

圖6 系統實車試驗

2.2 報文采集功能驗證

系統開啟工作后，報文采集設備獲取整車實時CAN通信報文并發送給客戶端，客戶端進行報文校驗和解碼，讀取報文對應的時間、信道、ID以及報文信息并顯示在客戶端界面，部分結果如圖7所示。

圖7 客戶端采集報文

客戶端導入試驗車所用的DBC，實現報文的在線解析，部分結果如圖8所示。解析結果與車輛當前狀態一致，表明系統的報文解析功能可靠。

圖8 客戶端DBC解析結果

2.3 自動測試功能驗證

本文以系統的上電邏輯為例驗證測試功能，測試流程見表1。

使用序列生成軟件按照測試流程依次填寫需要測試的內容項。完成填寫后，軟件檢測序列的語法和邏輯，導出測試序列文本。

表1 自動測試內容

客戶端導入編寫好的測試序列開始自動測試，檢測到車輛上電的各邏輯步驟均通過，部分結果如圖9所示。

圖9 客戶端測試結果

同時，使用CANoe 報文監測工具采集實時報文，并查看報文信號的變化曲線，如圖10所示。將系統的測試結果與實際信號曲線進行對比，表明系統測試結果無誤，并且兩者的時間戳一致，驗證了自動測試功能具有較高的時效性和準確性。

圖10 報文信號變化曲線(CANoe監測)

3 結束語

本文針對目前行業內CAN報文采集設備成本較高、報文分析操作復雜、后期維護困難等現象，提出了一種低成本替代解決方案。通過設計一種Android端CAN總線數據實時解析、自動測試的系統，同時考慮到用戶測試需求的不斷變化，將測試需求文本化，便于用戶根據實際需求自由編制測試序列，實現總線數據自動測試。系統具有便攜、低成本、便于維護等優點，并且能夠快速定位通訊故障，滿足整車下線的實際測試需求。