基于MQTT的液漏監(jiān)測系統(tǒng)的設(shè)計與實現(xiàn)

劉艷芳,侯鈺龍 ,高 凱

(中北大學(xué) 儀器與電子學(xué)院 太原 030051)

0 引言

大多廠房有著服務(wù)器等精密儀器電子設(shè)備，但液體泄漏的情況時有發(fā)生，同時也存在著供水管道漏水、雨水侵入等情況，這就需要及早地發(fā)現(xiàn)泄露情況，并精確感知泄漏的點位。分布式或準(zhǔn)分布式的光纖傳感器在液漏測量方面具有廣闊的應(yīng)用前景，可以在發(fā)現(xiàn)液漏的同時及時確定液漏的位置。瑞士SMARTEC SA 公司利用光纖拉曼散射技術(shù)來測試液體的泄漏，液漏定位精度達(dá)到了2 m[1]；西安石油大學(xué)利用布里淵光散射設(shè)計了分布式光纖傳感器，液漏定位精度達(dá)到了0.2 m[2]。上述方法所使用的光纖傳感技術(shù)都是通過單一光源定位，因此對所使用光源的強(qiáng)度提出了極高的要求，同時對于系統(tǒng)數(shù)據(jù)處理能力的精確度也隨之提高，進(jìn)而使得測量成本也隨之增加。但是目前市場上很難選配到具備厘米級空間定位能力，而且價格低廉的液漏傳感器[3]。

在這一特定需求領(lǐng)域應(yīng)用真空的背景下，實驗室采用了多源定位的技術(shù)[4]，即選用了柔性LED燈帶、POF光纖以及光功率計優(yōu)化了傳統(tǒng)的液漏傳感結(jié)構(gòu)。該結(jié)構(gòu)在1 m長的POF光纖上設(shè)計了20個監(jiān)測點位，每一個點位對應(yīng)一個價格低廉的LED燈珠。相比于單一光源技術(shù)，該設(shè)計大大降低了測量成本，同時空間分辨率達(dá)到了0.05 m，在降低成本的同時也提高了監(jiān)測系統(tǒng)的空間分辨率。

目前該液漏傳感系統(tǒng)僅支持通過串口協(xié)議與上位機(jī)通信，傳輸距離僅限于被測廠房內(nèi)。系統(tǒng)管理員和維修員無法在距廠房50 m以外的監(jiān)控中心遠(yuǎn)程控制和查看液漏狀態(tài)，然而部分工業(yè)環(huán)境不便現(xiàn)場監(jiān)測甚至可能會對人體產(chǎn)生危害，所以實現(xiàn)該傳感系統(tǒng)的遠(yuǎn)程監(jiān)測具有很大的研究意義[5]。

HTTP和MQTT是目前廣泛使用的遠(yuǎn)程通信協(xié)議[6]，但HTTP較MQTT協(xié)議而言，對設(shè)備的功耗要求相對高一些，不適合M2M的場景。而對于物聯(lián)網(wǎng)來說，網(wǎng)絡(luò)不穩(wěn)定、設(shè)備功耗大，是需要重點考慮的因素[7]。其次，HTTP的請求-響應(yīng)模式也不像MQTT的發(fā)布/訂閱模式那樣靈活，服務(wù)器的數(shù)據(jù)必須從設(shè)備端主動發(fā)送，設(shè)備端也需要在與服務(wù)器建立連接的情況下取得服務(wù)器端的數(shù)據(jù)[8]。更重要的是，MQTT的每個消息頭均可縮短為2個字節(jié)，而對于HTTP，每個消息頭至少需要200個字節(jié)[9]。綜合以上因素，在原有系統(tǒng)的基礎(chǔ)上，加入了更輕量級的MQTT協(xié)議進(jìn)行數(shù)據(jù)的推送與交互。相較于HTTP協(xié)議的重復(fù)建立連接，MQTT協(xié)議獨有的發(fā)布/訂閱永久連接模式，顯著降低了連接開銷，同時該協(xié)議對于在不穩(wěn)定網(wǎng)絡(luò)狀態(tài)下的傳輸也有著故障恢復(fù)的機(jī)制，該機(jī)制是原生HTTP所不具備的。

