基于LabVIEW的電池管理系統與充電機通信協議測試

摘 要： 為了促進電動汽車技術的標準化，實現對基于J1939協議的《電動汽車非車載傳導式充電機與電池管理系統之間的通信協議》進行測試，利用NI PXI CAN接口板卡和LabVIEW軟件開發平臺構建J1939協議CAN通信平臺，在此平臺上模擬充電機，通過監測與電池管理系統通信的各報文發送接收狀態來測試通信過程是否出現錯誤，將解析的通信信息以及錯誤類型通過用戶界面顯示。實驗證明很好實現了J1939協議多幀傳輸機制，模擬了充電機與電池管理系統的通信，并能實時顯示通信狀態、指出錯誤類型。

關鍵詞： LabVIEW； J1939協議； 電池管理系統； 充電機； 協議測試

中圖分類號： TN915?34 文獻標識碼： A 文章編號： 1004?373X（2013）17?0114?04

0 引 言

隨著近年來電動汽車行業如火如荼的發展，電動汽車技術相關的各種標準也相繼推出，其中包括了《電動汽車非車載傳導式充電機與電池管理系統之間的通信協議》（GB/T 27930?2011）[1]。該協議是基于CAN應用層協議SAE J1939，J1939是目前在國內汽車行業中應用廣泛的CAN總線應用層協議[2?4]。只有電池管理系統與充電機之間的正常數據交互才能保證電動汽車進行高效、安全的充電。因此，電池管理系統與充電機通信協議測試是電池管理系統測試的一個必不可少的項目。本課題來源于北方車輛研究所電池管理系統測試平臺項目。美國國家儀器NI PXI CAN采集卡以及LabVIEW為模擬充電機與BMS通信提供了良好的軟硬件環境。

LabVIEW是美國國家儀器推出的一種程序開發環境，圖形化語言使其與其他的代碼類型語言相比之下更為方便直觀[5]。以計算機作為運行環境的LabVIEW，充分利用了計算機無可比擬的硬件優勢，具有強大的數據處理能力。開發者可以很容易實現多線程編程，極大降低了軟件開發的難度。LabVIEW的前面板提供了豐富的類似傳統儀器的控件，開發者可以很方便的創建用戶界面。

本文重點在于如何用LabVIEW實現SAE J1939多幀傳輸機制，完成超過8 B報文的接收重組、拆分發送。以及如何實時判斷通信過程出現的錯誤、指出錯誤類型、定位錯誤發生的階段。

1 SAE J1939協議

J1939協議是基于CAN 2.0B制定的，協議對物理層、數據鏈路層、網路層以及應用層都進行了相關的規定。本文針對數據鏈路層的規定進行簡單介紹。

1.1 協議數據單元（PDU）

J1939將CAN 2.0B的29位標識符ID劃分為六部分，每部分都代表不同的含義，包括優先級（P）、保留位（R）、數據頁（DP）、PDU格式（PF）、特定PDU（PS）、源地址（SA），見表1。

根據CAN 2.0總線的仲裁機制，標識符值越小，CAN幀優先級越高，J1939把這一權利賦予了標識符最高三位（P）。R、DP通常為0。SA代表了該幀數據的發送節點的地址，CAN網絡中每個設備都分配了惟一的SA。在介紹PF與PS之前有必要先介紹下參數組編號（PGN）的概念。每個PGN代表著惟一的參數組（可以包含一個或多個參數），當參數組的數據域大于8 B時，需要遵循J1939的多幀傳輸機制。PGN由R、DP、PF以及PS組成，見表2。從表2中可以看出PDU2格式報文沒有目標地址，此類報文只能發送給全局地址。由于PS作為PDU2格式參數組編號的一部分，因此PDU2比PDU1能定義更多的參數組編號。

1.2 多幀傳輸機制

CAN 2.0B數據域最多有8 B，而在J1939協議中當一個參數組編號（PGN）所對應的數據超過8 B時，規定了一種多幀傳輸機制，發送者按此機制拆分發送，接收者按此機制接收重組，因此一個參數組編號所對應的數據最多可以為1 785 B。點對點未發生錯誤的多幀傳輸機制如圖1所示，J1939對傳輸過程出現錯誤的情況也規定了相應的處理機制，在此不作介紹。

