基于消息隊(duì)列遙測(cè)傳輸協(xié)議的灌溉系統(tǒng)

康云川, 鐘 靜*, 李若楓

(1.重慶三峽學(xué)院計(jì)算機(jī)科學(xué)與工程學(xué)院，重慶 404120;2.物聯(lián)網(wǎng)與智能控制技術(shù)重慶市工程研究中心，重慶 404120)

近年來(lái)，農(nóng)業(yè)智能化在人類社會(huì)中的地位逐年提高。隨著物聯(lián)網(wǎng)與傳感器技術(shù)的不斷完善，農(nóng)業(yè)智能化的手段越來(lái)越豐富。如今，數(shù)據(jù)實(shí)時(shí)監(jiān)測(cè)與設(shè)施設(shè)備的遠(yuǎn)程控制不管在科學(xué)層面還是經(jīng)濟(jì)層面，對(duì)推動(dòng)農(nóng)業(yè)的發(fā)展都具有重要意義[1]。因此，數(shù)據(jù)傳輸?shù)膶?shí)時(shí)性與安全性尤為重要，特別是對(duì)實(shí)時(shí)性要求較高的農(nóng)作物精準(zhǔn)化灌溉作業(yè)，需要保證消息推送的實(shí)時(shí)性與準(zhǔn)確性、網(wǎng)絡(luò)下發(fā)設(shè)施設(shè)備操作指令的可靠性與安全性。雖然目前有多種消息推送方式，最主要的有Polling 、SMS Push、IP Push等，但都存在一些的問(wèn)題，例如服務(wù)受限、需要收費(fèi)、安全漏洞、個(gè)性化智能推送不足等，其中，網(wǎng)絡(luò)與信息安全問(wèn)題較為明顯，因大多數(shù)系統(tǒng)在互聯(lián)網(wǎng)上透明運(yùn)行，任何人只需知道消息服務(wù)器 IP地址和端口就可以連接運(yùn)行，而消息傳輸過(guò)程中也未進(jìn)行加密與校驗(yàn)，導(dǎo)致面臨消息被竊取、被惡意篡改等威脅[2]。有些系統(tǒng)雖然增加了用戶名、密碼等身份鑒別，但這些信息很容易被暴力猜解，很難保證消息可靠安全的傳輸[3]。并且目前物聯(lián)網(wǎng)硬件控制單元與客戶端的通信方式大多數(shù)是基于超文本傳輸協(xié)議(hyper text transfer protocol，HTTP)，實(shí)現(xiàn)與服務(wù)器中轉(zhuǎn)間接通信，這些協(xié)議在物聯(lián)網(wǎng)應(yīng)用中存在網(wǎng)絡(luò)資源消耗大、傳輸時(shí)延高、數(shù)據(jù)包丟失、穩(wěn)定性低、安全性差等問(wèn)題[4]。

針對(duì)以上問(wèn)題，以作物智能灌溉系統(tǒng)為例，提出一種基于消息隊(duì)列遙測(cè)傳輸(message queuing telemetry transport,MQTT)協(xié)議，并對(duì)消息進(jìn)行加密與校驗(yàn)的設(shè)備聯(lián)網(wǎng)的方案。利用該方案使用NodeMCU、土壤墑情傳感器、無(wú)線網(wǎng)絡(luò)、MQTT代理服務(wù)器和全球廣域網(wǎng)(world wide web,WEB)技術(shù)構(gòu)建一個(gè)高效安全的智能灌溉系統(tǒng)，用戶根據(jù)作物生長(zhǎng)所需含水量，精確控制土壤水分，保證作物生長(zhǎng)，同時(shí)避免灌溉水資源的浪費(fèi)。

1 系統(tǒng)總體設(shè)計(jì)