Qt作為一種跨平臺的上位機(jī)應(yīng)用程序開發(fā)框架，具有跨平臺性廣、擴(kuò)展性強(qiáng)、開發(fā)模式簡單的特點，現(xiàn)已被廣泛運(yùn)用于嵌入式終端和數(shù)據(jù)采集等系統(tǒng)中[10]。因此基于以上優(yōu)點，選擇Qt作為客戶端的開發(fā)框架，管理員和維修員可通過該客戶端實現(xiàn)對系統(tǒng)的遠(yuǎn)程操控以及實時監(jiān)測。

1 總體設(shè)計

液漏監(jiān)測系統(tǒng)由光纖傳感端、MQTT傳輸端和軟件接收端三部分組成，其中光纖傳感端主要包括傳感帶和變換器兩部分。

傳感帶由POF光纖、柔性LED燈帶和光纖包層組成，當(dāng)出現(xiàn)漏液后，液體下落至光纖傳感端，從而改變了LED燈帶與光纖上耦合結(jié)構(gòu)間的折射率，傳感端監(jiān)測到該點的光強(qiáng)發(fā)生突變，進(jìn)而判斷該點位發(fā)生液漏。傳感帶的結(jié)構(gòu)如圖1所示。光強(qiáng)數(shù)據(jù)經(jīng)過變換器的光電轉(zhuǎn)換模塊和信號調(diào)理模塊，最終將數(shù)據(jù)傳輸?shù)阶儞Q器的總線傳輸模塊[11]。

圖1 傳感帶設(shè)計模型圖

圖2 液漏監(jiān)測系統(tǒng)架構(gòu)圖

對于傳輸端，最后一條傳感帶匯總的監(jiān)測數(shù)據(jù)經(jīng)過WIFI的ESP8266模塊發(fā)送至MQTT代理服務(wù)器，傳輸協(xié)議的應(yīng)用層采用輕量級的MQTT來實現(xiàn)數(shù)據(jù)交互。管理員通過移動端和PC端均可對系統(tǒng)液漏狀況進(jìn)行實時監(jiān)測和感知，系統(tǒng)維修員也可通過移動端和PC端查看待維修狀態(tài)的點位信息并提交維修單據(jù)。該軟件實現(xiàn)了對管道液漏點位的精準(zhǔn)定位和遠(yuǎn)程監(jiān)測，可以極大提高工作人員的效率。系統(tǒng)總體架構(gòu)如圖2所示。

2 傳感端設(shè)計

傳感端包括傳感帶和變換器兩部分，傳感帶之間用變換器連接來進(jìn)行數(shù)據(jù)傳輸。每1 m長的傳感帶上分布20個帶有缺陷結(jié)構(gòu)的傳感點位，每個缺陷結(jié)構(gòu)傳感點位和LED燈珠以及它們之間的耦合區(qū)域組成一個傳感探針。該探針基于光纖的側(cè)向耦合效應(yīng)來實現(xiàn)對每個點位的漏點監(jiān)測，LED燈帶的光源會通過缺陷結(jié)構(gòu)進(jìn)入光纖，發(fā)生漏液后，LED燈帶和傳感帶缺陷結(jié)構(gòu)之間的介質(zhì)由空氣變?yōu)槁┮?，從而改變了耦合結(jié)構(gòu)處光的折射率，進(jìn)而導(dǎo)致探測到的光強(qiáng)發(fā)生突變。

變換器電路的中央處理芯片為STM32F103ZET6，其控制流程為：中央處理芯片控制LED燈帶按規(guī)則閃爍，燈帶上燈珠發(fā)出的光耦合進(jìn)入所對應(yīng)的傳感帶上的缺陷結(jié)構(gòu)，中央處理芯片控制光電轉(zhuǎn)換模塊將光信號轉(zhuǎn)換為電信號，最后將信號放大，發(fā)送到總線傳輸模塊[12]。傳感端設(shè)計如圖3所示。

圖3 傳感端結(jié)構(gòu)示意圖

3 遠(yuǎn)程監(jiān)測技術(shù)

