基于Netty和Marshalling的青饲机工况远程监测系统研究

毛文华 韩少云 赵 博 王丽丽 汪凤珠 汪 洋

(1.中国农业机械化科学研究院土壤植物机器系统技术国家重点实验室， 北京 100083；2.中机华丰(北京)科技有限公司， 北京 100083)

0 引言

联合收获机作业环境复杂，连续作业时间长，负荷大，作业故障率高[1-4]。实时准确获取联合收获机主要工作部件信息，对提高农机作业品质和经济效益具有重要意义。目前，我国联合收获机多数产品存在产品同质化严重、竞争力不强、信息化水平相对落后、故障率高等问题。《全国农业机械化发展第十三个五年规划》明确指出，实施“互联网+”农业机械化，加快机械化信息化融合，支持在联合收获机、深松机等重点机具上装配智能信息装备。提升联合收获机信息收集、智能决策和精准作业能力，促进我国由农机制造大国向强国转变[1]。国外关于联合收获机的研究和应用较早，软硬件技术和产品相对成熟，已将人工智能、物联网等新技术运用到联合收获机的开发中，推出了一些信息化、智能化的产品。如美国John Deere(约翰迪尔)公司研发的Harvest Smart智能喂入量控制系统与GreenStar2 Harvest Doc产量监控系统，实现了联合收获机生产效率最大化，通过农业生产管理系统(AMS)实现高效率、高品质的精准收获[5-7]。英国福格森公司开发的FieldStar系统具有强大的系统诊断功能,用户利用诊断工具实现故障原因的快速查找[8]。

我国对联合收获机的智能化研究起步较晚，文献[2]指出，信息技术是提升中国农业机械化水平的核心。现有研究[2,9-12]大多数系统是针对单车作业，其中信息采集、处理、分析都由车载终端完成。随着全国大型农场数量的增加，车载终端的应用规模不断扩大，在作业季，车载终端向服务器高频次发送的数据量也急剧增加。在农机集群作业时，数据的采样频率与车载终端的并发量远高于单机作业，在这种情况下保证系统性能的可靠性和稳定性是急需解决的问题。传统的数据采集服务系统采用NIO(Non-blocked IO)框架[14-15]实现，NIO线程模型是同步非堵塞，在作业的间隙，如果大量待机状态的车载终端依然和服务器保持同步数据连接状态，则会出现epoll(一种I/O多路复用技术)bug导致 Selector(选择器)空轮询[16]，大量的空轮询将占用宝贵的线程资源，使CPU一直处于高负荷状态。

本文设计一种基于Netty[17-18]和Marshalling的青饲机工况远程监测系统，借助网络应用程序框架Netty的异步非堵塞[19]、事件驱动等特性，并结合自定义通信协议和Marshalling编解码方法，进一步提高监测系统的高并发处理能力和系统稳定性。

1 系统设计与构建

1.1 系统总体设计

青饲机工况远程监测系统利用CAN总线技术、Netty的Socket自定义通信协议、Marshalling编解码方法，实现多机协同作业的工况信息监测。系统将物联网、互联网通信开发框架(Netty)、第三方的编解码方式(Marshalling)等技术进行深度融合，将青饲机的数据采集、数据传输、Web应用三者剥离开，实现工况数据的高频率采集、可靠性网络传输和信息的高效管理。对集群节点的消息进行分区管理，降低节点间的耦合度，实现信息的高效管理。系统采用4层架构，主要包括感知层、网络层、中间层和应用层，系统总体架构如图1所示。

图1 系统总体架构Fig.1 Overall system architecture

1.2 监测系统硬件构成

图2 系统硬件组成Fig.2 Hardware composition of system

系统硬件主要包括传感器、车载终端、云服务器3部分，如图2所示。青饲机上安装的传感器类型主要有扭矩、转速、定位和位移等传感器，扭矩传感器采集的参数主要有切碎辊扭矩、割台扭矩等；转速传感器采集的参数主要有上下喂入辊转速、风机转速、切碎辊转速、籽粒破碎辊转速、割台转速、发动机转速等；位移传感器采集的参数主要有上下喂入辊位移、割台液压缸伸长量、喂入辊开度等；其他参数还包括北斗定位模块采集的经度和纬度、发动机油耗、液压马达压力、作物含水率、气象数据和田块信息等。

