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

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

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

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

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

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