遠(yuǎn)程監(jiān)測技術(shù)是一種隨著計算機(jī)技術(shù),通信技術(shù)以及傳感技術(shù)的發(fā)展，而逐漸興起的設(shè)備狀態(tài)監(jiān)測技術(shù)[13]。通過將監(jiān)測點、控制中心分別部署于兩個不同地域，可打破地域間的物理界限,實現(xiàn)通過網(wǎng)絡(luò)來傳輸監(jiān)測信息。該技術(shù)采用了多元化的信息傳輸、監(jiān)測方案,從而實現(xiàn)了信息、資源和任務(wù)的無邊界共享,達(dá)到了監(jiān)測的實時性、快速性和有效性,并能夠與其它網(wǎng)絡(luò)系統(tǒng)互連互通,為工業(yè)領(lǐng)域提供了一個更高效、全面、安全、快捷的監(jiān)測模式。

目前主流的遠(yuǎn)程監(jiān)測技術(shù)均應(yīng)用于因特網(wǎng)中,并基于TCP/IP協(xié)議和WWW規(guī)范,可擴(kuò)展的軟件組織架構(gòu),使工作人員可以通過訪問中心服務(wù)器來迅速獲取其對應(yīng)權(quán)限下的信息，同時也能及時做出響應(yīng)。未來,隨著嵌入式系統(tǒng)的迅速發(fā)展,遠(yuǎn)程監(jiān)測技術(shù)必然更廣泛的應(yīng)用于遠(yuǎn)程監(jiān)測系統(tǒng)上,是監(jiān)測系統(tǒng)未來的重點發(fā)展方向之一。

本系統(tǒng)在設(shè)計上使用了物理監(jiān)測設(shè)備作為采集前端，WIFI模塊作為網(wǎng)絡(luò)傳輸單元，QT客戶端作為接收信息端，將三者結(jié)合，共同組成了遠(yuǎn)程液漏監(jiān)測系統(tǒng)。采集前端主要包括光纖液漏采樣設(shè)備以及STM32中央處理器組成，其采集到的液漏數(shù)據(jù)，通過WIFI模塊的無線網(wǎng)絡(luò)，將信息傳遞給QT客戶端，最終實現(xiàn)了用戶通過internet便可輕松實現(xiàn)遠(yuǎn)端廠房內(nèi)的液漏監(jiān)測。

4 MQTT協(xié)議

MQTT(消息隊列遙測傳輸)是一種基于代理的發(fā)布/訂閱輕量級消息傳輸協(xié)議[14]。該協(xié)議是基于TCP/IP協(xié)議的應(yīng)用層傳輸協(xié)議，具有網(wǎng)絡(luò)占用開銷小、帶寬低且易于實現(xiàn)的特點，十分適合于物聯(lián)網(wǎng)應(yīng)用下的信息采集和工業(yè)控制。在MQTT協(xié)議中有發(fā)布者(Publisher)、消息代理服務(wù)器(Broker)、訂閱者(Subscriber)3種通信身份。MQTT消息的發(fā)布者和訂閱者都可以是客戶端，消息代理Broker作為中轉(zhuǎn)服務(wù)器，負(fù)責(zé)接收發(fā)布者發(fā)布的消息，并將消息傳遞給該主題的訂閱者。消息的發(fā)布者也可以同時是該主題的訂閱者[15]。MQTT的通信結(jié)構(gòu)如圖4所示。

圖4 MQTT通信結(jié)構(gòu)圖

MQTT設(shè)計了一套保證消息穩(wěn)定傳輸?shù)臋C(jī)制，包括消息應(yīng)答、存儲和重傳。在這套機(jī)制下,提供了3種不同層次QoS(quality of service)，QoS是消息的發(fā)送方和接收方之間達(dá)成的一個協(xié)議，MQTT通過控制QoS等級來確定服務(wù)質(zhì)量，QoS級別越高，服務(wù)質(zhì)量越高，流程越復(fù)雜，系統(tǒng)消耗越大[16]。本系統(tǒng)選用QoS0和QoS1兩種等級，發(fā)布者發(fā)布一個QoS0等級的消息后，無論訂閱者是否成功收到數(shù)據(jù)，都會刪除并丟棄已發(fā)送的數(shù)據(jù)包[17]，發(fā)布者和訂閱者傳遞一次QoS0等級消息的流程如圖5所示。QoS1等級要保證消息至少到達(dá)一次，所以需要有應(yīng)答機(jī)制[18]，發(fā)布者和訂閱者傳遞一次QoS1等級消息的流程如圖6所示。