1.3 监测系统软件构成

1.3.1车载终端系统

车载终端系统基于LabVIEW平台开发，主要具备青饲机工况信息采集、数据预处理、数据传输和信息实时显示等功能。

(1)数据采集

数据采集模块的控制器为工业平板计算机(PPC DL104E型，SSD 64 GB，DDR3 2 GB)，其通过CAN总线实现与各种传感器之间的数据传输。显示器采用8英寸高亮度TFT显示屏，带有蜂鸣器，在强光下仍然可以清晰显示工况数据。通过DTU实现与云服务器之间的无线数据传输。所采集的青饲机工况数据主要有车速、经纬度、割台扭矩、割台转速、时间、燃油量等29项，系统作业数据如表1所示。

表1 系统作业数据Tab.1 System operation information

(2)数据预处理

青饲机结构复杂、传感器多样，数据格式和采样频率差异大，所以在一个数据采集的周期内，有些传感参数值浮动较大，且有乱码的异常情况，需对数据采用归一化、平均值、最大值、字符校正等处理方法进行标准化处理。例如：由于青饲机作业所产生的电磁波有时会影响定位信号，导致定位模块的经纬度产生乱码，一旦发现乱码则采用最近邻点的正常数据作为此次的数据。同一个周期T内，割台扭矩取最大值，割台转速取均值。

(3)数据处理与显示

车载终端对传感器采集的电压、电流、频率等脉冲信号进行加工处理，变成统一的数字格式，并将这29个信号进行排序、分析校验、保存后，通过串口发送给数据传输模块。车载终端安装在青饲机驾驶室内的右侧梁上，如图3所示。所采集的青饲机实时工况信息在车载终端屏上以图表的形式显示，为驾驶员提供实时参考，如图4所示。

图3 车载终端的安装位置Fig.3 Installation location of vehicle terminal

图4 车载终端的主监控图Fig.4 Master monitor diagram of vehicle terminal

(4)数据传输

为了保证数据无线传输的稳定性，本文采用USR-G780型4G LTE DTU作为传输工具，在USR-G780 v2.0.1调试软件中配置如下参数：波特率为38 400、连接服务器的IP地址和端口号、连接类型为TCP长连接。针对长时间没有数据传输的通信状态下，形成CPU空轮询的问题，Netty框架下的心跳机制可以有效解决上述问题，提高CPU的利用率。

1.3.2云端系统

云端系统采用嵌入式操作系统(CentOS7)，并搭建数据存储服务器系统和业务逻辑处理系统。

(1)数据库

青饲机信息存储的高并发：青饲机集群作业时，每台车载终端都向云服务器发送所采集的工况信息，形成高频率、高并发的数据，云服务器要进行可靠高效的数据存储。因此，系统使用MySQL数据库，并用MyBatis持久层框架对数据库映射，实现车载终端和云服务器的可靠性通信。

用户访问量的高并发：青饲机集群作业时，会有大量的用户访问服务器，对业务逻辑的处理也会形成高并发量。因此，使用Redis数据库解决用户高访问量问题。Redis采用NoSQL技术，是一种基于内存的数据库，将用户操作频率高的数据直接存到内存中，提高数据读写性能，有效提升系统对业务逻辑数据的处理速度。

(2)Web管理系统

云端数据分析系统采用基于SpringBoot框架开发的Web服务器，包括表现层、业务逻辑层、持久层3层架构。为了缓解青饲机车载终端数据采集系统的压力，提高数据运算的能力，系统将Web应用都在云服务器上完成，服务器把数据处理分析结果实时推送给客户端和车载终端，实现车载终端、云端、客户端的数据共享、任务协同。

系统后台管理员通过数据库管理工具(Navicat Premium)直接对云服务器中的数据进行操作。开发者可以管理数据，运用机器学习、AI等各种方式进行数据处理和分析。

2 传输协议和编解码方法设计

