高鳳強，紀藝娟，陳俊仁

(廈門大學(xué)嘉庚學(xué)院 信息科學(xué)與技術(shù)學(xué)院，福建 漳州 363105)

近年來，對蝦養(yǎng)殖業(yè)發(fā)展迅猛，成為我國水產(chǎn)養(yǎng)殖的支柱性產(chǎn)業(yè)[1－2]。保持水質(zhì)穩(wěn)定和溶解氧充足是對蝦養(yǎng)殖的關(guān)鍵技術(shù)環(huán)節(jié)[3－4]。養(yǎng)殖水體溶解氧含量不足和氣候等因素突變導(dǎo)致的水質(zhì)失衡極易造成對蝦的疾病爆發(fā)和死亡，給養(yǎng)殖戶帶來經(jīng)濟損失[5－8]。因此，采用物聯(lián)網(wǎng)技術(shù)實現(xiàn)養(yǎng)殖設(shè)備、養(yǎng)殖水體的實時自動監(jiān)測對提高對蝦養(yǎng)殖的產(chǎn)量和質(zhì)量具有重要意義[9]。

針對水產(chǎn)養(yǎng)殖過程的監(jiān)測需求，學(xué)者們紛紛開展研究并提出了多種方案。金光[10]、蔡向科[11]、楊旭輝[12]等針對水產(chǎn)養(yǎng)殖水質(zhì)監(jiān)測系統(tǒng)功耗高和節(jié)點能量有限的問題，設(shè)計了低功耗水產(chǎn)養(yǎng)殖水質(zhì)監(jiān)測系統(tǒng)，顯著延長了采集節(jié)點的工作時間。劉敬彪[13]、李卓然[14]等針對傳統(tǒng)水產(chǎn)養(yǎng)殖水質(zhì)監(jiān)測實時性差和維修成本高等問題，設(shè)計了基于ZigBee 無線傳輸網(wǎng)絡(luò)的水質(zhì)監(jiān)測系統(tǒng)，改善了系統(tǒng)的實時性和可靠性。馬從國[15]、李慧[16]、史兵[17]、劉星橋[18]和宦娟[19]等針對規(guī)?；a(chǎn)養(yǎng)殖中有線監(jiān)控存在部署和維護困難的問題，設(shè)計了基于無線傳感網(wǎng)的水產(chǎn)養(yǎng)殖水質(zhì)監(jiān)測系統(tǒng)，實現(xiàn)了多傳感器節(jié)點的快速便捷部署。劉雨青等[20]針對螃蟹養(yǎng)殖基地的監(jiān)控需求，開發(fā)了由水質(zhì)監(jiān)控、氣象監(jiān)控和視頻監(jiān)控等構(gòu)成的螃蟹養(yǎng)殖基地監(jiān)控系統(tǒng)，實現(xiàn)了對養(yǎng)殖基地的本地和遠程智能監(jiān)控。郭一晶等[21]針對傳統(tǒng)對蝦養(yǎng)殖過程中容易出現(xiàn)未及時調(diào)控增氧機而造成重大經(jīng)濟損失的情況，提出了一款基于GSM 的對蝦養(yǎng)殖場增氧機監(jiān)控系統(tǒng)，實現(xiàn)了對養(yǎng)殖場增氧機的實時監(jiān)控、遠程操作和異常報警等功能。這些研究有效促進了我國水產(chǎn)養(yǎng)殖業(yè)的智能化發(fā)展。

