5G云化工业自动化监控系统的设计与实现

贾子翔 翟春辉 贾 捷

中国联通研究院 北京 100176

引言

随着5G、大数据以及边缘计算的蓬勃发展，在“中国制造2025”及德国“工业4.0”政策、行业标杆的驱动指引下[1]，越来越多的传统工业企业渴求在智能制造领域寻求突破。在对传统工业进行互联网化升级改造的过程中，5G“低时延、高可靠、大带宽”的性能满足了其对于无线高速网络连接、低时延计算和高数据安全的需求，充分保障了设备数据从OT向IT的实时传输、快速计算以及敏捷响应的能力。移动边缘计算(MEC)[2]的兴起，使得在设备侧部署具备存储计算能力的小型服务器成为现实，可以减少工业数据在不同节点传输的跳数，大幅缩短了设备数据从采集到展现的时延，进一步保障了工业监控的实时性需求。

“云化”即依托边缘云的应用承载能力，实现软件定义的控制系统，本文将介绍如何依托云化实时工业控制系统实现工业自动化监控。

1 工业监控系统现状

工业智能化监控系统与网络通信的发展紧密相连，早期出现的此类工业应用所需的设备、传感器以及服务器，采用有线网络方式连接，存在灵活性差、造价昂贵、不易扩展、响应时延大以及监控数据容易丢失等缺陷。

随着5G的商用和普及以及边缘计算技术的进步和发展，为工业设备数据的远程监控提供了发展前提和技术环境，很快远程设备数据监控系统被应用在了各行各业中。典型的设备监控系统基于物联网模型构建，物联网网络通常不是一个单纯的IP网络，它常常涉及多个异种网络的集成，从而进行业务通信和数据交换。通常工业监控应用的系统架构一般包括测控设备(传感器、测控仪、摄像头等)、工控设备、智能网关、应用服务端及客户端，测控设备作为设备数据的采集端，采集到的工业OT数据通过PLC(Programmable Logic Controller，可编程逻辑控制器，工业控制的核心)控制传输至工业网关，通过智能网关的协议解析，将OT数据转化为监控应用可用的IT数据，经过网络传输至应用服务端进行数据解析和数据持久化，在客户端经过图表渲染呈现给应用使用者。现阶段OT侧工控设备普遍采用传统PLC，需要专门的编程环境，且编程难度高，使用困难，且不同型号的控制器对应不同的协议，需要额外适配专用的网关，灵活性及扩展性较差。

2 工业自动化监控系统的设计

工业自动化监控系统承载了对工业设备数据实时监控、统计分析的基本需求，PLC作为OT侧控制核心，满足设备联网、数据采集、云端控制等需求，通过云化网关实现协议解析、数据上传、指令下达，实现对工业设备的自动化监控。本节将从技术选型和系统架构等方面介绍如何设计并构建该系统。

2.1 关键技术—云化PLC

PLC是一种具有微处理器的用于自动化控制的数字运算控制器，可以针对工业设备工作产生的数据，通过循环扫描，采用集中采样、集中输出的工作方式，控制数据经以太网连接或者外部访问协议(OPC-UA、MODBUS等)的方式向外传输。

云化PLC[3]即软件定义的PLC，通过软件配置实现控制设备行为、参数配置及组态，以开放平台的形式供用户使用，可灵活适配不同的供应商。云化PLC包括软件定义的控制系统、桌面系统、组态以及编程套件等，集成了传统工控机和PLC的全部功能。与传统PLC相比，云化PLC优势明显，如表1所示。

表1 云化PLC与传统PLC对比

云化PLC选用远程IO模块，实现IO系统配置的模块化，利用总线通信的方式，大大减少了现场复杂的走线。云化PLC还支持内置集成云化网关软件，支持丰富的工业协议，解决了因工业现场通信协议多样化、不统一带来的数据采集困难等问题。此外，由软件定义的云化PLC可灵活编排和扩展，面向复杂多样的应用场景，可通过软件升级支持工控系统的柔性化和灵活性配置，无需因需求升级导致大规模更换控制器，实现降本增效。

2.2 关键技术-MQTT

MQTT是IBM推出的一个极其轻量级的发布/订阅消息传输协议，构建于TCP/IP之上，提供有序、可靠的数据传输机制。

由于物联网设备普遍性能低下，且网络连接质量也不可靠，因此在设计协议时需要重点考虑以下特性：

1)足够轻量，方便嵌入式设备快速解析和响应；

2)支持双向通信，即服务器和客户端之间可以相互收发消息；

