隨著(zhu)國家對(dui)新(xin)能(neng)(neng)源(yuan)技術的(de)大(da)力扶持，電動(dong)汽(qi)車(che)(che)逐(zhu)漸成為國家在新(xin)能(neng)(neng)源(yuan)汽(qi)車(che)(che)產業大(da)力發展的(de)對(dui)象(xiang)，而電動(dong)汽(qi)車(che)(che)充(chong)電站、快(kuai)(kuai)速(su)(su)充(chong)電機(ji)是電動(dong)汽(qi)車(che)(che)大(da)規模化(hua)后(hou)不可(ke)或缺的(de)服(fu)務基礎設施之一(yi)。大(da)量分(fen)布于各住宅小區、停(ting)車(che)(che)場的(de)電動(dong)汽(qi)車(che)(che)用非車(che)(che)載智能(neng)(neng)快(kuai)(kuai)速(su)(su)充(chong)電機(ji)，實現高(gao)效、安全、智能(neng)(neng)化(hua)的(de)管理必定成為主流。針對(dui)目前快(kuai)(kuai)速(su)(su)充(chong)電機(ji)群實行(xing)無(wu)人值守的(de)運(yun)行(xing)情況，這就要求快(kuai)(kuai)速(su)(su)充(chong)電機(ji)須具有較高(gao)的(de)可(ke)靠性和自動(dong)化(hua)程(cheng)度，功(gong)(gong)能(neng)(neng)更加完善，可(ke)遠(yuan)程(cheng)維(wei)護等(deng)功(gong)(gong)能(neng)(neng)。

　　這樣，使(shi)得分布式、模塊化(hua)(hua)、智能化(hua)(hua)成為(wei)快速(su)充(chong)電(dian)(dian)機(ji)的(de)(de)發展方(fang)向，而高(gao)性能、低(di)成本的(de)(de)充(chong)電(dian)(dian)機(ji)監控終端是其中的(de)(de)關鍵技術。為(wei)管理(li)(li)區域(yu)多臺(tai)充(chong)電(dian)(dian)機(ji)的(de)(de)資(zi)源優化(hua)(hua)利用(yong)與(yu)管理(li)(li)的(de)(de)智能化(hua)(hua)，監控終端與(yu)Internet網(wang)的(de)(de)交互成為(wei)一種(zhong)必然。

　　1 監控網絡的整體方案

　　如圖1的的監控網絡結構圖所示，監控終端作為充電機與監控中心之間的一個重要網關。其有效的通信鏈路有：監控中心-監控終端；監控終端-充電機（或電池管理系統（BMS）、電動汽車等）。

　　

　　通過(guo)監(jian)(jian)控(kong)(kong)終(zhong)(zhong)端(duan)作(zuo)為媒介，實現(xian)了監(jian)(jian)控(kong)(kong)中(zhong)(zhong)心(xin)(xin)與充(chong)(chong)電(dian)(dian)(dian)(dian)(dian)機及(ji)(ji)電(dian)(dian)(dian)(dian)(dian)動(dong)汽(qi)車的通信鏈路的建立(li)。終(zhong)(zhong)端(duan)通過(guo)CAN網絡與充(chong)(chong)電(dian)(dian)(dian)(dian)(dian)機、BMS及(ji)(ji)電(dian)(dian)(dian)(dian)(dian)動(dong)汽(qi)車等相(xiang)互通信，采集相(xiang)關節點(dian)的數據信息(xi)并存儲，并將(jiang)相(xiang)關信息(xi)反饋(kui)給充(chong)(chong)電(dian)(dian)(dian)(dian)(dian)機。充(chong)(chong)電(dian)(dian)(dian)(dian)(dian)機根據相(xiang)關信息(xi)從而(er)實現(xian)電(dian)(dian)(dian)(dian)(dian)動(dong)汽(qi)車電(dian)(dian)(dian)(dian)(dian)池(chi)的智能(neng)充(chong)(chong)電(dian)(dian)(dian)(dian)(dian)。終(zhong)(zhong)端(duan)與監(jian)(jian)控(kong)(kong)中(zhong)(zhong)心(xin)(xin)之間是(shi)通過(guo)GPRS連接通信，終(zhong)(zhong)端(duan)將(jiang)充(chong)(chong)電(dian)(dian)(dian)(dian)(dian)機、電(dian)(dian)(dian)(dian)(dian)池(chi)、電(dian)(dian)(dian)(dian)(dian)動(dong)汽(qi)車等相(xiang)關數據傳回監(jian)(jian)控(kong)(kong)中(zhong)(zhong)心(xin)(xin)，監(jian)(jian)控(kong)(kong)中(zhong)(zhong)心(xin)(xin)實現(xian)對(dui)充(chong)(chong)電(dian)(dian)(dian)(dian)(dian)機的遠程控(kong)(kong)制和實時監(jian)(jian)控(kong)(kong)功(gong)能(neng)，記錄充(chong)(chong)電(dian)(dian)(dian)(dian)(dian)機的運行(xing)及(ji)(ji)故障(zhang)情況。車主可(ke)以由監(jian)(jian)控(kong)(kong)中(zhong)(zhong)心(xin)(xin)查詢了解當前空閑的充(chong)(chong)電(dian)(dian)(dian)(dian)(dian)機位置(zhi)，實現(xian)資源充(chong)(chong)分利用。

