0 引言

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

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

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

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

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

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

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

    分析圖1方案構(gòu)架，以第一時間將終端層數(shù)據(jù)傳輸?shù)綉?yīng)用層程序為基準(zhǔn)，對系統(tǒng)通信過程中存在的延時做時段劃分，如圖4所示。

    第一類延時的長短由通信網(wǎng)絡(luò)情況的優(yōu)劣決定。對于通信時段T1、T2，在LoRaWAN通信組網(wǎng)、LoRa網(wǎng)關(guān)與LoRa服務(wù)器之間的網(wǎng)絡(luò)越好，其數(shù)據(jù)傳輸延時越小。

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

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

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

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

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

    至此，WS與應(yīng)用程序、WS與LoRa服務(wù)器間，雙方均保持雙向、實(shí)時通信。本文實(shí)驗室安全監(jiān)測系統(tǒng)最終架構(gòu)如圖5所示。

3 系統(tǒng)解決方案實(shí)現(xiàn)

    系統(tǒng)主要模塊如圖6所示。下面將對應(yīng)用程序?qū)印oRa服務(wù)層進(jìn)行簡要闡述，并對應(yīng)用服務(wù)層做詳細(xì)闡述。

3.1 LoRa服務(wù)層實(shí)現(xiàn)

    LoRa服務(wù)層除實(shí)現(xiàn)基于LoRaWAN協(xié)議的硬件設(shè)備通信服務(wù)外，由于還負(fù)責(zé)維護(hù)與應(yīng)用服務(wù)層間數(shù)據(jù)的傳輸，需再實(shí)現(xiàn)MQTT數(shù)據(jù)傳輸服務(wù)。本系統(tǒng)選擇Mosquitto代理服務(wù)器來搭建一個MQTT消息中間件。服務(wù)器端本地安裝Mosquitto并在默認(rèn)端口1883開啟服務(wù)，并定義數(shù)據(jù)發(fā)布主題“l(fā)oraPub”。LoRa服務(wù)器端每收到一次終端數(shù)據(jù)，將開啟一個新進(jìn)程，通過MQTT服務(wù)發(fā)布所接收數(shù)據(jù)。

3.2 應(yīng)用服務(wù)層實(shí)現(xiàn)

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

3.2.1 通信模塊實(shí)現(xiàn)

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

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

3.2.2 數(shù)據(jù)存儲模塊實(shí)現(xiàn)

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

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

    服務(wù)端本地安裝Redis數(shù)據(jù)庫并開啟服務(wù)。Node端安裝Redis庫，并連接本地Redis服務(wù)器。內(nèi)存中建立WSClient對象變量，以sid為鍵，其對應(yīng)所屬區(qū)域area為值，實(shí)時記錄所有與Node服務(wù)端保持連接狀態(tài)的會話信息。

3.2.3 巡檢點(diǎn)名模塊實(shí)現(xiàn)

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

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

3.2.4 數(shù)據(jù)推送模塊實(shí)現(xiàn)

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

    WS在啟動時即與LoRa服務(wù)層的Mosquitto服務(wù)器建立連接，并訂閱“l(fā)oraPub”主題，監(jiān)聽LoRa服務(wù)層的數(shù)據(jù)發(fā)布。Web頁面與WS建立WebSocket連接后，WS將啟動巡檢點(diǎn)名模塊對Web頁面的連接狀態(tài)進(jìn)行實(shí)時監(jiān)聽。WS工作流程如圖8所示。

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

3.3 應(yīng)用程序?qū)?/strong>

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

4 功能與性能測試

    系統(tǒng)搭建環(huán)境為華中師范大學(xué)九號教學(xué)樓二樓各個實(shí)驗室，在各室中安裝LoRa煙霧節(jié)點(diǎn)及溫濕度節(jié)點(diǎn)，LoRa服務(wù)層均能正常接收所有終端節(jié)點(diǎn)上傳數(shù)據(jù)。

4.1 功能測試

    主動觸發(fā)對二樓監(jiān)測區(qū)域內(nèi)209室的煙霧報警節(jié)點(diǎn)，僅二樓管理員監(jiān)看界面在209室位置顯示異常告警圖標(biāo)，并播放告警音樂，頁面通知欄也立刻播放告警信息。二樓區(qū)域的其他管理員，即使未登錄網(wǎng)頁頁面，也將收到郵件提醒及App端的聲光報警。具體告警實(shí)現(xiàn)如圖10所示。

