充電樁狀態(tài)監(jiān)測(cè)與遠(yuǎn)程維護(hù)技術(shù)探析

國(guó)網(wǎng)電動(dòng)汽車服務(wù)（福建）有限公司 陳 涵 鄭蔚蔚 葉必超

1 充電樁狀態(tài)監(jiān)測(cè)與遠(yuǎn)程維護(hù)系統(tǒng)的總體設(shè)計(jì)

設(shè)計(jì)要求。主要是為滿足軟件的狀態(tài)監(jiān)測(cè)及遠(yuǎn)程維護(hù)，對(duì)充電樁管理系統(tǒng)的要求在于：可靠性。在滿足預(yù)定動(dòng)能前提下要確保自身穩(wěn)定高效運(yùn)轉(zhuǎn)，同時(shí)又可將充電樁源代碼帶來的影響降至最低，規(guī)避因管理系統(tǒng)產(chǎn)生軟件運(yùn)行故障；多能多樣化。針對(duì)充電樁軟件狀態(tài)監(jiān)測(cè)系統(tǒng)開發(fā)主要是為節(jié)約人力資源，所以要求數(shù)據(jù)能夠全面、功能能夠多樣，不僅可實(shí)現(xiàn)充電樁軟件運(yùn)行狀態(tài)監(jiān)測(cè)，同時(shí)又能實(shí)現(xiàn)對(duì)遠(yuǎn)程軟件的維護(hù)；通用性。這一類管理系統(tǒng)需滿足各種樁體的需求，并可預(yù)留可擴(kuò)展接口，基于不同的管理對(duì)象需求讓功能更加具有針對(duì)性[1]。

總體方案。針對(duì)充電樁軟件狀態(tài)監(jiān)測(cè)與遠(yuǎn)程維護(hù)系統(tǒng)，主要是為改善充電樁本身軟件故障頻繁出現(xiàn)的狀況，解決實(shí)際運(yùn)行效率較低問題（圖1）。

圖1 功能結(jié)構(gòu)圖

2 充電樁狀態(tài)監(jiān)測(cè)數(shù)據(jù)采集技術(shù)

為全面監(jiān)測(cè)軟件實(shí)際運(yùn)行狀態(tài)，本次研究中選擇嵌入式充電樁為基礎(chǔ)平臺(tái)，并考慮到軟硬件的架構(gòu)，這樣就可確保監(jiān)測(cè)對(duì)象滿足實(shí)際的要求。

在軟件的實(shí)際運(yùn)行過程及遠(yuǎn)程維護(hù)中監(jiān)測(cè)數(shù)據(jù)是基礎(chǔ)，所以對(duì)監(jiān)測(cè)對(duì)象的選擇應(yīng)盡可能覆蓋整個(gè)軟件的運(yùn)行過程[2]。如，可考慮到驅(qū)動(dòng)事件監(jiān)測(cè)中的電平事件。通過充電樁硬件架構(gòu)可知，針對(duì)部分外設(shè)、主要指繼電器組，通過簡(jiǎn)單的驅(qū)動(dòng)電路和單片機(jī)IO 引腳相連，就相當(dāng)于繼電器和IO 引腳能相互直接的影響，繼電器的通斷控制單片機(jī)引腳電平相對(duì)應(yīng)的高低，單片機(jī)引腳電平變化直接控制這繼電器的通斷，這時(shí)可直接利用引腳電平來實(shí)現(xiàn)主控板與外設(shè)間的交互。主控板直接與外設(shè)相互連接的單片機(jī)引腳設(shè)置成為中斷源，一旦在檢測(cè)中發(fā)現(xiàn)電平變化，就需直接執(zhí)行中斷處理函數(shù)，一般利用外設(shè)引起的電平事件可輕松實(shí)現(xiàn)對(duì)軟件運(yùn)行流程的改變。

在充電樁中有多個(gè)繼電器搭載，每一個(gè)繼電器對(duì)應(yīng)一個(gè)事件，如是否按下急停按鈕、是否已連接充電電纜、是否開啟充電進(jìn)程等。以電纜實(shí)際連接為例，相對(duì)應(yīng)的單片機(jī)物理管教是端口D 引腳10，在充電前用戶就需將充電槍直接插入到充電口中，這樣可攔截充電電纜，然后繼電器吸合，引腳PD.10電平就會(huì)逐漸從低到高，主程序也會(huì)直接進(jìn)入到電纜連接成功的子流程，執(zhí)行等待充電開啟的任務(wù)。在充電槍拔下后，斷開充電電纜、斷開繼電器，那么引腳的PD.10電平就會(huì)從高逐漸變低，主程序停止原本充電流程，執(zhí)行充電結(jié)束任務(wù)，如上傳交易記錄、消費(fèi)金額結(jié)算等。

