張征峰，鄭 梁，崔佳冬

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

0 引言

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

電氣火災(zāi)監(jiān)控系統(tǒng)能夠?qū)﹄姎饩€路異常及時(shí)預(yù)警，可以有效避免電氣火災(zāi)的發(fā)生。目前大部分電氣火災(zāi)監(jiān)控系統(tǒng)采用有線組網(wǎng)的方式，如RS232、RS485、CAN等總線組網(wǎng)和局域集中上位機(jī)管理的方式[2]，系統(tǒng)部署示意圖如圖1，需要在每個(gè)相對(duì)隔離的配電區(qū)域安裝有線組網(wǎng)的電氣火災(zāi)監(jiān)控系統(tǒng)，造成布線難度大的同時(shí)，每個(gè)區(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)以解決上述問(wèn)題。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 監(jiān)控平臺(tái)

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

圖6 監(jiān)控平臺(tái)架構(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ù)載均衡（圖中未畫(huà)出）、服務(wù)容錯(cuò)保護(hù)等，構(gòu)成微服務(wù)架構(gòu)應(yīng)用模塊開(kāi)發(fā)實(shí)現(xiàn)的基礎(chǔ)。各模塊使用Spring Boot框架實(shí)現(xiàn)。

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

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

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

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

3.3 客戶端

（1）瀏覽器客戶端

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

（2）移動(dòng)端 APP

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

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

4 測(cè)試與界面展示

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

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

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

圖7 漏電流采樣精度測(cè)試圖

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

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

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

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

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

4.2 管理員界面

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

圖8 管理員主頁(yè)界面

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

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

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

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

4.3 移動(dòng)端APP界面

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

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

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

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

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

5 結(jié)語(yǔ)

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