系統(tǒng)總體結(jié)構(gòu)如圖1所示。目前大多數(shù)物聯(lián)網(wǎng)硬件微控制器采用STM32、51、AVR等傳統(tǒng)單片機(jī)，開(kāi)發(fā)人員需要熟悉單片機(jī)寄存器知識(shí)，還需要熟悉常用的開(kāi)發(fā)語(yǔ)言，由于技術(shù)門檻很高，開(kāi)發(fā)難度大[5]。為了使系統(tǒng)開(kāi)發(fā)便捷、容易、高效，系統(tǒng)硬件主要使用NodeMCU微控制器、DHT11溫濕度傳感器、電容式土壤濕度傳感器、HC-SR04超聲測(cè)距傳感器等，采用MQTT協(xié)議的通信方法來(lái)實(shí)現(xiàn)客戶端與微控制器的交互，消息與應(yīng)用服務(wù)器端基于AliYun平臺(tái)、Mosquitto、LNMP(Linux、Nginx、MySQL、PHP)平臺(tái)構(gòu)建，消息通知軟件采用阿里釘釘客戶端軟件。

圖1 系統(tǒng)總體結(jié)構(gòu)Fig.1 System overall structure

系統(tǒng)主要功能如下。

(1)數(shù)據(jù)采集。傳感器采集空氣溫濕度、作物土壤墑情、灌溉系統(tǒng)蓄水容器水位等數(shù)據(jù)。

(2)消息訂閱與發(fā)布。NodeMCU微控制器向用戶終端發(fā)布消息，獲取所訂閱消息主題的指令，在整個(gè)消息發(fā)布與訂閱傳輸過(guò)程中，將對(duì)消息報(bào)文進(jìn)行加簽與驗(yàn)簽；在消息發(fā)布時(shí)根據(jù)私鑰對(duì)協(xié)議有效載荷負(fù)載內(nèi)容數(shù)據(jù)進(jìn)行加密傳輸。

(3)實(shí)時(shí)監(jiān)測(cè)與控制。灌溉系統(tǒng)蓄水容器水位不足或數(shù)據(jù)出現(xiàn)異常時(shí)，用戶的阿里釘釘作為用戶的消息通知軟件，實(shí)時(shí)接收服務(wù)器推送的警告信息；用戶也可通過(guò)軟件終端對(duì)數(shù)據(jù)進(jìn)行實(shí)時(shí)監(jiān)測(cè)，對(duì)灌溉水泵進(jìn)行遠(yuǎn)程控制。

(4)通信失效保護(hù)。當(dāng)用戶使用終端軟件進(jìn)行作物灌溉時(shí)，服務(wù)器會(huì)自動(dòng)檢測(cè)網(wǎng)絡(luò)狀態(tài)，如果服務(wù)器與網(wǎng)絡(luò)通信中斷，服務(wù)器會(huì)識(shí)別并自動(dòng)發(fā)送停止命令給NodeMCU微控制單元，避免作物一直處于被澆灌狀態(tài)；在系統(tǒng)程序設(shè)置蓄水位最低安全閾值，當(dāng)水位低于某個(gè)閾值時(shí)水泵停止工作，同時(shí)用戶消息通知軟件將會(huì)收到告警信息。

2 MQTT協(xié)議改進(jìn)

MQTT協(xié)議由IBM公司提出，最初用于遠(yuǎn)程醫(yī)療服務(wù)通信，該協(xié)議基于TCP/IP協(xié)議棧，是一種異步通信的輕量級(jí)消息發(fā)布/訂閱傳輸協(xié)議，由于其開(kāi)銷小、時(shí)延低、可靠性高等優(yōu)點(diǎn)，在時(shí)間和空間上，將消息發(fā)送者與接受者分離，可以在不可靠的網(wǎng)絡(luò)環(huán)境中進(jìn)行擴(kuò)展，適用于硬件性能低下的遠(yuǎn)程設(shè)備以及不可靠網(wǎng)絡(luò)的環(huán)境，在物聯(lián)網(wǎng)中得到了廣泛的應(yīng)用[6]。

MQTT協(xié)議的消息報(bào)文最多由3個(gè)部分組成：固定報(bào)頭、可變報(bào)頭和有效載荷。