但是，上述研究主要針對規(guī)模化基地養(yǎng)殖的水質(zhì)監(jiān)測進行研究設(shè)計，不能很好解決對蝦小散養(yǎng)殖戶的核心需求。實際上，我國對蝦養(yǎng)殖業(yè)主要以中小規(guī)模及粗放型養(yǎng)殖的小散戶養(yǎng)殖為主，而小散戶的養(yǎng)殖管理主要以人工巡塘方式進行，對于養(yǎng)殖設(shè)備、水質(zhì)環(huán)境的監(jiān)測和天氣預(yù)測基本依靠人工經(jīng)驗。同時，對蝦養(yǎng)殖塘基本處在偏遠地區(qū)，現(xiàn)場通信網(wǎng)絡(luò)處于2G、3G 和4G 的不同階段。因此相對其他養(yǎng)殖業(yè)，對蝦養(yǎng)殖戶對于系統(tǒng)的核心需求是實現(xiàn)遠程操作及異常報警、有效降低巡塘強度；同時設(shè)備需支持2G/3G/4G 等網(wǎng)絡(luò)，提升設(shè)備的現(xiàn)場穩(wěn)定性和適應(yīng)性。而前述分析的方案大多解決了設(shè)備遠程控制和水質(zhì)數(shù)據(jù)采集的問題，但沒有涉及設(shè)備工作異常的報警，不能有效降低巡塘的勞動強度。此外，已有研究僅支持單一網(wǎng)絡(luò)模式，不能同時支持2G/3G/4G網(wǎng)絡(luò)，限制了系統(tǒng)的應(yīng)用范圍和進一步推廣。因此，針對對蝦養(yǎng)殖的特殊需求，本文設(shè)計了一套基于物聯(lián)網(wǎng)架構(gòu)的對蝦養(yǎng)殖監(jiān)測預(yù)警系統(tǒng)，實現(xiàn)實時自動的增氧機遠程監(jiān)控、水質(zhì)數(shù)據(jù)監(jiān)測和天氣異常預(yù)警等處理；同時設(shè)計手機APP，方便用戶及時獲取水質(zhì)數(shù)據(jù)、天氣情況和異常報警等信息。本系統(tǒng)可以為養(yǎng)殖戶實現(xiàn)科學(xué)管理，促進養(yǎng)殖過程規(guī)范化，提高養(yǎng)殖的自動化和信息化水平提供技術(shù)支持。

1 系統(tǒng)方案設(shè)計

系統(tǒng)以物聯(lián)網(wǎng)的標(biāo)準(zhǔn)體系進行架構(gòu)，由感知層、傳輸層和應(yīng)用層組成，如圖1 所示。系統(tǒng)實現(xiàn)了對養(yǎng)殖場信息的采集、傳輸、處理以及用戶對信息的交換、通信與控制[22]。

圖1 系統(tǒng)整體框架

(1)多信息感知層

感知層由部署在養(yǎng)殖場的傳輸主站構(gòu)成。該層實現(xiàn)養(yǎng)殖場的溫度、pH 值、溶解氧、電能參數(shù)等數(shù)據(jù)的實時采集和增氧機的控制工作，完成感知層與基站之間的數(shù)據(jù)交互。

(2)雙向傳輸層

傳輸層是感知層和應(yīng)用層數(shù)據(jù)雙向交互的橋梁，具有接入功能和傳輸功能。首先，該層負責(zé)感知層設(shè)備的接入工作，將數(shù)據(jù)可靠地上傳到應(yīng)用層；其次，它又負責(zé)將應(yīng)用層的反饋或指令數(shù)據(jù)下發(fā)到感知層，保障指令和數(shù)據(jù)的上傳下達。

(3)多功能應(yīng)用層

應(yīng)用層是系統(tǒng)與用戶交互的接口，由服務(wù)器、手機用戶端和PC 管理端組成。該層負責(zé)數(shù)據(jù)的分析、存儲和展示，異常報警和用戶控制指令的下發(fā)等。

2 系統(tǒng)設(shè)計

2.1 多信息感知層設(shè)計

感知層的設(shè)計分為硬件設(shè)計和軟件設(shè)計。硬件設(shè)計主要是實現(xiàn)傳輸主站的電路設(shè)計；軟件設(shè)計主要是實現(xiàn)水環(huán)境和電能數(shù)據(jù)的自動采集、增氧機的控制和網(wǎng)絡(luò)數(shù)據(jù)的雙向傳輸。

2.1.1 硬件設(shè)計

感知層的硬件整體結(jié)構(gòu)框圖如圖2 所示。傳輸主站主要由控制模塊、電源模塊，無線通信模塊、RS485 通信模塊和驅(qū)動模塊構(gòu)成。其中主機通過RS485 總線連接水環(huán)境數(shù)據(jù)傳感器和電能傳感器，獲取水體環(huán)境和電能實時數(shù)據(jù)；通過驅(qū)動模塊實現(xiàn)增氧機的控制；通過無線通信模塊來完成數(shù)據(jù)上發(fā)和命令接收。

