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

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

0 引言

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

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

現(xiàn)階段，各種GIS 系統(tǒng)中都需要進行傳感器設備的數(shù)據(jù)傳輸，并實時控制傳感器設備的工作狀態(tài)，而目前的交互地圖還無法滿足上述要求。因此，本文在總結(jié)前人研究成果的基礎上，使用MINA 框架作為基于交互地圖的傳感器設備監(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)。該方法的設計思路以期對后續(xù)的研究有一定的啟發(fā)意義。

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

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

1.1 MINA框架

MINA（Multipurpose Infrastructure for Network Applications）是Apache 軟件組織開發(fā)的一個可用于開發(fā)高性能和高可用性網(wǎng)絡應用程序的基礎框架[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è)務邏輯實現(xiàn)，核心功能是接收和發(fā)送數(shù)據(jù)；IoSession 負責用戶定義屬性與應用數(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ù)庫，可以暫存交互地圖服務器和傳感器設備之間轉(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)的輪詢方式相比，響應更加及時，可以在一段時間內(nèi)保證服務端與客戶端之間的數(shù)據(jù)實時同步；網(wǎng)絡帶寬占用少，WebSocket 只在服務端數(shù)據(jù)變化時才會發(fā)出通知消息；WebSocket 服務端只需要保持與每一個客戶端連接即可，能夠節(jié)省很多開銷；并且WebSocket 協(xié)議中，服務端不需要等待客戶端的消息請求，就可以直接推送數(shù)據(jù)給客戶端，可以給用戶帶來良好的實時性體驗[11-12]。由于交互地圖為網(wǎng)頁服務端，使用Socket協(xié)議無法完成數(shù)據(jù)的轉(zhuǎn)發(fā)，因此，特選取WebSocket 協(xié)議實現(xiàn)網(wǎng)頁服務端的數(shù)據(jù)轉(zhuǎn)發(fā)。

2 總體設計

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

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

圖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ā)框架之間的交換。

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

應用層為交互地圖用戶界面，該界面通過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ù)傳輸信息的不同，以相應的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 詳細設計

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

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

3.2 交互地圖端的設計

GeoServer 是目前較為流行的地圖服務發(fā)布工具，其地圖服務發(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ù)對應不同的圖標（SVG 圖形塊），其中，使用矩形代表傳感器的主板部分，天線代表傳感器的數(shù)據(jù)采集和傳輸模塊。該對應關(guān)系通過映射規(guī)則的方式描述。例如，當接收到的傳感器溫度數(shù)據(jù)小于25℃時，生成的傳感器SVG 符號輪廓為黑色；溫度大于25℃時，其輪廓為紅色。傳感器數(shù)據(jù)傳輸至交互地圖后，GeoServer 服務端會根據(jù)映射規(guī)則，設計出相應的SVG 符號，JavaScript 編寫的網(wǎng)頁腳本可以獲取該SVG符號的ID，替換當前交互地圖上的SVG，達到實時更新傳感器SVG 符號的效果。

交互地圖端具有響應用戶操作的功能。當用戶通過鼠標點擊傳感器SVG 符號時，SVG 符號會響應鼠標點擊事件，生成控制（開啟或關(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 時，交互地圖上的傳感器主板恢復為白色，并且，交互地圖后端重新接收到溫度信息。

圖3 初始交互地圖界面圖

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

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

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

5 結(jié)語

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