基于Netty和Marshalling的青飼機工況遠(yuǎn)程監(jiān)測系統(tǒng)研究

毛文華 韓少云 趙 博 王麗麗 汪鳳珠 汪 洋

(1.中國農(nóng)業(yè)機械化科學(xué)研究院土壤植物機器系統(tǒng)技術(shù)國家重點實驗室， 北京 100083；2.中機華豐(北京)科技有限公司， 北京 100083)

0 引言

聯(lián)合收獲機作業(yè)環(huán)境復(fù)雜，連續(xù)作業(yè)時間長，負(fù)荷大，作業(yè)故障率高[1-4]。實時準(zhǔn)確獲取聯(lián)合收獲機主要工作部件信息，對提高農(nóng)機作業(yè)品質(zhì)和經(jīng)濟效益具有重要意義。目前，我國聯(lián)合收獲機多數(shù)產(chǎn)品存在產(chǎn)品同質(zhì)化嚴(yán)重、競爭力不強、信息化水平相對落后、故障率高等問題?！度珖r(nóng)業(yè)機械化發(fā)展第十三個五年規(guī)劃》明確指出，實施“互聯(lián)網(wǎng)+”農(nóng)業(yè)機械化，加快機械化信息化融合，支持在聯(lián)合收獲機、深松機等重點機具上裝配智能信息裝備。提升聯(lián)合收獲機信息收集、智能決策和精準(zhǔn)作業(yè)能力，促進(jìn)我國由農(nóng)機制造大國向強國轉(zhuǎn)變[1]。國外關(guān)于聯(lián)合收獲機的研究和應(yīng)用較早，軟硬件技術(shù)和產(chǎn)品相對成熟，已將人工智能、物聯(lián)網(wǎng)等新技術(shù)運用到聯(lián)合收獲機的開發(fā)中，推出了一些信息化、智能化的產(chǎn)品。如美國John Deere(約翰迪爾)公司研發(fā)的Harvest Smart智能喂入量控制系統(tǒng)與GreenStar2 Harvest Doc產(chǎn)量監(jiān)控系統(tǒng)，實現(xiàn)了聯(lián)合收獲機生產(chǎn)效率最大化，通過農(nóng)業(yè)生產(chǎn)管理系統(tǒng)(AMS)實現(xiàn)高效率、高品質(zhì)的精準(zhǔn)收獲[5-7]。英國福格森公司開發(fā)的FieldStar系統(tǒng)具有強大的系統(tǒng)診斷功能,用戶利用診斷工具實現(xiàn)故障原因的快速查找[8]。

我國對聯(lián)合收獲機的智能化研究起步較晚，文獻(xiàn)[2]指出，信息技術(shù)是提升中國農(nóng)業(yè)機械化水平的核心?，F(xiàn)有研究[2,9-12]大多數(shù)系統(tǒng)是針對單車作業(yè)，其中信息采集、處理、分析都由車載終端完成。隨著全國大型農(nóng)場數(shù)量的增加，車載終端的應(yīng)用規(guī)模不斷擴大，在作業(yè)季，車載終端向服務(wù)器高頻次發(fā)送的數(shù)據(jù)量也急劇增加。在農(nóng)機集群作業(yè)時，數(shù)據(jù)的采樣頻率與車載終端的并發(fā)量遠(yuǎn)高于單機作業(yè)，在這種情況下保證系統(tǒng)性能的可靠性和穩(wěn)定性是急需解決的問題。傳統(tǒng)的數(shù)據(jù)采集服務(wù)系統(tǒng)采用NIO(Non-blocked IO)框架[14-15]實現(xiàn)，NIO線程模型是同步非堵塞，在作業(yè)的間隙，如果大量待機狀態(tài)的車載終端依然和服務(wù)器保持同步數(shù)據(jù)連接狀態(tài)，則會出現(xiàn)epoll(一種I/O多路復(fù)用技術(shù))bug導(dǎo)致 Selector(選擇器)空輪詢[16]，大量的空輪詢將占用寶貴的線程資源，使CPU一直處于高負(fù)荷狀態(tài)。

