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

2.2 軟件實(shí)現(xiàn)

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

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

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

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

2.3 J1939平臺應(yīng)用效果

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

由第一幀ID可以看出源地址為0xF4(244)，目的地址為0×56(86)，PGN為0xEC00,因此該幀為鏈接管理幀TP.CM,并且Data 域控制字節(jié)(第1 字節(jié))為0×10,綜上該幀為BMS 發(fā)送給LabVIEW 的請求發(fā)送幀，并由Data域可以看出此次報(bào)文共有0×09字節(jié)(第2,3字節(jié))，數(shù)據(jù)包共有0×02 包(第4 字節(jié))，PGN 為0×0100(第6,7,8 字節(jié))。同理第二幀為LabVIEW發(fā)送的準(zhǔn)備發(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é)點(diǎn)的情況，總線時(shí)序圖如圖7所示，LabVIEW拆分前的發(fā)送數(shù)據(jù)如圖8所示。綜上分析，利用LabVIEW 開發(fā)平臺很好地實(shí)現(xiàn)了J1939協(xié)議。

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

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

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