基于交互地圖的傳感器監(jiān)控方法研究

林鎧，徐軻，李耀輝，焦東來

（南京郵電大學(xué)地理與生物信息學(xué)院，南京210023）

0 引言

設(shè)備管理是企業(yè)、工廠、農(nóng)業(yè)管理中的一個重要領(lǐng)域，加強設(shè)備管理對于保證工作的順利進行，提高工作效率有著十分重要的意義。由于地圖能將設(shè)備信息通過符號直觀地表現(xiàn)出來，其在設(shè)備管理方面具有很大優(yōu)勢。目前地圖在設(shè)備管理中的應(yīng)用越來越廣泛，例如，路燈管理系統(tǒng)[1]、古樹名木GIS 管理系統(tǒng)[2]、城市交通GIS 管理系統(tǒng)[3]等，上海大學(xué)的項金靈等人也將地圖應(yīng)用于校園設(shè)備的管理[4]。

移動互聯(lián)網(wǎng)時代已經(jīng)開始，各種領(lǐng)域都開始慢慢地滲入互聯(lián)網(wǎng)技術(shù)進行特定功能的拓展開發(fā)，地圖也逐步運用互聯(lián)網(wǎng)技術(shù)進行傳感器等設(shè)備的管理。傳感器帶有空間位置，互聯(lián)網(wǎng)可以使用傳感器獲取數(shù)據(jù)，兩者的相互需求使得基于交互地圖的傳感器設(shè)備管理方法的應(yīng)用越來越普及，Wunder[5]和Cordova-Lopez[6]分別使用交互地圖進行農(nóng)業(yè)生產(chǎn)監(jiān)視傳感器和大氣污染檢測傳感器的管理。

現(xiàn)階段，各種GIS 系統(tǒng)中都需要進行傳感器設(shè)備的數(shù)據(jù)傳輸，并實時控制傳感器設(shè)備的工作狀態(tài)，而目前的交互地圖還無法滿足上述要求。因此，本文在總結(jié)前人研究成果的基礎(chǔ)上，使用MINA 框架作為基于交互地圖的傳感器設(shè)備監(jiān)控方法的通信框架，在數(shù)據(jù)交互的過程中使用Redis 數(shù)據(jù)庫暫存數(shù)據(jù)，通過Web-Socket 協(xié)議互換Socket 和WebSocket 格式的數(shù)據(jù)，將WebSocket 數(shù)據(jù)發(fā)送至交互地圖端進行傳感器數(shù)據(jù)的可視化顯示，Socket 數(shù)據(jù)發(fā)送至傳感器端控制傳感器的工作狀態(tài)。該方法的設(shè)計思路以期對后續(xù)的研究有一定的啟發(fā)意義。

1 相關(guān)技術(shù)

基于交互地圖的監(jiān)控方法需要滿足以下幾點要求：高速穩(wěn)定地傳輸傳感器的海量數(shù)據(jù)；實時不間斷地監(jiān)控傳感器的工作狀態(tài)；允許多個用戶同時接入并同時管理多個傳感器設(shè)備等。因此，針對基于交互地圖的監(jiān)控方法對穩(wěn)定性、實時性和多線程性的需求，本文選取MINA 框架、Redis 數(shù)據(jù)庫和WebSocket 協(xié)議這三項技術(shù)來進行監(jiān)控方法的設(shè)計。

1.1 MINA框架

MINA（Multipurpose Infrastructure for Network Applications）是Apache 軟件組織開發(fā)的一個可用于開發(fā)高性能和高可用性網(wǎng)絡(luò)應(yīng)用程序的基礎(chǔ)框架[7]。MINA框架分為5 個部分[8]：IoService 負責在線程上創(chuàng)立套接字并監(jiān)聽是否有連接被建立；IoFilterChain 接收由IoService 轉(zhuǎn)化的事件；如果建立了連接，IoFilter 會定義一組攔截器，調(diào)用Encoder 和Decoder 方法解碼或編碼數(shù)據(jù)，并把處理后的數(shù)據(jù)交給IoHandler；IoHandler 負責業(yè)務(wù)邏輯實現(xiàn)，核心功能是接收和發(fā)送數(shù)據(jù)；IoSession 負責用戶定義屬性與應(yīng)用數(shù)據(jù)之間的聯(lián)系。