3)由于多数物联网设备网络时延不稳定，实际生产中设备也不适合持续等待服务器响应，因此协议需要支持异步传输机制；

4)足够灵活，支持设备和服务的多样化。

MQTT最初便是为物联网设备的网络接入而设计的[4]，具备以下主要特点：

1)发布订阅模式，支持一对多及双向消息发布；

2)1字节固定报头和2字节心跳报文，拥有较小的网络传输负载；

3)针对不同场景，支持三种级别的数据服务质量(QoS，只有一次、最少一次和最多一次)，按需保障数据准确性和传输效率。

这些特点让MQTT完美适配基于物联网构建的工业设备数据传输需求，可通过较少的代码、有限的带宽以及稳定的性能为设备提供实时可靠的消息服务。

MQTT拥有生产者(Publisher)、消费者(Subscriber)和代理服务器(Broker)三种角色，其关系如图1所示。生产者和消费者作为客户端，对彼此无感知，只需通过配置好的IP及端口与Broker建立连接，生产者可将数据发布至Broker指定主题(topic)，消费者可根据需求，订阅所需主题的数据。

图1 MQTT架构

2.3 关键技术—时序数据库

时序数据是基于稳定频率或非固定周期频率持续产生的一系列基于时间维度的指标监测数据，普遍存在于工业设备、仪表、传感器产生的数据，呈现出一定的趋势性和规律性[5]。时序数据库是一种针对时序数据高度优化的垂直型数据库，且以时间为索引，支持时序数据的快速写入和多维度实时查询等功能。

在实际工业生产中，特别是在IoT物联网以及OPS运维监控领域，由于工业设备的持续工作，因而会不间断地产生数据，所需的数据存储规模甚至会达到TB、PB级，传统关系型数据库很难支撑这么大的数据量以及这么大的写入压力。大规模IoT物联网，对数据存储的需求主要包括：

1)低存储成本：数据量呈指数级增长，且因贴近实际生产，对成本敏感；

2)弹性：工业设备监控场景存在业务数据爆发式增长的场景，需要拥有足够灵敏的弹性伸缩能力，能够快速扩容应对增长的业务需求；

3)高性能写入：工业设备数据采集频率较高，需要支持7×24小时不间断高压力海量数据写入能力；

4)高性能查询：由于要保证数据分析的实时性，对海量数据查询的实时性有较高要求；

5)高稳定性：对于工业软件的普遍性要求，避免设备数据丢失影响自动化业务。

工业场景的数据，普遍存在以下特点：

1)都有时间戳，且按时间顺序生成；

2)采集频率高，单条数据不长，但数据规模极大；

3)写入频率远高于查询频率；

4)很少需要更新特定时间点的数据内容。

面对海量数据存储，传统数据库多是采用主备架构，且对于时序数据存储压缩性能不佳，通常要求有较高的服务器硬件配置，这对于成本敏感的工业企业是难以承受的；在海量数据写入方面，传统数据库单机写入吞吐低，很难满足海量时序数据的写入压力，分布式集群模式在工业应用中也不现实；在查询性能方面，如未人工建立索引，按时间、标签等多维度的海量数据聚合分析性能较差，难以满足较高的实时性需求。相比之下，时序数据库利用时间递增、维度重复、指标平滑的特性，拥有较高数据压缩比，通过预降精度，对历史数据做聚合，可有效节省存储空间；时序数据库支持海量时序数据的批量写入，不支持数据更新；针对时序数据，时序数据库默认对时间建立索引，且通过缓存、routing等技术提高查询并发，可对海量时序数据进行实时查询和聚合分析。此外，时序数据库采用无锁设计和多核技术，让数据插入和查询的速度比传统数据库有了质的飞跃[6]。

结合工业场景数据的特点，综上所述，时序数据库无疑是工业设备数据持久化的上佳选择，它本身的分布式架构，使其不再依赖昂贵的硬件，在普通的x86服务器甚至虚拟机上都可运行，大大降低了使用成本。

2.4 系统架构设计

本节介绍如何运用前面介绍的关键技术，构建通用的工业监控系统，系统由三层架构构成：设备接入层、协议解析层和应用表示层，如图2所示。

图2 系统架构设计

1)设备接入层

当PLC投入运行后，其工作过程一般分为三个阶段，即输入采样、用户程序执行和输出刷新三个阶段。完成上述三个阶段称作一个扫描周期。在整个运行期间，PLC的CPU以一定的扫描速度重复执行上述三个阶段，实现对设备的控制和数据的采集。结合2.1中所述优势，本系统采用云化PLC软件，与云化网关部署在MEC服务器中，满足厂区数据的高性能接入、计算、传输需求，保障信息安全，降低传输成本。

