基于ZigBee的火災(zāi)監(jiān)控平臺的設(shè)計

劉志龍　杜寧

摘要： 本文針對傳統(tǒng)火災(zāi)監(jiān)控系統(tǒng)所存在的誤報警率較高、布線復(fù)雜以及維護(hù)困難等弊端，參考先進(jìn)的物聯(lián)網(wǎng)解決方案，設(shè)計并實(shí)現(xiàn)了基于ZigBee的火災(zāi)監(jiān)控平臺。監(jiān)控平臺主要包括基于JavaEE的分布式軟件架構(gòu)和基于ZigBee的無線硬件網(wǎng)絡(luò)搭建兩個核心部分，采用了私有云、MVC架構(gòu)、XBee封裝模塊等主流軟硬件技術(shù)，充分滿足了用戶對火災(zāi)監(jiān)控的網(wǎng)絡(luò)化、自動化、智能化要求。

關(guān)鍵詞：ZigBee；XBee； 火災(zāi)監(jiān)控

1 緒論

火災(zāi)自動探測報警系統(tǒng)作為早期探測火災(zāi)、將火災(zāi)遏制在萌芽狀態(tài)的重要設(shè)備，是實(shí)現(xiàn)防消結(jié)合，預(yù)防為主的消防策略的重要手段。目前主要的火災(zāi)自動報警系統(tǒng)大多采用有線方式，存在系統(tǒng)耗材多、造價高、布線繁瑣、線路容易老化、故障發(fā)生率和誤報率高等諸多問題[1]。

針對以上提出的問題，本文提出了無線監(jiān)控的解決方案，在深入的分析了用戶在火災(zāi)安全中的實(shí)際需求后，設(shè)計并實(shí)現(xiàn)了一套基于ZigBee的物聯(lián)網(wǎng)監(jiān)控網(wǎng)絡(luò)平臺[2]，彌補(bǔ)了現(xiàn)有的有線監(jiān)控方式所存在的不足，實(shí)現(xiàn)了火災(zāi)安全的管理網(wǎng)絡(luò)化。快速為用戶提供詳細(xì)準(zhǔn)確的火災(zāi)安全監(jiān)控數(shù)據(jù)，適應(yīng)不同規(guī)模環(huán)境的火災(zāi)監(jiān)控需求。

2火災(zāi)報警平臺的解決方案

本監(jiān)控平臺由數(shù)據(jù)采集終端、API中間件、數(shù)據(jù)展示終端三部分組成，采用分布式設(shè)計，平臺核心是基于私有云的API中間件，采用JavaEE技術(shù)進(jìn)行人機(jī)交互界面的研發(fā)。采用MySQL數(shù)據(jù)庫進(jìn)行實(shí)時數(shù)據(jù)的持久化，Redis數(shù)據(jù)庫用于管理緩存數(shù)據(jù)。在軟件架構(gòu)方面，采用Nginx反向代理服務(wù)器進(jìn)行負(fù)載均衡[3]。應(yīng)用服務(wù)器使用Tomcat集群，軟件代碼部分采用了企業(yè)開發(fā)中常用的Spring MVC作為MVC層，采用MyBatis作為ORM層，保證軟件平臺的代碼質(zhì)量和應(yīng)用級別的安全性。底層使用工業(yè)級的Xbee節(jié)點(diǎn)用于傳感器數(shù)據(jù)的傳輸，保證數(shù)據(jù)傳輸安全以及準(zhǔn)確性[3]。該網(wǎng)絡(luò)平臺經(jīng)過配置之后可以對不同類型的火災(zāi)監(jiān)控相關(guān)數(shù)據(jù)進(jìn)行記錄，傳輸，展示，分析等相關(guān)操作，同時該平臺采用分布式設(shè)計，保證了平臺的橫向和縱向擴(kuò)展的可行性。在記錄環(huán)境安全數(shù)據(jù)的同時，對數(shù)據(jù)進(jìn)行分析和折線圖展示，以及安全威脅的預(yù)警與報警，并設(shè)計和實(shí)現(xiàn)了前端展示平臺，可以對不同的屏幕大小進(jìn)行自動適應(yīng)，方便適用于不同類型的使用環(huán)境。

2.1 平臺總體結(jié)構(gòu)設(shè)計

本平臺的結(jié)構(gòu)主要分為三部分：API中間件部分、數(shù)據(jù)節(jié)點(diǎn)、數(shù)據(jù)展示終端，整體的網(wǎng)絡(luò)拓?fù)浼軜?gòu)如圖1所示。