　　2 監控終端功能模塊

　　2.1 監控終端的總體設計

　　監(jian)控(kong)終(zhong)端是連接監(jian)控(kong)中(zhong)心與充電機的(de)橋梁。其(qi)總體設計(ji)(ji)結構如圖(tu)2所示(shi)，監(jian)控(kong)終(zhong)端主(zhu)要由Cortex- M3 內(nei)(nei)核(he)的(de)STM32ZGT6 的(de)核(he)心模(mo)塊(kuai)、數據(ju)采(cai)(cai)集(ji)模(mo)塊(kuai)（CAN 網絡）、用(yong)戶計(ji)(ji)費交互(hu)信(xin)息模(mo)塊(kuai)、數據(ju)存儲模(mo)塊(kuai)、實(shi)時時鐘模(mo)塊(kuai)和(he)GPRS通(tong)信(xin)模(mo)塊(kuai)6個(ge)部(bu)分所組成。終(zhong)端采(cai)(cai)用(yong)Co-tex-M3內(nei)(nei)核(he)的(de)STM32ZGT6微處理器芯片。該(gai)單片機具有(you)豐富的(de)片上硬件(jian)資源(yuan)，內(nei)(nei)含CAN 2.0B的(de)控(kong)制器，以(yi)及多達(da)4 個(ge)串口，滿(man)足終(zhong)端CAN 與GPRS 網絡接口的(de)需(xu)求。

　　

　　監控(kong)終端(duan)的工(gong)作流程如下(xia)：用戶(hu)計費模塊讀取用戶(hu)信息以及選擇充(chong)(chong)電模式，通(tong)過CAN 網(wang)絡向充(chong)(chong)電模塊發送相應充(chong)(chong)電命令；同時監控(kong)終端(duan)讀取CAN 網(wang)絡中(zhong)的關鍵數據(ju)幀(zhen)如充(chong)(chong)電機的運行(xing)狀況(kuang)等(deng)，并將數據(ju)保存于NandFlash中(zhong)。

　　定時將當前充(chong)電用(yong)(yong)戶信息和(he)充(chong)電機等運(yun)行參數通過GPRS 發送到監控(kong)中心。監控(kong)終端可以根據用(yong)(yong)戶的需要，打印用(yong)(yong)戶的余額或收費(fei)憑(ping)據等。

　　2.2 CAN總線模塊

　　為了更(geng)好(hao)地保證(zheng)CAN 總(zong)線(xian)可靠的傳(chuan)輸，系(xi)統定義了一套通(tong)用的應用層的CAN 總(zong)線(xian)協(xie)議。主(zhu)要針(zhen)對CAN 2.0B協(xie)議的報文ID進(jin)行了分配(pei)及定義。

　　如(ru)表1 所示。

　　

　　（1）優(you)先(xian)級(ji)(ji)確(que)定。CAN協議規定報文ID越小，其報文的(de)(de)優(you)先(xian)級(ji)(ji)越高(gao)。在競爭總線時，優(you)先(xian)級(ji)(ji)高(gao)的(de)(de)報文優(you)先(xian)發(fa)送，優(you)先(xian)級(ji)(ji)低(di)的(de)(de)退出總線競爭。CAN 總線競爭的(de)(de)算法效率很高(gao)，是一種非破壞性競爭［3］。因CAN協議規定標(biao)識符由高(gao)至低(di)，前7位不能全(quan)為(wei)顯性位。所以優(you)先(xian)級(ji)(ji)1111b保留，故(gu)系統具有(you)15 級(ji)(ji)優(you)先(xian)級(ji)(ji)別(bie)。