圖5 QoS0消息傳遞流程圖

圖6 QoS1消息傳遞流程圖

當(dāng)傳感端上報液漏監(jiān)測數(shù)據(jù)時，傳感端作為MQTT協(xié)議中的發(fā)布者(Publisher)，接收端作為訂閱者(Subscriber)，系統(tǒng)一經(jīng)啟動便會進(jìn)入循環(huán)監(jiān)測狀態(tài)，當(dāng)某一個液漏數(shù)據(jù)包傳輸失敗時，也不會對監(jiān)測結(jié)果產(chǎn)生較大影響，所以該數(shù)據(jù)包的傳遞選用QoS0等級。

當(dāng)液漏監(jiān)測系統(tǒng)上傳待維修液漏點位信息數(shù)據(jù)時，傳感端作為MQTT協(xié)議中的發(fā)布者(Publisher),系統(tǒng)維修員作為訂閱者；當(dāng)系統(tǒng)維修員在維修完成后回傳維修單時，系統(tǒng)維修員作為MQTT協(xié)議中的發(fā)布者(Publisher),系統(tǒng)管理員作為訂閱者。以上兩種情況需保證消息發(fā)送成功，所以選用QoS1等級。

5 B/S架構(gòu)和C/S架構(gòu)的介紹

C/S即Client/Server(客戶機(jī)/服務(wù)器)結(jié)構(gòu)，它是一種網(wǎng)絡(luò)體系結(jié)構(gòu)，客戶端是用戶運(yùn)行應(yīng)用程序的PC端，要依靠服務(wù)器來獲取資源。C/S架構(gòu)通過查詢共享數(shù)據(jù)庫來響應(yīng)客戶端請求，在客戶端和服務(wù)器之間通信一般采用遠(yuǎn)程調(diào)用(RPC)或標(biāo)準(zhǔn)查詢語言(SQL)語句。它允許多用戶通過GUI前端更新到共享數(shù)據(jù)庫， C/S架構(gòu)有以下優(yōu)點：1)響應(yīng)速度快，信息處理能力強(qiáng)。2)用戶界面美觀漂亮，人性化強(qiáng)。3)C/S架構(gòu)的客戶端面向固定的用戶群體，所以對信息的存儲方式更加安全。但是C/S架構(gòu)也有以下缺點：1)需要專門的客戶端安裝，不能快速完成安裝與配置。2)兼容性差，對于不一樣的開發(fā)工具，具有較大的局限性。3)開發(fā)成本高，C/S架構(gòu)的客戶端需要專業(yè)的技術(shù)人員開發(fā)和維修，每修改一次，就要全部更改程序完成升級。

隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，B/S軟件體系結(jié)構(gòu)出現(xiàn)了。B/S(browser/server)架構(gòu)被稱為瀏覽器/服務(wù)器體系結(jié)構(gòu)。這種結(jié)構(gòu)可以使信息分布式處理，有效的降低資源成本，提高系統(tǒng)的設(shè)計性能。B/S架構(gòu)有以下優(yōu)點：1)客戶端不需要維護(hù)，在瀏覽器中就可以使用。2)業(yè)務(wù)擴(kuò)展簡單便利，通過添加網(wǎng)頁就可以添加服務(wù)器功能。3)只需要更改網(wǎng)頁就可以實現(xiàn)對客戶端的維護(hù)，所有用戶的客戶端就隨之更新。但是B/S架構(gòu)也有以下缺點：1)客戶端無法實現(xiàn)個性化的需求。2)客戶端服務(wù)器端的交互是請求-響應(yīng)模式，需要經(jīng)常性的動態(tài)刷新頁面，所以響應(yīng)速度慢。3)安全性弱，在開發(fā)時要花費很大精力在安全性和速度上。

