基于物聯(lián)網(wǎng)的電氣火災(zāi)監(jiān)控系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

張征峰，鄭 梁，崔佳冬

（杭州電子科技大學(xué)CAE研究所，浙江 杭州 310018）

0 引言

據(jù)統(tǒng)計(jì)，2011～2016年，我國共發(fā)生電氣火災(zāi)52.4萬起，對人民的生命財(cái)產(chǎn)安全造成了巨大威脅和損失，政府對此高度重視，并開展了為期三年的電氣火災(zāi)綜合治理工作，從2017年5月開始至2020年4月結(jié)束[1]。

電氣火災(zāi)監(jiān)控系統(tǒng)能夠?qū)﹄姎饩€路異常及時預(yù)警，可以有效避免電氣火災(zāi)的發(fā)生。目前大部分電氣火災(zāi)監(jiān)控系統(tǒng)采用有線組網(wǎng)的方式，如RS232、RS485、CAN等總線組網(wǎng)和局域集中上位機(jī)管理的方式[2]，系統(tǒng)部署示意圖如圖1，需要在每個相對隔離的配電區(qū)域安裝有線組網(wǎng)的電氣火災(zāi)監(jiān)控系統(tǒng)，造成布線難度大的同時，每個區(qū)域都需要專人看管，進(jìn)而造成了人力資源的浪費(fèi)[3]；在歷史數(shù)據(jù)展示上通常也難以實(shí)現(xiàn)圖形化顯示，用戶不能快速直觀地了解監(jiān)控系統(tǒng)的歷史數(shù)據(jù)信息。

圖1 傳統(tǒng)電氣火災(zāi)監(jiān)控系統(tǒng)部署示意圖

為此，本文設(shè)計(jì)實(shí)現(xiàn)了基于物聯(lián)網(wǎng)技術(shù)的電氣火災(zāi)監(jiān)控系統(tǒng)以解決上述問題。

1 系統(tǒng)總體架構(gòu)

本系統(tǒng)按物聯(lián)網(wǎng)體系架構(gòu)分為感知、網(wǎng)絡(luò)、應(yīng)用三層，由多傳感器組合獨(dú)立式電氣火災(zāi)探測器、監(jiān)控平臺、Web客戶端和移動端APP組成，總體框架如圖2所示。

圖2 系統(tǒng)框架圖

探測器除完成傳統(tǒng)電氣火災(zāi)探測器功能外，還將相關(guān)設(shè)備狀態(tài)信息通過GPRS，按照設(shè)定的傳輸協(xié)議（MQTT/CoAP/HTTP）定時上報(bào)到監(jiān)控平臺，Web客戶端和移動端APP通過HTTP協(xié)議向監(jiān)控平臺請求獲取相關(guān)服務(wù)。當(dāng)探測器報(bào)警時，平臺收到探測器報(bào)警消息后，通過短信等方式通知用戶。

2 電氣火災(zāi)探測器

2.1 硬件結(jié)構(gòu)

多傳感器組合獨(dú)立式電氣火災(zāi)探測器的硬件結(jié)構(gòu)如圖3所示，由A9G GPRS模組、RN8209D漏電流采集、DS18B20溫度采集、報(bào)警輸出、聲光報(bào)警、顯示、SD存儲、按鍵等電路模塊組成。

圖3 電氣火災(zāi)探測器硬件結(jié)構(gòu)圖

A9G GRPS模組在探測器中充當(dāng)微處理器和通信模組的雙重角色，采用SDK二次開發(fā)的方式，不需要外接控制器，最大限度降低了硬件成本。經(jīng)過開發(fā)，其支持MQTT、CoAP、HTTP三種物聯(lián)網(wǎng)通訊協(xié)議，提供給用戶靈活選擇。

A9G模組通過UART接口獲取RN8209D采集到的漏電流信號、DS18B20中采集的溫度信息后，與用戶設(shè)定的漏電流和溫度報(bào)警閾值進(jìn)行比較，若超出相應(yīng)閾值，A9G模組驅(qū)動電路發(fā)出聲光報(bào)警信號，并輸出控制信號給消防聯(lián)動，如切斷斷路器，使線路斷路。A9G模組會定時向監(jiān)控平臺上報(bào)探測器的相關(guān)信息。

2.2 程序設(shè)計(jì)