TP.CM_RTS、TP.CM_CTS、TP.DT、TP.EndofMsgACK均為J1939特定功能報文，其參數組編號也由J1939規定，因此這些參數組編號不能再被用戶定義。TP.CM_RTS為消息發送者發送的請求發送幀，由此開始建立多幀傳輸鏈接，其數據域包括了此次發送的消息全部字節數、全部數據包數（TP.DT幀數）以及該消息的參數組編號等信息。接收者根據自己的接收能力，發送準備發送幀TP.CM_CTS，通知發送者下次可發送的數據包數、下一個要發送的數據包編號以及消息的參數組編號。發送者根據接收者的要求開始發送數據包TP.DT，數據包的數據域第一字節代表了該包號，因此一個數據包最多包含消息的7 B。

這個過程循環進行，直至接收者接收到全部數據包后發送消息結束應答幀TP.EndofMsgACK代表著這次多幀傳輸的結束。若發送的消息是全局消息，則所有接收者不應有任何應答，整個傳輸過程如圖2所示。

2 基于LabVIEW實現J1939協議平臺

2.1 硬件接口

利用NI PXI?8513 CAN接口板卡實現該系統的硬件接口。NI已為開發者提供了該板卡的底層驅動，可以很方便對CAN節點參數進行配置以及接收和發送符合CAN 2.0的消息幀，然而對于多幀傳輸機制還需開發者自行設計。由于J1939協議涉及發送者與接收者的應答，因此在基于LabVIEW開發J1939同時也利用C語言開發基于飛思卡爾單片機的電池管理系統中使用的J1939協議，兩者相輔相成，并且利用VECTOR CANoe軟件監視總線，以保證程序開發的順利進行。

2.2 軟件實現

利用LabVIEW多線程編程以及生產者消費者結構實現J1939協議。分別為未拆分的發送報文、已拆分發送報文、未重組的接收報文、已重組的接收報文建立隊列。創建已重組報文讀取線程，已重組報文出隊列用于應用層協議。創建接收報文處理線程，用于按多幀傳輸機制處理接收到的CAN 2.0數據幀，程序流程圖如圖3所示，經過目的地址過濾報文后，利用條件結構按照報文參數組編號進行分類處理，在計算參數組編號時要注意PDU1與PDU2格式的區別，主要分為以下幾種情況：數據小于7 B的正常數據報文：直接入已處理接收報文隊列供應用層使用；請求發送幀TP.CM_RTS：由于兩個節點之間同一時間最多只能有一個發送和一個接收的多幀傳輸鏈接，若這時已有一個接收鏈接，則需要發送放棄鏈接幀TP.ABORT告知發送者，若無接收鏈接，創建新的接收狀態機并插入接收狀態機數組。接收狀態機為一個數據簇，包含了參數組編號、下一個接收數據包編號、數據包總數、當前已接收字節數、字節總數、以及已接收字節數組。之后應發送準備發送幀TP.CM_CTS通知發送者發送數據包，同時應開始計時，若發送者響應時間超過規定時間，應發送放棄幀TP.ABORT；準備發送幀TP.CM_CTS：此報文為接收者對發送報文的應答，此次發送狀態機已建立，搜索相應狀態機，根據準備發送幀要求拆分數據創建數據包TP.DT；數據包TP.DT：搜索相應的接收狀態機并核對是否與目前狀態機相符，如果相符則對數據進行重組存入狀態機的接收字節數組，若不符則發送該參數組編號的放棄鏈接幀，最后判斷多幀傳輸是否結束，并根據是否為全局報文決定是否發送完成鏈接幀；完成鏈接幀TP.EndofMsgACK：表示相應的多幀發送鏈接已完成，刪除相應的發送狀態機。廣播公告消息TP.CM_BAM：收到全局消息的請求鏈接幀，只需建立相應的接收狀態機，等待接收數據包，而不需要任何的應答。

發送報文均先入未拆分發送報文隊列；創建未拆分發送報文處理線程，用于按多幀傳輸機制處理發送報文，程序流程圖如圖4所示，若發送報文數據超過8 B則需要通過多幀傳輸機制拆分發送。

2.3 J1939平臺應用效果