圖2 感知層系統(tǒng)硬件架構(gòu)圖

(1)基于STM32F103VET6 微處理器的控制模塊

為降低功耗，簡化系統(tǒng)電路，選取了STM32F103VET6 微處理器作為控制模塊的核心[23－24]。其內(nèi)核采用高性能的ARM Cortex－M3 CPU，工作頻率可達72MHz，內(nèi)置高速存儲器，并具備豐富的I/O 口。該模塊具體電路如圖3 所示。

圖3 控制模塊電路圖

(2)基于騏俊ML810 的無線通信模塊

為確保在缺乏4G 網(wǎng)絡(luò)的偏遠地區(qū)也能正常工作，選取了騏俊ML810 無線通信模組進行數(shù)據(jù)通信，實現(xiàn)將感知層和服務(wù)器端數(shù)據(jù)交換。該模組是一款4G 無線通信模組，兼容現(xiàn)存的3G 或2G 網(wǎng)絡(luò)。該模組內(nèi)置豐富的網(wǎng)絡(luò)協(xié)議，并且擁有豐富的硬件接口，工作溫度范圍寬，可滿足物聯(lián)網(wǎng)數(shù)據(jù)傳輸?shù)男枨骩25－27]。為了方便該模組出現(xiàn)故障時的更換和不同項目中的快速應(yīng)用，將ML810 模組封裝成模塊。該模塊再通過預(yù)留的UART 口連接主控，使用AT指令進行絡(luò)連接和數(shù)據(jù)通信，具體電路如圖4 所示。

圖4 無線模塊電路圖

(3)基于MAX485 的通信模塊

為抑制共模干擾，實現(xiàn)收發(fā)器高靈敏度，主站通過RS485 總線與傳感器進行物理連接，實現(xiàn)對水質(zhì)的溫度、pH 值、溶解氧和電能參數(shù)的采集，并選用MAX485 作為RS485 總線的接口芯片。該接口芯片內(nèi)部配備一個驅(qū)動器和一個接收器，外圍電路連接簡單。為了提高網(wǎng)絡(luò)的可靠性，在MAX485 芯片的A 端與B 端之間匹配了120 Ω 的電阻，具體電路如圖5 所示。

圖5 RS485 通信模塊電路圖

(4)基于ULN2003 的驅(qū)動模塊

為達到電流增益高、工作溫度范圍寬和帶負載能力強，主站選用了ULN2003 驅(qū)動芯片，同時，為滿足對多增氧機設(shè)備控制，選用了具備靈敏度高、功耗低、適合高密度安裝等性能的HK4100F－DC24V 繼電器實現(xiàn)對增氧機的啟?？刂?，具體電路如圖6 所示。

圖6 驅(qū)動模塊電路圖

2.1.2 軟件設(shè)計

感知層軟件部分主要實現(xiàn)養(yǎng)殖場水質(zhì)及增氧機工作狀態(tài)監(jiān)控、增氧機工作異常報警，數(shù)據(jù)遠程傳輸?shù)裙δ堋８兄獙拥闹鞒绦蛄鞒虉D如圖7 所示。

圖7 感知層的主程序偽代碼

主站開始運行時，首先進行初始化工作。初始化的內(nèi)容包括初始化串口工作模式、無線通信模塊工作模式、定時器、中斷和標(biāo)志位等。在初始化完成后，主站將開啟無線通信模塊，建立起與服務(wù)器的通信鏈路。然后主站開始定時獲取水質(zhì)數(shù)據(jù)和電能數(shù)據(jù)，并將獲取到的數(shù)據(jù)通過無線通信模塊傳輸至服務(wù)器。服務(wù)器通過算法對數(shù)據(jù)進行分析并呈現(xiàn)給用戶，若數(shù)據(jù)異常，則執(zhí)行應(yīng)急方案并報警和通知用戶。數(shù)據(jù)定時采集和傳輸?shù)臅r間由預(yù)設(shè)的定時器控制。在采集數(shù)據(jù)的同時，主站會通過中斷接收遠程服務(wù)器的控制指令。主站在控制指令解析的基礎(chǔ)上對指令內(nèi)容進行執(zhí)行并將執(zhí)行結(jié)果反饋至服務(wù)器端。