由于MINA 框架具有多線程特性，可以同時監(jiān)聽多個不同位置的傳感器的消息請求，既不會造成系統(tǒng)擁擠，也不會浪費資源，并且在進行大批量數(shù)據(jù)傳輸?shù)耐瑫r，還能保持較高的通信速度。所以選擇MINA 框架作為基于交互地圖的傳感器監(jiān)控方法中的通信框架，可以同時處理多個傳感器的數(shù)據(jù)，減少數(shù)據(jù)發(fā)送的延遲。

1.2 Redis數(shù)據(jù)庫

Redis（Remote Dictionary Server）是NoSQL 數(shù)據(jù)庫中使用廣泛的非關(guān)系內(nèi)存數(shù)據(jù)庫，它的內(nèi)部形式是Key-Value 鍵值對存儲結(jié)構(gòu)。相較于傳統(tǒng)DB 數(shù)據(jù)庫而言，Redis 作為一個內(nèi)存數(shù)據(jù)庫，讀寫數(shù)據(jù)的時候不會受到硬盤I/O 速度的限制，具有對數(shù)據(jù)高并發(fā)讀寫和高效率存儲訪問的性能[9]。

基于交互地圖的傳感器監(jiān)控方法中，轉(zhuǎn)發(fā)的數(shù)據(jù)量和連接的用戶數(shù)眾多，且交互地圖在實時性方面需求較高，傳統(tǒng)關(guān)系型數(shù)據(jù)庫已經(jīng)不能滿足海量數(shù)據(jù)轉(zhuǎn)發(fā)的要求。選取Redis 作為傳感器監(jiān)控方法的緩存數(shù)據(jù)庫，可以暫存交互地圖服務(wù)器和傳感器設(shè)備之間轉(zhuǎn)發(fā)的海量信息，緩解數(shù)據(jù)傳輸?shù)膲毫?，對提高整個系統(tǒng)的性能起到了關(guān)鍵性的作用。同時Redis 會周期性地把更新的數(shù)據(jù)寫入追加的記錄文件中，很好地實現(xiàn)了實時監(jiān)控傳感器的功能。

1.3 WebSocket協(xié)議

WebSocket 協(xié)議是由HTML5 提供的一種基于TCP的持久化協(xié)議，是為了解決持久性連接和資源浪費等問題而開發(fā)的一種新協(xié)議[10]。WebSocket 協(xié)議與傳統(tǒng)的輪詢方式相比，響應(yīng)更加及時，可以在一段時間內(nèi)保證服務(wù)端與客戶端之間的數(shù)據(jù)實時同步；網(wǎng)絡(luò)帶寬占用少，WebSocket 只在服務(wù)端數(shù)據(jù)變化時才會發(fā)出通知消息；WebSocket 服務(wù)端只需要保持與每一個客戶端連接即可，能夠節(jié)省很多開銷；并且WebSocket 協(xié)議中，服務(wù)端不需要等待客戶端的消息請求，就可以直接推送數(shù)據(jù)給客戶端，可以給用戶帶來良好的實時性體驗[11-12]。由于交互地圖為網(wǎng)頁服務(wù)端，使用Socket協(xié)議無法完成數(shù)據(jù)的轉(zhuǎn)發(fā)，因此，特選取WebSocket 協(xié)議實現(xiàn)網(wǎng)頁服務(wù)端的數(shù)據(jù)轉(zhuǎn)發(fā)。

2 總體設(shè)計

2.1 基于交互地圖的傳感器監(jiān)控方法系統(tǒng)框架

