基于手動測試硬件的BUS OFF自動化測試解決方案

李林澤，孟 鑫，徐 嫚，黃祖朋，謝佶宏，邵 杰

（上汽通用五菱汽車股份有限公司，廣西 柳州 545007）

引言

科學技術的發展帶動了汽車電子技術的進步，其在汽車行業中得到了廣泛應用，使汽車操作更為安全、穩定。CAN網絡是汽車普遍使用的一種通信技術，在系統內汽車能夠接收不同的數據信息，以及發送數據信息，CAN 網絡推動了汽車計算機網絡走向了更高的發展領域[1]。隨著新能源汽車的崛起，越來越多的新功能、新科技搭載在新能源汽車上，從而導致上 CAN節點增多。各主機廠為了管理數量龐大的CAN節點，會根據ISO 11898及ISO 11595標準協議制定更符合整車項目的 CAN通訊策略來管控 CAN網絡上的各節點。為了保證零部件廠商開發出的上 CAN節點軟件及硬件能夠滿足主機廠的CAN通訊策略，需要對CAN節點進行零件級、系統級、整車級三項 CAN網絡測試。為了更好地完成這項工作，本文結合工作實踐經驗，提出了一種新的測試方案，該方案具有搭載簡單、操作簡單、拓展性強、可自動化等優點，不僅解放人力和物力上的投入，大大減少測試周期，提高效率，降低成本，而且使測試更加規范化、標準化，減少由于人為的操作失誤引起的錯誤結果[2]。

1 BUS OFF簡介

CAN總線的協議規定，ECU在總線上發送報文，若出現發不出去的情況，ECU會立刻嘗試重新發送，當連續255次無法發送，ECU自己進入總線關閉模式，即BUS OFF，該狀態下，ECU是無法發送報文的。ECU在自己內部檢測到BUS OFF后，從邏輯上退出了總線，暫時不影響其他節點通訊，由于ECU自身也不明白是什么原因導致BUS OFF，于是在內部記錄“xx年xx月xx日xx時xx分xx秒，汽車電量、里程、xx是多少”，“我”BUSOFF了，即故障診斷。然后ECU開始計時，達到特定時間后，重啟自身的CAN模塊，這一套具體的恢復規則，即故障恢復機制。

2 測試方案系統搭建

以零件級測試為例，如表1所示，所述系統包括：并聯在雙絞線即 CAN總線上的一個以上的 CAN節點和型號為VH6501的CAN總線干擾儀、供電的電源及開關，通過USB線與CAN總線干擾儀相連的安裝了CANoe軟件的上位機。

表1 硬件單元表

若為整車級測試，電源、開關替換為整車KL30電源，CAN節點替換為整車節點，即CAN總線干擾儀直接接入整車CAN網段。

以零件級測試舉例說明，連接方式如圖1所示，CAN節點是連接在 CAN總線上的電子設備，如汽車上的車身控制器、防制動抱死控制器和電機控制器等。CAN節點的數量可以是一個，也可以是多個，并且可以同時對多個 CAN節點進行故障檢測。因此，為了提高檢測效率，一般會設置多個CAN節點。

圖1 硬件連接圖

電源是為 CAN節點工作供電的，一般采用穩壓電源。開關用來控制電源供電的通斷，串聯在電源正極和 CAN節點之間。

CAN總線干擾儀連接在 CAN總線上，通過干擾 CAN節點發送的報文數據中的特定的位或者特定位的特定長度（最小6.25 ns），如某個位是“1”的，將其干擾為“0”，實現其干擾功能。通過驗證 CAN節點發送錯誤數據所處的狀態（主動錯誤狀態、被動錯誤狀態、總線關閉Bus Off狀態）、采樣點位置是否符合規范定義判斷其受干擾情況。CAN總線干擾儀可采用德國Vector公司生產的VH6501。VH6501的前身CANstress是Vector早期針對傳統CAN的總線干擾儀產品，只有干擾功能，不能同時監控總線上的CAN報文數據，如果采用CANstress進行Bus Off故障檢測，還需要設置一個CAN報文監控設備。由于干擾設備與監控設備分離，使CANstress對一個CAN節點實施干擾后，需重新進行干擾配置才能對其它CAN節點實施干擾。VH6501是新一代總線干擾儀，在CANstress的功能上進行了升級和擴展。一方面，VH6501可用作干擾儀，在上位機上導入事先編寫好的軟件腳本、DBC數據庫，然后打開軟件腳本相關的panel工具，輸入待測試 CAN節點，發送干擾信號對報文進行干擾；另一方面，VH6501可在上位機的CANoe軟件控制下，監控總線上的CAN報文數據，生成記錄文件（Trace文件）。