　　（2）類型碼(ma)。協議將ID24~ID22 規定消息的類型。

　　在本(ben)系統中(zhong)，用到的(de)消息類(lei)型(xing)主要有：控制(zhi)、狀態、測(ce)量、警告和廣播(bo)5 種類(lei)型(xing)。根據將類(lei)型(xing)碼(ma)的(de)具體分配如(ru)表(biao)2所示。

　　

　　（3）源地(di)(di)址(zhi)(zhi)。協議規(gui)定(ding)ID12~ID16 為(wei)源地(di)(di)址(zhi)(zhi)，ID17~ID21為(wei)目標(biao)地(di)(di)址(zhi)(zhi)，進而標(biao)識報文的各(ge)接收節(jie)點(dian)與發送節(jie)點(dian)。5位(wei)地(di)(di)址(zhi)(zhi)位(wei)，保留(liu)11111b為(wei)廣播地(di)(di)址(zhi)(zhi)，可以(yi)確定(ding)31個控制節(jie)點(dian)，可滿足電(dian)動汽車充(chong)電(dian)機的監控需求。在此系(xi)統中，定(ding)義00000b為(wei)監控終端，00001b為(wei)充(chong)電(dian)機節(jie)點(dian)，00010b為(wei)電(dian)池管理系(xi)統（BMS）節(jie)點(dian)。

　　（4）分段(duan)碼。因不(bu)同(tong)的節點所發(fa)送(song)的數(shu)(shu)據(ju)(ju)量不(bu)同(tong)，可能(neng)會出現一個數(shu)(shu)據(ju)(ju)幀不(bu)能(neng)把從(cong)底(di)層采集到的數(shu)(shu)據(ju)(ju)一次(ci)性發(fa)送(song)完畢（即超(chao)過8 個字節的情況）。協議中將ID11~ID4定(ding)義為(wei)分段(duan)碼，如(ru)表3所示(shi)。

　　

　　在表3 中，某節點的(de)數據幀由分段碼(ma)00H 開始，由FFH結束(shu)，最大可支(zhi)持發送(song)256×8字(zi)節的(de)數據。若該節點只有一幀數據，定義(yi)FFH同時也為(wei)單(dan)幀數據。

　　例如，BMS節點(dian)，包含了(le)電(dian)池(chi)組(zu)(zu)總電(dian)壓、電(dian)池(chi)組(zu)(zu)總電(dian)流、電(dian)池(chi)組(zu)(zu)SoC、電(dian)池(chi)組(zu)(zu)各個(ge)箱體(ti)（9個(ge)）的(de)(de)溫度以及(ji)電(dian)池(chi)組(zu)(zu)狀態(tai)的(de)(de)信息等。每個(ge)數據(ju)占用(yong)2 B.顯(xian)然一個(ge)數據(ju)幀是無法發送(song)(song)該節點(dian)的(de)(de)全(quan)部信息，故(gu)須(xu)采用(yong)多(duo)幀方式(shi)發送(song)(song)。

　　2.3 數據發送模塊

　　終端是通(tong)(tong)過(guo)串(chuan)口(kou)外(wai)接(jie)周立功GPRS 模塊（ZWG-23A）連接(jie)到互聯網。通(tong)(tong)過(guo)GPRS網絡(luo)上網，連接(jie)到服務器之后(hou)，按照通(tong)(tong)信協議(yi)定時向服務器發(fa)送數據(ju)。根據(ju)《深圳市電動汽車充電系(xi)統技術規范》標準文件，協議(yi)由(you)報文起始標識(shi)、版本號、命令字、報文長度、數據(ju)內容、校檢(jian)碼等組(zu)成(cheng)的(de)，其具體格(ge)式如表4 所示。

　　

　　（1）起始標(biao)識。設為(wei)0xFAF5，用于喚醒接收(shou)方準備接收(shou)數據。

　　（2）報文(wen)長度(du)。是由［發送序列號(hao)］到［數(shu)據內容(rong)］的總長度(du)。

　　（3）校驗碼。是從［起始標識(shi)］到［數據內容(rong)］的無進位累加和。