定義電池管理系統BMS和LabVIEW的J1939協議地址分別為244和86。首先由BMS發送PGN為256的9 B報文給LabVIEW，CANoe監視到總線時序如圖5所示。

由第一幀ID可以看出源地址為0xF4（244），目的地址為0x56（86），PGN為0xEC00，因此該幀為鏈接管理幀TP.CM，并且Data域控制字節（第1字節）為0x10，綜上該幀為BMS發送給LabVIEW的請求發送幀，并由Data域可以看出此次報文共有0x09字節（第2，3字節），數據包共有0x02包（第4字節），PGN為0x0100（第6，7，8字節）。同理第二幀為LabVIEW發送的準備發送幀，通知BMS從第0x01包（第3字節）開始發送0x02（第2字節）包數據包。待接收到BMS發送的兩幀TP.DT，LabVIEW發送TP.EndofMsgACK代表此次多幀傳輸完成。LabVIEW接收重組后的數據如圖6所示。

同理分析LabVIEW作為發送節點的情況，總線時序圖如圖7所示，LabVIEW拆分前的發送數據如圖8所示。綜上分析，利用LabVIEW開發平臺很好地實現了J1939協議。

3 通信協議測試軟件的開發

通信協議將整個通信分為多個階段：充電握手階段、充電參數配置階段、充電階段、充電結束階段。每個通信階段均涉及充電機與BMS的信息交互，每次信息交互均有超時限制。為了實現對通信協議進行測試，不僅要模擬充電機與BMS進行通信，還要實時監測通信的狀態，判斷通信過程是否出錯并解析BMS發送的信息。測試軟件主要測試通信階段出現的時序錯亂以及信息交互超時這兩種錯誤。

在已開發J1939協議基礎上進行測試軟件的開發，J1939協議提供了兩個接口：需要發送報文直接入未處理發送報文隊列、已處理接收報文出隊列供應用層使用。通信階段改變利用LabVIEW狀態機結構來實現。創建充電機接收狀態、充電機發送狀態兩個數據簇，記錄接收報文是否已被接收、發送報文是否已被發送以及發送的時間。利用單獨程序線程通過這兩個數據簇實時判斷是否有錯誤發生。

應用效果如圖9所示，為了試驗是否能準確測試出錯誤類型，有意將BMS程序設置為不發送電池充電需求報文，測試軟件指示超時類型代碼為5，即電池充電需求報文超時，接收錯誤類型主要為通信順序出錯。通過對每個接收超時類型以及順序出錯類型進行測試，結果表明能很好地實現對通信協議進行測試。

4 結 語

在LabVIEW開發平臺上，利用其強大的數據處理能力以及豐富實用的程序結構實現了J1939協議，在此基礎上開發電動汽車非車載傳導式充電機與電池管理系統之間的通信協議測試軟件，不僅可以輔助BMS的程序開發，還可以作為BMS測試平臺的部分功能評價BMS合格與否。通過與BMS進行通信，并利用CANoe對總線進行監視，試驗結果表明該測試軟件可以實現J1939協議，能完成多幀傳輸機制，并且可以測試出通信協議中出現的通信流程錯亂以及通信超時錯誤，可以滿足要求。

參考文獻

[1] 中國國家標準化管理委員會.GB/T 27930?2011電動汽車非車載傳導式充電機與電池管理系統之間的通信協議[S].北京：中國標準出版社，2011.

[2] SAE Group. SAE J1939?21 data link layer standard [S]. USA： SAE Group， 2001.

[3] 高松.淺談J1939協議在客車CAN總線中的應用[J].農業裝備與車輛工程，2005（2）：30?31.

[4] 蘇喜紅.基于J1939的汽車網絡控制系統CAN高層協議設計與實現[D].哈爾濱：哈爾濱工業大學，2007.

[5] 陳樹學，劉萱.LabVIEW寶典[M].北京：電子工業出版社，2011.

[6] 阮奇楨.我和LabVIEW[M].北京：北京航空航天大學出版社，2009.

作者簡介：劉 武 男，1989年出生，福建人，碩士。主要研究方向為儲能系統綜合測試與控制技術。

朱春波 男，1964年出生，哈爾濱人，博士，教授。主要研究方向為儲能系統綜合測試與控制技術、無線能量傳輸技術。