(1)固定報(bào)頭。MessageType：表示14 種消息類型；Dup Flag：當(dāng)客戶端或服務(wù)端試圖重新傳送 PUBLISH、PUBREL、SUBSCRIBE或UNSUBSCRIBE命令消息時(shí)設(shè)置此標(biāo)志；QoSlevel：服務(wù)質(zhì)量級(jí)別。

(2)可變報(bào)頭。報(bào)頭位于固定報(bào)頭和有效載荷之間，不同報(bào)文的可變報(bào)頭是不同的。可變報(bào)頭主要包括 Protocol name、Protocol version、Clean session、Will 標(biāo)志等頭域。

(3)有效載荷。載荷位于報(bào)文最后一部分，其負(fù)載內(nèi)容有需要發(fā)布的消息，如PUBLISH。

MQTT協(xié)議通過(guò)控制服務(wù)質(zhì)量(quality of service,QoS)等級(jí)來(lái)確定服務(wù)質(zhì)量，消息在傳輸過(guò)程中由QoS的值來(lái)決定安全級(jí)別，但協(xié)議本身并沒(méi)有提供消息加簽、驗(yàn)簽與加密的功能，數(shù)據(jù)以明文傳輸方式[7]。MQTT協(xié)議消息發(fā)布抓包如圖2所示。

圖2 MQTT協(xié)議消息發(fā)布抓包Fig.2 MQTT protocol message release capture

根據(jù)圖2中Wireshark抓包工具可分析出消息的報(bào)文標(biāo)記、類型、長(zhǎng)度、主題、內(nèi)容等信息，并且消息報(bào)文在傳輸過(guò)程中，MQTT協(xié)議已明文方式傳輸數(shù)據(jù)，報(bào)文也未進(jìn)行加簽處理。因此，MQTT協(xié)議在推送數(shù)據(jù)的過(guò)程中可能面臨數(shù)據(jù)被惡意篡改或非法竊取的風(fēng)險(xiǎn)。結(jié)合MQTT通信協(xié)議的報(bào)文特征與數(shù)據(jù)推送的安全要求，提出一種協(xié)議的安全改進(jìn)方案，改進(jìn)后的協(xié)議傳輸流程如圖3所示。

圖3 改進(jìn)后的協(xié)議傳輸流程Fig.3 Improved protocol transport flow

2.1 有效載荷負(fù)載內(nèi)容加密傳輸

消息報(bào)文在傳輸過(guò)程中，有效載荷負(fù)載內(nèi)容存在被非法竊取的風(fēng)險(xiǎn)。加密過(guò)程在數(shù)據(jù)推送前完成，加密時(shí)需要一個(gè)私鑰“PrivateEncryption”來(lái)生成密文，PrivateEncryption是一個(gè)由用戶隨機(jī)生成的32位的字符串，圖4展示了有效載荷負(fù)載內(nèi)容加密與解密過(guò)程，其主要步驟有：第1步，將發(fā)送端傳輸?shù)南?bào)文的載荷內(nèi)容根據(jù)用戶的PrivateEncryption進(jìn)行AES算法加密，以密文方式傳輸；第2步，消息接收端根據(jù)用戶的PrivateEncryption對(duì)載荷內(nèi)容密文解密，還原原始負(fù)載內(nèi)容。

圖4 有效載荷負(fù)載內(nèi)容加密與解密Fig.4 Payload content encryption and decryption

2.2 消息報(bào)文加簽與驗(yàn)簽

加簽的過(guò)程是在MQTT消息報(bào)文形成之后，消息推送之前。加簽時(shí)需要2.1節(jié)內(nèi)容所用的私鑰“PrivateEncryption”來(lái)生成驗(yàn)簽。圖5所示為消息報(bào)文加簽的流程，其主要步驟有：第1步，將需要推送的消息報(bào)文“S”與PrivateEncryption組合，形成新的字符串“SP”；第2步，將新的字符串“SP”進(jìn)行MD5算法加密，生成一個(gè)128位的數(shù)字簽名“MD5(SP)”；第3步，將生成的數(shù)字簽名“MD5(SP)”添加到報(bào)尾，組合為新的消息報(bào)文“SMD5(SP)”；最后修改MQTT報(bào)文的固定頭部分，調(diào)整RemainLength，以適應(yīng)報(bào)文總長(zhǎng)度變化。

