隨著國家對新能源(yuan)技術的(de)(de)大力(li)扶持(chi)，電(dian)(dian)動(dong)(dong)汽(qi)車(che)(che)(che)(che)逐漸成為國家在新能源(yuan)汽(qi)車(che)(che)(che)(che)產(chan)業大力(li)發展的(de)(de)對象，而電(dian)(dian)動(dong)(dong)汽(qi)車(che)(che)(che)(che)充電(dian)(dian)站、快(kuai)速(su)(su)充電(dian)(dian)機是電(dian)(dian)動(dong)(dong)汽(qi)車(che)(che)(che)(che)大規模化后不可(ke)或缺(que)的(de)(de)服務(wu)基礎設施(shi)之一。大量分布于各住(zhu)宅小(xiao)區、停車(che)(che)(che)(che)場(chang)的(de)(de)電(dian)(dian)動(dong)(dong)汽(qi)車(che)(che)(che)(che)用非車(che)(che)(che)(che)載智能快(kuai)速(su)(su)充電(dian)(dian)機，實(shi)現高效、安(an)全(quan)、智能化的(de)(de)管理(li)必定成為主流。針對目前快(kuai)速(su)(su)充電(dian)(dian)機群(qun)實(shi)行無人值(zhi)守的(de)(de)運行情況(kuang)，這就(jiu)要求快(kuai)速(su)(su)充電(dian)(dian)機須具有較高的(de)(de)可(ke)靠性(xing)和自動(dong)(dong)化程度，功能更加(jia)完(wan)善，可(ke)遠程維(wei)護等功能。

　　這樣，使得分布式、模(mo)塊化(hua)、智能化(hua)成(cheng)為(wei)(wei)快(kuai)速充電機(ji)的(de)發展方向，而高性能、低成(cheng)本的(de)充電機(ji)監控終(zhong)端是(shi)其中的(de)關鍵技術。為(wei)(wei)管(guan)理區(qu)域多臺充電機(ji)的(de)資源優化(hua)利用與管(guan)理的(de)智能化(hua)，監控終(zhong)端與Internet網的(de)交互成(cheng)為(wei)(wei)一種必(bi)然。

　　1 監控網絡的整體方案

　　如圖1的的監控(kong)網絡結構圖所(suo)示，監控(kong)終(zhong)端作(zuo)為(wei)充電機與(yu)監控(kong)中心(xin)之間(jian)的一(yi)個重要(yao)網關。其有(you)效的通信鏈路(lu)有(you)：監控(kong)中心(xin)-監控(kong)終(zhong)端；監控(kong)終(zhong)端-充電機（或(huo)電池(chi)管理系統（BMS）、電動汽(qi)車(che)等）。

　　

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

　　2 監控終端功能模塊

　　2.1 監控終端的總體設計

　　監控終端是連(lian)接(jie)監控中心與(yu)充電機的(de)(de)(de)橋梁。其總體設(she)計結構如(ru)圖2所示，監控終端主要由Cortex- M3 內核的(de)(de)(de)STM32ZGT6 的(de)(de)(de)核心模(mo)(mo)塊(kuai)、數(shu)據采集模(mo)(mo)塊(kuai)（CAN 網絡）、用(yong)戶計費交(jiao)互信息模(mo)(mo)塊(kuai)、數(shu)據存儲(chu)模(mo)(mo)塊(kuai)、實時(shi)時(shi)鐘(zhong)模(mo)(mo)塊(kuai)和(he)GPRS通信模(mo)(mo)塊(kuai)6個部分所組(zu)成。終端采用(yong)Co-tex-M3內核的(de)(de)(de)STM32ZGT6微處理器(qi)芯片。該單片機具有豐富的(de)(de)(de)片上硬(ying)件(jian)資源，內含CAN 2.0B的(de)(de)(de)控制(zhi)器(qi)，以及多達4 個串(chuan)口(kou)，滿足終端CAN 與(yu)GPRS 網絡接(jie)口(kou)的(de)(de)(de)需求(qiu)。

　　

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

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

　　2.2 CAN總線模塊

　　為了(le)更好地保(bao)證CAN 總線可靠的(de)傳(chuan)輸，系統定義了(le)一(yi)套(tao)通用的(de)應用層的(de)CAN 總線協議(yi)。主要針對CAN 2.0B協議(yi)的(de)報文ID進行了(le)分配及定義。

　　如表(biao)1 所示。

　　

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

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

　　在本系統中，用到的消(xiao)息類(lei)(lei)型(xing)主要有：控制、狀態(tai)、測量(liang)、警告和廣播5 種類(lei)(lei)型(xing)。根據將類(lei)(lei)型(xing)碼的具(ju)體分(fen)配如表2所示。

　　

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

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

　　

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

