0 引言

    物聯網技術不斷發展和完善，其在社會各領域中逐漸得到推廣和應用。在環境監測領域，存在監測范圍廣、傳感器數量多及節點數據上傳頻繁等特征，人們一直致力于發展高效的通信技術，以實現更低的功耗、更遠的通信距離、更大的覆蓋范圍^[1]。物聯網的通信手段從ZigBee、Wi-Fi和藍牙等傳統技術，發展到目前國內熱度極高的窄帶物聯網(Narrow Band Internet of Things，NB-IoT)、長距離通信(Long of Range，LoRa)等低功耗廣域網技術^[2]。各大物聯網企業都相繼推出針對這兩種新技術的解決方案。這些方案架構大致相似，例如中興的LoRaWAN解決方案，其涵蓋終端層、網關層、云平臺層及應用層，在應用層提供豐富的功能，如查看歷史數據報表、異常信息告警、數據分析和設備控制等。但針對不同應用場景，需要實現個性化功能時，平臺提供的操作接口都比較單一，很難滿足二次開發的需求。目前，基于LoRaWAN協議的監測系統開發，大部分開發者均選擇圖1所示的方案架構。該架構包含終端層、傳輸層、網絡層和應用層四層。網絡層又由LoRa服務器、Web服務器(Web網絡應用服務器)和數據庫三部分組成。該分層架構為開發人員提供了更多的操作空間，系統的靈活性與可擴展性更強。

    實驗室安全監測屬于室內環境監測中的一類，該應用場景主要功能需求如圖2所示。安全監測系統集中管理多個區域的實驗室，各實驗室內主要配置溫濕度傳感器、煙霧報警傳感器等終端設備。終端周期采集數據，并上傳至數據中心進行集中處理，各實驗室管理人員登錄應用層網頁端頁面和移動端App時，均能查看其管轄實驗室內所有終端最新采集數據，接收異常數據的告警信息。對于終端上傳的非緊急類異常數據信息，如超出閾值的溫濕度數據，應用層無須即刻獲知此信息，但對于煙霧報警等緊急類異常消息，須在盡可能短的時間內被通知到管理人員并得到妥善處理，以免釀成重大安全事故?？梢姡h境監測系統在應用于實驗室安全管理時，系統數據傳輸的即時性尤為重要。然而，圖1所示架構應用在此場景時，實現的監測系統卻不能展現出較好的實時性。對于圖1架構，其網絡層采用數據庫系統作為終端層采集數據的存儲中轉站，LoRa服務器接收處理所有終端數據并存入數據庫，Web服務器（WS）通過讀取數據庫來獲得最新終端數據以響應應用層數據請求。這類“拉取”式的通信方式在本質上就會為系統帶來不同程度的延時^[3]。并且，終端數量眾多，系統長期運行，使得數據庫存儲著大量的記錄，數據讀取操作耗時過長，這也導致WS延時響應應用程序請求。

    考慮上述問題，并針對實驗室安全監測應用場景，本文基于現有方案架構，在LoRa服務器與WS間建立基于MQTT協議的通信鏈路，取代基于數據庫讀取的數據共享方式，實現WS對終端數據的即時獲取。同時，系統引入WebSocket通信技術，實現WS與應用層程序的實時數據傳輸。并且，針對監測系統同時對多個監測區域進行統一管理、分區展示的應用需求，為系統設計數據推送策略，進一步提高系統數據交互實時性。