API服務(wù)器部分包括：用戶注冊，用戶登錄和回話鑒別等部分。其中，用戶可以使用個人信息進(jìn)行注冊，用登錄系統(tǒng)中，用戶正常使用的情況下不需要注意其他問題，用戶的數(shù)據(jù)安全和用戶賬戶的安全由服務(wù)器端進(jìn)行確認(rèn)和保障。

底層數(shù)據(jù)節(jié)點(diǎn)包括：一到多個數(shù)據(jù)節(jié)點(diǎn)的數(shù)據(jù)緩存和數(shù)據(jù)的簡單處理，對數(shù)據(jù)進(jìn)行處理包括驗(yàn)證數(shù)據(jù)是否達(dá)到了警報值，選擇對用戶告警并傳出警報信息到API服務(wù)器，該模塊還包括把普通的數(shù)據(jù)傳送到API服務(wù)器。

終端展示部分包括：用戶的登錄，注冊，瀏覽的頁面，以及作為用戶和API服務(wù)器的橋梁，封裝用戶的請求和API服務(wù)器的反饋，并解析為元數(shù)據(jù)展示給用戶，以及簡單的鑒別用戶的輸入，防止一些不正確和非法的請求直接請求到API服務(wù)器。

2.2 API中間件架構(gòu)

API中間件是底層硬件部分和數(shù)據(jù)展示終端之間的橋梁，這部分接受來自于底層硬件部分的數(shù)據(jù)，對數(shù)據(jù)進(jìn)行操作，持久化到數(shù)據(jù)庫中，通過數(shù)據(jù)展示終端的請求，提取用戶需要的數(shù)據(jù)，對數(shù)據(jù)進(jìn)行封裝之后發(fā)送到數(shù)據(jù)展示前端。通過這部分的中轉(zhuǎn)，實(shí)現(xiàn)整個系統(tǒng)的聯(lián)動，也是通過API中間件，實(shí)現(xiàn)了底層與前端展現(xiàn)的分離，保證了平臺的健壯和可伸縮性，防止出現(xiàn)數(shù)據(jù)流失和數(shù)據(jù)泄密，這部分采用了三層架構(gòu)的設(shè)計模式。從對接HTTP請求，到業(yè)務(wù)層分流，到DAO層的數(shù)據(jù)庫操作，再次采用分層解耦的方式保證了API中間件本身的健壯性和彈性，維持了“高內(nèi)聚，低耦合”的軟件工程設(shè)計思想，這部分是整個火災(zāi)監(jiān)控平臺的“心臟”，各個部分的依靠弱關(guān)系進(jìn)行連接，每一個部分的宕機(jī)都不會導(dǎo)致整個系統(tǒng)的崩潰，API中間件起到了很大作用，API中單件的架構(gòu)如圖2所示。

2.3 硬件設(shè)計

數(shù)據(jù)處理節(jié)點(diǎn)是一個中轉(zhuǎn)站，用于對接多個數(shù)據(jù)采集節(jié)點(diǎn)，收集數(shù)據(jù)采集節(jié)點(diǎn)的數(shù)據(jù)，對數(shù)據(jù)進(jìn)行簡單的處理，并把數(shù)據(jù)發(fā)送到API服務(wù)器。這是數(shù)據(jù)處理節(jié)點(diǎn)的功能。數(shù)據(jù)處理節(jié)點(diǎn)是一個較之?dāng)?shù)據(jù)采集節(jié)點(diǎn)更高一級的處理單位，這個部分是保證上下層聯(lián)通的物理保障。

數(shù)據(jù)處理節(jié)點(diǎn)可以安裝一個SD卡模塊，通過在SD卡中存儲配置文件來保證可以動態(tài)修改一些配置文件，類似于API中間件的IP地址。在初始化節(jié)點(diǎn)的同時讀取配置文件，保證用戶可以簡單的編輯配置文件完成一些節(jié)點(diǎn)的復(fù)雜配置，減少用戶的學(xué)習(xí)成本。數(shù)據(jù)采集節(jié)點(diǎn)由四個部分組成：

1. SD模塊：

這部分用于讀取配置文件，做到配置和程序代碼的低耦合性，保證配置文件可以單獨(dú)進(jìn)行處理，方便用戶隨時升級配置。

2. HTTP模塊：