探測器程序主要包括探測器核心任務(wù)、通信存儲、按鍵設(shè)置、OLED顯示、運(yùn)行指示五個主要任務(wù)（進(jìn)程）。其中優(yōu)先級最高的是探測器核心任務(wù)，即檢測漏電流、溫度是否超過閾值，給出聲光報(bào)警信號和斷路器動作信號。

在沒有發(fā)生異常時，定時向服務(wù)器上報(bào)，在發(fā)生異常時，探測器以3s/次的頻率持續(xù)上報(bào)60次，確保服務(wù)器能夠準(zhǔn)確記錄異常發(fā)生時的情況。

A9G模組提供了 MQTT協(xié)議相關(guān)的API，CoAP協(xié)議在其提供Socket網(wǎng)絡(luò)接口之上參考github上的iotkit-embedded中的CoAP客戶端實(shí)現(xiàn)，HTTP協(xié)議在請求行中指定版本為HTTP 1.1，請求頭部的Connection指定為keep-alive，與監(jiān)控平臺保持長連接。

探測器核心任務(wù)流程如圖4所示。啟動定時器時需要指定回調(diào)函數(shù)，在定時時間到達(dá)時調(diào)用該函數(shù)，在回調(diào)函數(shù)中完成漏電流和溫度的采集，并分別與設(shè)置的閾值進(jìn)行比較，若超出閾值則報(bào)警，并在更新數(shù)據(jù)后使用OS_SendEvent接口向主任務(wù)發(fā)送緊急優(yōu)先級的報(bào)警事件，最后更新定時器，進(jìn)入下一次循環(huán)。通信存儲任務(wù)在完成定時通信和存儲后，在循環(huán)中阻塞等待事件，收到報(bào)警事件后，立刻向平臺上報(bào)數(shù)據(jù)。

由于互感器的非線性及其他干擾信號影響，導(dǎo)致漏電流的測量值和實(shí)際值之間可能存在較大誤差，在程序中先采用限幅平均濾波法去除可能的干擾值，然后通過Matlab進(jìn)行數(shù)據(jù)擬合，以校準(zhǔn)精度，擬合曲線如圖5所示。

圖5 漏電流校準(zhǔn)擬合曲線圖

3 監(jiān)控平臺

監(jiān)控平臺基于微服務(wù)架構(gòu)設(shè)計(jì)實(shí)現(xiàn)。系統(tǒng)應(yīng)采用分布式架構(gòu)，要求各種服務(wù)之間耦合度低以便于維護(hù)，同時必須具備改造升級的可能性，而微服務(wù)架構(gòu)可以很好地滿足這些要求[4]。監(jiān)控平臺總體架構(gòu)如圖6所示，主要由服務(wù)端、客戶端以及數(shù)據(jù)庫三部分組成。

圖6 監(jiān)控平臺架構(gòu)

3.1 服務(wù)端

服務(wù)端由微服務(wù)架構(gòu)組件和微服務(wù)應(yīng)用模塊組成。微服務(wù)架構(gòu)組件由Spring Cloud提供，主要有API網(wǎng)關(guān)、服務(wù)發(fā)現(xiàn)以及負(fù)載均衡（圖中未畫出）、服務(wù)容錯保護(hù)等，構(gòu)成微服務(wù)架構(gòu)應(yīng)用模塊開發(fā)實(shí)現(xiàn)的基礎(chǔ)。各模塊使用Spring Boot框架實(shí)現(xiàn)。

MQTT、CoAP以及HTTP服務(wù)實(shí)現(xiàn)與探測器的通信功能。若探測器使用HTTP協(xié)議則需要先經(jīng)過API網(wǎng)關(guān)，再由HTTP服務(wù)模塊進(jìn)行處理。設(shè)備服務(wù)提供探測器最新上報(bào)數(shù)據(jù)、歷史數(shù)據(jù)信息查詢等服務(wù)；信息通知服務(wù)主要負(fù)責(zé)異步給用戶發(fā)送報(bào)警信息通知等服務(wù)；用戶服務(wù)提供用戶登錄和探測器管理服務(wù)。

3.2 數(shù)據(jù)庫

本監(jiān)控平臺使用了關(guān)系型數(shù)據(jù)庫MySQL和非關(guān)系型數(shù)據(jù)庫Redis分別進(jìn)行數(shù)據(jù)的存儲和緩存。