1 相關技術介紹

    WebSocket協議在單個TCP連接上實現全雙工通信^[4]，其工作機制基于訂閱-發布模式。WebSocket通信的建立過程如圖3所示。Websocket復用HTTP通道，兩者使用相同的TCP端口。在Web端網頁開發中，WebSocket協議已被納入HTML5規范中，現代主流瀏覽器都支持此協議的使用。

    消息隊列遙測傳輸協議(Message Queuing Telemetry Transport，MQTT）是IBM發布的一種“輕量級”、基于發布-訂閱機制的協議。該協議基于TCP/IP協議，提供可靠、有序與雙向的數據傳輸機制^[5]，在物聯網領域應用廣泛。發布-訂閱機制中存在三種角色：發布者、訂閱者和代理^[6]。發布者將特定主題標識的消息發送給代理，然后代理將該消息轉發給對該特定主題感興趣的每個訂閱者。

2 延時原因分析及解決方案

    分析圖1方案構架，以第一時間將終端層數據傳輸到應用層程序為基準，對系統通信過程中存在的延時做時段劃分，如圖4所示。

    第一類延時的長短由通信網絡情況的優劣決定。對于通信時段T1、T2，在LoRaWAN通信組網、LoRa網關與LoRa服務器之間的網絡越好，其數據傳輸延時越小。

    第二類延時由系統進行數據處理產生。時段T3是LoRa服務器接收處理網關上傳數據，并進行數據存儲時系統內部操作用時，該部分時長主要與搭載運行LoRa服務器的硬件設備相關，設備處理速度越快，T3時段用時越短。時段T4主要由WS讀取數據庫產生，數據庫表中紀錄越多，數據讀取耗時越長。時段T5涵蓋從應用程序發起請求到收到響應整個過程，主要由兩部分組成，一是數據包在網絡通道中的傳輸，顯然，此處的時長同樣與網絡情況相關；二是WS請求處理時間，若WS運行內存充裕，則此處耗時較小，但若在高并發場景，WS資源的耗盡將導致其不能即刻響應應用程序請求，則此部分的時長無法確定，最壞情況下甚至會丟失請求，應用程序無法獲取到數據響應。

    對于上述兩類延時，通過使用通信穩定的硬件設備，確保底層終端數據正常傳輸，并為系統配置滿足應用場景需求的硬件處理設備，最大程度地減少T1、T2、T3時段的延時。本文將重點解決T4與T5兩個時間段存在的延時，該部分主要涉及應用程序與WS間的通信及WS的數據庫操作。

    目前，Web頁面程序多選用輪詢技術來實現與WS的實時通信^[7]，頻繁地發起HTTP請求來模擬實時數據傳輸?？紤]本文應用場景的特點：各類終端上傳數據的周期各異，即便上傳周期相同，因設備并非在同一時間開機運行，數據上傳時刻也將不同。故Web頁面主動發起的請求若周期大，無法獲取所有終端最新數據；若周期小，過于頻繁地請求也必將加重服務器的負擔，降低系統整體響應速度。為了避免上述情況，本文將數據傳輸的主動方從應用程序端轉換到WS端。選用WebSocket通信技術，實現WS主動將終端采集數據發送至Web頁面，進而從根本上實現頁面與WS間的實時數據傳輸。

    考慮移動應用App，若其與WS時刻保持長連接將占據移動設備大量資源，且考慮管理員無須時刻查看終端數據，故兩者通信仍采用HTTP協議即可。對于需要及時處理的異常信息，例如煙霧傳感報警，通過在WS啟用短信及郵件服務，將告警信息及時通知到對應管理人員。

    轉變頁面程序與WS間數據通信主動方后，需要考慮WS應在何時推送數據至應用程序。圖1架構中，所有終端上傳的數據均經由LoRa服務器處理并存儲至數據庫。若WS仍采用周期讀取數據庫的方式來獲取最新終端層數據，讀取間隔選取和讀取操作耗時問題仍存在。本文在LoRa服務器和WS間建立MQTT通信服務，使其在接收到終端數據時，立即發布終端數據至WS，WS接收處理完數據后，即刻推送數據消息到應用程序。對接收的每條數據信息，WS在將結合該終端更多基本信息，對數據進行綜合處理。為實現更加快速的基本信息查詢，搭建基于內存的高速緩存數據庫，存儲系統內終端基本信息。本文仍保留傳統架構中涵蓋的數據庫系統，用于持久化存儲全部終端數據記錄，以便系統功能拓展。

    至此，WS與應用程序、WS與LoRa服務器間，雙方均保持雙向、實時通信。本文實驗室安全監測系統最終架構如圖5所示。

3 系統解決方案實現

    系統主要模塊如圖6所示。下面將對應用程序層、LoRa服務層進行簡要闡述，并對應用服務層做詳細闡述。

3.1 LoRa服務層實現

    LoRa服務層除實現基于LoRaWAN協議的硬件設備通信服務外，由于還負責維護與應用服務層間數據的傳輸，需再實現MQTT數據傳輸服務。本系統選擇Mosquitto代理服務器來搭建一個MQTT消息中間件。服務器端本地安裝Mosquitto并在默認端口1883開啟服務，并定義數據發布主題“loraPub”。LoRa服務器端每收到一次終端數據，將開啟一個新進程，通過MQTT服務發布所接收數據。

3.2 應用服務層實現

    應用服務層既需監聽LoRa服務層發布數據，將其快速傳送至相應應用程序，也需為應用程序層提供訪問連接服務，并對訪問連接進行管理。為了最大程度減小應用程序層數據更新的延時，本系統實現結合WebSocket與MQTT通信的服務模塊。設計數據緩沖層，存儲常用信息于內存中，減少數據讀取耗時。為實現同時對多區域進行實時監管，設計數據推送及異常告警模塊，保證終端數據被解析處理后能推送至正確應用程序。數據緩沖層中保存著系統運行中所有在線WebSocket客戶端的連接數據，為數據推送模塊提供數據參考。同時，由于在網絡不穩定、斷網等異常情況下，WebSocket服務端無法及時感知客戶端斷開連接。為使數據推送更加高效，設計巡檢模塊實時監測客戶端連接情況。下面將對該層實現進行詳細說明。