圖2 嵌入式充電樁硬件結(jié)構(gòu)圖

圖3 嵌入式充電樁軟件結(jié)構(gòu)圖

3 充電樁遠(yuǎn)程維護(hù)實(shí)現(xiàn)方法

充電樁在狀態(tài)監(jiān)測(cè)實(shí)施后，為落實(shí)遠(yuǎn)程維護(hù)技術(shù)，要重點(diǎn)考慮到軟件故障預(yù)警功能的實(shí)現(xiàn)及遠(yuǎn)程查看功能的實(shí)現(xiàn)，這樣才有利于遠(yuǎn)程維護(hù)技術(shù)的有效使用。

3.1 軟件故障預(yù)警功能實(shí)現(xiàn)

3.1.1 軟件故障預(yù)警方法

針對(duì)軟件故障預(yù)警方法，考慮到本研究選擇的監(jiān)測(cè)對(duì)象是基于控制流與數(shù)據(jù)流，且需對(duì)軟件實(shí)際運(yùn)行狀態(tài)進(jìn)行重點(diǎn)關(guān)注。因包含了變量數(shù)值變化情況、函數(shù)調(diào)用關(guān)系等，所以在實(shí)際分析后要考慮到基于控制流模型和抽象解釋模型的方式來進(jìn)行處理[3]。

3.1.2 預(yù)警信息查詢過程

在程序中如軟件運(yùn)行出現(xiàn)故障，就可選擇利用預(yù)警代碼實(shí)現(xiàn)預(yù)警信息的自動(dòng)生成，開發(fā)人員按照信息復(fù)現(xiàn)故障產(chǎn)生過程，最終就可基于故障的原因?qū)崿F(xiàn)對(duì)代碼的維護(hù)及優(yōu)化處理。

預(yù)警信息主要是針對(duì)發(fā)生故障時(shí)軟件運(yùn)行狀態(tài)的描述，如故障類型、發(fā)生時(shí)間、日志等。預(yù)先規(guī)定故障代碼，實(shí)現(xiàn)故障類型的區(qū)分。如，0x01代表因電能統(tǒng)計(jì)出現(xiàn)錯(cuò)誤從而導(dǎo)致的金額問題；0x02代表因無法跳轉(zhuǎn)導(dǎo)致的金額問題。基于軟件中對(duì)時(shí)間信息的存儲(chǔ)方式判別，主要是對(duì)故障發(fā)生的時(shí)間基數(shù)及二次相對(duì)量的記錄，由于二次技術(shù)已在日志中存儲(chǔ)就不需再次記錄，直接將三個(gè)數(shù)據(jù)相加就可獲取故障產(chǎn)生的具體時(shí)間。對(duì)于故障日志，也就是故障發(fā)生時(shí)的日志內(nèi)容，在本次預(yù)警軟件中軟件故障不會(huì)卡死程序，所以可不斷更新日志。如沒有及時(shí)進(jìn)行保存，新產(chǎn)生的日志就會(huì)覆蓋過往日志，導(dǎo)致故障發(fā)生前無法獲取程序運(yùn)轉(zhuǎn)流程，最終影響故障處理。

在本次研究中，直接在外部存儲(chǔ)器EEPROM 開辟固定的空間，然后按照發(fā)生時(shí)間、故障類型、故障順序，基于字節(jié)作為單位來進(jìn)行存儲(chǔ)。在發(fā)生故障后程序就會(huì)立即在指定程序?qū)懭腩A(yù)警信息，并針對(duì)與服務(wù)器端上位機(jī)是否建立連接來進(jìn)行檢測(cè)。只要判斷連接建立就可主動(dòng)上報(bào)預(yù)警信息，開發(fā)人員就會(huì)了解充電樁軟件的異常運(yùn)行問題。當(dāng)然作為開發(fā)人員也可針對(duì)存儲(chǔ)器指定區(qū)域進(jìn)行自主查看，以此來判斷是否有故障的出現(xiàn)，對(duì)于軟件的運(yùn)行狀態(tài)加以把控。

3.2 遠(yuǎn)程查看功能實(shí)現(xiàn)

程序日志主要對(duì)軟件實(shí)際運(yùn)行過程描述，如果實(shí)際問題針對(duì)性不強(qiáng)就需考慮到遠(yuǎn)程維護(hù)，所以將日志作為基礎(chǔ)，然后結(jié)合具體的需求可獲取額外的信息。如果可利用上位機(jī)模塊從本地充電樁采集對(duì)應(yīng)的制定數(shù)據(jù)，就能實(shí)現(xiàn)維護(hù)靈活性的提升，對(duì)應(yīng)增加遠(yuǎn)程查看功能。

3.2.1 變量數(shù)值查看

