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