3.2.1 通信模塊實現

    系統運行中常出現LoRa服務層同時接收大量數據包的情況，導致WS端常需同時支持多個MQTT通信服務。系統需有應對高并發連接的能力。Node作為一種新型的Web服務器，在很多場景下展現出極強的高并發處理能力^[8]，本文選擇它作為系統的WS的具體實現，并使用Express應用框架創建Node服務，基于該服務，實現WebSocket、HTTP及MQTT通信服務。

    Node端安裝MQTT庫，通過訪問Mosquitto服務器與LoRa服務層建立通信連接。訂閱主題“loraPub”，通過node_mqtt模塊提供的on方法監聽LoRa服務層數據的發布。安裝Socket.io庫WebSocket服務，配置HTTP與WebSocket開啟同一端口號3000使兩個通信服務共存。

3.2.2 數據存儲模塊實現

    使用Redis數據庫實現系統高速數據存儲，Redis是基于內存的，以“鍵-值”形式對數據進行存儲的數據庫^[9]。數據庫存儲內容及詳情如表1所示。鍵NODE、USER分別用于保存終端信息和用戶信息。鍵onlineClient用于管理系統運行中的WebSocket連接客戶端信息，在非客戶端主動斷開連接的情況下，實時記錄登錄客戶端的連接狀態，作為后續高效數據推送的依據。

    表中area字段表示節點/用戶所屬區域，pwd代表用戶名對應登錄密碼，type代表終端節點類型，posx、posy表示終端在Web展示頁面上對應的坐標位置。sid標識每個Socket連接會話的id，這是一個隨機生成唯一標識，每一次新的連接建立，其對應一個新的sid，定義該鍵有兩種取值，0代表該連接客戶端離線，1代表該連接客戶端在線。

    服務端本地安裝Redis數據庫并開啟服務。Node端安裝Redis庫，并連接本地Redis服務器。內存中建立WSClient對象變量，以sid為鍵，其對應所屬區域area為值，實時記錄所有與Node服務端保持連接狀態的會話信息。

3.2.3 巡檢點名模塊實現

    Web頁面與WS建立WebSocket連接，并訂閱“devMsg”主題監聽數據發布。為實現WS實時感知WebSocket客戶端連接情況，頁面程序中自定義“myPing”主題的周期心跳發布。WS每監聽到一個“myPing”主題數據，便在onlineClient中修改對應sid的狀態值為1。WS將把監聽同一區域數據的連接會話分配至同一room，并以區域名命名該room。利用庫提供的rooms、join和leave等相關操作方法，建立如圖7所示巡檢點名流程，實現服務端對連接會話的狀態監測。

    WS在周期讀取鍵onlineClient中數據，判斷所有記錄會話連接狀態。所有離線會話將被全局記錄量WSClient和Socket中所屬對應room中移除。每次巡檢最后，都會將所有會話狀態重新置0，WS重新等待Web頁面上傳的心跳。巡檢點名模塊實現了WS對會話連接情況的精準掌握，為其實現高效數據推送提供參考。

3.2.4 數據推送模塊實現

    系統若不為WS設計一套數據推送策略，其在監聽到LoRa服務器的數據時，將不加區分地發送數據至所有在線Web頁面，這將帶來數據安全問題。且瀏覽器會因為耗時處理多余的數據，令真正需要處理的數據等待更長時間。本系統設計數據推送方案，減小此情況引起的頁面數據渲染延時。

    WS在啟動時即與LoRa服務層的Mosquitto服務器建立連接，并訂閱“loraPub”主題，監聽LoRa服務層的數據發布。Web頁面與WS建立WebSocket連接后，WS將啟動巡檢點名模塊對Web頁面的連接狀態進行實時監聽。WS工作流程如圖8所示。

    LoRa服務層發布數據時，數據以字符串“dev_eui#data”形式傳輸。該字符串包含終端編號與數據值，并以字符“#”作為分隔符。當WS監聽到數據時，先對接收到的字符串進行解析，獲取設備編號，并根據設備編號查找出該設備所屬區域area及其余基本信息，若此時全局記錄對象WSClient中存在監聽該區域的在線會話端，則將推送數據到對應的Web頁面；若此時WSClient中無監聽該區域的在線會話，則不執行數據推送操作。若此時判斷出數據異常，例如，煙霧傳感器狀態值異常等，WS將啟動短信郵件服務，發送異常告警信息到對應實驗室管理員。具體數據推送流程如圖9所示。