在本系統(tǒng)中，考慮到漏液監(jiān)測實時性要求高的特點，同時使用的用戶固定單一，所以選擇C/S架構(gòu)模式，使用阿里云物聯(lián)網(wǎng)平臺作為C/S架構(gòu)的服務(wù)器端，采用Qt開發(fā)的管理員和維修員的操作軟件作為C/S架構(gòu)的客戶端。

6 阿里云物聯(lián)網(wǎng)云平臺配置

阿里云物聯(lián)網(wǎng)平臺是一個集成了設(shè)備管理、數(shù)據(jù)安全通信和消息訂閱等能力的一體化平臺，為客戶端和設(shè)備端組建了一個安全可靠的通信網(wǎng)絡(luò)[19]。該平臺支持大體量設(shè)備接入，并可將遠(yuǎn)端采集數(shù)據(jù)進(jìn)行上報，由云端服務(wù)器進(jìn)行存儲。同時云端提供大量已封裝完成的API接口，服務(wù)器可直接使用這些接口，將指令下發(fā)至分布式設(shè)備端，并實現(xiàn)對設(shè)備的遠(yuǎn)端調(diào)用及控制能力。

該平臺的使用十分簡單快捷，僅需提前向平臺注冊設(shè)備端ID，端口號，MQTT協(xié)議版本，心跳回包時間間隔，用戶名及密碼等，通過Internet網(wǎng)絡(luò)，使用QT基礎(chǔ)庫中的publish方法發(fā)送消息，received方法接收消息，通過QT獨有的槽信號機(jī)制，也可通過槽函數(shù)來實現(xiàn)對消息的接收和處理操作。

客戶端云設(shè)備和設(shè)備端對應(yīng)的云設(shè)備的注冊分為創(chuàng)建產(chǎn)品、自定義Topic和創(chuàng)建設(shè)備3個步驟。在本系統(tǒng)中，按照所提的3個步驟進(jìn)行注冊操作。

創(chuàng)建產(chǎn)品時，需要指定必要的信息，如：產(chǎn)品名稱(液漏監(jiān)測系統(tǒng))，品類(自定義類型)，設(shè)備鏈接方式(直連)，聯(lián)網(wǎng)方式(以太網(wǎng)/WIFI)，數(shù)據(jù)格式(ICA標(biāo)準(zhǔn)數(shù)據(jù)格式)，認(rèn)證方式(設(shè)備密鑰)。設(shè)置完這些字段后，產(chǎn)品創(chuàng)建即為成功。

自定義Topic時，需要兩個Topic，其一為發(fā)布主題，提供客戶端到設(shè)備端間的啟動/停止交互命令傳輸，其二為訂閱主題，提供設(shè)備端到客戶端的液漏詳細(xì)數(shù)據(jù)傳輸。

創(chuàng)建設(shè)備時，可在該平臺提供的web頁面中，點擊創(chuàng)建設(shè)備頁面，在產(chǎn)品下拉框中選擇液漏監(jiān)測系統(tǒng)，為其命名設(shè)備名稱以及備用名稱。點擊設(shè)備詳情頁面，獲取設(shè)備名(DeviceName)、產(chǎn)品鑒權(quán)(ProductKey)、設(shè)備密鑰(DeviceSecret)，同時可獲取MQTT協(xié)議相關(guān)鏈接參數(shù)：客戶端ID(ClientId)、用戶名(UserName)、密碼(Password)。通過這些參數(shù)的設(shè)置，即可將整個監(jiān)測系統(tǒng)、客戶端全部接入該平臺，點擊連接即可激活設(shè)備，此時，整個系統(tǒng)即可完成全部接入。

7 數(shù)據(jù)庫設(shè)計

為保證液漏信息、狀態(tài)的可復(fù)盤，本系統(tǒng)也設(shè)計使用了數(shù)據(jù)庫作為存儲介質(zhì)，將液漏點位，液漏上報時間，維修完成時間做存儲，以便更清晰的展示年度、月度大盤數(shù)據(jù)，供企業(yè)相關(guān)管理人員進(jìn)行故障分析、定損額度的確定。數(shù)據(jù)庫的設(shè)計如表1所示。