本文設(shè)計一種基于Netty[17-18]和Marshalling的青飼機工況遠(yuǎn)程監(jiān)測系統(tǒng)，借助網(wǎng)絡(luò)應(yīng)用程序框架Netty的異步非堵塞[19]、事件驅(qū)動等特性，并結(jié)合自定義通信協(xié)議和Marshalling編解碼方法，進(jìn)一步提高監(jiān)測系統(tǒng)的高并發(fā)處理能力和系統(tǒng)穩(wěn)定性。

1 系統(tǒng)設(shè)計與構(gòu)建

1.1 系統(tǒng)總體設(shè)計

青飼機工況遠(yuǎn)程監(jiān)測系統(tǒng)利用CAN總線技術(shù)、Netty的Socket自定義通信協(xié)議、Marshalling編解碼方法，實現(xiàn)多機協(xié)同作業(yè)的工況信息監(jiān)測。系統(tǒng)將物聯(lián)網(wǎng)、互聯(lián)網(wǎng)通信開發(fā)框架(Netty)、第三方的編解碼方式(Marshalling)等技術(shù)進(jìn)行深度融合，將青飼機的數(shù)據(jù)采集、數(shù)據(jù)傳輸、Web應(yīng)用三者剝離開，實現(xiàn)工況數(shù)據(jù)的高頻率采集、可靠性網(wǎng)絡(luò)傳輸和信息的高效管理。對集群節(jié)點的消息進(jìn)行分區(qū)管理，降低節(jié)點間的耦合度，實現(xiàn)信息的高效管理。系統(tǒng)采用4層架構(gòu)，主要包括感知層、網(wǎng)絡(luò)層、中間層和應(yīng)用層，系統(tǒng)總體架構(gòu)如圖1所示。

圖1 系統(tǒng)總體架構(gòu)Fig.1 Overall system architecture

1.2 監(jiān)測系統(tǒng)硬件構(gòu)成

圖2 系統(tǒng)硬件組成Fig.2 Hardware composition of system

系統(tǒng)硬件主要包括傳感器、車載終端、云服務(wù)器3部分，如圖2所示。青飼機上安裝的傳感器類型主要有扭矩、轉(zhuǎn)速、定位和位移等傳感器，扭矩傳感器采集的參數(shù)主要有切碎輥扭矩、割臺扭矩等；轉(zhuǎn)速傳感器采集的參數(shù)主要有上下喂入輥轉(zhuǎn)速、風(fēng)機轉(zhuǎn)速、切碎輥轉(zhuǎn)速、籽粒破碎輥轉(zhuǎn)速、割臺轉(zhuǎn)速、發(fā)動機轉(zhuǎn)速等；位移傳感器采集的參數(shù)主要有上下喂入輥位移、割臺液壓缸伸長量、喂入輥開度等；其他參數(shù)還包括北斗定位模塊采集的經(jīng)度和緯度、發(fā)動機油耗、液壓馬達(dá)壓力、作物含水率、氣象數(shù)據(jù)和田塊信息等。

1.3 監(jiān)測系統(tǒng)軟件構(gòu)成

1.3.1車載終端系統(tǒng)

車載終端系統(tǒng)基于LabVIEW平臺開發(fā)，主要具備青飼機工況信息采集、數(shù)據(jù)預(yù)處理、數(shù)據(jù)傳輸和信息實時顯示等功能。

(1)數(shù)據(jù)采集

數(shù)據(jù)采集模塊的控制器為工業(yè)平板計算機(PPC DL104E型，SSD 64 GB，DDR3 2 GB)，其通過CAN總線實現(xiàn)與各種傳感器之間的數(shù)據(jù)傳輸。顯示器采用8英寸高亮度TFT顯示屏，帶有蜂鳴器，在強光下仍然可以清晰顯示工況數(shù)據(jù)。通過DTU實現(xiàn)與云服務(wù)器之間的無線數(shù)據(jù)傳輸。所采集的青飼機工況數(shù)據(jù)主要有車速、經(jīng)緯度、割臺扭矩、割臺轉(zhuǎn)速、時間、燃油量等29項，系統(tǒng)作業(yè)數(shù)據(jù)如表1所示。

表1 系統(tǒng)作業(yè)數(shù)據(jù)Tab.1 System operation information

(2)數(shù)據(jù)預(yù)處理