　　（4）接收（發(fa)送(song)）方類(lei)型(xing)與地址。監(jian)控中心(xin)為(wei)類(lei)型(xing)為(wei)“業務服務平臺”，其(qi)(qi)數值為(wei)1，其(qi)(qi)地址為(wei)在(zai)此(ci)類(lei)型(xing)碼下的(de)某(mou)一個(ge)惟一地址；終端的(de)類(lei)型(xing)為(wei)“調(diao)度(du)終端”，其(qi)(qi)數值為(wei)255，地址為(wei)此(ci)類(lei)型(xing)下的(de)某(mou)一個(ge)惟一地址。

　　（5）數據內容與命令字：不同的(de)命令字決定該報文所攜(xie)帶(dai)的(de)數據的(de)內容的(de)構成及(ji)所占用的(de)字節數。

　　數(shu)據(ju)(ju)內容一(yi)般(ban)由一(yi)個或(huo)多個數(shu)據(ju)(ju)對(dui)象組合而成，也(ye)可以為(wei)空。發送方在(zai)應(ying)答(da)非正(zheng)常(chang)或(huo)無(wu)應(ying)答(da)的情況(kuang)下，每(mei)條(tiao)數(shu)據(ju)(ju)報文最多重復發6次，每(mei)次間隔時間為(wei)30 s.數(shu)據(ju)(ju)內容根據(ju)(ju)命令字(zi)的不同(tong)其所組成的數(shu)據(ju)(ju)對(dui)象也(ye)不同(tong)，通常(chang)情況(kuang)下，終端(duan)與監控中(zhong)(zhong)心的通信包括終端(duan)注冊(ce)、中(zhong)(zhong)心應(ying)答(da)、終端(duan)就(jiu)緒(xu)、定時發送4個階段。部分命令字(zi)與對(dui)應(ying)的數(shu)據(ju)(ju)內容見表5所示。

　　

　　3 軟件設計

　　3.1 μC/OS-Ⅱ的多任務管理

　　移植μC/OS-Ⅱ實時操作系(xi)(xi)(xi)統(tong)(tong)為(wei)監控終(zhong)端(duan)的(de)系(xi)(xi)(xi)統(tong)(tong)平臺，該系(xi)(xi)(xi)統(tong)(tong)是可(ke)剝奪(duo)性(xing)多(duo)任務內核(he)的(de)實時操作系(xi)(xi)(xi)統(tong)(tong)，具有實時、可(ke)裁剪、可(ke)靠和(he)穩定性(xing)等(deng)優點。μC/OS-Ⅱ的(de)系(xi)(xi)(xi)統(tong)(tong)資源豐富，除去自(zi)身的(de)系(xi)(xi)(xi)統(tong)(tong)任務外，用戶可(ke)以建立多(duo)達56個(ge)任務，并提供(gong)信號量(liang)、消息郵箱、消息隊列(lie)及(ji)內存管理等(deng)系(xi)(xi)(xi)統(tong)(tong)級(ji)服務，足以滿(man)足充電樁的(de)監控終(zhong)端(duan)的(de)系(xi)(xi)(xi)統(tong)(tong)要求。

　　為實現(xian)監控終端的功能(neng)要求，在μC/OS-Ⅱ中設計(ji)了以下13個(ge)任(ren)(ren)(ren)(ren)務(wu)(wu)(wu)：顯示任(ren)(ren)(ren)(ren)務(wu)(wu)(wu)、鍵盤(pan)查(cha)詢(xun)任(ren)(ren)(ren)(ren)務(wu)(wu)(wu)、輸入處理任(ren)(ren)(ren)(ren)務(wu)(wu)(wu)、打印任(ren)(ren)(ren)(ren)務(wu)(wu)(wu)、數據(ju)的存儲任(ren)(ren)(ren)(ren)務(wu)(wu)(wu)、IC 卡的讀/寫(xie)任(ren)(ren)(ren)(ren)務(wu)(wu)(wu)、GPRS 的發送(song)任(ren)(ren)(ren)(ren)務(wu)(wu)(wu)、CAN 數據(ju)的接(jie)收(shou)任(ren)(ren)(ren)(ren)務(wu)(wu)(wu)、CAN 數據(ju)的發送(song)任(ren)(ren)(ren)(ren)務(wu)(wu)(wu)、GPRS的接(jie)收(shou)任(ren)(ren)(ren)(ren)務(wu)(wu)(wu)、命(ming)令(ling)控制(zhi)任(ren)(ren)(ren)(ren)務(wu)(wu)(wu)、報警任(ren)(ren)(ren)(ren)務(wu)(wu)(wu)及看門狗(gou)的喂狗(gou)和異(yi)常檢(jian)測(ce)任(ren)(ren)(ren)(ren)務(wu)(wu)(wu)。