在日志中變量數(shù)值的查看可看成為一種事件，主要是了解驅(qū)動(dòng)程序的運(yùn)行或執(zhí)行流程如何改變，變量查看主要是基于實(shí)際情況，從而實(shí)現(xiàn)某些日志沒有體現(xiàn)的信息查看，關(guān)注的是變量本身的數(shù)值變化情況。雖然兩者的使用目的不一樣，但都是描述變量，實(shí)際監(jiān)測(cè)的內(nèi)容相同，都囊括了內(nèi)存空間、地址、數(shù)值等內(nèi)容[4]。

通過變量查看功能就可滿足程序任意變量數(shù)值的獲取，也不需考慮存儲(chǔ)區(qū)域，如全局與靜態(tài)變量都是在靜態(tài)區(qū)域中存在；同樣也不需考慮變量的意義，如代表實(shí)際充電的電壓、電流等，基于標(biāo)志位形式來表示充電口的實(shí)際狀態(tài)、啟動(dòng)方式、充電模式等，表示程序執(zhí)行情況的定時(shí)器技術(shù)、循環(huán)次數(shù)等。只要能夠獲取變量地址就可實(shí)現(xiàn)變量數(shù)值的獲取。

對(duì)于服務(wù)器端的上位機(jī)和本地充電樁間基于變量查看的通信協(xié)議見表1。其中0xA5代表上位機(jī)模塊下發(fā)查看變量指令，開/停位為1代表的是開啟這一變量查看，為2則代表的暫停查看，為3代表停止查看。在樁接收后就分別執(zhí)行對(duì)應(yīng)的代碼段。0x25代表充電樁上傳具體變量數(shù)值，不同的變量數(shù)據(jù)長(zhǎng)度要求結(jié)合實(shí)際情況來做好數(shù)據(jù)幀個(gè)數(shù)的計(jì)算。

表1 變量查看功能的通信協(xié)議

3.2.2 CPU 占用率查詢

針對(duì)嵌入式系統(tǒng)中系統(tǒng)是否能夠長(zhǎng)時(shí)間穩(wěn)定運(yùn)行，需通過CPU 占用率來進(jìn)行評(píng)價(jià)，體現(xiàn)的是空間與繁忙程度。在相同時(shí)刻只有一個(gè)任務(wù)會(huì)占據(jù)CPU，但嵌入式系統(tǒng)可滿足多任務(wù)切換及搶占式任務(wù)的調(diào)度，這樣就可滿足不同時(shí)刻CPU 任務(wù)分配的實(shí)現(xiàn)。一般CPU 處于任務(wù)占用或是空閑狀態(tài)，占用率就是執(zhí)行任務(wù)的時(shí)長(zhǎng)與總執(zhí)行時(shí)長(zhǎng)的比值。因本次研究的硬件平臺(tái)會(huì)有涉及到操作系統(tǒng)，所以CPU任務(wù)占用狀態(tài)就是軟件處于充電流程中，CPU 空閑狀態(tài)就是軟件處于空循環(huán)之中。因?yàn)榭昭h(huán)執(zhí)行時(shí)間獲取更加容易，占用率的計(jì)算公式就可以調(diào)整為：CPU 占用率=（CPU 總執(zhí)行時(shí)長(zhǎng)-CPU 空閑時(shí)長(zhǎng)）/CPU 總執(zhí)行時(shí)長(zhǎng)。

在本文的研究分析中，基于小時(shí)數(shù)來進(jìn)行統(tǒng)計(jì)，當(dāng)充電樁接受到對(duì)CPU 占用率查詢指令后，就會(huì)將當(dāng)前重時(shí)長(zhǎng)不到1h 的時(shí)間段內(nèi)及之后完整4h 的占用率直接上傳，這樣就會(huì)讓上位機(jī)直接呈現(xiàn)出一段時(shí)間之中CPU 具體的任務(wù)執(zhí)行情況。表2為服務(wù)器端上位機(jī)與本地充電樁間的CPU 占用率查詢的通信協(xié)議，其中0xA6代表上位機(jī)下發(fā)的CPU 占用率指令的查詢情況，0x26代表的是上傳這一段時(shí)間內(nèi)實(shí)際的CPU 使用數(shù)值。

表2 CPU 占用率查詢功能的通信協(xié)議

本章節(jié)主要是針對(duì)軟件故障預(yù)警以及遠(yuǎn)程查看的維護(hù)方式進(jìn)行分析。其中軟件故障預(yù)警主要是基于控制流以及抽象高潔絲模型來進(jìn)行設(shè)計(jì)的，這樣的方式就可通過預(yù)警信息復(fù)現(xiàn)故障原因定位與故障過程；遠(yuǎn)程查看則是基于變量查詢與CPU 占用率查詢，實(shí)現(xiàn)日志查詢功能的輔助，最終滿足軟件運(yùn)行的全面監(jiān)測(cè)需求[5]。