2.1.3 數(shù)據(jù)處理

本系統(tǒng)正常持續(xù)運行過程中，電能和水質(zhì)數(shù)據(jù)均屬于穩(wěn)定、變化緩慢類型的數(shù)據(jù)。但在增氧機的啟動過程中會造成電能數(shù)據(jù)的快速上升和下降。為了避免出現(xiàn)增氧機啟動而誤判增氧機工作狀態(tài)的情況，應(yīng)將增氧機啟動過程的數(shù)據(jù)給予剔除[21]。類似的，水質(zhì)數(shù)據(jù)采集過程中相鄰數(shù)據(jù)點的快速波動屬于異常現(xiàn)象，應(yīng)給予濾除。根據(jù)系統(tǒng)數(shù)據(jù)的特點和濾波需求，本項目采用遞推中值濾波算法。該算法融合了遞推和中位值平均濾波算法的優(yōu)點，可以有效抑制干擾且數(shù)據(jù)平滑度好[28]。

該算法的具體工作代碼如圖8 所示。系統(tǒng)采集的數(shù)據(jù)總共有5 個，其中水質(zhì)數(shù)據(jù)3 個(溫度、pH 值和溶解氧含量)，電能數(shù)據(jù)2 個(電壓和電流)。因此，系統(tǒng)首先開辟5 個長度為12 的固定隊列，分別用于緩存每個數(shù)據(jù)分量最新采集的12 個數(shù)值。在每次采集新的數(shù)據(jù)分量之前，先將隊首的數(shù)據(jù)Xi，0刪除，并將所有數(shù)據(jù)往隊首方向移動1 位，空出隊尾位置Xi，11。其次將采樣到新的數(shù)據(jù)分量放入隊尾Xi，11的位置。然后將每個隊列中的數(shù)據(jù)進行累加得到Si，并找出每個數(shù)據(jù)分量的最大值Xmax，i和最小值Xmin，i。最后，根據(jù)公式1，計算出每個數(shù)據(jù)分量的當(dāng)前值。

圖8 遞推中值濾波算法偽代碼

2.2 傳輸層設(shè)計

傳輸層可以通過2G、3G 或者4G 網(wǎng)絡(luò)建立感知層與服務(wù)器、Internet 網(wǎng)絡(luò)之間的通信。本系統(tǒng)采用TCP/IP 協(xié)議進行遠程無線數(shù)據(jù)傳輸，存在服務(wù)器主動發(fā)起和傳輸主站主動發(fā)起兩種情況。本系統(tǒng)規(guī)定由服務(wù)器主動發(fā)起的數(shù)據(jù)傳輸稱為發(fā)送，接收主站數(shù)據(jù)稱為返回；由傳輸主站主動發(fā)起的數(shù)據(jù)傳輸稱為請求，接收服務(wù)器數(shù)據(jù)稱為響應(yīng)，如圖9 所示。傳輸層設(shè)計的核心內(nèi)容是TCP 通信報文設(shè)計。系統(tǒng)采用的TCP 通信報文格式如圖10 所示。通信報文具體每個字段的格式說明如表1 所示。

圖9 數(shù)據(jù)流向說明圖

圖10 通信報文格式

表1 通信報文格式字段說明表

2.3 應(yīng)用層設(shè)計

應(yīng)用層的軟件設(shè)計是整個系統(tǒng)的核心，包括硬件連接服務(wù)器、業(yè)務(wù)服務(wù)器、PC 管理端和移動端的軟件設(shè)計。應(yīng)用層的服務(wù)器連接框圖如圖1 所示。

硬件連接服務(wù)器提供感知層設(shè)備接入的API，并實現(xiàn)與業(yè)務(wù)服務(wù)器的數(shù)據(jù)通信。該部分軟件的開發(fā)語言為JAVA，開發(fā)工具為Eclipse。同時連接服務(wù)器采用高性能事件驅(qū)動框架Netty 建立與感知層設(shè)備的Socket 連接[29－31]。連接服務(wù)器與業(yè)務(wù)服務(wù)器的連接采用的是HTTP 協(xié)議。