为满足青饲机车载终端与云端传输中对通信服务器高并发、高性能、高可靠性的要求，设计了基于Netty框架的Socket通信协议，实现车载终端和云服务器的全双工数据通信。

Codec(编解码器)有两个组成部分：Decoder(解码器)和Encoder(编码器)。Encoder负责把业务数据转换成字节码数据，Decoder负责把字节码数据转换成业务数据。Netty本身带有Java序列化方法，该方法可以作为Codec使用，但存在无法跨语言、序列化后的体积太大(是二进制编码的5倍多)、序列化性能太低等缺点。而Netty本身提供Codec的同时也支持第三方Codec。因此，针对青饲机工况信息采集的长字符串，对比研究了Java序列化、Protobuf和Marshalling等3种编解码方法对系统性能的影响，优选系统的编解码方法。

2.1 基于Netty框架的网络通信协议设计

Netty是一个异步事件驱动的网络应用程序框架，支持TCP长连接，支持快速、简单地开发协议服务器和客户端等[20]。Netty实现对NIO的封装，比传统的NIO具有更好的并发性。

(1)提高并发性

Netty是异步非阻塞，先声明bossGroup和workerGroup两个线程池：

EventLoopGroup bossGroup = new NioEventLoopGroup();

EventLoopGroup workerGroup = new NioEventLoopGroup();

bossGroup(业务线程池)负责车载终端与云服务器之间的连接，用来处理TCP连接请求，workerGroup(I/O线程池)用来处理I/O事件。使用线程池解决了线程阻塞的情况。因为CPU的速度是网络速度的1×105倍以上，所以bossGroup中的一个线程就能解决N个客户端连接服务器的操作(理论上)。在服务器满负荷的情况下，若并发量不断增大，系统容易出现数据丢包问题。workerGroup将溢出的数据先缓存在消息队列，再依次I/O处理，可提高通信的并发性、稳定性。

(2)提高I/O速度

Netty通过对Socket读写零拷贝模式，使I/O速度得到有效提高。通过DefaultFileRegion方法中的transferTo()函数，直接使用内存ByteBuffer(字节缓冲区)进行收发操作，避免使用JVM(Java virtual machine，Java虚拟机)的堆内存进行Socket收发，也就避免了一次堆内存和直接内存的拷贝过程。直接在内核空间完成数据操作，不消耗CPU资源来控制数据拷贝。

2.2 Protobuf编解码

Protobuf全称Google Protocol Buffers，由谷歌开源而来，是一个灵活、高效、结构化的数据序列化框架。它将数据结构以.proto文件进行描述，通过代码生成工具可以生成对应数据结构的POJO对象和Protobuf相关的方法和属性，其具有结构化数据存储格式(XML、JSON等)、编解码性能高效、扩展性好等特点。

2.3 Marshalling编解码

Marshalling是JBoss(一种Web服务器)内部使用的序列化框架，是Java对象序列化包，对JDK默认的序列化框架进行了优化，但又保持与java.io.Serializable接口的兼容性，同时增加了一些可调参数和附加特性，这些参数和特性需要通过工厂类进行配置。

每个新的Channel(通道)，都会创建一个新的ChannelPipeline(链)，ChannelPipeline链是ChannelHandler(接口)实例对象的链表，用于处理或截获通道的接收和发送数据。ChannelPipeline链式操作的过程如图5所示，主要负责消息的读取、解码、处理、编码、发送。

图5 链式操作流程图Fig.5 Chain operation flowchart

Marshalling解决了Java本身序列化造成的后字节码流太大，以及序列化程度太低等问题。用MarshallingDecoder()方法对一个长字符串数据进行解码，用MarshallingEncoder()方法代替Java序列化的StringDecoder()(字符串解码器)和StringEncoder()(字符串编码器)方法。

3 测试与分析

系统测试包括两部分：编写测试用例进行系统压力测试和青饲机实际田间作业测试。

服务器配置为：1核CPU，2 GB内存，CentOS 7.3 64位操作系统，1 Mb/s带宽，40 GB硬盘容量，青饲机车载终端发送一个TCP通信的字符串长度为182。

3.1 系统压力测试