基于交互地圖的傳感器設(shè)備監(jiān)控方法由四個層次構(gòu)成（圖1），數(shù)據(jù)層、傳輸層、服務(wù)層、應(yīng)用層。

圖1 基于交互地圖的傳感器監(jiān)控方法系統(tǒng)框架

數(shù)據(jù)層完成傳感器的數(shù)據(jù)采集工作，控制傳感器數(shù)據(jù)采集模塊定時采集數(shù)據(jù)；

傳輸層分為兩層，一層可以通過數(shù)據(jù)傳輸模塊實現(xiàn)Socket 數(shù)據(jù)在傳感器與面向傳感器的MINA 數(shù)據(jù)轉(zhuǎn)發(fā)框架之間的交換，另外一層可以實現(xiàn)WebSocket 數(shù)據(jù)在交互地圖與面向交互地圖的MINA 數(shù)據(jù)轉(zhuǎn)發(fā)框架之間的交換。

服務(wù)層為兩個MINA 數(shù)據(jù)轉(zhuǎn)發(fā)框架，面向傳感器的MINA 數(shù)據(jù)轉(zhuǎn)發(fā)框架可完成兩項工作：監(jiān)聽傳感器的發(fā)送的數(shù)據(jù)，發(fā)送交互地圖的鼠標點擊事件，且可以對這兩種數(shù)據(jù)進行編解碼。面向交互地圖的MINA 數(shù)據(jù)轉(zhuǎn)發(fā)框架的功能為：監(jiān)聽交互地圖的鼠標點擊事件，發(fā)送傳感器的數(shù)據(jù)至交互地圖，并進行Socket 數(shù)據(jù)和WebSocket 數(shù)據(jù)的互相轉(zhuǎn)換。

本研究對喜遼妥與常規(guī)護理對PICC置管患兒發(fā)生機械性靜脈炎預(yù)防效果進行了對比分析，結(jié)果表明：治療組機械性靜脈炎的發(fā)生率低于對照組(P<0.05)，嚴重程度小于對照組(P<0.01)，此結(jié)果與李智英等[7]研究結(jié)果一致；治療組機械性靜脈炎的發(fā)生時間晚于對照組(P<0.01)，對比兩組患兒其他早期并發(fā)癥的發(fā)生率比較差異無統(tǒng)計學(xué)意義(P>0.05)，由此說明喜遼妥可有效延緩預(yù)防機械性靜脈炎。

應(yīng)用層為交互地圖用戶界面，該界面通過JavaScript 編寫了一套映射規(guī)則，對傳感器進行可視化顯示。用戶在交互地圖用戶界面，可通過點擊傳感器符號，遠程控制傳感器工作狀態(tài)。

2.2 基于交互地圖的傳感器監(jiān)控方法實現(xiàn)流程

在基于交互地圖的傳感器監(jiān)控方法實現(xiàn)流程中（圖2），數(shù)據(jù)的傳輸有兩個流向。

圖2 基于MINA框架的監(jiān)控方法實現(xiàn)流程

在采集數(shù)據(jù)的過程中，傳感器端的數(shù)據(jù)采集模塊會定時采集數(shù)據(jù)并通過數(shù)據(jù)傳輸模塊發(fā)送至面向傳感器的MINA 數(shù)據(jù)轉(zhuǎn)發(fā)框架。面向傳感器的MINA 數(shù)據(jù)轉(zhuǎn)發(fā)框架由于其多線程性，在其監(jiān)聽到傳感器的建立請求命令后，立刻監(jiān)聽傳感器數(shù)據(jù)，并將數(shù)據(jù)發(fā)布（publish）到Redis 數(shù)據(jù)庫。傳感器數(shù)據(jù)會暫存于Redis數(shù)據(jù)庫。面向交互地圖的MINA 數(shù)據(jù)轉(zhuǎn)發(fā)框架將訂閱（subscribe）Redis 數(shù)據(jù)庫中的數(shù)據(jù)，并使用WebSocket協(xié)議將Socket 數(shù)據(jù)包裝為WebSocket 數(shù)據(jù)，發(fā)送至交互地圖。交互地圖前端使用JavaScript 編寫了一套完整的映射規(guī)則，根據(jù)傳輸信息的不同，以相應(yīng)的Scalable Vector Graphics（SVG）符號表示傳感器狀態(tài)，實現(xiàn)傳感器數(shù)據(jù)的可視化顯示。