表1 數(shù)據(jù)庫表結(jié)構(gòu)設(shè)計

本系統(tǒng)采用sqlite作為數(shù)據(jù)庫，sqlite的最佳使用場景主要包括以下幾點：1)嵌入式設(shè)備和物聯(lián)網(wǎng)。2)應(yīng)用程序的文件存儲格式。3)大多數(shù)中低流量網(wǎng)站。4)數(shù)據(jù)分析。5)企業(yè)數(shù)據(jù)緩存。6)服務(wù)器端數(shù)據(jù)庫。7)數(shù)據(jù)傳輸格式。8)文件歸檔或數(shù)據(jù)容器。9)替換臨時磁盤文件。本系統(tǒng)中將其用于場景1所使用。

8 MQTT協(xié)議在傳感端的實現(xiàn)

設(shè)備端通過Wi-Fi網(wǎng)絡(luò)連接至服務(wù)器，使用MQTT協(xié)議作為服務(wù)器和Wi-Fi模塊之間的通信協(xié)議。本系統(tǒng)選擇了ESP8266做為Wi-Fi傳輸模塊，ESP8266是一款高性能、超低功耗的異步串行通信接口無線Wi-Fi模塊[20]。 傳感端主函數(shù)流程圖如圖7所示。

9 接收端設(shè)計

Qt針對每一種操作系統(tǒng)的平臺，都有一套對應(yīng)的底層類庫，且接口是完全一致的[21]。因此，在基于Qt框架所開發(fā)的應(yīng)用程序中，在添加相應(yīng)的基礎(chǔ)庫之后，就可以直接編譯運(yùn)行。基于Qt跨平臺的特性，系統(tǒng)的接收端采用Qt開發(fā)，該軟件既可在Windows系統(tǒng)中使用，也可在Android系統(tǒng)中使用，一次開發(fā)即可滿足客戶端在不同平臺的復(fù)用。

通過該接收端，系統(tǒng)管理員可以實現(xiàn)現(xiàn)場或遠(yuǎn)程啟動/停止監(jiān)測、接收液漏消息、發(fā)送維修信息給系統(tǒng)維修員，同時也支持維修狀態(tài)查詢等功能，從而實現(xiàn)對系統(tǒng)的實時監(jiān)測，在方便了工作人員的同時避免了嚴(yán)重后果的發(fā)生。系統(tǒng)管理員界面如圖8所示。

圖8 管理員界面設(shè)計圖

系統(tǒng)維修員通過接收端實現(xiàn)已維修點位、未維修點位的信息查看，未維修點位信息中包含發(fā)生液漏后需要及時維修的點位信息，以及維修完成后需要填寫的維修單，同時在維修員的界面顯示有液漏監(jiān)測設(shè)備的相關(guān)信息。系統(tǒng)維修員界面如圖9所示。

圖9 維修員界面設(shè)計圖

10 MQTT協(xié)議在接收端的實現(xiàn)

在本系統(tǒng)中，接收端和服務(wù)器通信主要包括以下3個部分[22]：

1)建立連接。接收端通過connect控制包來連接MQTT服務(wù)器，服務(wù)器在信息匹配成功后建立連接，同時發(fā)送CONNACK包給接收端表示同意本次連接，建立起接收端和服務(wù)器端的連接通道。

2)主題訂閱。建立連接后，接收端向服務(wù)器端發(fā)送SUBSCRIBE包訂閱關(guān)于液漏的相關(guān)主題報文，當(dāng)傳感端發(fā)送此類主題報文到服務(wù)器端后，服務(wù)器端將此類報文發(fā)送到接收端。

3)消息發(fā)布。建立連接后，接收端向服務(wù)器端發(fā)送對傳感系統(tǒng)的控制命令，服務(wù)器端收到之后下發(fā)給傳感端，傳感端解析命令后執(zhí)行相應(yīng)的操作，最終實現(xiàn)遠(yuǎn)程控制傳感端的功能。