業(yè)務(wù)服務(wù)器實現(xiàn)了感知層數(shù)據(jù)的分析存儲與展示、移動端數(shù)據(jù)訪問與遠程控制API、天氣信息的獲取和設(shè)備故障報警電話的撥打，并實現(xiàn)對感知層設(shè)備管理、用戶信息維護等功能。該部分軟件的開發(fā)語言為PHP，開發(fā)工具為PhpStorm，并采用ThinkPHP5.0 框架進行開發(fā)。

PC 管理端實現(xiàn)了用戶管理、設(shè)備管理、數(shù)據(jù)管理和設(shè)備遠程控制功能。PC 管理端的功能基礎(chǔ)是業(yè)務(wù)服務(wù)器提供的功能接口，且同樣部署在業(yè)務(wù)服務(wù)器。因此該端采用和業(yè)務(wù)服務(wù)器一致的的開發(fā)語言、開發(fā)工具和框架。

移動端實現(xiàn)了水質(zhì)數(shù)據(jù)監(jiān)測、設(shè)備遠程控制、設(shè)備工作監(jiān)控、天氣預(yù)警等功能。該部分軟件采用HTML5 技術(shù)來實現(xiàn)對安卓端和蘋果端的統(tǒng)一支持，并采用WeX5 跨端工具進行開發(fā)。

3 系統(tǒng)測試

本系統(tǒng)于2018 年5 月開始逐步在福建省部分地區(qū)進行應(yīng)用測試，截止到目前已經(jīng)有23 套設(shè)備分布在莆田市、漳州市下轄的龍海市、漳浦縣等地區(qū)使用。部分安裝設(shè)備的現(xiàn)場照片如圖11 所示。以下將分別對系統(tǒng)數(shù)據(jù)傳輸穩(wěn)定性和移動端功能進行測試。

圖11 部分安裝設(shè)備現(xiàn)場圖

3.1 數(shù)據(jù)傳輸穩(wěn)定性

數(shù)據(jù)傳輸過程包括感知層的數(shù)據(jù)獲取，傳輸層的中間傳輸和應(yīng)用層服務(wù)器的接收。感知層的傳輸主站每隔6 s 發(fā)送一次報文到服務(wù)器，內(nèi)容包括水質(zhì)數(shù)據(jù)、電能數(shù)據(jù)和設(shè)備狀態(tài)數(shù)據(jù)。為了保證每條報文都能傳輸?shù)椒?wù)器端，傳輸主站建立了重發(fā)機制。當(dāng)超過2 s 沒有收到服務(wù)器返回的報文時，傳輸主站會重新發(fā)送一次數(shù)據(jù)，每條報文最多重發(fā)3 次。

本次實驗選取了6 臺設(shè)備隨機4 天的數(shù)據(jù)作為樣本進行測試，分析數(shù)據(jù)傳輸?shù)姆€(wěn)定性。根據(jù)數(shù)據(jù)發(fā)送的頻率，理論上每臺設(shè)備一天應(yīng)往服務(wù)器發(fā)送14 400 條報文，由于重發(fā)機制的影響，實際發(fā)送報文數(shù)超過14 400 條。讀取服務(wù)器端和傳輸主站的日志，設(shè)備每天的分析數(shù)據(jù)如圖12 所示，所有設(shè)備的數(shù)據(jù)整體情況如圖13 所示。每臺設(shè)備4 天的數(shù)據(jù)合計如圖14 所示。測試結(jié)果表明，本系統(tǒng)的通信成功率為99.05%，數(shù)據(jù)傳輸穩(wěn)定，滿足實際應(yīng)用需求。

圖12 數(shù)據(jù)丟失率分析

圖13 所有設(shè)備數(shù)據(jù)合計

圖14 單設(shè)備整體數(shù)據(jù)分析

3.2 移動端功能測試

本系統(tǒng)開發(fā)了移動端APP 應(yīng)用，同時支持安卓端和蘋果端。筆者于2019 年12 月22 日和23 日在龍海市浮宮鎮(zhèn)際都村的一個養(yǎng)殖場進行了移動端功能測試，測試現(xiàn)場的環(huán)境如圖11 所示。

(1)設(shè)備遠程控制