　　例如，BMS節(jie)點(dian)，包(bao)含(han)了電(dian)池組(zu)總電(dian)壓、電(dian)池組(zu)總電(dian)流、電(dian)池組(zu)SoC、電(dian)池組(zu)各個箱體（9個）的(de)溫度以(yi)及(ji)電(dian)池組(zu)狀(zhuang)態的(de)信息等。每個數(shu)據占用2 B.顯然一個數(shu)據幀(zhen)是無法發送該(gai)節(jie)點(dian)的(de)全部信息，故須采用多幀(zhen)方式發送。

　　2.3 數據發送模塊

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

　　

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

　　（2）報文(wen)長(chang)度。是由［發送序(xu)列(lie)號］到［數據(ju)內容］的(de)總長(chang)度。

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

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

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

　　數據(ju)(ju)(ju)(ju)內(nei)(nei)容一般(ban)由一個或多個數據(ju)(ju)(ju)(ju)對象組(zu)合而成，也(ye)可以為(wei)空。發(fa)(fa)送(song)方在(zai)應(ying)答非正常(chang)或無應(ying)答的(de)(de)情(qing)況下，每條數據(ju)(ju)(ju)(ju)報文最多重復發(fa)(fa)6次，每次間隔時(shi)間為(wei)30 s.數據(ju)(ju)(ju)(ju)內(nei)(nei)容根據(ju)(ju)(ju)(ju)命令字的(de)(de)不(bu)同其所組(zu)成的(de)(de)數據(ju)(ju)(ju)(ju)對象也(ye)不(bu)同，通常(chang)情(qing)況下，終端(duan)(duan)與監控(kong)中(zhong)心的(de)(de)通信包括終端(duan)(duan)注(zhu)冊、中(zhong)心應(ying)答、終端(duan)(duan)就緒、定時(shi)發(fa)(fa)送(song)4個階(jie)段。部分(fen)命令字與對應(ying)的(de)(de)數據(ju)(ju)(ju)(ju)內(nei)(nei)容見表5所示。

　　

　　3 軟件設計

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

　　移(yi)植μC/OS-Ⅱ實時(shi)(shi)操作(zuo)系(xi)統(tong)(tong)為監(jian)控終(zhong)(zhong)端的系(xi)統(tong)(tong)平臺，該系(xi)統(tong)(tong)是(shi)可剝奪性多任務內(nei)核的實時(shi)(shi)操作(zuo)系(xi)統(tong)(tong)，具有實時(shi)(shi)、可裁剪、可靠和穩(wen)定性等優點。μC/OS-Ⅱ的系(xi)統(tong)(tong)資源(yuan)豐富，除(chu)去自身的系(xi)統(tong)(tong)任務外，用戶可以建立多達56個任務，并提供(gong)信號量、消息郵箱(xiang)、消息隊列及內(nei)存(cun)管理(li)等系(xi)統(tong)(tong)級服務，足以滿足充電(dian)樁的監(jian)控終(zhong)(zhong)端的系(xi)統(tong)(tong)要求。

　　為實現監控終(zhong)端的(de)(de)功(gong)能要求，在μC/OS-Ⅱ中設計了以下13個任(ren)(ren)(ren)務：顯示(shi)任(ren)(ren)(ren)務、鍵(jian)盤查詢任(ren)(ren)(ren)務、輸(shu)入(ru)處理任(ren)(ren)(ren)務、打印任(ren)(ren)(ren)務、數(shu)據的(de)(de)存儲任(ren)(ren)(ren)務、IC 卡的(de)(de)讀/寫任(ren)(ren)(ren)務、GPRS 的(de)(de)發送任(ren)(ren)(ren)務、CAN 數(shu)據的(de)(de)接(jie)收任(ren)(ren)(ren)務、CAN 數(shu)據的(de)(de)發送任(ren)(ren)(ren)務、GPRS的(de)(de)接(jie)收任(ren)(ren)(ren)務、命令控制(zhi)任(ren)(ren)(ren)務、報警任(ren)(ren)(ren)務及看(kan)門狗的(de)(de)喂狗和異常檢測任(ren)(ren)(ren)務。

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

　　

　　表1 中基本數據包(bao)括城市區(qu)號(hao)、停(ting)車場序號(hao)、充(chong)電樁位置信(xin)息(xi)(xi)、報文發送時間以(yi)及充(chong)電機、BMS和用戶IC卡的(de)相(xiang)關(guan)信(xin)息(xi)(xi)共計209 B.

　　表(biao)中各任務優先級之間保留(liu)一定(ding)的(de)(de)間隔，方便系(xi)統(tong)(tong)以后的(de)(de)改(gai)進和升級。系(xi)統(tong)(tong)設定(ding)時鐘節拍為10 ms，滿足充電(dian)樁(zhuang)的(de)(de)實時性要求(qiu)。μC/OS-Ⅱ系(xi)統(tong)(tong)利用信(xin)號量、消(xiao)息(xi)郵箱(xiang)和消(xiao)息(xi)隊(dui)列三種(zhong)通信(xin)方式將本系(xi)統(tong)(tong)中的(de)(de)13個應用任務關聯在一起(qi)，其關系(xi)如(ru)圖3所示。

　　

　　3.2 ZWG-23A模塊的配置

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

　　

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

　　4 結語

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