使用單一的關(guān)系型數(shù)據(jù)庫，受限于硬盤讀寫速度和數(shù)據(jù)庫本身的性能，易造成效率低下，難以滿足高并發(fā)訪問的需求。例如當(dāng)用戶查看設(shè)備的最新信息時，如果每次都直接從MySQL數(shù)據(jù)庫中獲取，MySQL的搜索引擎需要先根據(jù)設(shè)備ID從硬盤讀取該設(shè)備所有的數(shù)據(jù)信息，然后根據(jù)時間字段降序或者升序排序，取出第一條或者最后一條才能得到最終需要的數(shù)據(jù)。這種方式在用戶訪問量大及設(shè)備多的情況下，將對數(shù)據(jù)庫造成巨大壓力，同時服務(wù)器的響應(yīng)時間延長也會影響用戶體驗(yàn)。相似的問題也會出現(xiàn)在用戶查詢設(shè)備的歷史數(shù)據(jù)時。為此，平臺使用非關(guān)系型數(shù)據(jù)庫Redis作為補(bǔ)充，以減輕關(guān)系型數(shù)據(jù)庫的壓力，提高平臺的處理速度和并發(fā)能力。此外，在分布式系統(tǒng)中的用戶單點(diǎn)登錄、本平臺中存儲隨機(jī)密碼的短時間定時存儲業(yè)務(wù)中，非關(guān)系型數(shù)據(jù)庫也具有更好的適應(yīng)性。

3.3 客戶端

（1）瀏覽器客戶端

前端頁面部分，使用AJAX技術(shù)[5]，通過在后臺與服務(wù)端進(jìn)行少量數(shù)據(jù)交換，在不重新加載整個網(wǎng)頁的情況下，實(shí)時更新設(shè)備上報(bào)信息。數(shù)據(jù)可視化使用Datatables表格插件和Hightcharts圖表庫。

（2）移動端 APP

為實(shí)現(xiàn)用戶隨時隨地查詢電氣火災(zāi)監(jiān)控探測器的相關(guān)信息狀態(tài)的需求，開發(fā)了基于Android的移動端APP。

采用經(jīng)典的MVC開發(fā)架構(gòu)，分為業(yè)務(wù)層、視圖層和操作層。業(yè)務(wù)層處理各類應(yīng)用業(yè)務(wù)，完成網(wǎng)絡(luò)請求、數(shù)據(jù)分析、數(shù)據(jù)處理功能；視圖層分為可視視圖和隱藏視圖，主要完成手機(jī)端與用戶的交互和應(yīng)用界面的更新替換；操作層用來分離業(yè)務(wù)層和視圖層的聯(lián)系，降低程序的耦合，使應(yīng)用更加健壯，同時為后期維護(hù)做準(zhǔn)備具體，具體實(shí)現(xiàn)功能與瀏覽器端類似。

4 測試與界面展示

4.1 電氣火災(zāi)探測器測試

根據(jù)消防規(guī)范GB14287-2014《電氣火災(zāi)監(jiān)控系統(tǒng)》第2部分剩余電流式電氣火災(zāi)監(jiān)控探測器和第3部分測溫式電氣火災(zāi)監(jiān)控探測器中對獨(dú)立式探測器的要求，本探測器的剩余電流測量范圍應(yīng)在20mA～1000mA之間，能在30s內(nèi)對超出報(bào)警設(shè)定剩余電流值的情況進(jìn)行報(bào)警；溫度測量值最低為45℃，應(yīng)在40s內(nèi)對超出溫度報(bào)警設(shè)定值的情況發(fā)出報(bào)警；在報(bào)警設(shè)定范圍內(nèi)，剩余電流和溫度側(cè)報(bào)警值與設(shè)定值之間的誤差以及顯示誤差均不能超過5%。

漏電流采樣精度測試如圖7所示。單相可調(diào)變壓器一次側(cè)接入市電，二次側(cè)其中一個端子輸出串聯(lián)一個功率電阻（20Ω 200W）后，經(jīng)電流表，穿過漏電流互感器后，接入二次側(cè)另一端子。通過調(diào)節(jié)變壓器，改變電路中的電流值，以電流表測量值為參照，讀取探測器OLED顯示的漏電流數(shù)據(jù)，測試了多組數(shù)據(jù)，如表1所示。

