電動汽車快速充電機監控終端的設計
隨著國(guo)家對新(xin)能(neng)(neng)源技術的(de)(de)大(da)(da)力(li)扶持(chi),電(dian)(dian)(dian)動汽(qi)(qi)車逐漸成為國(guo)家在新(xin)能(neng)(neng)源汽(qi)(qi)車產業大(da)(da)力(li)發展的(de)(de)對象,而電(dian)(dian)(dian)動汽(qi)(qi)車充(chong)電(dian)(dian)(dian)站(zhan)、快速(su)充(chong)電(dian)(dian)(dian)機(ji)是電(dian)(dian)(dian)動汽(qi)(qi)車大(da)(da)規(gui)模化(hua)(hua)后(hou)不可或缺的(de)(de)服(fu)務基礎設施(shi)之一。大(da)(da)量分布于(yu)各住(zhu)宅小區、停(ting)車場(chang)的(de)(de)電(dian)(dian)(dian)動汽(qi)(qi)車用非車載(zai)智能(neng)(neng)快速(su)充(chong)電(dian)(dian)(dian)機(ji),實現(xian)高效、安全、智能(neng)(neng)化(hua)(hua)的(de)(de)管理必定(ding)成為主流(liu)。針(zhen)對目(mu)前快速(su)充(chong)電(dian)(dian)(dian)機(ji)群實行無人值守的(de)(de)運行情況,這就要求快速(su)充(chong)電(dian)(dian)(dian)機(ji)須具有較(jiao)高的(de)(de)可靠(kao)性和自動化(hua)(hua)程度,功能(neng)(neng)更加完善(shan),可遠(yuan)程維護等功能(neng)(neng)。
這樣,使得分布式、模(mo)塊化(hua)(hua)、智(zhi)能化(hua)(hua)成(cheng)為(wei)快(kuai)速充電(dian)(dian)機(ji)的發展方(fang)向,而(er)高性能、低成(cheng)本的充電(dian)(dian)機(ji)監控終(zhong)端是其中的關鍵技(ji)術(shu)。為(wei)管理區域多臺充電(dian)(dian)機(ji)的資源優化(hua)(hua)利用與管理的智(zhi)能化(hua)(hua),監控終(zhong)端與Internet網的交(jiao)互成(cheng)為(wei)一種必然。
1 監控網絡的整體方案
如圖1的的監(jian)控網絡(luo)結構圖所示,監(jian)控終(zhong)端(duan)作為(wei)充(chong)電(dian)機與監(jian)控中心(xin)之間的一個重要網關。其(qi)有(you)效(xiao)的通信鏈路有(you):監(jian)控中心(xin)-監(jian)控終(zhong)端(duan);監(jian)控終(zhong)端(duan)-充(chong)電(dian)機(或(huo)電(dian)池管理系統(BMS)、電(dian)動汽車等)。
通過監控(kong)終(zhong)端(duan)作為(wei)媒介,實(shi)現(xian)(xian)了監控(kong)中(zhong)心(xin)與充(chong)(chong)(chong)電(dian)機(ji)(ji)(ji)及電(dian)動(dong)(dong)汽車(che)(che)的(de)(de)(de)(de)通信(xin)鏈路的(de)(de)(de)(de)建立(li)。終(zhong)端(duan)通過CAN網絡與充(chong)(chong)(chong)電(dian)機(ji)(ji)(ji)、BMS及電(dian)動(dong)(dong)汽車(che)(che)等相互通信(xin),采集相關節點的(de)(de)(de)(de)數(shu)據(ju)信(xin)息并(bing)存儲(chu),并(bing)將相關信(xin)息反饋給充(chong)(chong)(chong)電(dian)機(ji)(ji)(ji)。充(chong)(chong)(chong)電(dian)機(ji)(ji)(ji)根據(ju)相關信(xin)息從而實(shi)現(xian)(xian)電(dian)動(dong)(dong)汽車(che)(che)電(dian)池(chi)的(de)(de)(de)(de)智能充(chong)(chong)(chong)電(dian)。終(zhong)端(duan)與監控(kong)中(zhong)心(xin)之間是(shi)通過GPRS連(lian)接通信(xin),終(zhong)端(duan)將充(chong)(chong)(chong)電(dian)機(ji)(ji)(ji)、電(dian)池(chi)、電(dian)動(dong)(dong)汽車(che)(che)等相關數(shu)據(ju)傳(chuan)回監控(kong)中(zhong)心(xin),監控(kong)中(zhong)心(xin)實(shi)現(xian)(xian)對充(chong)(chong)(chong)電(dian)機(ji)(ji)(ji)的(de)(de)(de)(de)遠程控(kong)制(zhi)和實(shi)時監控(kong)功能,記(ji)錄充(chong)(chong)(chong)電(dian)機(ji)(ji)(ji)的(de)(de)(de)(de)運行及故障情況。車(che)(che)主(zhu)可以由(you)監控(kong)中(zhong)心(xin)查詢了解當前空閑的(de)(de)(de)(de)充(chong)(chong)(chong)電(dian)機(ji)(ji)(ji)位(wei)置,實(shi)現(xian)(xian)資源充(chong)(chong)(chong)分利用。
2 監控終端功能模塊
2.1 監控終端的總體設計
監控(kong)(kong)終(zhong)(zhong)端是連(lian)接監控(kong)(kong)中心與充(chong)電機的(de)橋梁。其總體設計結構(gou)如圖2所示,監控(kong)(kong)終(zhong)(zhong)端主要由Cortex- M3 內(nei)核(he)(he)的(de)STM32ZGT6 的(de)核(he)(he)心模塊(kuai)(kuai)(kuai)、數(shu)據(ju)采集模塊(kuai)(kuai)(kuai)(CAN 網絡)、用(yong)戶計費交互信(xin)息(xi)模塊(kuai)(kuai)(kuai)、數(shu)據(ju)存儲模塊(kuai)(kuai)(kuai)、實時時鐘模塊(kuai)(kuai)(kuai)和GPRS通(tong)信(xin)模塊(kuai)(kuai)(kuai)6個部分所組(zu)成。終(zhong)(zhong)端采用(yong)Co-tex-M3內(nei)核(he)(he)的(de)STM32ZGT6微(wei)處理器(qi)芯片。該單片機具(ju)有豐富的(de)片上(shang)硬件資(zi)源(yuan),內(nei)含(han)CAN 2.0B的(de)控(kong)(kong)制器(qi),以及(ji)多達4 個串口,滿足終(zhong)(zhong)端CAN 與GPRS 網絡接口的(de)需求。
監控終(zhong)端(duan)(duan)的(de)工(gong)作流(liu)程如下:用(yong)戶計費模塊讀(du)取用(yong)戶信息以及選(xuan)擇充(chong)(chong)電(dian)模式,通(tong)過CAN 網(wang)(wang)絡向充(chong)(chong)電(dian)模塊發送相應充(chong)(chong)電(dian)命令(ling);同時監控終(zhong)端(duan)(duan)讀(du)取CAN 網(wang)(wang)絡中(zhong)的(de)關(guan)鍵(jian)數(shu)據幀(zhen)如充(chong)(chong)電(dian)機(ji)的(de)運行狀況等,并將數(shu)據保存于NandFlash中(zhong)。
定時將當(dang)前充電用(yong)戶信息和(he)充電機(ji)等(deng)運行參數(shu)通過(guo)GPRS 發送(song)到監控中心。監控終端可(ke)以根據用(yong)戶的需要(yao),打印用(yong)戶的余額或收費憑據等(deng)。
2.2 CAN總線模塊
為了(le)(le)更好地保證CAN 總(zong)線可靠(kao)的(de)傳輸(shu),系統定義了(le)(le)一套通用(yong)的(de)應用(yong)層的(de)CAN 總(zong)線協議。主要(yao)針對CAN 2.0B協議的(de)報文ID進行了(le)(le)分配及(ji)定義。
如表1 所示。
(1)優(you)先(xian)級(ji)(ji)確定。CAN協議(yi)規定報文ID越小,其報文的優(you)先(xian)級(ji)(ji)越高(gao)。在(zai)競(jing)爭總(zong)線時(shi),優(you)先(xian)級(ji)(ji)高(gao)的報文優(you)先(xian)發送,優(you)先(xian)級(ji)(ji)低(di)的退出總(zong)線競(jing)爭。CAN 總(zong)線競(jing)爭的算法(fa)效率很高(gao),是一種(zhong)非破壞性競(jing)爭[3]。因CAN協議(yi)規定標識符由高(gao)至低(di),前7位不能全為(wei)顯性位。所以優(you)先(xian)級(ji)(ji)1111b保留,故(gu)系統具有(you)15 級(ji)(ji)優(you)先(xian)級(ji)(ji)別。
(2)類型(xing)碼。協議將ID24~ID22 規定消息的類型(xing)。
在(zai)本系統中(zhong),用到(dao)的消息類(lei)型主要有:控制、狀(zhuang)態、測量、警告(gao)和廣播(bo)5 種類(lei)型。根(gen)據(ju)將類(lei)型碼的具體分配如(ru)表2所示(shi)。
(3)源(yuan)地址(zhi)(zhi)。協議(yi)規定ID12~ID16 為(wei)(wei)源(yuan)地址(zhi)(zhi),ID17~ID21為(wei)(wei)目標地址(zhi)(zhi),進(jin)而標識報文的各接收節(jie)(jie)點與發送節(jie)(jie)點。5位(wei)地址(zhi)(zhi)位(wei),保留(liu)11111b為(wei)(wei)廣播地址(zhi)(zhi),可以(yi)確定31個(ge)控(kong)制節(jie)(jie)點,可滿足電(dian)動汽車充電(dian)機的監控(kong)需求。在此系統中,定義00000b為(wei)(wei)監控(kong)終端,00001b為(wei)(wei)充電(dian)機節(jie)(jie)點,00010b為(wei)(wei)電(dian)池管理系統(BMS)節(jie)(jie)點。
(4)分段碼(ma)。因不同的(de)節(jie)點所發送的(de)數據量(liang)不同,可能會出現(xian)一個(ge)數據幀不能把(ba)從底層采(cai)集(ji)到的(de)數據一次性(xing)發送完(wan)畢(即超過8 個(ge)字節(jie)的(de)情況)。協議中將(jiang)ID11~ID4定義為分段碼(ma),如(ru)表3所示。
在表3 中,某(mou)節點(dian)的數據幀由分段碼00H 開始,由FFH結束,最大可支持發送256×8字節的數據。若該節點(dian)只有(you)一幀數據,定義(yi)FFH同時也為單幀數據。
例如(ru),BMS節(jie)點(dian),包含了(le)電(dian)(dian)池組總(zong)電(dian)(dian)壓、電(dian)(dian)池組總(zong)電(dian)(dian)流(liu)、電(dian)(dian)池組SoC、電(dian)(dian)池組各個箱體(9個)的溫度以(yi)及電(dian)(dian)池組狀(zhuang)態(tai)的信(xin)息等。每個數據占用2 B.顯然一個數據幀是(shi)無法發送該節(jie)點(dian)的全(quan)部信(xin)息,故須(xu)采用多幀方(fang)式發送。
2.3 數據發送模塊
終(zhong)端是(shi)通過串口外接周立功GPRS 模塊(ZWG-23A)連接到(dao)互聯網(wang)(wang)。通過GPRS網(wang)(wang)絡上網(wang)(wang),連接到(dao)服務器之后(hou),按照通信協(xie)議(yi)(yi)定時向(xiang)服務器發(fa)送數據。根據《深圳市電動汽車充電系統技術規范》標準文件,協(xie)議(yi)(yi)由(you)報文起始標識、版本號、命(ming)令(ling)字、報文長(chang)度、數據內容、校檢碼(ma)等組成(cheng)的,其具體格式(shi)如表4 所示。
(1)起(qi)始標識(shi)。設為0xFAF5,用于喚醒接(jie)收方準備接(jie)收數據。
(2)報文長(chang)度(du)。是由[發(fa)送序列號]到(dao)[數據內容]的總長(chang)度(du)。
(3)校驗碼。是從[起始標(biao)識]到[數據內容]的無進位累加和。
(4)接收(發送)方類(lei)(lei)型與地(di)(di)址。監控(kong)中心為(wei)類(lei)(lei)型為(wei)“業務(wu)(wu)服務(wu)(wu)平(ping)臺(tai)”,其(qi)數值為(wei)1,其(qi)地(di)(di)址為(wei)在此類(lei)(lei)型碼下(xia)的(de)某一(yi)個(ge)惟一(yi)地(di)(di)址;終(zhong)(zhong)端的(de)類(lei)(lei)型為(wei)“調(diao)度(du)終(zhong)(zhong)端”,其(qi)數值為(wei)255,地(di)(di)址為(wei)此類(lei)(lei)型下(xia)的(de)某一(yi)個(ge)惟一(yi)地(di)(di)址。
(5)數(shu)據內(nei)容(rong)與命令字(zi):不同的(de)(de)命令字(zi)決定(ding)該報文(wen)所攜帶的(de)(de)數(shu)據的(de)(de)內(nei)容(rong)的(de)(de)構成及所占用的(de)(de)字(zi)節數(shu)。
數據(ju)內容一(yi)般由一(yi)個(ge)或多(duo)個(ge)數據(ju)對象組(zu)合而成,也可以為空。發送方在應答非(fei)正常或無(wu)應答的(de)情況下(xia),每條數據(ju)報文(wen)最(zui)多(duo)重復發6次,每次間隔(ge)時(shi)間為30 s.數據(ju)內容根據(ju)命令字(zi)的(de)不(bu)同其所組(zu)成的(de)數據(ju)對象也不(bu)同,通常情況下(xia),終(zhong)端(duan)與(yu)監控中(zhong)心的(de)通信包括(kuo)終(zhong)端(duan)注冊、中(zhong)心應答、終(zhong)端(duan)就(jiu)緒、定時(shi)發送4個(ge)階(jie)段。部(bu)分命令字(zi)與(yu)對應的(de)數據(ju)內容見表5所示。
3 軟件設計
3.1 μC/OS-Ⅱ的多任務管理
移植μC/OS-Ⅱ實(shi)時(shi)(shi)操作系(xi)(xi)(xi)(xi)統(tong)(tong)為(wei)監(jian)(jian)控終端的(de)系(xi)(xi)(xi)(xi)統(tong)(tong)平臺(tai),該系(xi)(xi)(xi)(xi)統(tong)(tong)是可剝奪性多任務(wu)內(nei)核的(de)實(shi)時(shi)(shi)操作系(xi)(xi)(xi)(xi)統(tong)(tong),具(ju)有實(shi)時(shi)(shi)、可裁(cai)剪(jian)、可靠(kao)和穩定性等(deng)優(you)點(dian)。μC/OS-Ⅱ的(de)系(xi)(xi)(xi)(xi)統(tong)(tong)資源豐富,除去(qu)自身(shen)的(de)系(xi)(xi)(xi)(xi)統(tong)(tong)任務(wu)外,用戶可以(yi)建立多達56個(ge)任務(wu),并提供(gong)信號量(liang)、消(xiao)息(xi)郵箱、消(xiao)息(xi)隊(dui)列及內(nei)存管理等(deng)系(xi)(xi)(xi)(xi)統(tong)(tong)級服務(wu),足以(yi)滿足充電樁的(de)監(jian)(jian)控終端的(de)系(xi)(xi)(xi)(xi)統(tong)(tong)要求。
為實現監控終(zhong)端的(de)功能要(yao)求,在μC/OS-Ⅱ中設(she)計了以下(xia)13個任(ren)務(wu)(wu):顯示任(ren)務(wu)(wu)、鍵盤查詢任(ren)務(wu)(wu)、輸入處理任(ren)務(wu)(wu)、打印任(ren)務(wu)(wu)、數(shu)(shu)據(ju)的(de)存儲任(ren)務(wu)(wu)、IC 卡的(de)讀/寫任(ren)務(wu)(wu)、GPRS 的(de)發送任(ren)務(wu)(wu)、CAN 數(shu)(shu)據(ju)的(de)接收任(ren)務(wu)(wu)、CAN 數(shu)(shu)據(ju)的(de)發送任(ren)務(wu)(wu)、GPRS的(de)接收任(ren)務(wu)(wu)、命(ming)令(ling)控制任(ren)務(wu)(wu)、報警任(ren)務(wu)(wu)及看門(men)狗的(de)喂狗和異常檢測任(ren)務(wu)(wu)。
μC/OS-Ⅱ的(de)多任(ren)(ren)務(wu)(wu)(wu)的(de)特點,規定每個(ge)任(ren)(ren)務(wu)(wu)(wu)都必須具有不同的(de)優先級。根據任(ren)(ren)務(wu)(wu)(wu)的(de)關(guan)聯性(xing)、關(guan)鍵性(xing)、緊迫性(xing)、頻(pin)繁性(xing)、實時(shi)要求性(xing)來確定任(ren)(ren)務(wu)(wu)(wu)的(de)優先級,既要保證每個(ge)任(ren)(ren)務(wu)(wu)(wu)的(de)相對獨立性(xing),又(you)要避免任(ren)(ren)務(wu)(wu)(wu)調度頻(pin)繁致使系(xi)統的(de)效(xiao)率下降。任(ren)(ren)務(wu)(wu)(wu)的(de)優先級規劃如(ru)表6所示。
表1 中基本數據包括城市區(qu)號、停車場序號、充(chong)電樁位置信(xin)息、報(bao)文發(fa)送時(shi)間(jian)以及充(chong)電機(ji)、BMS和用戶IC卡的相關信(xin)息共計(ji)209 B.
表中各任(ren)務(wu)優先級之(zhi)間保留一定的(de)間隔(ge),方便(bian)系(xi)統以后的(de)改(gai)進和(he)升(sheng)級。系(xi)統設(she)定時鐘節拍為10 ms,滿足充電樁的(de)實時性要求。μC/OS-Ⅱ系(xi)統利(li)用信號量、消息郵箱(xiang)和(he)消息隊列三種通信方式將本系(xi)統中的(de)13個應用任(ren)務(wu)關聯在一起,其關系(xi)如圖(tu)3所示。
3.2 ZWG-23A模塊的配置
ZWG-23A 通過串口(kou)與終端(duan)鏈(lian)接(jie)(jie),它通過移動通信(xin)的GPRS 網(wang)絡鏈(lian)接(jie)(jie)互聯網(wang)。由于周立功公(gong)司并沒有提供基于μC/OS-Ⅱ的DTU 配置程序(xu)(xu),所以(yi)系統中需(xu)要自行開發相關的配置程序(xu)(xu),其配置DTU 的程序(xu)(xu)流程圖(tu)如圖(tu)4所示(shi)。
假設終(zhong)端(duan)每(mei)天與中心連接(jie)注冊一(yi)次,以每(mei)隔30 s的(de)(de)心跳時(shi)(shi)間定時(shi)(shi)向中心發送監(jian)控信息(xi),根據表6數據內容字節計算,一(yi)臺(tai)終(zhong)端(duan)一(yi)天發送報文所(suo)產生(sheng)(sheng)的(de)(de)GPRS流(liu)量大約為(wei) (228 × 2 × 60 × 24 + 294 × 2 + 100) (128 × 1 024) =5 MB,以每(mei)月30天計算,一(yi)年一(yi)臺(tai)終(zhong)端(duan)所(suo)產生(sheng)(sheng)的(de)(de)GPRS流(liu)量為(wei)1.7 GB.采用2 GB的(de)(de)包(bao)年流(liu)量套餐足以滿足終(zhong)端(duan)一(yi)年所(suo)產生(sheng)(sheng)的(de)(de)流(liu)量費。
4 結語
本文研(yan)究了(le)(le)電動汽車快速充電機監控網絡的(de)結構(gou)組(zu)成,詳(xiang)細(xi)分(fen)析了(le)(le)監控終(zhong)端的(de)通(tong)(tong)信(xin)(xin)網絡的(de)CAN與GPRS的(de)通(tong)(tong)信(xin)(xin)應用層(ceng)協議(yi)。其(qi)(qi)CAN 網絡協議(yi)具有廣泛的(de)通(tong)(tong)用性(xing),GPRS的(de)流量少,可推廣到(dao)自動化的(de)其(qi)(qi)他領域中的(de)應用。
- 上一篇:直流電焊機能不能改成充電機? 2019/5/16
- 下一篇:充電機的分類和使用注意事項 2019/5/14