青飼機結(jié)構(gòu)復(fù)雜、傳感器多樣，數(shù)據(jù)格式和采樣頻率差異大，所以在一個數(shù)據(jù)采集的周期內(nèi)，有些傳感參數(shù)值浮動較大，且有亂碼的異常情況，需對數(shù)據(jù)采用歸一化、平均值、最大值、字符校正等處理方法進(jìn)行標(biāo)準(zhǔn)化處理。例如：由于青飼機作業(yè)所產(chǎn)生的電磁波有時會影響定位信號，導(dǎo)致定位模塊的經(jīng)緯度產(chǎn)生亂碼，一旦發(fā)現(xiàn)亂碼則采用最近鄰點的正常數(shù)據(jù)作為此次的數(shù)據(jù)。同一個周期T內(nèi)，割臺扭矩取最大值，割臺轉(zhuǎn)速取均值。

(3)數(shù)據(jù)處理與顯示

車載終端對傳感器采集的電壓、電流、頻率等脈沖信號進(jìn)行加工處理，變成統(tǒng)一的數(shù)字格式，并將這29個信號進(jìn)行排序、分析校驗、保存后，通過串口發(fā)送給數(shù)據(jù)傳輸模塊。車載終端安裝在青飼機駕駛室內(nèi)的右側(cè)梁上，如圖3所示。所采集的青飼機實時工況信息在車載終端屏上以圖表的形式顯示，為駕駛員提供實時參考，如圖4所示。

圖3 車載終端的安裝位置Fig.3 Installation location of vehicle terminal

圖4 車載終端的主監(jiān)控圖Fig.4 Master monitor diagram of vehicle terminal

(4)數(shù)據(jù)傳輸

為了保證數(shù)據(jù)無線傳輸?shù)姆€(wěn)定性，本文采用USR-G780型4G LTE DTU作為傳輸工具，在USR-G780 v2.0.1調(diào)試軟件中配置如下參數(shù)：波特率為38 400、連接服務(wù)器的IP地址和端口號、連接類型為TCP長連接。針對長時間沒有數(shù)據(jù)傳輸?shù)耐ㄐ艩顟B(tài)下，形成CPU空輪詢的問題，Netty框架下的心跳機制可以有效解決上述問題，提高CPU的利用率。

1.3.2云端系統(tǒng)

云端系統(tǒng)采用嵌入式操作系統(tǒng)(CentOS7)，并搭建數(shù)據(jù)存儲服務(wù)器系統(tǒng)和業(yè)務(wù)邏輯處理系統(tǒng)。

(1)數(shù)據(jù)庫

青飼機信息存儲的高并發(fā)：青飼機集群作業(yè)時，每臺車載終端都向云服務(wù)器發(fā)送所采集的工況信息，形成高頻率、高并發(fā)的數(shù)據(jù)，云服務(wù)器要進(jìn)行可靠高效的數(shù)據(jù)存儲。因此，系統(tǒng)使用MySQL數(shù)據(jù)庫，并用MyBatis持久層框架對數(shù)據(jù)庫映射，實現(xiàn)車載終端和云服務(wù)器的可靠性通信。

用戶訪問量的高并發(fā)：青飼機集群作業(yè)時，會有大量的用戶訪問服務(wù)器，對業(yè)務(wù)邏輯的處理也會形成高并發(fā)量。因此，使用Redis數(shù)據(jù)庫解決用戶高訪問量問題。Redis采用NoSQL技術(shù)，是一種基于內(nèi)存的數(shù)據(jù)庫，將用戶操作頻率高的數(shù)據(jù)直接存到內(nèi)存中，提高數(shù)據(jù)讀寫性能，有效提升系統(tǒng)對業(yè)務(wù)邏輯數(shù)據(jù)的處理速度。

(2)Web管理系統(tǒng)

云端數(shù)據(jù)分析系統(tǒng)采用基于SpringBoot框架開發(fā)的Web服務(wù)器，包括表現(xiàn)層、業(yè)務(wù)邏輯層、持久層3層架構(gòu)。為了緩解青飼機車載終端數(shù)據(jù)采集系統(tǒng)的壓力，提高數(shù)據(jù)運算的能力，系統(tǒng)將Web應(yīng)用都在云服務(wù)器上完成，服務(wù)器把數(shù)據(jù)處理分析結(jié)果實時推送給客戶端和車載終端，實現(xiàn)車載終端、云端、客戶端的數(shù)據(jù)共享、任務(wù)協(xié)同。