在控制傳感器工作狀態(tài)的過程中，用戶在交互地圖界面通過點擊傳感器圖標，可以產(chǎn)生鼠標點擊事件，這個命令以WebSocket 格式發(fā)送至面向交互地圖的MINA 數(shù)據(jù)轉(zhuǎn)發(fā)框架。面向交互地圖的MINA 數(shù)據(jù)轉(zhuǎn)發(fā)框架監(jiān)聽到數(shù)據(jù)后，將其轉(zhuǎn)換為Socket 數(shù)據(jù)發(fā)布到Redis 數(shù)據(jù)庫。面向傳感器的MINA 數(shù)據(jù)轉(zhuǎn)發(fā)框架訂閱數(shù)據(jù)，并反饋給傳感器，控制傳感器的工作狀態(tài)。

3 詳細設(shè)計

3.1 基于訂閱發(fā)布的數(shù)據(jù)轉(zhuǎn)發(fā)機制

基于交互地圖的傳感器監(jiān)控方法中傳輸?shù)臄?shù)據(jù)分為兩種格式：Socket 和WebSocket。MINA 服務(wù)器和傳感器之間傳輸?shù)氖荢ocket 數(shù)據(jù)，而交互地圖和MINA服務(wù)器之間傳輸?shù)氖荳ebSocket 數(shù)據(jù)，所以必須要有兩套編解碼方式。為了連接兩種編解碼方式，本文選取Redis 數(shù)據(jù)庫，使用其特有的訂閱和發(fā)布功能，將兩種數(shù)據(jù)存儲在緩存數(shù)據(jù)庫中，再使用WebSocket 協(xié)議進行數(shù)據(jù)轉(zhuǎn)換，以此建立傳感器設(shè)備和交互地圖網(wǎng)頁的數(shù)據(jù)傳輸通道。

3.2 交互地圖端的設(shè)計

GeoServer 是目前較為流行的地圖服務(wù)發(fā)布工具，其地圖服務(wù)發(fā)布滿足OGC 規(guī)范[13]，因此被廣泛的用于WebGIS 系統(tǒng)。GeoServer 可以將空間數(shù)據(jù)發(fā)布成JPG、SVG、GML、KML 等格式的地圖數(shù)據(jù)，由于SVG 能夠較好地支持JavaScript，所以本研究采用GeoServer 發(fā)布的SVG 格式的地圖數(shù)據(jù)作為交互地圖的底圖。每個傳感器抽象成SVG 圖形塊（Block）與底圖疊加顯示，不同的傳感器數(shù)據(jù)對應(yīng)不同的圖標（SVG 圖形塊），其中，使用矩形代表傳感器的主板部分，天線代表傳感器的數(shù)據(jù)采集和傳輸模塊。該對應(yīng)關(guān)系通過映射規(guī)則的方式描述。例如，當接收到的傳感器溫度數(shù)據(jù)小于25℃時，生成的傳感器SVG 符號輪廓為黑色；溫度大于25℃時，其輪廓為紅色。傳感器數(shù)據(jù)傳輸至交互地圖后，GeoServer 服務(wù)端會根據(jù)映射規(guī)則，設(shè)計出相應(yīng)的SVG 符號，JavaScript 編寫的網(wǎng)頁腳本可以獲取該SVG符號的ID，替換當前交互地圖上的SVG，達到實時更新傳感器SVG 符號的效果。