圖5 消息報(bào)文加簽Fig.5 Message signature

圖6 消息報(bào)文驗(yàn)簽Fig.6 Message check

圖6所示為消息報(bào)文驗(yàn)簽過(guò)程，主要有以下4個(gè)步驟：第1步，提取消息報(bào)文“SMD5(SP)”的最后128位“MD5(SP)”，作為原始驗(yàn)簽，剩余部分為原始消息報(bào)文“OS”；第2步，將“OS” 與PrivateEncryption組合，形成新的字符串“SP2”；第3步，將新的字符串“SP2”進(jìn)行 MD5 算法加密，生成一個(gè)128位的數(shù)字簽名“MD5(SP2)”；最后判斷“MD5(SP)==MD5(SP2)”是否成立，若成立，則消息合法未被篡改，若不成立，則表明數(shù)據(jù)已被篡改。

3 硬件系統(tǒng)設(shè)計(jì)

系統(tǒng)硬件電路如圖7所示，系統(tǒng)控制單元采用NodeMCU微型開(kāi)發(fā)板，NodeMCU微型開(kāi)發(fā)板是一款開(kāi)源的硬件產(chǎn)品，基于ESP8266 WIFI模塊構(gòu)建，具有WIFI、GPIO、PWM、I2C、1-Wire、ADC等功能[8]。

圖7 系統(tǒng)硬件電路Fig.7 System hardware circuit

NodeMCU其主要特點(diǎn)有：①開(kāi)發(fā)板體積較小，價(jià)格低廉，F(xiàn)lash和RAM的存儲(chǔ)容量較大，具有豐富的外圍接口，輸入電壓為5 V，工作電壓為3.3 V，可采用USB接口或GPIO針腳接口供電[9]。②NodeMCU燒錄程序比傳統(tǒng)的單片機(jī)更簡(jiǎn)單方便，不需要額外的燒錄器，直接通過(guò)USB接口上傳程序[10]。③采用NodeJS語(yǔ)言語(yǔ)法進(jìn)行編寫(xiě)網(wǎng)絡(luò)應(yīng)用事件驅(qū)動(dòng)型API，開(kāi)發(fā)人員不需要熟悉芯片寄存器就可實(shí)現(xiàn)程序開(kāi)發(fā)，這樣一來(lái)編寫(xiě)代碼容易，開(kāi)發(fā)效率更高[11]。本系統(tǒng)NodeMCU主要作用有：獲取傳感器感知的數(shù)據(jù)，并將數(shù)據(jù)進(jìn)行加密處理；與Mosquitto消息服務(wù)器進(jìn)行無(wú)線通信；根據(jù)用戶終端下發(fā)的指令對(duì)灌溉系統(tǒng)的水泵進(jìn)行控制。使用NodeMCU時(shí)，首先需要燒寫(xiě)固件并預(yù)裝Crypto庫(kù)與MQTT庫(kù)，Crypto庫(kù)提供了AES、MD5、SHA1、HASH等加密算法功能，用于實(shí)現(xiàn)傳感器感知數(shù)據(jù)與終端下發(fā)的指令的加解密處理，MQTT庫(kù)則提供與消息服務(wù)器通信功能，硬件系統(tǒng)程序簽名與加密參考代碼如下。

(1)MQTT_Header_Flags="0x30"--[MQTT固定報(bào)頭]

(2)MQTT_Message_Type="0011"

(3)MQTT_Dup_Flag=0

(4)MQTT_QoS_Level=0

(5)MQTT_MSG_Length=45

(6)MQTT_Topic_Length=41

(7)MQTT_Topic_Addr="/IoT_Product/user/temperature"--[MQTT有效載荷負(fù)載內(nèi)容]