系統(tǒng)后臺管理員通過數(shù)據(jù)庫管理工具(Navicat Premium)直接對云服務(wù)器中的數(shù)據(jù)進(jìn)行操作。開發(fā)者可以管理數(shù)據(jù)，運用機器學(xué)習(xí)、AI等各種方式進(jìn)行數(shù)據(jù)處理和分析。

2 傳輸協(xié)議和編解碼方法設(shè)計

為滿足青飼機車載終端與云端傳輸中對通信服務(wù)器高并發(fā)、高性能、高可靠性的要求，設(shè)計了基于Netty框架的Socket通信協(xié)議，實現(xiàn)車載終端和云服務(wù)器的全雙工數(shù)據(jù)通信。

Codec(編解碼器)有兩個組成部分：Decoder(解碼器)和Encoder(編碼器)。Encoder負(fù)責(zé)把業(yè)務(wù)數(shù)據(jù)轉(zhuǎn)換成字節(jié)碼數(shù)據(jù)，Decoder負(fù)責(zé)把字節(jié)碼數(shù)據(jù)轉(zhuǎn)換成業(yè)務(wù)數(shù)據(jù)。Netty本身帶有Java序列化方法，該方法可以作為Codec使用，但存在無法跨語言、序列化后的體積太大(是二進(jìn)制編碼的5倍多)、序列化性能太低等缺點。而Netty本身提供Codec的同時也支持第三方Codec。因此，針對青飼機工況信息采集的長字符串，對比研究了Java序列化、Protobuf和Marshalling等3種編解碼方法對系統(tǒng)性能的影響，優(yōu)選系統(tǒng)的編解碼方法。

2.1 基于Netty框架的網(wǎng)絡(luò)通信協(xié)議設(shè)計

Netty是一個異步事件驅(qū)動的網(wǎng)絡(luò)應(yīng)用程序框架，支持TCP長連接，支持快速、簡單地開發(fā)協(xié)議服務(wù)器和客戶端等[20]。Netty實現(xiàn)對NIO的封裝，比傳統(tǒng)的NIO具有更好的并發(fā)性。

(1)提高并發(fā)性

Netty是異步非阻塞，先聲明bossGroup和workerGroup兩個線程池：

EventLoopGroup bossGroup = new NioEventLoopGroup();

EventLoopGroup workerGroup = new NioEventLoopGroup();

bossGroup(業(yè)務(wù)線程池)負(fù)責(zé)車載終端與云服務(wù)器之間的連接，用來處理TCP連接請求，workerGroup(I/O線程池)用來處理I/O事件。使用線程池解決了線程阻塞的情況。因為CPU的速度是網(wǎng)絡(luò)速度的1×105倍以上，所以bossGroup中的一個線程就能解決N個客戶端連接服務(wù)器的操作(理論上)。在服務(wù)器滿負(fù)荷的情況下，若并發(fā)量不斷增大，系統(tǒng)容易出現(xiàn)數(shù)據(jù)丟包問題。workerGroup將溢出的數(shù)據(jù)先緩存在消息隊列，再依次I/O處理，可提高通信的并發(fā)性、穩(wěn)定性。

(2)提高I/O速度

Netty通過對Socket讀寫零拷貝模式，使I/O速度得到有效提高。通過DefaultFileRegion方法中的transferTo()函數(shù)，直接使用內(nèi)存ByteBuffer(字節(jié)緩沖區(qū))進(jìn)行收發(fā)操作，避免使用JVM(Java virtual machine，Java虛擬機)的堆內(nèi)存進(jìn)行Socket收發(fā)，也就避免了一次堆內(nèi)存和直接內(nèi)存的拷貝過程。直接在內(nèi)核空間完成數(shù)據(jù)操作，不消耗CPU資源來控制數(shù)據(jù)拷貝。

2.2 Protobuf編解碼

Protobuf全稱Google Protocol Buffers，由谷歌開源而來，是一個靈活、高效、結(jié)構(gòu)化的數(shù)據(jù)序列化框架。它將數(shù)據(jù)結(jié)構(gòu)以.proto文件進(jìn)行描述，通過代碼生成工具可以生成對應(yīng)數(shù)據(jù)結(jié)構(gòu)的POJO對象和Protobuf相關(guān)的方法和屬性，其具有結(jié)構(gòu)化數(shù)據(jù)存儲格式(XML、JSON等)、編解碼性能高效、擴展性好等特點。