交互地圖端具有響應(yīng)用戶操作的功能。當用戶通過鼠標點擊傳感器SVG 符號時，SVG 符號會響應(yīng)鼠標點擊事件，生成控制（開啟或關(guān)閉）命令，發(fā)送至傳感器端控制其工作狀態(tài)。接受到“開啟”命令時，傳感器端的傳感器開始采集數(shù)據(jù)，交互地圖端傳感器SVG 符號主板部分（傳感器符號中的矩形）替換為白色；接受到“關(guān)閉”命令時，傳感器端的傳感器停止采集數(shù)據(jù)，交互地圖端傳感器SVG 符號主板部分替換為黑色。

4 測試與分析

本文以南京市玄武區(qū)為實驗區(qū)，進一步驗證基于交互地圖的傳感器監(jiān)控方法的可行性和映射規(guī)則的準確性。我們分別在研究區(qū)的不同位置放置了8 個傳感器，每個傳感器的dht11 模塊每隔1h 采集一次數(shù)據(jù)，并將數(shù)據(jù)通過esp8266Wifi 模塊發(fā)送至面向傳感器的MINA 數(shù)據(jù)轉(zhuǎn)發(fā)框架。本次實驗僅觀察3 個傳感器所監(jiān)視的地區(qū)在交互地圖上的變化情況（圖3），共采集7時-18 時的12 組數(shù)據(jù)（表1）來驗證傳感器符號的狀態(tài)變化與測試數(shù)據(jù)的映射情況。

7-10 時及14 時-18 時，傳感器采集到的溫度低于26℃，傳感器SVG 的輪廓為黑色；11 時-12 時，傳感器采集到的溫度高于26℃，傳感器SVG 的輪廓為紅色（圖4）。

12 時45 分，點擊交互地圖上的傳感器圖標，產(chǎn)生“關(guān)閉”命令，傳感器停止采集數(shù)據(jù)。13 時，交互地圖后端沒有接收到溫度信息，且交互地圖上的傳感器SVG主板顏色被替換為黑色（圖5）。13 時45 分，再次點擊交互地圖上的傳感器圖標，開啟傳感器。14 時，交互地圖上的傳感器主板恢復(fù)為白色，并且，交互地圖后端重新接收到溫度信息。

圖3 初始交互地圖界面圖

圖4 傳感器溫度發(fā)生變化

圖5 傳感器關(guān)閉

通過實驗證明：交互地圖會根據(jù)傳感器實時發(fā)送的溫度信息，相應(yīng)地改變傳感器符號輪廓的填充顏色，反映監(jiān)視地區(qū)溫度的高低變化。用戶可以在交互地圖網(wǎng)頁上通過點擊傳感器符號，達到對傳感器設(shè)備進行遠程控制的功能。

5 結(jié)語

本文研究了在地圖上進行數(shù)據(jù)交互的方法，并在數(shù)據(jù)的交互過程中實現(xiàn)傳感器設(shè)備的監(jiān)控。為了滿足設(shè)備監(jiān)控對穩(wěn)定性、實時性和多線程性的需求，我們設(shè)計了相應(yīng)的方法，通過Redis 的訂閱和發(fā)布功能建立Socket 和WebSocket 的數(shù)據(jù)傳輸通道，實現(xiàn)了在交互地圖上監(jiān)控傳感器設(shè)備的功能。這種方法為遠程設(shè)備的監(jiān)控與維護提供了一個直觀方便、經(jīng)濟有效的手段。維護人員可以通過交互地圖了解到傳感器設(shè)備的狀態(tài)，快速確定傳感器設(shè)備的位置，對傳感器設(shè)備產(chǎn)生的故障進行初步排查，實現(xiàn)快速、高效、準確的維護工作。但該方法尚存在一些不足，例如用戶權(quán)限問題，所有用戶均可以在交互地圖界面中控制傳感器工作狀態(tài)?？墒窃趯嶋H應(yīng)用中，傳感器的控制具有很嚴格的要求。因此，給傳感器的控制加上管理員權(quán)限，成為我們未來的改進方向。