2)协议解析层

作为OT和IT的分界线，工业网关支持丰富多样的工业协议，将工业世界的数据通过协议解析转化为IT世界可用的结构化数据，向下可作为大规模分布式设备(如工业控制器、传感器、仪器仪表、数控机床等)的接入节点，向上可通过以太网、无线网等多种信道通过TCP等网络协议传输数据至工业应用，构建工业设备与应用之间的桥梁。

3)应用表示层

工业监控应用通过微服务实现前后台分离，应用后台作为MQTT消息的消费者客户端，订阅特定topic的实时数据，并通过数据解析模板配置的方式，无需编程开发，按照模板即可对订阅的数据解析入时序数据库，实现对工业数据的持久化。同时时序数据库可以通过配置Retention Policy，即数据保存策略，设置数据的存储时间、存储备份数等参数，保障不同数据可以按需保存，定期清理过期数据，防止溢出硬件存储能力。应用前台主要有两种模式，一种是通过AJAX轮询等方式，实时通过图表等方式可视化展现最新的监控数据，为企业决策者多维度、多形态地展示参考；另一种针对专业工程师或设备操作员，模拟产线构建图形组态，提供HMI(人机交互)界面，使得操作员可以根据监控数据发现设备问题，在线通过界面远程操作并修正设备。在反控设备时，通常由应用后台作为HTTP RESTful请求的客户端，将操作指令或配置参数封装在请求体，向网关或者支持HTTP的设备发送请求，用户操作全程对设备信息无感知，所有的请求方式、请求参数以及触发条件均在应用启动时预先配置完成。

3 结果验证

本文以某大型工业企业智能皮带纠偏应用为验证背景，基于第2节中所介绍的系统架构，构建在皮带纠偏应用中关键网络时延的监控应用，分别验证该系统设计的可行性和异常捕获及云化控制能力。

如图3所示，整个网络监控应用依托于皮带纠偏网络监控流程，主要由MEC服务器中部署的组件保证应用的正常工作及功能验证(图2中所示的模块除设备均部署在MEC内)，MEC外的组件主要用来保证设备和工控系统之间网络的连接，流程中各模块简介如下。

图3 皮带纠偏网络监控流程

1)纠偏设备：由两台皮带纠偏电机及传感器组成，通过两台工业IO设备进行modbus(工业领域通信协议的业界标准，并且现在是工业电子设备之间常用的连接方式)信号传输，与工业IO通过有线连接，纠偏操作通过部署在MEC的云化PLC控制；

2)工业IO：承担工业信号的输入/输出，输入指从仪表进入控制系统的测量参数，输出指从控制系统输出到执行机构的参量；

3)工业交换机：承担工业IO与DTU之间的通信，与二者均通过有线连接；

4)5GDTU：5G数据传输单元(5G Data Transfer Unit)，是专门用于将串口数据转换为IP数据或将IP数据转换为串口数据通过无线通信网络进行传送的无线终端设备，系统采用联通的“先锋者2号”产品，提供工业控制接口，集成通用工业现场总线协议，可以快速为行业用户提供5G无线网络接入能力；

5)5G宏站：与MEC服务器通过光缆连接，提供其对外界的5G无线通信能力；

6)MEC：即边缘计算服务器，部署了云化PLC(集成了网关)、MQTT代理、监控应用以及时序数据库(采用influxDB)。

3.1 可行性验证

“先锋者2号”在测试环境中IP为10.250.2.143，结合其支持端口映射的特性，将两台工业IO的业务端口502、503分别映射到“先锋者2号”设备的10.250.2.143:502和10.250.2.143:503，实现分别控制两台纠偏电机。本应用主要监测两个点位的网络通信时延，一个是控制端(即MEC中的监控应用)到“先锋者2号”的通信网络时延(以`xianfengzhe2`表示)，另一个是控制端到纠偏设备的端到端时延(以`time_delay`表示)。

网络时延数据的采集方式通过部署在MEC中的shell脚本，使用tcping命令定时分别ping“先锋者2号”的100、502、503端口(日志信息如图4所示)，其中100代表控制端到“先锋者2号”的时延，即`xianfengzhe2`，502、503则分别代表控制端到两台纠偏设备的端到端时延。该shell脚本在捕获时延数据之后，会将其拼接成如图5的数据格式，发布到MQTT特定topic。

图4 日志信息

图5 网络时延数据