2.3 Marshalling編解碼

Marshalling是JBoss(一種Web服務(wù)器)內(nèi)部使用的序列化框架，是Java對象序列化包，對JDK默認(rèn)的序列化框架進(jìn)行了優(yōu)化，但又保持與java.io.Serializable接口的兼容性，同時增加了一些可調(diào)參數(shù)和附加特性，這些參數(shù)和特性需要通過工廠類進(jìn)行配置。

每個新的Channel(通道)，都會創(chuàng)建一個新的ChannelPipeline(鏈)，ChannelPipeline鏈?zhǔn)荂hannelHandler(接口)實例對象的鏈表，用于處理或截獲通道的接收和發(fā)送數(shù)據(jù)。ChannelPipeline鏈?zhǔn)讲僮鞯倪^程如圖5所示，主要負(fù)責(zé)消息的讀取、解碼、處理、編碼、發(fā)送。

圖5 鏈?zhǔn)讲僮髁鞒虉DFig.5 Chain operation flowchart

Marshalling解決了Java本身序列化造成的后字節(jié)碼流太大，以及序列化程度太低等問題。用MarshallingDecoder()方法對一個長字符串?dāng)?shù)據(jù)進(jìn)行解碼，用MarshallingEncoder()方法代替Java序列化的StringDecoder()(字符串解碼器)和StringEncoder()(字符串編碼器)方法。

3 測試與分析

系統(tǒng)測試包括兩部分：編寫測試用例進(jìn)行系統(tǒng)壓力測試和青飼機實際田間作業(yè)測試。

服務(wù)器配置為：1核CPU，2 GB內(nèi)存，CentOS 7.3 64位操作系統(tǒng)，1 Mb/s帶寬，40 GB硬盤容量，青飼機車載終端發(fā)送一個TCP通信的字符串長度為182。

3.1 系統(tǒng)壓力測試

(1)使用for循環(huán)開啟2 000個模擬的車載終端，新的車載終端向服務(wù)器發(fā)起連接請求并發(fā)送數(shù)據(jù)，每個車載終端發(fā)送周期T為500 ms，每個車載終端發(fā)送1 000次，編寫ConnectionCountHandler()函數(shù)統(tǒng)計服務(wù)器連接車載終端的數(shù)量，記錄模擬周期(50 s)內(nèi)最大統(tǒng)計值。進(jìn)行20次試驗取平均值，基于NIO開發(fā)的系統(tǒng)最大青飼機并發(fā)總量為972臺，以Netty框架為底層，分別采用Java序列化、Protobuf和Marshalling編解方法開發(fā)的系統(tǒng)最大青飼機并發(fā)總量分別為1 811、1 811、1 813臺。試驗結(jié)果表明，基于Netty框架下采用不同的編解碼方法，對并發(fā)總量影響較??；基于Netty的系統(tǒng)比基于NIO的系統(tǒng)在并發(fā)總量上提高了0.8倍左右。

(2)為了驗證不同編解碼方法對青飼機工況數(shù)據(jù)I/O速度的影響，模擬50個車載終端，每個車載終端發(fā)送周期為T，每個車載終端發(fā)送1 000次，分別采用Java序列化、Protobuf和 Marshalling 3種編解碼方法進(jìn)行對比試驗，通過每秒TCP的接入量(數(shù)據(jù)庫存儲TCP數(shù)量)來衡量I/O速度。T設(shè)置了5組，分別為600、400、200、100、50 ms。

每組模擬發(fā)送50 000條數(shù)據(jù)，統(tǒng)計數(shù)據(jù)庫中每組保存成功的TCP總數(shù)，試驗結(jié)果如圖6所示。試驗結(jié)果表明，在傳輸頻率不斷增加的情況下，Java序列化和Protobuf數(shù)據(jù)庫接入的TCP總數(shù)基本呈下降趨勢，采用Marshalling方法的青飼機工況監(jiān)測系統(tǒng)在TCP接入量上基本保持穩(wěn)定。

圖6 每組TCP接入總數(shù)Fig.6 Total number of TCP access per group