(8)MQTT_Message=30--[MQTT有效載荷負(fù)載內(nèi)容]

(9)Str=MQTT_Header_Flags + MQTT_Message_Type

(10)+ MQTT_Dup_Flag + MQTT_QoS_Level + MQTT_MSG_Length

(11)+MQTT_Topic_Length + MQTT_Topic_Addr + MQTT_Message

(12)MD5_SP=crypto.hmac("MD5", Str, PrivateEncryption)--[生成簽名]

(13)SMD5_SP=str + MD5_SP--[報(bào)文加簽]

(14)status, temp, humi, temp_dec, humi_dec=dht.read11(D4)--[返回DHT11狀態(tài)、溫濕度]

(15)temparature_encrypted=crypto.encrypt("AES-ECB", PrivateEncryption, temp)--[數(shù)據(jù)加密]

(16)myMQTT:publish(MQTT_Topic_Addr,temparature_encrypted,0,0,function(client)--[MQTT消息發(fā)布]

第12行代碼中的crypto.hmac函數(shù)用于生成簽名，第15行代碼對(duì)DHT11傳感器溫度數(shù)據(jù)進(jìn)行AES加密，最后一行代碼為MQTT傳輸協(xié)議把數(shù)據(jù)發(fā)布至消息與應(yīng)用服務(wù)器。

空氣溫濕度傳感器采用DHT11，用于環(huán)境的溫度與濕度的測(cè)量，DHT11型數(shù)字溫濕度傳感器是一種含復(fù)合傳感器，體積較小、低功耗，已被校準(zhǔn)過(guò)的數(shù)字信號(hào)輸出溫度、濕度，其專用的數(shù)字模塊采集技術(shù)和溫度、濕度傳感器技術(shù)，確保了傳感器可靠性高，能長(zhǎng)期穩(wěn)定運(yùn)行[12]。

土壤濕度傳感器采用DFROBOT moisture sensor v1.0電容式傳感器，適用于測(cè)量土壤水分，電容式傳感器精確度高，響應(yīng)快，受土壤鹽度影響小，耐電解，耐腐蝕，防水防銹，適用于各種土壤類型，可長(zhǎng)期埋于土壤中[13]。由于土壤傳感器采用模擬信號(hào)輸入，NodeMCU調(diào)用adc.force_init_mode(adc.INIT_ADC)、adc.read(0)函數(shù)獲取土壤電阻值，根據(jù)所測(cè)電阻值計(jì)算出土壤水分。

蓄水容器水位測(cè)量采用HC-SR04超聲測(cè)距傳感器，HC-SR04超聲模塊精確度能達(dá)到0.3 cm，模塊高精度，盲區(qū)小，常應(yīng)用于機(jī)器人避障、物體測(cè)距、液位檢測(cè)、公共安防、停車場(chǎng)檢測(cè)等領(lǐng)域[14]。HC-SR04模塊基本原理：NodeMCU提供10 μs的高電平給模塊的觸發(fā)控制信號(hào)輸入引腳Trig，模塊會(huì)自動(dòng)發(fā)送頻率為40 kHz的8個(gè)方波信號(hào)，同時(shí)，模塊會(huì)自動(dòng)檢測(cè)信號(hào)的返回情況；當(dāng)存在信號(hào)返回時(shí)，通過(guò)Echo引腳端輸出一個(gè)高電平信號(hào)，通過(guò)記錄高電平信號(hào)的持續(xù)時(shí)間的長(zhǎng)短，可判斷出超聲波從發(fā)射到結(jié)束返回的時(shí)間，從而通過(guò)測(cè)試距離公式計(jì)算聲波與相鄰物體的距離S：

S=tECHOc/2

(1)

式(1)中：tECHO為ECHO持續(xù)的時(shí)間；c為聲音的速度。為了防止發(fā)射信號(hào)影響回響信號(hào)，一般測(cè)試周期時(shí)間持續(xù)60 ms以上。超聲波的傳播距離S與溫度密切相關(guān)，因在空中傳播時(shí)，S隨周圍環(huán)境溫度升高而加快，當(dāng)溫度變化顯著時(shí)，需要進(jìn)行溫度補(bǔ)償[15],近似公式為

(2)

式(2)中:331.4表示超聲波在0 ℃下的傳播速度，m/s；T表示當(dāng)前環(huán)境下的實(shí)際溫度。最終用已知容器深度減去HC-SR04測(cè)出的水面距離就可得出容器的當(dāng)前水位。水位測(cè)量參考代碼如下。

(1)Trig_pin=5--[定義Trig針腳]

(2)Echo_pin=6--[定義Echo針腳]

(3)container_heigh=10--[定義蓄水容器深度]

(4)time_start=0--[Echo持續(xù)開(kāi)始時(shí)間初始化]

(5)time_end=0--[Echo持續(xù)結(jié)束時(shí)間初始化]

(6)gpio.mode(Trig_pin,gpio.OUTPUT)--[定義針腳5模式為輸出]

(7)gpio.mode(Echo_pin,gpio.INPUT)--[定針腳6模式為輸入]

(8)gpio.write(Trig_pin,gpio.LOW)--[定義針腳5為低電平]

(9)tmr.delay(2000000)--[延時(shí)2000000 ms]

(10)gpio.write(Trig_pin,gpio.HIGH)--[定義針腳5為高電平]

(11)tmr.delay(60)--[延時(shí)60 ms]

(12)gpio.write(Trig_pin,gpio.LOW)--[定義針腳5為低電平]

(13)while gpio.read(Echo_pin)==0 do--[持續(xù)讀取針腳6數(shù)據(jù)]

(14)time_start=tmr.now()

(15)end

(16)while gpio.read(Echo_pin)==1 do--[持續(xù)讀取針腳6數(shù)據(jù)]

(17)time_end=tmr.now()

(18)end

(19)time_duration=time_end-time_start--[超聲波的結(jié)束時(shí)間與發(fā)射時(shí)間之差]

(20)distance_cm=time_duration / 58--[求出距離]

(21)water_position=container_heigh-distance_cm--[當(dāng)前水位]

4 軟件系統(tǒng)設(shè)計(jì)

4.1 用戶終端軟件

圖8 用戶終端軟件流程Fig.8 User terminal software flow

用戶終端軟件流程如圖8所示，終端軟件基于B/S架構(gòu)開(kāi)發(fā)，采用Linux、PHP與MySQL數(shù)據(jù)庫(kù)，遵循HTML5標(biāo)準(zhǔn)。HTML5作為新一代WEB應(yīng)用標(biāo)準(zhǔn)，其不僅支持PC端，而且適用于各種移動(dòng)終端，采用HTML5進(jìn)行移動(dòng)應(yīng)用程序開(kāi)發(fā)，開(kāi)發(fā)成本低，效率高[16]，并且易于維護(hù)，不但支持傳統(tǒng)多媒體等應(yīng)用功能，還支持離線存儲(chǔ)、圖像繪制、微數(shù)據(jù)與智能表單、用戶交互、語(yǔ)義標(biāo)簽等功能，并具有強(qiáng)大API接口[17]。用戶訪問(wèn)終端軟件時(shí)，需要鑒別身份才能進(jìn)行下一步操作，防止非法用戶越權(quán)訪問(wèn)系統(tǒng)。

4.2 用戶消息通知

采用阿里釘釘軟件向用戶通知灌溉系統(tǒng)蓄水容器水位不足或告警信息。阿里釘釘屬于輕量級(jí)應(yīng)用，具有零門檻、體驗(yàn)好、流量少、無(wú)需多次下載安裝等特點(diǎn)，更易被用戶所接受和廣泛應(yīng)用，同時(shí)，釘釘是免費(fèi)平臺(tái)，基于其基礎(chǔ)功能的應(yīng)用部署，比起購(gòu)買或者自主開(kāi)發(fā)獨(dú)立APP，更節(jié)約成本[18]。釘釘開(kāi)發(fā)平臺(tái)提供其個(gè)人服務(wù)器通信接口，借助其接口，開(kāi)發(fā)人員可以快速實(shí)現(xiàn)消息通知類APP。消息服務(wù)器與釘釘開(kāi)放平臺(tái)通信采用NodeJS語(yǔ)言，通信實(shí)現(xiàn)參考代碼如下。

(1)const accessToken=" "; //釘釘開(kāi)發(fā)平臺(tái)訪問(wèn)令牌

(2)module.exports.handler=function(event, context, callback) {

(3)var eventJson=JSON.parse(event.toString());

(4)const postData=JSON.stringify({"msgtype": "markdown",

(5)//消息類型為支持markdown格式的正文內(nèi)容

(6)"markdown": {"title": "提示信息","text": "####數(shù)據(jù)上報(bào) " +

(7)">水箱水位" + eventJson.items['waterPosition'].value + "CM "+ },"at": {"isAtAll": false}});

(8)const options={

(9)hostname: 'oapi.dingtalk.com', port: 443, //釘釘開(kāi)放平臺(tái)接口地址

(10)path: '/robot/send?access_token='+accessToken, //機(jī)器人消息發(fā)送路徑

(11)method: 'POST', //消息推送方式

(12)headers: {

(13)'Content-Type': 'application/json', //數(shù)據(jù)類型

(14)'Content-Length': Buffer.byteLength(postData)

(15)}

(16)};const req=require('https').request(options, (res)=> {

(17)res.setEncoding('utf8'); res.on('data', (chunk)=> {}); //字符集設(shè)置

(18)res.on('end', ()=> {callback(null, 'success'); });

(19)});req.write(postData); req.end();}; //消息推送

5 實(shí)驗(yàn)結(jié)果與分析

在完成系統(tǒng)設(shè)計(jì)后，對(duì)本系統(tǒng)的功能、性能、安全性進(jìn)行測(cè)試。功能測(cè)試主要測(cè)試用戶移動(dòng)WEB端數(shù)據(jù)實(shí)時(shí)推送、遠(yuǎn)程灌溉功能和阿里釘釘客戶端告警信息推送功能。用戶登錄進(jìn)入移動(dòng)WEB平臺(tái)后，平臺(tái)將實(shí)時(shí)刷新數(shù)據(jù)，當(dāng)環(huán)境溫度過(guò)高，土壤水分低于系統(tǒng)設(shè)置最低閾值，蓄水容器水位低于正常閾值，阿里釘釘客戶端及時(shí)主動(dòng)向用戶推送告警信息。圖9所示的是阿里釘釘告警信息推送與用戶終端界面。

圖9 告警消息推送與用戶終端Fig.9 Alert message push and user WEB

性能測(cè)試主要測(cè)試消息服務(wù)器在高負(fù)載情況下能正常運(yùn)行，運(yùn)用MQTT-JMeter插件測(cè)試服務(wù)器性能，利用用戶插件創(chuàng)建2個(gè)虛擬用戶組，用戶組分別為消息發(fā)布者與消息訂閱者進(jìn)行發(fā)布、訂閱操作，虛擬用戶數(shù)量分別為100、200、300、500、600、800、1 000，消息數(shù)量分別為100、300、500、700，每隔1 s發(fā)送一條32字節(jié)的隨機(jī)串，附加時(shí)間戳，時(shí)間戳用于數(shù)據(jù)傳輸時(shí)延計(jì)算，循環(huán)10次結(jié)束，發(fā)送時(shí)間和接收時(shí)間結(jié)果如表1所示。

表1 消息推送性能測(cè)試結(jié)果Table 1 Message push performance test results

從表1可以看出，在消息推送數(shù)量不變的情況下，增加用戶數(shù)，則消息推送時(shí)間與接收時(shí)間會(huì)隨著用戶數(shù)的增加而延長(zhǎng)，但延長(zhǎng)的趨勢(shì)并不太明顯，用戶數(shù)量的增加對(duì)灌溉系統(tǒng)的性能影響不大；隨著消息發(fā)送數(shù)量的增多，在用戶數(shù)量不變情況下，消息推送時(shí)間和接收時(shí)間增幅較大，消息推送時(shí)間明顯增加，可看出消息的推送數(shù)量對(duì)系統(tǒng)性能影響較大。

MQTT與HTTP性能對(duì)比如圖10所示，利用測(cè)試插件分別對(duì)MQTT、HTTP協(xié)議進(jìn)行了發(fā)送與接收測(cè)試，消息數(shù)量為500，測(cè)試用戶數(shù)為1 000，測(cè)試表明兩協(xié)議用戶數(shù)量在500以內(nèi)時(shí)，數(shù)據(jù)接收時(shí)的性能差異不明顯，但數(shù)據(jù)在發(fā)送時(shí)性能差異較大，MQTT協(xié)議性能明顯比HTTP協(xié)議更具有優(yōu)勢(shì)，總體上MQTT協(xié)議性能比HTTP協(xié)議更好。

圖10 性能測(cè)試對(duì)比結(jié)果Fig.10 Performance tests comparison

從總體上分析，系統(tǒng)傳輸時(shí)延低，并且性能穩(wěn)定良好，用戶能實(shí)時(shí)無(wú)縫獲取信息，并且能遠(yuǎn)程精確執(zhí)行灌溉指令。安全性測(cè)試主要測(cè)試NodeMCU微控制單元、用戶終端與MQTT消息服務(wù)器推送數(shù)據(jù)過(guò)程中，消息報(bào)文是否存在被非法篡改、竊取風(fēng)險(xiǎn)。利用Wireshark抓包軟件分析消息報(bào)文加簽，數(shù)據(jù)加密，如圖11所示。

圖11 消息報(bào)文加簽與數(shù)據(jù)加密Fig.11 Message signature and data encryption

從圖11可看出，消息報(bào)文Msg-Header在傳輸過(guò)程中已被加簽，同時(shí)，推送的數(shù)據(jù)Temperature也進(jìn)行了加密，因此，消息服務(wù)器只需進(jìn)行驗(yàn)證簽名就可防止報(bào)文在傳輸中被非法篡改，并且消息接收端利用私鑰就能還原推送過(guò)來(lái)的數(shù)據(jù)，防止數(shù)據(jù)被非法竊取，從而保證系統(tǒng)安全運(yùn)行。

6 結(jié)論

提出一種基于消息隊(duì)列遙測(cè)傳輸?shù)墓喔认到y(tǒng)，討論了利用MD5算法對(duì)MQTT傳輸協(xié)議的消息報(bào)文進(jìn)行了加簽，利用AES算法對(duì)感知數(shù)據(jù)進(jìn)行了加密，避免了數(shù)據(jù)在推送過(guò)程中被非法篡改與竊取的安全風(fēng)險(xiǎn)，從而提高了系統(tǒng)的安全性與可靠性。最后通過(guò)實(shí)驗(yàn)對(duì)系統(tǒng)的功能、性能、安全3個(gè)指標(biāo)進(jìn)行了分析，實(shí)驗(yàn)結(jié)果表明：本系統(tǒng)比已有的研究成果性能更加高效穩(wěn)定、安全、實(shí)用，更能實(shí)時(shí)無(wú)縫推送數(shù)據(jù)，并且更能遠(yuǎn)程精確執(zhí)行灌溉指令；用戶端移動(dòng)WEB平臺(tái)能長(zhǎng)期穩(wěn)定運(yùn)行，能實(shí)時(shí)刷新數(shù)據(jù)，能遠(yuǎn)程精確控制灌溉水泵；阿里釘釘APP能向用戶及時(shí)推送異常數(shù)據(jù)，運(yùn)行效果良好；系統(tǒng)的穩(wěn)定性與安全性較高，為智慧農(nóng)業(yè)提供了一種安全可靠的解決方案。