监控应用作为消费者客户端，订阅该topic实时获取数据，并解析入influxDB时序库，同时监控应用会对目标库进行AJAX轮询，一旦有数据增量，便实时同步至前台展示，监控效果图如图6所示，其中蓝线表示控制端到两台设备通信的端到端时延(time_delay)，红线表示控制端到“先锋者2号”时延(xianfengzhe2)。需要注意的是，xianfengzhe2理论上应该小于time_delay，但由于实际情况中，“先锋者2号”为设备数据提供5G无线接入传输能力，而xianfengzhe2的意义则是验证5G网络在设备和终端间是否可用，即当其有正常数值时表示5G接入网络正常可用，当其值为‘-1’时表示5G接入网络连接已断开。图6中偶尔出现的xianfengzhe2>time_delay的情况是由于两个时延数据采集的shell脚本分别独立运行，为了验证5G网络可用，xianfengzhe2的获取需要加上接收回传响应信息所需的时延，而time_delay是直接的单向通信时延。

图6 网络时延实时监控

由于influxDB有丰富的统计函数库，同时支持以时间维度对数据进行周期性统计报表。以2021.2.21～2021.2.25期间全天实时监控数据为例，得到的统计信息如表2所示，设备管理者可以根据这些数据得知网络的状况，进而判断是否会影响设备正常工作。由于“先锋者2号”主要起了5G网络接入的能力，`xianfengzhe2`字段所示时延无较大意义，只为测试网络连接是否正常，端到端网络时延性能是重要监控指标，如果网络发生闪断(通信状态timeout，`time_delay`表示为`-1`)，可快速重连。

表2 网络时延重要指标统计

3.2 异常捕获及云化控制能力验证

网络时延超过100ms将对皮带纠偏产生滞后影响，容易导致生产事故，因此当网络时延大于100ms时，需要监控系统预先设定策略，触发云化PLC反控纠偏设备的纠偏开关调整为延时纠偏模式(参数为JP_MODE:02)，直到网络时延恢复正常，再控制纠偏开关回到正常模式(参数为JP_MODE:01)。正常模式下，现场的视频摄像头收集皮带偏转数据、物料数据进行纠偏判断、物料识别和调整纠偏力度控制。高通信时延作为该场景下存在的影响正常纠偏的主要因素，影响图像数据的实时传输、解析和响应，延时纠偏模式因此被设计用来保障在时延过大时仍能确保皮带的正常工作，其核心设计思路是暂时不根据图像响应判断纠偏程度和力度，而通过机械控制的液压杆维持皮带稳定，保证物料不掉落，待时延切回正常模式后，重新由纠偏开关控制纠偏电机进行纠偏修复。

本节重点验证应用的云化控制能力，即通过部署在MEC中的监控应用传递控制参数给同样部署在MEC的云化PLC，进而控制设备纠偏方式的转变。由于云化PLC集成了支持HTTP RESTful接口访问的云化网关(MEC内网IP：172.16.0.21:48082)，因此在发生超高网络时延时，由监控应用服务端向网关(与云化PLC集成)对应的API PUT一个变更参数，使得云化PLC控制参数JP_MODE由01变更为02并输出相应的控制信号，通过其所在MEC依托的5G宏站向现场发送，位于现场的“先锋者2号”负责接收该5G控制信号，经由工业IO转化为实际控制的电信号，通过工业线缆传输到皮带现场端，伺服电机接收到电信号驱动纠偏开关按延时纠偏模式进行纠偏。整个响应控制过程，用户在用户界面(监控面板)是无感知的，为了方便验证，监控系统提供了支持HTTP API访问的测试功能。在网络状况正常时，如图7所示，向该接口发送GET请求查询当前JP_MODE的值，可以看到响应结果为01；在时延超过100ms时，如图8所示，采用同样的GET请求，响应结果JP_MODE参数值变更为02。

图7 正常网络状况下的纠偏参数

图8 异常网络状况下的纠偏参数

4 结语

本文以传统工业智能化转型为背景，针对设备自动化监控场景，基于云化控制、解析的理念提供了一套通用解决方案，并以实际生产场景加以验证。该方案由5G和MEC驱动，满足了实际工业生产中对于数据传输实时性和准确性的要求，构建了对工业数据多维度、多形态可视化展现并快速定位工控问题的能力，解决了海量工业应用在数据维度智能化不足的问题。在可以预见的将来，随着技术不断成熟和场景的不断优化，云化的工业自动化控制必将在工业智能化改造进程中画上浓墨重彩的一笔。