統(tǒng)計每次試驗中數(shù)據(jù)庫接入的TCP總數(shù)和花費總時間(s)，計算每秒TCP的接入數(shù)，試驗結(jié)果如圖7所示。試驗結(jié)果表明，在發(fā)送頻率不斷增加的情況下，數(shù)據(jù)庫中每秒存儲成功的TCP總數(shù)不斷增大，且傳輸頻率越高，Marshalling方法的優(yōu)勢越明顯。在200、100、50 ms發(fā)送周期下，每秒存儲成功的TCP總數(shù)分別提高了0.4、3.9、1.5倍，數(shù)據(jù)I/O速度也相應(yīng)提高。

圖7 每秒TCP接入數(shù)Fig.7 TCP access per second

3.2 系統(tǒng)田間性能測試

圖8 部分?jǐn)?shù)據(jù)變化情況Fig.8 Partial data change diagram

2019年9月，以五征集團生產(chǎn)的4QZ-350型自走式青飼料收獲機為試驗樣機進(jìn)行青貯飼料收獲試驗。試驗時，車載終端數(shù)據(jù)的發(fā)送周期為400 ms，數(shù)據(jù)字符串長度為182。青飼機連續(xù)作業(yè)15 d，共產(chǎn)生1×106條數(shù)據(jù)。在割臺為中速擋位時，青飼機工作中的車速、割臺外側(cè)轉(zhuǎn)速和扭矩的數(shù)據(jù)分析如圖8所示。由數(shù)據(jù)id 175320～175626所記錄的主要部件參數(shù)數(shù)據(jù)可知，青飼機在田間開始作業(yè)時，割臺先于機器啟動，割臺轉(zhuǎn)速先于車速由零上升至作業(yè)轉(zhuǎn)速4.5 r/s；青飼機在田間正常作業(yè)時，割臺轉(zhuǎn)速和扭矩在一個范圍內(nèi)上下波動；青飼機在田間停止作業(yè)時，先停車再停割臺，車速先于割臺轉(zhuǎn)速降為零。圖8說明青飼機上的傳感器能正常工作，達(dá)到了系統(tǒng)預(yù)期的目標(biāo)。

為了進(jìn)一步驗證青飼機工況遠(yuǎn)程監(jiān)測系統(tǒng)中數(shù)據(jù)的可靠性，用統(tǒng)計學(xué)的方法單獨對參數(shù)中的割臺轉(zhuǎn)速進(jìn)行數(shù)據(jù)驗證分析。割臺高擋位時轉(zhuǎn)速工況如圖9所示。由圖9可知，選擇數(shù)據(jù)id 300846～300930的記錄進(jìn)行分析，運用總體標(biāo)準(zhǔn)偏差方程計算出控制上限和控制下限，工作中轉(zhuǎn)速在穩(wěn)定數(shù)值區(qū)間內(nèi)，也進(jìn)一步驗證了系統(tǒng)采集數(shù)據(jù)的可靠性。

圖9 割臺轉(zhuǎn)速變化曲線Fig.9 Chart of cutting table speed

4 結(jié)論

(1)設(shè)計的青飼機工況遠(yuǎn)程監(jiān)測系統(tǒng)將數(shù)據(jù)傳輸、Web應(yīng)用從車載終端系統(tǒng)中剝離，減輕了車載終端系統(tǒng)對數(shù)據(jù)處理的壓力，增加了系統(tǒng)穩(wěn)定性與可靠性。

(2)通過采用第三方Marshalling編解碼方法和Netty框架對系統(tǒng)進(jìn)行優(yōu)化，解決了在并發(fā)量和數(shù)據(jù)量突然增大時I/O速度降低的問題。發(fā)送周期為500 ms，基于Netty的系統(tǒng)比NIO的系統(tǒng)在并發(fā)量總量上提高了0.8倍；發(fā)送周期為200、100、50 ms，采用Marshalling的系統(tǒng)性能比Java序列化方法的系統(tǒng)在I/O速度上分別提高了0.4、3.9、1.5倍。

(3)青飼機工況遠(yuǎn)程監(jiān)測系統(tǒng)移植了目前互聯(lián)網(wǎng)流行的Netty網(wǎng)絡(luò)通信框架，降低了軟件開發(fā)的耦合度；采用通用接口設(shè)計，增強了系統(tǒng)可移植性。