3.3 應用程序層

    應用程序層由Web端界面和移動App組成。WS開啟短信、郵件服務，將異常信息實時發送至管理員，當App捕獲到設備接收到告警信息時，將調用手機閃關燈及揚聲器等硬件設備，觸發聲光報警，再次提醒管理人員。APP端同時為用戶提供信息注冊、數據查看等基本功能，用戶主動查看數據時，通過向應用服務層發起HTTP請求來獲取最新數據。對于Web頁面展示，核心功能是為各實驗室管理人員實時展示其管轄實驗室內所有終端最新采集數據。使用Vue.js前端庫來編寫Web端應用程序，利用其“虛擬節點”和“數據綁定”特性[10]，Web頁面能對接收數據進行快速渲染，減小視圖更新延時。Web頁面與WS間的WebSocket通信通過Socket.IO模塊中的socket.io-client庫進行實現。

4 功能與性能測試

    系統搭建環境為華中師范大學九號教學樓二樓各個實驗室，在各室中安裝LoRa煙霧節點及溫濕度節點，LoRa服務層均能正常接收所有終端節點上傳數據。

4.1 功能測試

    主動觸發對二樓監測區域內209室的煙霧報警節點，僅二樓管理員監看界面在209室位置顯示異常告警圖標，并播放告警音樂，頁面通知欄也立刻播放告警信息。二樓區域的其他管理員，即使未登錄網頁頁面，也將收到郵件提醒及App端的聲光報警。具體告警實現如圖10所示。

4.2 性能測試

    采用自動化測試工具Apache ab對系統進行測試。為了排除網絡的不穩定性對測試結果的影響，配置本系統WS與應用程序的網絡處于同一交換機的同一局域網下。對于數據推送方案的用時測試，由于減少了不必要的數據推送及頁面渲染處理，系統的延時將必定得到減小。

    測試系統數據傳輸延時。定義數據傳輸時間為WS監聽到LoRa服務層數據，到Web頁面收到所監聽區域內所有終端數據并完成視圖渲染的全程總用時。對比傳統輪詢數據庫查詢方式，分別測試監測區域內有單個/多個終端時，數據傳輸時長，測試結果如圖11所示?？梢?，本系統的通信延時明顯低于傳統方案，且監測范圍內終端越多，本系統優勢越明顯。并且，對基于Ajax輪詢的數據傳輸用時測試時，是基于所有終端均在同一時刻完成數據采集上傳，Web頁面零延時發起請求，實際最新數據更新到Web頁面會有更長的時延。

5 結論

    本文分析了環境監測領域中，基于LoRa技術的解決方案的應用現狀，并針對實驗室安全監測這一特殊應用場景時，系統無法滿足高實時性需求這一問題，在現有解決方案架構中引入MQTT與WebSockt通信技術，并結合使用Redis數據存儲技術、Node.js服務端技術等，減小監測系統通信的整體延時。并針對系統需集中管理多個監測區域的實際應用場景，設計了服務端數據推送策略，使得Web頁面能高效接收對應監管區域數據，進一步降低系統數據更新時延。

參考文獻

[1] 劉偉，胡安林.無線傳感器網絡覆蓋率與節能性研究[J].電子技術應用，2016，42(6)：98-100，104.

[2] 邵嘉，龐成鑫，盧小姣，等.LPWAN技術在能源物聯網領域應用研究[J].物聯網技術，2018，8(12)：44-47.

[3] 吳麗梅，韓利峰，黃文博，等.實時Web技術在輻射監測系統中的應用[J].計算機應用，2018(S2)：337-340.

[4] 張玉清，賈巖，雷柯楠，等.HTML5新特性安全研究綜述[J].計算機研究與發展，2016，53(10)：2163-2172.

[5] 朱明輝，趙信廣，尤星懿.基于FreeRTOS和MQTT的海洋監測網絡框架[J].電子技術應用，2018，44(1)：41-44.

[6] ADHITYA B.A publish subscribe based middleware for enabling real time web access on constrained device[C].2017 9th International Conference on Information Technology and Electrical Engineering(ICITEE)，2017：1-5.

[7] 張藝.基于WebSocket的即時通信系統研究與實現[J].軟件，2015，36(3)：89-94.

[8] LIANG L，ZHU L，SHANG W，et al.Express supervision system based on NodeJS and MongoDB[C].IEEE/ACIS International Conference on Computer & Information Science.IEEE，2017.

[9] 李鵬鵬，鄭揚飛，劉玉龍.Redis在即時通訊系統中的應用[J].軟件，2017，38(1)：115-119.

[10] 麥冬，陳濤，梁宗灣.輕量級響應式框架Vue.js應用分析[J].信息與電腦(理論版)，2017(7)：58-59.

作者信息:

張  麗，李  達，劉輝席，劉守印

(華中師范大學 物理科學與技術學院，湖北 武漢430079)