(1)使用for循环开启2 000个模拟的车载终端，新的车载终端向服务器发起连接请求并发送数据，每个车载终端发送周期T为500 ms，每个车载终端发送1 000次，编写ConnectionCountHandler()函数统计服务器连接车载终端的数量，记录模拟周期(50 s)内最大统计值。进行20次试验取平均值，基于NIO开发的系统最大青饲机并发总量为972台，以Netty框架为底层，分别采用Java序列化、Protobuf和Marshalling编解方法开发的系统最大青饲机并发总量分别为1 811、1 811、1 813台。试验结果表明，基于Netty框架下采用不同的编解码方法，对并发总量影响较小；基于Netty的系统比基于NIO的系统在并发总量上提高了0.8倍左右。

(2)为了验证不同编解码方法对青饲机工况数据I/O速度的影响，模拟50个车载终端，每个车载终端发送周期为T，每个车载终端发送1 000次，分别采用Java序列化、Protobuf和 Marshalling 3种编解码方法进行对比试验，通过每秒TCP的接入量(数据库存储TCP数量)来衡量I/O速度。T设置了5组，分别为600、400、200、100、50 ms。

每组模拟发送50 000条数据，统计数据库中每组保存成功的TCP总数，试验结果如图6所示。试验结果表明，在传输频率不断增加的情况下，Java序列化和Protobuf数据库接入的TCP总数基本呈下降趋势，采用Marshalling方法的青饲机工况监测系统在TCP接入量上基本保持稳定。

图6 每组TCP接入总数Fig.6 Total number of TCP access per group

统计每次试验中数据库接入的TCP总数和花费总时间(s)，计算每秒TCP的接入数，试验结果如图7所示。试验结果表明，在发送频率不断增加的情况下，数据库中每秒存储成功的TCP总数不断增大，且传输频率越高，Marshalling方法的优势越明显。在200、100、50 ms发送周期下，每秒存储成功的TCP总数分别提高了0.4、3.9、1.5倍，数据I/O速度也相应提高。

图7 每秒TCP接入数Fig.7 TCP access per second

3.2 系统田间性能测试

图8 部分数据变化情况Fig.8 Partial data change diagram

2019年9月，以五征集团生产的4QZ-350型自走式青饲料收获机为试验样机进行青贮饲料收获试验。试验时，车载终端数据的发送周期为400 ms，数据字符串长度为182。青饲机连续作业15 d，共产生1×106条数据。在割台为中速挡位时，青饲机工作中的车速、割台外侧转速和扭矩的数据分析如图8所示。由数据id 175320～175626所记录的主要部件参数数据可知，青饲机在田间开始作业时，割台先于机器启动，割台转速先于车速由零上升至作业转速4.5 r/s；青饲机在田间正常作业时，割台转速和扭矩在一个范围内上下波动；青饲机在田间停止作业时，先停车再停割台，车速先于割台转速降为零。图8说明青饲机上的传感器能正常工作，达到了系统预期的目标。

为了进一步验证青饲机工况远程监测系统中数据的可靠性，用统计学的方法单独对参数中的割台转速进行数据验证分析。割台高挡位时转速工况如图9所示。由图9可知，选择数据id 300846～300930的记录进行分析，运用总体标准偏差方程计算出控制上限和控制下限，工作中转速在稳定数值区间内，也进一步验证了系统采集数据的可靠性。

图9 割台转速变化曲线Fig.9 Chart of cutting table speed

4 结论

(1)设计的青饲机工况远程监测系统将数据传输、Web应用从车载终端系统中剥离，减轻了车载终端系统对数据处理的压力，增加了系统稳定性与可靠性。

(2)通过采用第三方Marshalling编解码方法和Netty框架对系统进行优化，解决了在并发量和数据量突然增大时I/O速度降低的问题。发送周期为500 ms，基于Netty的系统比NIO的系统在并发量总量上提高了0.8倍；发送周期为200、100、50 ms，采用Marshalling的系统性能比Java序列化方法的系统在I/O速度上分别提高了0.4、3.9、1.5倍。

(3)青饲机工况远程监测系统移植了目前互联网流行的Netty网络通信框架，降低了软件开发的耦合度；采用通用接口设计，增强了系统可移植性。