4.2 性能測試

    采用自動化測試工具Apache ab對系統(tǒng)進(jìn)行測試。為了排除網(wǎng)絡(luò)的不穩(wěn)定性對測試結(jié)果的影響，配置本系統(tǒng)WS與應(yīng)用程序的網(wǎng)絡(luò)處于同一交換機(jī)的同一局域網(wǎng)下。對于數(shù)據(jù)推送方案的用時測試，由于減少了不必要的數(shù)據(jù)推送及頁面渲染處理，系統(tǒng)的延時將必定得到減小。

    測試系統(tǒng)數(shù)據(jù)傳輸延時。定義數(shù)據(jù)傳輸時間為WS監(jiān)聽到LoRa服務(wù)層數(shù)據(jù)，到Web頁面收到所監(jiān)聽區(qū)域內(nèi)所有終端數(shù)據(jù)并完成視圖渲染的全程總用時。對比傳統(tǒng)輪詢數(shù)據(jù)庫查詢方式，分別測試監(jiān)測區(qū)域內(nèi)有單個/多個終端時，數(shù)據(jù)傳輸時長，測試結(jié)果如圖11所示。可見，本系統(tǒng)的通信延時明顯低于傳統(tǒng)方案，且監(jiān)測范圍內(nèi)終端越多，本系統(tǒng)優(yōu)勢越明顯。并且，對基于Ajax輪詢的數(shù)據(jù)傳輸用時測試時，是基于所有終端均在同一時刻完成數(shù)據(jù)采集上傳，Web頁面零延時發(fā)起請求，實(shí)際最新數(shù)據(jù)更新到Web頁面會有更長的時延。

5 結(jié)論

    本文分析了環(huán)境監(jiān)測領(lǐng)域中，基于LoRa技術(shù)的解決方案的應(yīng)用現(xiàn)狀，并針對實(shí)驗室安全監(jiān)測這一特殊應(yīng)用場景時，系統(tǒng)無法滿足高實(shí)時性需求這一問題，在現(xiàn)有解決方案架構(gòu)中引入MQTT與WebSockt通信技術(shù)，并結(jié)合使用Redis數(shù)據(jù)存儲技術(shù)、Node.js服務(wù)端技術(shù)等，減小監(jiān)測系統(tǒng)通信的整體延時。并針對系統(tǒng)需集中管理多個監(jiān)測區(qū)域的實(shí)際應(yīng)用場景，設(shè)計了服務(wù)端數(shù)據(jù)推送策略，使得Web頁面能高效接收對應(yīng)監(jiān)管區(qū)域數(shù)據(jù)，進(jìn)一步降低系統(tǒng)數(shù)據(jù)更新時延。

參考文獻(xiàn)

[1] 劉偉，胡安林.無線傳感器網(wǎng)絡(luò)覆蓋率與節(jié)能性研究[J].電子技術(shù)應(yīng)用，2016，42(6)：98-100，104.

[2] 邵嘉，龐成鑫，盧小姣，等.LPWAN技術(shù)在能源物聯(lián)網(wǎng)領(lǐng)域應(yīng)用研究[J].物聯(lián)網(wǎng)技術(shù)，2018，8(12)：44-47.

[3] 吳麗梅，韓利峰，黃文博，等.實(shí)時Web技術(shù)在輻射監(jiān)測系統(tǒng)中的應(yīng)用[J].計算機(jī)應(yīng)用，2018(S2)：337-340.

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

[5] 朱明輝，趙信廣，尤星懿.基于FreeRTOS和MQTT的海洋監(jiān)測網(wǎng)絡(luò)框架[J].電子技術(shù)應(yīng)用，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的即時通信系統(tǒng)研究與實(shí)現(xiàn)[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] 李鵬鵬，鄭揚(yáng)飛，劉玉龍.Redis在即時通訊系統(tǒng)中的應(yīng)用[J].軟件，2017，38(1)：115-119.

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

作者信息:

張  麗，李  達(dá)，劉輝席，劉守印

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