根據(jù)接收端和服務(wù)器通信的過程，設(shè)計接收端的系統(tǒng)架構(gòu)主要包括業(yè)務(wù)層、協(xié)議層、邏輯層、運(yùn)算層和數(shù)據(jù)層。業(yè)務(wù)層的主要功能是顯示、接收和傳遞用戶的反饋，同時提供交互式操作界面[23]。協(xié)議層提供可靠的數(shù)據(jù)傳輸服務(wù)。邏輯層將協(xié)議層傳過來的操作信息進(jìn)行甄別處理，實現(xiàn)具體的業(yè)務(wù)邏輯[24]。運(yùn)算層封裝了數(shù)據(jù)庫，提供了對數(shù)據(jù)庫增刪改查的操作接口[25]。數(shù)據(jù)層用來存儲用戶信息、系統(tǒng)發(fā)生液漏信息、維修情況信息等數(shù)據(jù)[26]。接收端的系統(tǒng)架構(gòu)圖如圖10所示。

圖10 接收端設(shè)計架構(gòu)圖

11 系統(tǒng)測試

11.1 系統(tǒng)管理員操控測試

系統(tǒng)管理員在PC端輸入相應(yīng)的賬號密碼登陸系統(tǒng)后，對傳感端下發(fā)啟動監(jiān)測的命令，命令包經(jīng)MQTT協(xié)議發(fā)送給傳感端，傳感端對命令進(jìn)行相應(yīng)解析后，執(zhí)行啟動監(jiān)測的硬件操作，開始向服務(wù)器不斷傳送液漏監(jiān)測的數(shù)據(jù)包，服務(wù)器將該數(shù)據(jù)包發(fā)送給管理員客戶端，管理員客戶端在收到數(shù)據(jù)包后及時對數(shù)據(jù)進(jìn)行解析，判斷是否發(fā)生液漏，若發(fā)生液漏，則及時將該液漏信息反饋給系統(tǒng)維修員。系統(tǒng)管理員操作系統(tǒng)的時序圖如圖11所示。

圖11 系統(tǒng)管理員操控系統(tǒng)時序圖

在實際測試中，將系統(tǒng)搭建連接好后，給傳感帶的第2條燈帶的第1個點位注水， 10 s左右后，用作測試的客戶端收到液漏的消息，客戶端的界面如圖12所示。當(dāng)停止對該點位注水，管理員客戶端界面不再提示發(fā)生液漏。

圖12 發(fā)生液漏后管理員客戶端界面

11.2 系統(tǒng)維修員操控測試

發(fā)生液漏后，系統(tǒng)會通過短信的方式以1次/min的頻次向系統(tǒng)維修員發(fā)送告警信息，當(dāng)系統(tǒng)維修員回復(fù)“確認(rèn)收到”之后，告警停止。維修完成后，在客戶端的移動端輸入相應(yīng)的賬號密碼登錄在系統(tǒng)上提交維修單據(jù)供系統(tǒng)管理員核驗。系統(tǒng)維修員操作系統(tǒng)的時序圖如圖13所示。

圖13 系統(tǒng)維修員操控系統(tǒng)時序圖

在實際測試中，當(dāng)傳感帶的第2條燈帶中第1個點位發(fā)生液漏時，管理員客戶端將該液漏信息發(fā)送給服務(wù)器后，維修員客戶端登錄系統(tǒng)后，客戶端顯示界面如圖14所示。

圖14 發(fā)生液漏后維修員客戶端界面

12 結(jié)束語

針對實驗室設(shè)計的高分辨率且成本低廉的液漏傳感系統(tǒng)不能實現(xiàn)遠(yuǎn)程監(jiān)測的問題，本文基于輕量級的MQTT協(xié)議，實現(xiàn)了液漏監(jiān)測的遠(yuǎn)程通信，使用Qt的跨平臺特性，開發(fā)了windows和Android系統(tǒng)都可使用的接收端軟件。經(jīng)測試表明，該系統(tǒng)能夠?qū)崿F(xiàn)對液漏監(jiān)測數(shù)據(jù)的高效遠(yuǎn)程采集，提高了液漏的維修實時性，避免了產(chǎn)生更大范圍的液漏所帶來的嚴(yán)重后果，具有較高的應(yīng)用推廣價值。