3 測試方案系統軟件實現

如上所述，VH6501要實現干擾，需要導入事先編寫好的軟件腳本、DBC數據庫，然后打開軟件腳本相關的panel工具，其中軟件腳本是本測試方案系統的主要軟件部分。沒有腳本就無法驅動 VH6501，它不像 CANstress有個專屬的APP去操控，所以通過編寫CANoe腳本，包括操作界面設計，即可實現操作的邏輯（干擾模式、干擾報文信息、運行、停止、保存等等），再導入數據庫，結合調用干擾報文相關的函數并設置循環，即可實現自動化測試甚至自動化解析。具體操作流程為：連接VH6501硬件，在CANoe總線仿真界面創建VH6501的仿真節點，從仿真節點進入CANoe軟件自帶的腳本編輯器CAPL Browser，也可以導入編寫好的腳本。腳本使用CALP語言編寫，協議中有相關函數直接調用來配置干擾模式及作出干擾動作，然后還要使用CANoe內部的panl設計工具設計一款對應腳本軟件的人機交互界面，使用環境變量將腳本代碼和界面關聯起來，這只是對ECU簡單地進行干擾，由于用代碼進行的驅動，可以繼續豐富代碼來實現自動化測試，即將運行、監控、停止、保存的邏輯代碼寫好，導入待測車型的整車DBC數據庫文件，DBC里面定義好車型中的節點 ID及收發報文的信息，程序中設置每次測試干擾的報文就從 DBC中讀取，以及測試完成后以節點名稱、報文ID命名trce文件及自動保存，此過程代替了手動輸入節點名稱和報文ID的操作。過程如圖2所示。

圖2 干擾流程圖

4 分析測試結果

在測試過程中在上位機上保存了trce文件，對其中的數據進行分析，判斷是否滿足標準要求。圖3為BUS OFF恢復時序圖，標準中對BUS OFF故障通訊行為及恢復機制有以下評價標準：（1）上電/復位后，連續BUS OFF標志被設置為0，第1次BUS OFF屬于首次BUS OFF，所以要求T1小于 40 ms，越快越好。（2）如果t6大于 100 ms，則連續BUS OFF標志位被設置為0，那么第6次BUS OFF仍然屬于首次BUS OFF。（3）如果t6小于100 ms，則連續BUS OFF標志位被設置為1，那么第6次BUS OFF仍然屬于連續BUS OFF。（4）在極限情況下，當BUS OFF恢復后無正常報文發送時，即報文發送與下一次BUS OFF之間的時間不等于0 ms（t 6=0 ms），所以要求 T2、T3、T4、T5、T7、T8、T9、均在200±30 ms范圍內。

圖3 BUSOFF恢復時序圖

用 CANoe軟件回放功能，可分析數據是否滿足標準定義。

5 結束語

CAN網絡測試的自動化，不僅節省了人力物力，還很大程度地提升了測試效率。雖說自動化測試能帶來的好處很多，但是由于成本的原因，實際上部分測試項的復雜度還很高，自動化程度并不是越高越好。比如，整車的CAN網絡測試，問題點變化大，自動化測試設備很難分析得出預期的結果。本文描述的自動化測試系統，實際上就是基于純手動測試的硬件實現的。導入自動化的腳本，成本上沒有增加，卻比使用網絡自動化測試的板卡的設備性價比更高。本文提出的低成本自動化測試方案，為主機廠提高測試能力提供了的新方向。