文獻標識碼: A
DOI:10.16157/j.issn.0258-7998.190193
中文引用格式: 張麗,李達,劉輝席,等. 減小LoRa技術在實驗室監(jiān)測系統(tǒng)中報警延遲的方法研究[J].電子技術應用,2019,45(6):135-140.
英文引用格式: Zhang Li,Li Da,Liu Huixi,et al. Research on method of reducing alarm delay time of LoRa technology in laboratory monitoring system[J]. Application of Electronic Technique,2019,45(6):135-140.
0 引言
物聯(lián)網技術不斷發(fā)展和完善,其在社會各領域中逐漸得到推廣和應用。在環(huán)境監(jiān)測領域,存在監(jiān)測范圍廣、傳感器數(shù)量多及節(jié)點數(shù)據(jù)上傳頻繁等特征,人們一直致力于發(fā)展高效的通信技術,以實現(xiàn)更低的功耗、更遠的通信距離、更大的覆蓋范圍[1]。物聯(lián)網的通信手段從ZigBee、Wi-Fi和藍牙等傳統(tǒng)技術,發(fā)展到目前國內熱度極高的窄帶物聯(lián)網(Narrow Band Internet of Things,NB-IoT)、長距離通信(Long of Range,LoRa)等低功耗廣域網技術[2]。各大物聯(lián)網企業(yè)都相繼推出針對這兩種新技術的解決方案。這些方案架構大致相似,例如中興的LoRaWAN解決方案,其涵蓋終端層、網關層、云平臺層及應用層,在應用層提供豐富的功能,如查看歷史數(shù)據(jù)報表、異常信息告警、數(shù)據(jù)分析和設備控制等。但針對不同應用場景,需要實現(xiàn)個性化功能時,平臺提供的操作接口都比較單一,很難滿足二次開發(fā)的需求。目前,基于LoRaWAN協(xié)議的監(jiān)測系統(tǒng)開發(fā),大部分開發(fā)者均選擇圖1所示的方案架構。該架構包含終端層、傳輸層、網絡層和應用層四層。網絡層又由LoRa服務器、Web服務器(Web網絡應用服務器)和數(shù)據(jù)庫三部分組成。該分層架構為開發(fā)人員提供了更多的操作空間,系統(tǒng)的靈活性與可擴展性更強。
實驗室安全監(jiān)測屬于室內環(huán)境監(jiān)測中的一類,該應用場景主要功能需求如圖2所示。安全監(jiān)測系統(tǒng)集中管理多個區(qū)域的實驗室,各實驗室內主要配置溫濕度傳感器、煙霧報警傳感器等終端設備。終端周期采集數(shù)據(jù),并上傳至數(shù)據(jù)中心進行集中處理,各實驗室管理人員登錄應用層網頁端頁面和移動端App時,均能查看其管轄實驗室內所有終端最新采集數(shù)據(jù),接收異常數(shù)據(jù)的告警信息。對于終端上傳的非緊急類異常數(shù)據(jù)信息,如超出閾值的溫濕度數(shù)據(jù),應用層無須即刻獲知此信息,但對于煙霧報警等緊急類異常消息,須在盡可能短的時間內被通知到管理人員并得到妥善處理,以免釀成重大安全事故??梢姡h(huán)境監(jiān)測系統(tǒng)在應用于實驗室安全管理時,系統(tǒng)數(shù)據(jù)傳輸?shù)募磿r性尤為重要。然而,圖1所示架構應用在此場景時,實現(xiàn)的監(jiān)測系統(tǒng)卻不能展現(xiàn)出較好的實時性。對于圖1架構,其網絡層采用數(shù)據(jù)庫系統(tǒng)作為終端層采集數(shù)據(jù)的存儲中轉站,LoRa服務器接收處理所有終端數(shù)據(jù)并存入數(shù)據(jù)庫,Web服務器(WS)通過讀取數(shù)據(jù)庫來獲得最新終端數(shù)據(jù)以響應應用層數(shù)據(jù)請求。這類“拉取”式的通信方式在本質上就會為系統(tǒng)帶來不同程度的延時[3]。并且,終端數(shù)量眾多,系統(tǒng)長期運行,使得數(shù)據(jù)庫存儲著大量的記錄,數(shù)據(jù)讀取操作耗時過長,這也導致WS延時響應應用程序請求。
考慮上述問題,并針對實驗室安全監(jiān)測應用場景,本文基于現(xiàn)有方案架構,在LoRa服務器與WS間建立基于MQTT協(xié)議的通信鏈路,取代基于數(shù)據(jù)庫讀取的數(shù)據(jù)共享方式,實現(xiàn)WS對終端數(shù)據(jù)的即時獲取。同時,系統(tǒng)引入WebSocket通信技術,實現(xiàn)WS與應用層程序的實時數(shù)據(jù)傳輸。并且,針對監(jiān)測系統(tǒng)同時對多個監(jiān)測區(qū)域進行統(tǒng)一管理、分區(qū)展示的應用需求,為系統(tǒng)設計數(shù)據(jù)推送策略,進一步提高系統(tǒng)數(shù)據(jù)交互實時性。
1 相關技術介紹
WebSocket協(xié)議在單個TCP連接上實現(xiàn)全雙工通信[4],其工作機制基于訂閱-發(fā)布模式。WebSocket通信的建立過程如圖3所示。Websocket復用HTTP通道,兩者使用相同的TCP端口。在Web端網頁開發(fā)中,WebSocket協(xié)議已被納入HTML5規(guī)范中,現(xiàn)代主流瀏覽器都支持此協(xié)議的使用。
消息隊列遙測傳輸協(xié)議(Message Queuing Telemetry Transport,MQTT)是IBM發(fā)布的一種“輕量級”、基于發(fā)布-訂閱機制的協(xié)議。該協(xié)議基于TCP/IP協(xié)議,提供可靠、有序與雙向的數(shù)據(jù)傳輸機制[5],在物聯(lián)網領域應用廣泛。發(fā)布-訂閱機制中存在三種角色:發(fā)布者、訂閱者和代理[6]。發(fā)布者將特定主題標識的消息發(fā)送給代理,然后代理將該消息轉發(fā)給對該特定主題感興趣的每個訂閱者。
2 延時原因分析及解決方案
分析圖1方案構架,以第一時間將終端層數(shù)據(jù)傳輸?shù)綉脤映绦驗榛鶞剩瑢ο到y(tǒng)通信過程中存在的延時做時段劃分,如圖4所示。
第一類延時的長短由通信網絡情況的優(yōu)劣決定。對于通信時段T1、T2,在LoRaWAN通信組網、LoRa網關與LoRa服務器之間的網絡越好,其數(shù)據(jù)傳輸延時越小。
第二類延時由系統(tǒng)進行數(shù)據(jù)處理產生。時段T3是LoRa服務器接收處理網關上傳數(shù)據(jù),并進行數(shù)據(jù)存儲時系統(tǒng)內部操作用時,該部分時長主要與搭載運行LoRa服務器的硬件設備相關,設備處理速度越快,T3時段用時越短。時段T4主要由WS讀取數(shù)據(jù)庫產生,數(shù)據(jù)庫表中紀錄越多,數(shù)據(jù)讀取耗時越長。時段T5涵蓋從應用程序發(fā)起請求到收到響應整個過程,主要由兩部分組成,一是數(shù)據(jù)包在網絡通道中的傳輸,顯然,此處的時長同樣與網絡情況相關;二是WS請求處理時間,若WS運行內存充裕,則此處耗時較小,但若在高并發(fā)場景,WS資源的耗盡將導致其不能即刻響應應用程序請求,則此部分的時長無法確定,最壞情況下甚至會丟失請求,應用程序無法獲取到數(shù)據(jù)響應。
對于上述兩類延時,通過使用通信穩(wěn)定的硬件設備,確保底層終端數(shù)據(jù)正常傳輸,并為系統(tǒng)配置滿足應用場景需求的硬件處理設備,最大程度地減少T1、T2、T3時段的延時。本文將重點解決T4與T5兩個時間段存在的延時,該部分主要涉及應用程序與WS間的通信及WS的數(shù)據(jù)庫操作。
目前,Web頁面程序多選用輪詢技術來實現(xiàn)與WS的實時通信[7],頻繁地發(fā)起HTTP請求來模擬實時數(shù)據(jù)傳輸??紤]本文應用場景的特點:各類終端上傳數(shù)據(jù)的周期各異,即便上傳周期相同,因設備并非在同一時間開機運行,數(shù)據(jù)上傳時刻也將不同。故Web頁面主動發(fā)起的請求若周期大,無法獲取所有終端最新數(shù)據(jù);若周期小,過于頻繁地請求也必將加重服務器的負擔,降低系統(tǒng)整體響應速度。為了避免上述情況,本文將數(shù)據(jù)傳輸?shù)闹鲃臃綇膽贸绦蚨宿D換到WS端。選用WebSocket通信技術,實現(xiàn)WS主動將終端采集數(shù)據(jù)發(fā)送至Web頁面,進而從根本上實現(xiàn)頁面與WS間的實時數(shù)據(jù)傳輸。
考慮移動應用App,若其與WS時刻保持長連接將占據(jù)移動設備大量資源,且考慮管理員無須時刻查看終端數(shù)據(jù),故兩者通信仍采用HTTP協(xié)議即可。對于需要及時處理的異常信息,例如煙霧傳感報警,通過在WS啟用短信及郵件服務,將告警信息及時通知到對應管理人員。
轉變頁面程序與WS間數(shù)據(jù)通信主動方后,需要考慮WS應在何時推送數(shù)據(jù)至應用程序。圖1架構中,所有終端上傳的數(shù)據(jù)均經由LoRa服務器處理并存儲至數(shù)據(jù)庫。若WS仍采用周期讀取數(shù)據(jù)庫的方式來獲取最新終端層數(shù)據(jù),讀取間隔選取和讀取操作耗時問題仍存在。本文在LoRa服務器和WS間建立MQTT通信服務,使其在接收到終端數(shù)據(jù)時,立即發(fā)布終端數(shù)據(jù)至WS,WS接收處理完數(shù)據(jù)后,即刻推送數(shù)據(jù)消息到應用程序。對接收的每條數(shù)據(jù)信息,WS在將結合該終端更多基本信息,對數(shù)據(jù)進行綜合處理。為實現(xiàn)更加快速的基本信息查詢,搭建基于內存的高速緩存數(shù)據(jù)庫,存儲系統(tǒng)內終端基本信息。本文仍保留傳統(tǒng)架構中涵蓋的數(shù)據(jù)庫系統(tǒng),用于持久化存儲全部終端數(shù)據(jù)記錄,以便系統(tǒng)功能拓展。
至此,WS與應用程序、WS與LoRa服務器間,雙方均保持雙向、實時通信。本文實驗室安全監(jiān)測系統(tǒng)最終架構如圖5所示。
3 系統(tǒng)解決方案實現(xiàn)
系統(tǒng)主要模塊如圖6所示。下面將對應用程序層、LoRa服務層進行簡要闡述,并對應用服務層做詳細闡述。
3.1 LoRa服務層實現(xiàn)
LoRa服務層除實現(xiàn)基于LoRaWAN協(xié)議的硬件設備通信服務外,由于還負責維護與應用服務層間數(shù)據(jù)的傳輸,需再實現(xiàn)MQTT數(shù)據(jù)傳輸服務。本系統(tǒng)選擇Mosquitto代理服務器來搭建一個MQTT消息中間件。服務器端本地安裝Mosquitto并在默認端口1883開啟服務,并定義數(shù)據(jù)發(fā)布主題“l(fā)oraPub”。LoRa服務器端每收到一次終端數(shù)據(jù),將開啟一個新進程,通過MQTT服務發(fā)布所接收數(shù)據(jù)。
3.2 應用服務層實現(xiàn)
應用服務層既需監(jiān)聽LoRa服務層發(fā)布數(shù)據(jù),將其快速傳送至相應應用程序,也需為應用程序層提供訪問連接服務,并對訪問連接進行管理。為了最大程度減小應用程序層數(shù)據(jù)更新的延時,本系統(tǒng)實現(xiàn)結合WebSocket與MQTT通信的服務模塊。設計數(shù)據(jù)緩沖層,存儲常用信息于內存中,減少數(shù)據(jù)讀取耗時。為實現(xiàn)同時對多區(qū)域進行實時監(jiān)管,設計數(shù)據(jù)推送及異常告警模塊,保證終端數(shù)據(jù)被解析處理后能推送至正確應用程序。數(shù)據(jù)緩沖層中保存著系統(tǒng)運行中所有在線WebSocket客戶端的連接數(shù)據(jù),為數(shù)據(jù)推送模塊提供數(shù)據(jù)參考。同時,由于在網絡不穩(wěn)定、斷網等異常情況下,WebSocket服務端無法及時感知客戶端斷開連接。為使數(shù)據(jù)推送更加高效,設計巡檢模塊實時監(jiān)測客戶端連接情況。下面將對該層實現(xiàn)進行詳細說明。
3.2.1 通信模塊實現(xiàn)
系統(tǒng)運行中常出現(xiàn)LoRa服務層同時接收大量數(shù)據(jù)包的情況,導致WS端常需同時支持多個MQTT通信服務。系統(tǒng)需有應對高并發(fā)連接的能力。Node作為一種新型的Web服務器,在很多場景下展現(xiàn)出極強的高并發(fā)處理能力[8],本文選擇它作為系統(tǒng)的WS的具體實現(xiàn),并使用Express應用框架創(chuàng)建Node服務,基于該服務,實現(xiàn)WebSocket、HTTP及MQTT通信服務。
Node端安裝MQTT庫,通過訪問Mosquitto服務器與LoRa服務層建立通信連接。訂閱主題“l(fā)oraPub”,通過node_mqtt模塊提供的on方法監(jiān)聽LoRa服務層數(shù)據(jù)的發(fā)布。安裝Socket.io庫WebSocket服務,配置HTTP與WebSocket開啟同一端口號3000使兩個通信服務共存。
3.2.2 數(shù)據(jù)存儲模塊實現(xiàn)
使用Redis數(shù)據(jù)庫實現(xiàn)系統(tǒng)高速數(shù)據(jù)存儲,Redis是基于內存的,以“鍵-值”形式對數(shù)據(jù)進行存儲的數(shù)據(jù)庫[9]。數(shù)據(jù)庫存儲內容及詳情如表1所示。鍵NODE、USER分別用于保存終端信息和用戶信息。鍵onlineClient用于管理系統(tǒng)運行中的WebSocket連接客戶端信息,在非客戶端主動斷開連接的情況下,實時記錄登錄客戶端的連接狀態(tài),作為后續(xù)高效數(shù)據(jù)推送的依據(jù)。
表中area字段表示節(jié)點/用戶所屬區(qū)域,pwd代表用戶名對應登錄密碼,type代表終端節(jié)點類型,posx、posy表示終端在Web展示頁面上對應的坐標位置。sid標識每個Socket連接會話的id,這是一個隨機生成唯一標識,每一次新的連接建立,其對應一個新的sid,定義該鍵有兩種取值,0代表該連接客戶端離線,1代表該連接客戶端在線。
服務端本地安裝Redis數(shù)據(jù)庫并開啟服務。Node端安裝Redis庫,并連接本地Redis服務器。內存中建立WSClient對象變量,以sid為鍵,其對應所屬區(qū)域area為值,實時記錄所有與Node服務端保持連接狀態(tài)的會話信息。
3.2.3 巡檢點名模塊實現(xiàn)
Web頁面與WS建立WebSocket連接,并訂閱“devMsg”主題監(jiān)聽數(shù)據(jù)發(fā)布。為實現(xiàn)WS實時感知WebSocket客戶端連接情況,頁面程序中自定義“myPing”主題的周期心跳發(fā)布。WS每監(jiān)聽到一個“myPing”主題數(shù)據(jù),便在onlineClient中修改對應sid的狀態(tài)值為1。WS將把監(jiān)聽同一區(qū)域數(shù)據(jù)的連接會話分配至同一room,并以區(qū)域名命名該room。利用庫提供的rooms、join和leave等相關操作方法,建立如圖7所示巡檢點名流程,實現(xiàn)服務端對連接會話的狀態(tài)監(jiān)測。
WS在周期讀取鍵onlineClient中數(shù)據(jù),判斷所有記錄會話連接狀態(tài)。所有離線會話將被全局記錄量WSClient和Socket中所屬對應room中移除。每次巡檢最后,都會將所有會話狀態(tài)重新置0,WS重新等待Web頁面上傳的心跳。巡檢點名模塊實現(xiàn)了WS對會話連接情況的精準掌握,為其實現(xiàn)高效數(shù)據(jù)推送提供參考。
3.2.4 數(shù)據(jù)推送模塊實現(xiàn)
系統(tǒng)若不為WS設計一套數(shù)據(jù)推送策略,其在監(jiān)聽到LoRa服務器的數(shù)據(jù)時,將不加區(qū)分地發(fā)送數(shù)據(jù)至所有在線Web頁面,這將帶來數(shù)據(jù)安全問題。且瀏覽器會因為耗時處理多余的數(shù)據(jù),令真正需要處理的數(shù)據(jù)等待更長時間。本系統(tǒng)設計數(shù)據(jù)推送方案,減小此情況引起的頁面數(shù)據(jù)渲染延時。
WS在啟動時即與LoRa服務層的Mosquitto服務器建立連接,并訂閱“l(fā)oraPub”主題,監(jiān)聽LoRa服務層的數(shù)據(jù)發(fā)布。Web頁面與WS建立WebSocket連接后,WS將啟動巡檢點名模塊對Web頁面的連接狀態(tài)進行實時監(jiān)聽。WS工作流程如圖8所示。
LoRa服務層發(fā)布數(shù)據(jù)時,數(shù)據(jù)以字符串“dev_eui#data”形式傳輸。該字符串包含終端編號與數(shù)據(jù)值,并以字符“#”作為分隔符。當WS監(jiān)聽到數(shù)據(jù)時,先對接收到的字符串進行解析,獲取設備編號,并根據(jù)設備編號查找出該設備所屬區(qū)域area及其余基本信息,若此時全局記錄對象WSClient中存在監(jiān)聽該區(qū)域的在線會話端,則將推送數(shù)據(jù)到對應的Web頁面;若此時WSClient中無監(jiān)聽該區(qū)域的在線會話,則不執(zhí)行數(shù)據(jù)推送操作。若此時判斷出數(shù)據(jù)異常,例如,煙霧傳感器狀態(tài)值異常等,WS將啟動短信郵件服務,發(fā)送異常告警信息到對應實驗室管理員。具體數(shù)據(jù)推送流程如圖9所示。
3.3 應用程序層
應用程序層由Web端界面和移動App組成。WS開啟短信、郵件服務,將異常信息實時發(fā)送至管理員,當App捕獲到設備接收到告警信息時,將調用手機閃關燈及揚聲器等硬件設備,觸發(fā)聲光報警,再次提醒管理人員。APP端同時為用戶提供信息注冊、數(shù)據(jù)查看等基本功能,用戶主動查看數(shù)據(jù)時,通過向應用服務層發(fā)起HTTP請求來獲取最新數(shù)據(jù)。對于Web頁面展示,核心功能是為各實驗室管理人員實時展示其管轄實驗室內所有終端最新采集數(shù)據(jù)。使用Vue.js前端庫來編寫Web端應用程序,利用其“虛擬節(jié)點”和“數(shù)據(jù)綁定”特性[10],Web頁面能對接收數(shù)據(jù)進行快速渲染,減小視圖更新延時。Web頁面與WS間的WebSocket通信通過Socket.IO模塊中的socket.io-client庫進行實現(xiàn)。
4 功能與性能測試
系統(tǒng)搭建環(huán)境為華中師范大學九號教學樓二樓各個實驗室,在各室中安裝LoRa煙霧節(jié)點及溫濕度節(jié)點,LoRa服務層均能正常接收所有終端節(jié)點上傳數(shù)據(jù)。
4.1 功能測試
主動觸發(fā)對二樓監(jiān)測區(qū)域內209室的煙霧報警節(jié)點,僅二樓管理員監(jiān)看界面在209室位置顯示異常告警圖標,并播放告警音樂,頁面通知欄也立刻播放告警信息。二樓區(qū)域的其他管理員,即使未登錄網頁頁面,也將收到郵件提醒及App端的聲光報警。具體告警實現(xiàn)如圖10所示。
4.2 性能測試
采用自動化測試工具Apache ab對系統(tǒng)進行測試。為了排除網絡的不穩(wěn)定性對測試結果的影響,配置本系統(tǒng)WS與應用程序的網絡處于同一交換機的同一局域網下。對于數(shù)據(jù)推送方案的用時測試,由于減少了不必要的數(shù)據(jù)推送及頁面渲染處理,系統(tǒng)的延時將必定得到減小。
測試系統(tǒng)數(shù)據(jù)傳輸延時。定義數(shù)據(jù)傳輸時間為WS監(jiān)聽到LoRa服務層數(shù)據(jù),到Web頁面收到所監(jiān)聽區(qū)域內所有終端數(shù)據(jù)并完成視圖渲染的全程總用時。對比傳統(tǒng)輪詢數(shù)據(jù)庫查詢方式,分別測試監(jiān)測區(qū)域內有單個/多個終端時,數(shù)據(jù)傳輸時長,測試結果如圖11所示??梢?,本系統(tǒng)的通信延時明顯低于傳統(tǒng)方案,且監(jiān)測范圍內終端越多,本系統(tǒng)優(yōu)勢越明顯。并且,對基于Ajax輪詢的數(shù)據(jù)傳輸用時測試時,是基于所有終端均在同一時刻完成數(shù)據(jù)采集上傳,Web頁面零延時發(fā)起請求,實際最新數(shù)據(jù)更新到Web頁面會有更長的時延。
5 結論
本文分析了環(huán)境監(jiān)測領域中,基于LoRa技術的解決方案的應用現(xiàn)狀,并針對實驗室安全監(jiān)測這一特殊應用場景時,系統(tǒng)無法滿足高實時性需求這一問題,在現(xiàn)有解決方案架構中引入MQTT與WebSockt通信技術,并結合使用Redis數(shù)據(jù)存儲技術、Node.js服務端技術等,減小監(jiān)測系統(tǒng)通信的整體延時。并針對系統(tǒng)需集中管理多個監(jiān)測區(qū)域的實際應用場景,設計了服務端數(shù)據(jù)推送策略,使得Web頁面能高效接收對應監(jiān)管區(qū)域數(shù)據(jù),進一步降低系統(tǒng)數(shù)據(jù)更新時延。
參考文獻
[1] 劉偉,胡安林.無線傳感器網絡覆蓋率與節(jié)能性研究[J].電子技術應用,2016,42(6):98-100,104.
[2] 邵嘉,龐成鑫,盧小姣,等.LPWAN技術在能源物聯(lián)網領域應用研究[J].物聯(lián)網技術,2018,8(12):44-47.
[3] 吳麗梅,韓利峰,黃文博,等.實時Web技術在輻射監(jiān)測系統(tǒng)中的應用[J].計算機應用,2018(S2):337-340.
[4] 張玉清,賈巖,雷柯楠,等.HTML5新特性安全研究綜述[J].計算機研究與發(fā)展,2016,53(10):2163-2172.
[5] 朱明輝,趙信廣,尤星懿.基于FreeRTOS和MQTT的海洋監(jiān)測網絡框架[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的即時通信系統(tǒng)研究與實現(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] 李鵬鵬,鄭揚飛,劉玉龍.Redis在即時通訊系統(tǒng)中的應用[J].軟件,2017,38(1):115-119.
[10] 麥冬,陳濤,梁宗灣.輕量級響應式框架Vue.js應用分析[J].信息與電腦(理論版),2017(7):58-59.
作者信息:
張 麗,李 達,劉輝席,劉守印
(華中師范大學 物理科學與技術學院,湖北 武漢430079)