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

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

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

本文重點(diǎn)在于如何用LabVIEW實(shí)現(xiàn)SAEJ1939多幀傳輸機(jī)制，完成超過(guò)8B報(bào)文的接收重組、拆分發(fā)送。以及如何實(shí)時(shí)判斷通信過(guò)程出現(xiàn)的錯(cuò)誤、指出錯(cuò)誤類(lèi)型、定位錯(cuò)誤發(fā)生的階段。

1SAEJ1939協(xié)議

J1939協(xié)議是基于CAN2.0B制定的，協(xié)議對(duì)物理層、數(shù)據(jù)鏈路層、網(wǎng)路層以及應(yīng)用層都進(jìn)行了相關(guān)的規(guī)定。本文針對(duì)數(shù)據(jù)鏈路層的規(guī)定進(jìn)行簡(jiǎn)單介紹。

1.1協(xié)議數(shù)據(jù)單元(pDU)

J1939將CAN2.0B的29位標(biāo)識(shí)符ID劃分為六部分，每部分都代表不同的含義，包括優(yōu)先級(jí)(p)、保留位(R)、數(shù)據(jù)頁(yè)(Dp)、pDU格式(pF)、特定pDU(pS)、源地址(SA)，見(jiàn)表1.

根據(jù)CAN2.0總線的仲裁機(jī)制，標(biāo)識(shí)符值越小，CAN幀優(yōu)先級(jí)越高，J1939把這一權(quán)利賦予了標(biāo)識(shí)符最高三位(p)。R、Dp通常為0.SA代表了該幀數(shù)據(jù)的發(fā)送節(jié)點(diǎn)的地址，CAN網(wǎng)絡(luò)中每個(gè)設(shè)備都分配了惟一的SA.在介紹pF與pS之前有必要先介紹下參數(shù)組編號(hào)(pGN)的概念。每個(gè)pGN代表著惟一的參數(shù)組(可以包含一個(gè)或多個(gè)參數(shù))，當(dāng)參數(shù)組的數(shù)據(jù)域大于8B時(shí)，需要遵循J1939的多幀傳輸機(jī)制。pGN由R、Dp、pF以及pS組成，見(jiàn)表2.從表2中可以看出pDU2格式報(bào)文沒(méi)有目標(biāo)地址，此類(lèi)報(bào)文只能發(fā)送給全局地址。由于pS作為pDU2格式參數(shù)組編號(hào)的一部分，因此pDU2比pDU1能定義更多的參數(shù)組編號(hào)。

1.2多幀傳輸機(jī)制

CAN2.0B數(shù)據(jù)域最多有8B,而在J1939協(xié)議中當(dāng)一個(gè)參數(shù)組編號(hào)(pGN)所對(duì)應(yīng)的數(shù)據(jù)超過(guò)8B時(shí)，規(guī)定了一種多幀傳輸機(jī)制，發(fā)送者按此機(jī)制拆分發(fā)送，接收者按此機(jī)制接收重組，因此一個(gè)參數(shù)組編號(hào)所對(duì)應(yīng)的數(shù)據(jù)最多可以為1785B.點(diǎn)對(duì)點(diǎn)未發(fā)生錯(cuò)誤的多幀傳輸機(jī)制如圖1所示，J1939對(duì)傳輸過(guò)程出現(xiàn)錯(cuò)誤的情況也規(guī)定了相應(yīng)的處理機(jī)制，在此不作介紹。

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

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

2基于LabVIEW實(shí)現(xiàn)J1939協(xié)議平臺(tái)

2.1硬件接口

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

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

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

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

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

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

定義電池管理系統(tǒng)BMS和LabVIEW的J1939協(xié)議地址分別為244和86.首先由BMS發(fā)送pGN為256的9B報(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的請(qǐng)求發(fā)送幀，并由Data域可以看出此次報(bào)文共有0×09字節(jié)(第2,3字節(jié))，數(shù)據(jù)包共有0×02包(第4字節(jié))，pGN為0×0100(第6,7,8字節(jié))。同理第二幀為L(zhǎng)abVIEW發(fā)送的準(zhǔn)備發(fā)送幀，通知BMS從第0×01包(第3字節(jié))開(kāi)始發(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開(kāi)發(fā)平臺(tái)很好地實(shí)現(xiàn)了J1939協(xié)議。

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

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

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

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

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

4結(jié)語(yǔ)

在LabVIEW開(kāi)發(fā)平臺(tái)上，利用其強(qiáng)大的數(shù)據(jù)處理能力以及豐富實(shí)用的程序結(jié)構(gòu)實(shí)現(xiàn)了J1939協(xié)議，在此基礎(chǔ)上開(kāi)發(fā)電動(dòng)汽車(chē)非車(chē)載傳導(dǎo)式充電機(jī)與電池管理系統(tǒng)之間的通信協(xié)議測(cè)試軟件，不僅可以輔助BMS的程序開(kāi)發(fā)，還可以作為BMS測(cè)試平臺(tái)的部分功能評(píng)價(jià)BMS合格與否。通過(guò)與BMS進(jìn)行通信，并利用CANoe對(duì)總線進(jìn)行監(jiān)視，試驗(yàn)結(jié)果表明該測(cè)試軟件可以實(shí)現(xiàn)J1939協(xié)議，能完成多幀傳輸機(jī)制，并且可以測(cè)試出通信協(xié)議中出現(xiàn)的通信流程錯(cuò)亂以及通信超時(shí)錯(cuò)誤，可以滿足要求。