基于LabVIEW的電池管理系統(tǒng)與充電機通信協(xié)議測試

　　摘要：為了促進電動汽車技術的標準化，實現(xiàn)對基于J1939協(xié)議的《電動汽車非車載傳導式充電機與電池管理系統(tǒng)之間的通信協(xié)議》進行測試，利用NI PXI CAN接口板卡和LabVIEW軟件開發(fā)平臺構建J1939協(xié)議CAN通信平臺。

　　然后，通過在此平臺上模擬充電機，通過監(jiān)測與電池管理系統(tǒng)通信的各報文發(fā)送接收狀態(tài)來測試通信過程是否出現(xiàn)錯誤，將解析的通信信息以及錯誤類型通過用戶界面顯示。實驗證明很好實現(xiàn)了J1939協(xié)議多幀傳輸機制，模擬了充電機與電池管理系統(tǒng)的通信，并能實時顯示通信狀態(tài)、指出錯誤類型。

　　0 引言

　　隨著近年來電動汽車行業(yè)如火如荼的發(fā)展，電動汽車技術相關的各種標準也相繼推出，其中包括了《電動汽車非車載傳導式充電機與電池管理系統(tǒng)之間的通信協(xié)議》（GB/T 27930-2011）。該協(xié)議是基于CAN應用層協(xié)議SAE J1939,J1939 是目前在國內汽車行業(yè)中應用廣泛的CAN總線應用層協(xié)議。只有電池管理系統(tǒng)與充電機之間的正常數(shù)據(jù)交互才能保證電動汽車進行高效、安全的充電。因此，電池管理系統(tǒng)與充電機通信協(xié)議測試是電池管理系統(tǒng)測試的一個必不可少的項目。

　　本課題來源于北方車輛研究所電池管理系統(tǒng)測試平臺項目。美國國家儀器NI PXI CAN采集卡以及LabVIEW為模擬充電機與BMS通信提供了良好的軟硬件環(huán)境。

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

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

　　1 SAE J1939 協(xié)議

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

　　1.1 協(xié)議數(shù)據(jù)單元（PDU）

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

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

　　1.2 多幀傳輸機制

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

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

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

　　2 基于LabVIEW實現(xiàn)J1939 協(xié)議平臺

　　2.1 硬件接口

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

　　2.2 軟件實現(xiàn)

　　利用LabVIEW多線程編程以及生產者消費者結構實現(xiàn)J1939協(xié)議。分別為未拆分的發(fā)送報文、已拆分發(fā)送報文、未重組的接收報文、已重組的接收報文建立隊列。創(chuàng)建已重組報文讀取線程，已重組報文出隊列用于應用層協(xié)議。創(chuàng)建接收報文處理線程，用于按多幀傳輸機制處理接收到的CAN 2.0數(shù)據(jù)幀，程序流程圖如圖3所示，經過目的地址過濾報文后，利用條件結構按照報文參數(shù)組編號進行分類處理，在計算參數(shù)組編號時要注意PDU1與PDU2格式的區(qū)別，主要分為以下幾種情況：

　　數(shù)據(jù)小于7 B的正常數(shù)據(jù)報文：直接入已處理接收報文隊列供應用層使用；請求發(fā)送幀TP.CM_RTS:由于兩個節(jié)點之間同一時間最多只能有一個發(fā)送和一個接收的多幀傳輸鏈接，若這時已有一個接收鏈接，則需要發(fā)送放棄鏈接幀TP.ABORT告知發(fā)送者，若無接收鏈接，創(chuàng)建新的接收狀態(tài)機并插入接收狀態(tài)機數(shù)組。接收狀態(tài)機為一個數(shù)據(jù)簇，包含了參數(shù)組編號、下一個接收數(shù)據(jù)包編號、數(shù)據(jù)包總數(shù)、當前已接收字節(jié)數(shù)、字節(jié)總數(shù)、以及已接收字節(jié)數(shù)組。之后應發(fā)送準備發(fā)送幀TP.CM_CTS 通知發(fā)送者發(fā)送數(shù)據(jù)包，同時應開始計時，若發(fā)送者響應時間超過規(guī)定時間，應發(fā)送放棄幀TP.ABORT;準備發(fā)送幀TP.CM_CTS:此報文為接收者對發(fā)送報文的應答，此次發(fā)送狀態(tài)機已建立，搜索相應狀態(tài)機，根據(jù)準備發(fā)送幀要求拆分數(shù)據(jù)創(chuàng)建數(shù)據(jù)包TP.DT;數(shù)據(jù)包TP.DT:搜索相應的接收狀態(tài)機并核對是否與目前狀態(tài)機相符，如果相符則對數(shù)據(jù)進行重組存入狀態(tài)機的接收字節(jié)數(shù)組，若不符則發(fā)送該參數(shù)組編號的放棄鏈接幀，最后判斷多幀傳輸是否結束，并根據(jù)是否為全局報文決定是否發(fā)送完成鏈接幀；完成鏈接幀TP.EndofMsgACK:表示相應的多幀發(fā)送鏈接已完成，刪除相應的發(fā)送狀態(tài)機。廣播公告消息TP.