該測試的主要目的是驗證能否正常遠程開關(guān)增氧機及識別開啟異常的情況。在驗證遠程控制功能時，任意選擇早中晚各1 h 作為測試時間，在測試時間段內(nèi)每隔2 min 進行1 次遠程開關(guān)，實驗結(jié)果表明90 次的開啟和關(guān)閉操作都正常完成。系統(tǒng)在實現(xiàn)過程中加入對增氧機開啟過程的監(jiān)控，當(dāng)增氧機不能正常啟動時提示開啟失敗。為驗證該功能，將與增氧機連接的漏電保護開關(guān)斷開，再進行一次遠程控制的實驗。實驗結(jié)果表明90 次的開啟均提示“開啟失敗”，可正常識別開啟過程中的異常情況。開啟成功或失敗界面如圖15所示。

圖15 開啟成功和失敗界面圖

(2)設(shè)備工作監(jiān)控

該測試的主要目的是驗證增氧機工作異常時系統(tǒng)是否會撥打報警電話，并在移動端顯示消息提醒。測試實驗任意選擇早晚各2 h 作為測試時段，每隔10 min 進行一次測試，在增氧機正常工作的情況下，通過斷開漏電保護開關(guān)模擬增氧機工作異常，接收到報警電話和提醒消息算一次完整測試。實驗結(jié)果表明12 次的異常模擬均收到了報警電話和提醒信息。移動端的報警記錄如圖16(a)所示。

(3)水質(zhì)數(shù)據(jù)監(jiān)測

該測試的主要目的是驗證數(shù)據(jù)采集和顯示是否正常。在移動端主界面中可以實時顯示各養(yǎng)殖池的數(shù)據(jù)信息，如圖16(b)所示。通過移動端可以選擇任一養(yǎng)殖池實時查看水質(zhì)溶解氧、pH 值和溫度等水質(zhì)數(shù)據(jù)信息。同時系統(tǒng)可設(shè)置各參數(shù)的正常閾值，數(shù)據(jù)超出范圍時會進行異常報警。另外用戶可以查看各水質(zhì)數(shù)據(jù)的歷史數(shù)據(jù)，按照天、月、年的形式查看變化趨勢。

(4)天氣預(yù)警

該測試的主要目的是驗證天氣異常時，系統(tǒng)是否能夠進行異常提醒。系統(tǒng)根據(jù)每個養(yǎng)殖場所處地區(qū)進行設(shè)置，定時從第三方服務(wù)器獲取該地區(qū)的天氣情況。天氣預(yù)警界面中顯示對應(yīng)地區(qū)氣象情況，系統(tǒng)獲取到天氣異常信息后，發(fā)布預(yù)警信息提醒用戶做好防范措施，如圖16(c)所示。

圖16 移動端應(yīng)用界面

4 結(jié)論

針對對蝦養(yǎng)殖過程中對于增氧機監(jiān)控和水質(zhì)監(jiān)測的需求，本文設(shè)計了一套基于物聯(lián)網(wǎng)技術(shù)的對蝦養(yǎng)殖監(jiān)測系統(tǒng)。系統(tǒng)由感知層、傳輸層和應(yīng)用層組成，實現(xiàn)了對增氧機遠程監(jiān)控，水質(zhì)數(shù)據(jù)監(jiān)測與異常報警，天氣異常預(yù)警等功能。系統(tǒng)目前已經(jīng)投入到福建省多處對蝦養(yǎng)殖場進行實際應(yīng)用測試，結(jié)果表明該系統(tǒng)達到了預(yù)期設(shè)計目標(biāo)、運行穩(wěn)定，可有效降低對蝦養(yǎng)殖過程中的人力成本和養(yǎng)殖過程中設(shè)備及天氣異常帶來的風(fēng)險。作為物聯(lián)網(wǎng)技術(shù)在對蝦養(yǎng)殖業(yè)中的示范應(yīng)用，該系統(tǒng)的進一步推廣應(yīng)用可以有效解決傳統(tǒng)對蝦養(yǎng)殖場管理需要人工全天候干預(yù)的問題，為養(yǎng)殖戶實現(xiàn)科學(xué)管理和養(yǎng)殖經(jīng)驗的積累、提高養(yǎng)殖收益提供技術(shù)支持。