這部分負(fù)責(zé)把已經(jīng)包裝好的數(shù)據(jù)通過HTTP請求發(fā)送到API服務(wù)器模塊，以及讀取來自于服務(wù)器的反饋，確認(rèn)通信的成功與否。把這部分單獨(dú)抽取出來，可以保證減少重復(fù)代碼，合并多個需要發(fā)送HTTP請求的部分。這部分需要依賴SD模塊，通過SD模塊讀取的配置文件獲取到API中間件的IP地址，之后可以與服務(wù)器進(jìn)行通信。

3. 警報模塊：

警報模塊是對數(shù)據(jù)進(jìn)行第一次處理的部分，這部分同樣需要依賴SD模塊，通過SD模塊中存儲的報警標(biāo)準(zhǔn)，在對數(shù)據(jù)進(jìn)行過濾的時候，通過警報模塊對每一條數(shù)據(jù)和標(biāo)準(zhǔn)進(jìn)行對比，如果發(fā)現(xiàn)超出了標(biāo)準(zhǔn)，就進(jìn)行報警處理，通過一個報警設(shè)備持續(xù)播放警報信息，直到用戶介入。

4. OLED模塊：

負(fù)責(zé)把實(shí)時信息顯示到一塊小屏幕上，可以讓用戶隨時了解當(dāng)前節(jié)點(diǎn)的工作狀態(tài)，可以簡單的判斷出現(xiàn)的問題，當(dāng)數(shù)據(jù)處理節(jié)點(diǎn)每接收到一條數(shù)據(jù)的時候，均顯示到OLED屏幕上面，平臺采用動態(tài)刷新的方式對數(shù)據(jù)進(jìn)行展示，當(dāng)觸發(fā)警報的時候，在屏幕上顯示出當(dāng)前報警的節(jié)點(diǎn)的序列號，方便用戶對報警的節(jié)點(diǎn)位置進(jìn)行排查，這部分采用點(diǎn)陣對字母進(jìn)行顯示，可以使用軟件對常用的字幕進(jìn)行構(gòu)造點(diǎn)陣狀態(tài)，把字符映射到點(diǎn)陣中，可以實(shí)現(xiàn)在屏幕上對一些常用字符進(jìn)行顯示。

5. XBee讀取模塊：

這部分負(fù)責(zé)對通過XBee傳出的傳感器數(shù)據(jù)進(jìn)行提取，并把16進(jìn)制數(shù)據(jù)轉(zhuǎn)換為10進(jìn)制，方便程序?qū)?shù)據(jù)進(jìn)行處理，可以方便的把數(shù)據(jù)顯示到OLED屏幕上面。這部分負(fù)責(zé)對XBee節(jié)點(diǎn)進(jìn)行輪詢，讀取實(shí)時數(shù)據(jù)，保證在對接多個數(shù)據(jù)采集節(jié)點(diǎn)的時候，保證數(shù)據(jù)采集的穩(wěn)定性。硬件設(shè)計如圖3所示：

3 結(jié)論

基于ZigBee的火災(zāi)監(jiān)控平臺實(shí)現(xiàn)了軟硬件的聯(lián)動，數(shù)據(jù)自底向上的傳輸，整個平臺是對目前物聯(lián)網(wǎng)技術(shù)的一次完整的實(shí)踐，底層的數(shù)據(jù)采集節(jié)點(diǎn)實(shí)現(xiàn)了聯(lián)網(wǎng)，API中間件的設(shè)計保證了平臺數(shù)據(jù)的上傳下達(dá)，使用JSON進(jìn)行數(shù)據(jù)包裝，保證了前端展示的平臺無關(guān)性，平臺依照統(tǒng)一化設(shè)計，模塊化開發(fā)，構(gòu)造出了一套跨平臺的，穩(wěn)定的，結(jié)構(gòu)可伸縮性的物聯(lián)網(wǎng)平臺。

參考文獻(xiàn)

[1] 楊艷華， 張鳳登， 馬進(jìn)明. ZigBee技術(shù)在火災(zāi)自動報警系統(tǒng)中的應(yīng)用[J].上海電力學(xué)院學(xué)報，2008，24（4）：393-396

[2]李娟，胡方明. 基于ZigBee的高層建筑無線火災(zāi)報警系統(tǒng)[J].電子科技，2012，25（6）：34-40

[3]高守偉，吳燦陽，楊超. ZigBee 技術(shù)實(shí)踐教程： CC2430 /31 的無線傳感器網(wǎng)絡(luò)解決方案[M].北京： 北京航空航天出版社，2009.