　　CM_BAM:收到全局消息的請求鏈接幀，只需建立相應的接收狀態(tài)機，等待接收數(shù)據(jù)包，而不需要任何的應答。

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

　　2.3 J1939平臺應用效果

　　定義電池管理系統(tǒng)BMS和LabVIEW的J1939協(xié)議地址分別為244和86.首先由BMS發(fā)送PGN為256的9 B報文給LabVIEW,CANoe監(jiān)視到總線時序如圖5所示。

　　由第一幀ID可以看出源地址為0xF4（244），目的地址為0×56（86），PGN為0xEC00,因此該幀為鏈接管理幀TP.CM,并且Data 域控制字節(jié)（第1 字節(jié)）為0×10,綜上該幀為BMS 發(fā)送給LabVIEW 的請求發(fā)送幀，并由Data域可以看出此次報文共有0×09字節(jié)（第2,3字節(jié)），數(shù)據(jù)包共有0×02 包（第4 字節(jié)），PGN 為0×0100（第6,7,8 字節(jié)）。同理第二幀為LabVIEW發(fā)送的準備發(fā)送幀，通知BMS 從第0×01 包（第3 字節(jié)）開始發(fā)送0×02（第2 字節(jié)）包數(shù)據(jù)包。待接收到BMS發(fā)送的兩幀TP.DT,LabVIEW發(fā)送TP.EndofMsgACK 代表此次多幀傳輸完成。Lab-VIEW接收重組后的數(shù)據(jù)如圖6所示。

　　同理分析LabVIEW 作為發(fā)送節(jié)點的情況，總線時序圖如圖7所示，LabVIEW拆分前的發(fā)送數(shù)據(jù)如圖8所示。綜上分析，利用LabVIEW 開發(fā)平臺很好地實現(xiàn)了J1939協(xié)議。

　　3 通信協(xié)議測試軟件的開發(fā)

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

　　在已開發(fā)J1939協(xié)議基礎上進行測試軟件的開發(fā)，J1939協(xié)議提供了兩個接口：需要發(fā)送報文直接入未處理發(fā)送報文隊列、已處理接收報文出隊列供應用層使用。通信階段改變利用LabVIEW 狀態(tài)機結構來實現(xiàn)。

　　創(chuàng)建充電機接收狀態(tài)、充電機發(fā)送狀態(tài)兩個數(shù)據(jù)簇，記錄接收報文是否已被接收、發(fā)送報文是否已被發(fā)送以及發(fā)送的時間。利用單獨程序線程通過這兩個數(shù)據(jù)簇實時判斷是否有錯誤發(fā)生。

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

　　4 結語

　　在LabVIEW開發(fā)平臺上，利用其強大的數(shù)據(jù)處理能力以及豐富實用的程序結構實現(xiàn)了J1939協(xié)議，在此基礎上開發(fā)電動汽車非車載傳導式充電機與電池管理系統(tǒng)之間的通信協(xié)議測試軟件，不僅可以輔助BMS的程序開發(fā)，還可以作為BMS測試平臺的部分功能評價BMS合格與否。通過與BMS進行通信，并利用CANoe對總線進行監(jiān)視，試驗結果表明該測試軟件可以實現(xiàn)J1939協(xié)議，能完成多幀傳輸機制，并且可以測試出通信協(xié)議中出現(xiàn)的通信流程錯亂以及通信超時錯誤，可以滿足要求。（作者：劉武，武國良，徐冰亮，李曉宇，馮飛，朱春波）