　　μC/OS-Ⅱ的(de)(de)多任(ren)(ren)務(wu)(wu)(wu)的(de)(de)特點，規定每個任(ren)(ren)務(wu)(wu)(wu)都必須具(ju)有不(bu)同的(de)(de)優先(xian)級(ji)。根據任(ren)(ren)務(wu)(wu)(wu)的(de)(de)關(guan)聯(lian)性(xing)(xing)(xing)、關(guan)鍵性(xing)(xing)(xing)、緊迫(po)性(xing)(xing)(xing)、頻繁性(xing)(xing)(xing)、實時要求性(xing)(xing)(xing)來確定任(ren)(ren)務(wu)(wu)(wu)的(de)(de)優先(xian)級(ji)，既要保證每個任(ren)(ren)務(wu)(wu)(wu)的(de)(de)相對獨(du)立性(xing)(xing)(xing)，又要避免(mian)任(ren)(ren)務(wu)(wu)(wu)調度頻繁致使系統的(de)(de)效率(lv)下降。任(ren)(ren)務(wu)(wu)(wu)的(de)(de)優先(xian)級(ji)規劃如表6所示。

　　

　　表(biao)1 中(zhong)基本數據包括城市(shi)區號、停車場序號、充電樁位(wei)置信息、報文(wen)發送(song)時間以及充電機、BMS和用戶IC卡的(de)相關信息共計209 B.

　　表(biao)中各任(ren)務優先(xian)級(ji)之間保留一定的間隔(ge)，方便系(xi)統(tong)以后的改進和升(sheng)級(ji)。系(xi)統(tong)設定時(shi)鐘節(jie)拍為10 ms，滿(man)足(zu)充電樁的實時(shi)性要求。μC/OS-Ⅱ系(xi)統(tong)利(li)用(yong)信號量、消(xiao)(xiao)息郵箱和消(xiao)(xiao)息隊列三種通信方式將本(ben)系(xi)統(tong)中的13個應用(yong)任(ren)務關聯在一起，其(qi)關系(xi)如圖3所示。

　　

　　3.2 ZWG-23A模塊的配置

　　ZWG-23A 通過(guo)串口與終端(duan)鏈(lian)(lian)接(jie)，它(ta)通過(guo)移動通信的(de)GPRS 網絡鏈(lian)(lian)接(jie)互(hu)聯(lian)網。由于周立(li)功公司并沒(mei)有提供基(ji)于μC/OS-Ⅱ的(de)DTU 配置程(cheng)序，所以系(xi)統中需要自行開發相關的(de)配置程(cheng)序，其(qi)配置DTU 的(de)程(cheng)序流程(cheng)圖如圖4所示。

　　

　　假設終端(duan)(duan)每天與中(zhong)心(xin)連接(jie)注冊(ce)一(yi)(yi)(yi)次，以每隔30 s的心(xin)跳時(shi)間定時(shi)向中(zhong)心(xin)發(fa)(fa)送監(jian)控信息，根(gen)據表6數(shu)據內容字節計(ji)算(suan)，一(yi)(yi)(yi)臺終端(duan)(duan)一(yi)(yi)(yi)天發(fa)(fa)送報(bao)文所產(chan)生(sheng)的GPRS流(liu)量(liang)(liang)大約為 （228 × 2 × 60 × 24 + 294 × 2 + 100） （128 × 1 024） =5 MB，以每月30天計(ji)算(suan)，一(yi)(yi)(yi)年一(yi)(yi)(yi)臺終端(duan)(duan)所產(chan)生(sheng)的GPRS流(liu)量(liang)(liang)為1.7 GB.采用2 GB的包(bao)年流(liu)量(liang)(liang)套餐足以滿足終端(duan)(duan)一(yi)(yi)(yi)年所產(chan)生(sheng)的流(liu)量(liang)(liang)費(fei)。

　　4 結語

　　本文研究了(le)電(dian)動(dong)汽車快速充電(dian)機監控網(wang)絡(luo)的結構組成，詳細分析(xi)了(le)監控終端的通信網(wang)絡(luo)的CAN與GPRS的通信應用(yong)(yong)(yong)層協議(yi)。其(qi)CAN 網(wang)絡(luo)協議(yi)具有廣泛的通用(yong)(yong)(yong)性，GPRS的流量少，可推(tui)廣到自動(dong)化的其(qi)他(ta)領域中的應用(yong)(yong)(yong)。