圖7 漏電流采樣精度測試圖

表1 漏電流測試數(shù)據(jù)表

從表1可以看出，探測器顯示數(shù)據(jù)最大誤差為1.6%，遠(yuǎn)小于規(guī)范要求的最大5%的誤差。

溫度采樣使用DS18B20數(shù)字溫度傳感器，測量精度為 ±0.5℃，報(bào)警值設(shè)為≥45℃，實(shí)測最大誤差為1.1%，滿足精度要求。

探測器核心任務(wù)每200ms執(zhí)行一次采樣和判斷報(bào)警，OLED顯示任務(wù)每休眠500ms刷新一次顯示數(shù)據(jù)，在上表測試過程中，通過觀察A9G模組的下載調(diào)試工具CoolWatcher Develop中的打印信息發(fā)現(xiàn)，報(bào)警值與OLED上顯示數(shù)據(jù)值差距非常小，據(jù)此可認(rèn)為報(bào)警值與設(shè)定值之間誤差亦滿足設(shè)計(jì)要求，獨(dú)立式探測器自成系統(tǒng)，無論是檢測漏電流還是溫度報(bào)警，本探測器均可在1s內(nèi)發(fā)出聲光報(bào)警，遠(yuǎn)低于要求的30s。

探測器在關(guān)鍵指標(biāo)上滿足規(guī)范要求，限于條件，其他有關(guān)測試未完成。

4.2 管理員界面

管理員主界面，提供了管理員對普通用戶及對探測器權(quán)限分級管理頁面，如圖8所示。

圖8 管理員主頁界面

通過管理員界面可以查看電氣火災(zāi)探測器2天的歷史數(shù)據(jù)和詳細(xì)的設(shè)備信息，如圖9所示。

圖9 電氣火災(zāi)探測器數(shù)據(jù)可視化圖

點(diǎn)擊頁面中的“查看位置”按鈕，可以顯示電氣火災(zāi)探測器所在位置的地圖信息，當(dāng)探測器出現(xiàn)異常時，用戶可根據(jù)該地圖快速找到探測器，進(jìn)行異常處理，如圖10所示。

圖10 電氣火災(zāi)探測器位置地圖

4.3 移動端APP界面

APP部分頁面如圖11所示。圖11a）為APP管理員主界面，顯示了所有用戶、在線設(shè)備數(shù)量以及報(bào)警數(shù)量信息；圖11b）為加載了探測器最新數(shù)據(jù)信息及歷史數(shù)據(jù)的圖形化顯示界面。

圖11 APP部分頁面a）主界面 b）數(shù)據(jù)顯示界面

4.4 報(bào)警信息通知

圖12 為監(jiān)控平臺收到探測器報(bào)警信息后發(fā)送給用戶的短信、郵件通知圖。

圖12 報(bào)警信息通知

5 結(jié)語

本文利用物聯(lián)網(wǎng)技術(shù)，設(shè)計(jì)實(shí)現(xiàn)了部署容易、使用方便和網(wǎng)絡(luò)化的電氣火災(zāi)監(jiān)控系統(tǒng)。在探測器上增加了GPRS遠(yuǎn)程通信功能，解決傳統(tǒng)有線組網(wǎng)電氣火災(zāi)監(jiān)控系統(tǒng)部署難的問題；同時，在設(shè)計(jì)實(shí)現(xiàn)中最大限度降低了探測器的硬件成本；支持三種主流的物聯(lián)網(wǎng)通信協(xié)議，提供給用戶靈活的選擇。采用微服務(wù)架構(gòu)使監(jiān)控平臺在系統(tǒng)擴(kuò)容、升級、維護(hù)等方面具備天然優(yōu)勢；平臺通過瀏覽器和Android客戶端向用戶提供服務(wù)；并增強(qiáng)數(shù)據(jù)的可視化水平。當(dāng)設(shè)備報(bào)警時，能夠通過短信、郵件通知用戶及時處理，使監(jiān)控報(bào)警更加智能、人性化。經(jīng)測試，該系統(tǒng)對漏電流和溫度的檢測精度較高，報(bào)警響應(yīng)敏捷，具有較好的推廣價(jià)值。