多源异构数控设备监控服务器的研究与实现

周 正，胡 毅，杨 巍，苏文举，于 东

1(中国科学院 沈阳计算技术研究所有限公司，沈阳 110168)

2(中国科学院大学，北京 100049)

3(沈阳中科数控技术股份有限公司，沈阳 110168)

4(沈阳飞机工业(集团)有限公司，沈阳 110034)

1 引 言

设计使用良好的通信服务器监视数控机床状态，对多厂家多型号多操作系统版本的数控设备产生的数据进行统一采集、管理和调度，并且实现接口的可扩展性、向上向下适用性、安全性和实时性[1]，对于数字化车间的构建具有重要意义.无论是在智能制造的不断发展中，还是在利用制造执行系统[2]优化生产的过程中，都需要对工业设备产生的数据进行有效、规范的收集，以便对获得的数据进行有效的处理，如恢复工业制造过程、分析机器的制造效率以及对机器故障进行有效的停机损失预警等.在国家发布的《中国制造2025》和智能制造强国战略中，着重强调智能制造工程作为制造强国重点工程，已成为中国制造业发展的重中之重.

在工业4.0的发展进程中，物联网是现今行业发展的核心问题[3].目前，国内多家制造公司所使用的生产设备存在两个显著的问题：

1)设备数据管理问题.由于各个主流设备生产厂商的系统对采集的数据没有统一的管理规则，对于设备接口的使用者进行管理数据造成了极大的困扰.

2)设备协议兼容问题.国内外的主流设备厂商包括秦川、华中、西门子等主流系统设备的通信，由于生产厂商的不同、甚至是厂家自定义的通信协议方式，导致了数据兼容性差.因此，数据管理问题和协议兼容问题对数据通信提出了更高的需求.

为了实现对本厂商的数控系统的信息采集，几大主流厂商针对自己的数控设备设计了采集接口，其中大多数厂商采用的是传统的发布动态链接库的形式进行采集数据，代表性的厂商有：沈阳中科数控公司的蓝天数控系统、日本发那科数控系统等，也有部分厂商尝试内置了OPC技术，使用了较为常见的发布者-订阅者机制进行数据采集，比如德国西门子数控设备等.当前，实现数控设备的网络化也已经逐渐成为了国内外科研工作者的研究热点，如徐永乐等开发出的嵌入式数控机床状态信息采集装置，实现了机床开关量信号和主轴电流模拟量信号的实时采集[4]，刘洋等将消息代理机制应用到OPC UA，实现了OPC UA发布/订阅通信模式，适应于分布式系统的发展要求[5]，王丽娜等基于MTConnect协议建立了一个通用的采集与处理数控设备信息的Agent架构，实现了网络化监控[6]，Ben Edringto等使用了一种基于Web的监控系统，解决了采集终端同时监控多种设备的问题[7].

OPC UA(Unified Architecture，统一架构)是下一代的OPC 标准，它提供了一个完整、安全、可靠的跨平台架构来获取实时和历史数据和时间[8].它不是最初的基于OLE的对象，而是一种开放的，并非为某一个或某一些厂商定制的，有通信不是只有模型的统一架构.OPC UA把很多原来的OPC中的概念，进行了统一化的描述，统一化的概念如地址空间等.OPC UA是美国OPC基金会制定，被接纳为工业上的IEC62541，是国家标准，已经发布了8部分，还有4部分正在制定.OPC UA标准是一套方法论和基础模型，要和各行各业去结合才能真正体现其互联互通互操作.

综上所述，本文首先分析了当前数据采集的主流的OPC UA技术，接着基于OPC UA标准，提出一种兼容多种数据采集格式的技术架构，并针对多个型号和厂家的数控设备，进行了采集接口框架的调试与发布.最后基于所设计的框架，对程序进行了实验验证并对实验结果进行了分析与测试.

2 OPC UA概述

2.1 OPC UA协议标准

OPC UA(OLE for Process Control Unified Architecture，过程控制统一对象模型)是一个开放的跨平台架构，是 OPC 基金会在 2008 年发布的规范[9]，由全世界 30 多家知名制造企业联合开发，目前已成为工业4.0 中的通信标准.OPC UA协议独立于上位机的操作平台，并且具有很高的数据通讯和安全机制.其还能支持各类设备复杂的数据结构通信，将设备中的数据和结构节点抽象成对象对设备模型进行描述.由于其优良的设计机制，目前已经被各种数控系统所支持.OPC UA采用节点进行数据存放，并由地址空间和数据组成的节点对格式，对采集数据进行唯一标识，以构建采集模型.

2.2 OPC UA服务器通信方式

OPC规范中可以使用两种通信设备与上位机之间的通信方式[10]：同步通信模式和异步通信模式.其中，同步通信适用于OPC客户端程序比较少、传输的数据量比较小的场合，因为OPC客户端程序只有在服务器程序相应的所有操作完成后才能返回.异步通信可以在不等待OPC服务器操作完成的情况下执行其他操作，因此更加高效，适合多个客户端访问一个OPC服务器.

3 OPC UA标准和数据模型

此部分着重介绍一些OPC UA标准协议中常见的一些专业术语，为便于读者对后文的理解，对其中的核心词汇进行解释.

地址空间[11](AddressSpace)：OPC UA服务器向接收信息的客户端展现的信息集合与呈现方式.

客户端(Client)：是一种软件程序.可以依据OPC UA提供的接口与OPC UA服务器(Servers)发送和接收消息.

OPC UA信息模型(Information Model)：用于定义一个数据信息组织框架结构.

节点(Node)：地址空间(AddressSpace)中的基础组件.其中，一个节点唯一标识一台数控设备的一个属性，通常由地址空间，自定义编号组成.

对象(Object)：用于表示系统中的物理或抽象元素的节点(Node).对象(Objects)是由OPC UA的信息模型建模而来的.系统、子系统或设备都是对象(Objects)，一个对象(Object)可以被定义为对象类型(ObjectType)的实例(Instance).

3.1 OPC UA标准架构

OPC UA是建立在Socket之上的通信协议[12]，实现多种设备数据采集的主要思路是：若设备支持OPC UA协议，则把值直接存储至OPC节点进行读取；若设备不支持，则在数控设备和OPC UA服务器之间，搭建一个单独的中间层，用于创造一个平台中转由多家数控厂商中的设备所发布的不同数据类型的信息流，以保证OPC UA服务器所收到的数据类型是一致的.在此思想的指导下，本论文通过建立可插拔的OPC UA服务器模型，实现了异构设备数据的采集；采用OPC UA协议进行映射，通过当前开源的open62541库设计了该接口，并通过可插拔的方式，分别对沈阳中科数控公司的蓝天数控系统GJ430、日本发那科公司的FAUNC 0i-MateTc数控系统、武汉华中数控公司的HNC 818D数控系统、广州数控公司988TD数控系统、德国西门子840D SL数控系统等多台设备进行了实验验证与平台环境搭建，在实验中主要面临解决的有3个问题：

1)多个数控设备源信息模型的建立问题；

2)通过OPC UA建立的模型与实际设置的数据对应项的映射问题；

3)用于中间层数据格式转化和节点存储问题.

3.2 OPC UA标准数据模型

在OPC UA中使用OPC UA Modeler，编辑的节点工具可以根据OPC UA Nodeset XML模式导出数据；OPC UA Modeler的SDK中包含一个基于Python的节点集编译器库，可将这些信息模型定义转换为工作服务器节点模型.其XML头部包含了对协议标准的说明，XML主体部分包含了对不同设备数据的具体描述.OPC UA协议定义的标准化信息模型包括UA节点(UAVariable)、关联关系集(References)、关联关系(Reference)、节点值(Value)等部分.其中，UA节点表示了数据采集项的节点储存的逻辑位置并且包含了描述该节点的必要信息，如节点名称、关联关系等，关联关系集包含了该节点的一个或多个该节点与其他节点的具体关联关系.节点值表示了节点存储项的初始值.使用节点集编译器对该部分XML代码进行编译，编译器将在解析XML文件时创建内部表示，并尝试理解和验证此表示的正确性，以便生成编程语言可识别的代码.

4 服务架构设计

4.1 OPC UA系统车间网络结构

基于 OPC UA 架构的车间数据通信的设计思想是：将种类繁多的底层设备如传感器、 PLC 设备、机器人、AGV、数控机床等所采集到的数据全部采用 OPC UA 格式标准进行封装和传输，以此来统一管理底层设备信息，通过 OPC UA 统一架构存入数据中心，再由 MES、 ERP 等上层应用系统来调用，完成对底层设备的监控和业务应用，也可以将这些信息存入数据库或云端，供今后进行大数据分析使用.

基于OPC UA协议的智能车间通信架构系统由管理信息系统、储存库、OPC UA服务器、中间层接口和加工设备组成.系统架构图如图1所示.

图1 系统架构图

4.2 服务器信息交互运行逻辑

系统开始运行后，首先由OPC UA服务器进程启动已经准备好的读取配置信息的函数，对服务器准备进行初始化操作.读取配置文件，根据所配置的文件进行初始化，初始化操作包括传递设备信息，信息模型实例化，服务器进程创建数据节点，等待填充内容等.运行中间层接口进程，使得中间层和数控设备进行连接.多台数控设备数据的不同格式的信息不断被传送至中间层的进程进行过渡，中间层进程按照一定的时间间隔从数控设备中读取数据，并进行包装，把数据转化为OPC UA节点可存储的形式，在OPC UA服务器主进程已经启动的情况下，写入主进程OPC UA节点中.写入完成后检查当前的连接状态，同时对客户端的显示进行刷新.由于当前多数设备不具备断线自动重连的能力，所以若发生中断，中间层进程须删除连接的信息，并把连接时间进行重置，提示系统异常状态，重新创建对象对其连接.该流程如图2所示.

图2 运行逻辑图

当OPC UA服务端收到数据节点的写入请求后，首先判断请求的合法性，是否有写入权限，编码格式以及传输格式是否兼容等.若请求合法，则调用数控设备的函数接口数据对象进行写入.所配置的文件包括设备的IP，端口号，名称以及待采集数据项的种类等.

4.3 中间层交互接口的实现

为减少OPC UA服务器同时采集和处理多台数控设备的不同格式数据产生的数据交换和使用某些通信协议和数据格式后，处理过程造成的实时性不能满足客户端需求，本文设计了OPC UA的中间层，中间层结构如图3所示.

图3 中间层模型

中间层必须为多种接口类型和不同数控系统的数控设备提供相应的转换实现多种数据格式的采集.

中间层必须支持对采集到的数据进行转换与保真，能传输到OPC UA 服务器中.

中间层作为一个介于数控设备和OPC UA服务器之间的信息传递层，其承担的主要任务是实时转换数控设备产生的数据值，并将获得的值或字串进行规范的解析，之后把规范的OPC UA协议支持的信息传递至OPC UA服务器中，服务器进行暂存，等待可读OPC UA信息的客户端请求访问，实现数控设备的网络化传递.本文设计的中间层架构如图3所示，主要设计了信息过滤模块、网络配置模块、支持库模块，通信测试模块、通信诊断与意外处理模块和节点信息通信模块.

网络配置模块包含编程人员对数控设备的各种配置信息，主要指的是其软件信息，包括设备名称、IP地址和端口号等.对于不同的下位机设备，其基础信息应包含不同的接口参数.支持库模块包含了通信协议常使用的函数和厂家提供的提取通信函数，这些函数提供了原始数据的采集.信息模型对不同的类型的数控设备，根据其可采集的参数，可采集的函数，采集需要使用的方式不同，可以建立多个不同的采集过程.

信息过滤模块实现对于原始数据的采集和过滤工作，该模块是一切后续工作的基础[13].对不同类型数据的传输格式，都有着相似的数据处理流程，首先对数据项的筛选，接着进行格式转换和封装.首先根据设备不同的配置信息及接口信息，确定数据获取方式，如通过供应商已经提供好的接口函数或数控设备手动配置过的接口，对采集项进行筛选.然后，对于不同的数控系统的信息使用不同的方法进行采集，比如沈阳中科数控公司的加工机床和国外的发那科数控系统，可以直接通过其二次开发函数库调用函数进行机床信息内容的读取；广州数控公司的数控机床数据以Web服务的网络Socket形式进行发布，这时使用编程语言自带的Socket函数进行读取；西门子数控机床的大部分型号自带有OPC服务，采用了订阅的形式进行读写数据，因此为了保证其传输效率，可以模拟一个接收OPC服务的客户端，用于读取数据.待各种类型的数据读取完成之后，使用OPC UA协议的函数进行封装，等待发送指令.这时，根据数据需求的实时性进行不同频率的采样，以达到要求所采集的精度和频率.

节点通信模块和通信诊断与意外处理模块.是为保证在数据处理完成后，能把数据成功的传入客户端或数据库中，以进行实时监控或持久储存，由于在信息过滤模块经过其内部的3步运行逻辑，已经成功把不同格式数据转化为了OPC UA格式.因此在此部分只需要把相同格式数据转发给OPC UA节点.在通信突然中断时，诊断模块负责清除连接信息，并中断运行程序，自动尝试重连，并抛出异常信息以引起监视人员注意.

根据以上模块的设计，尽管采集的是多种设备的不同形式的数据，在中间层针对不同的数据传输形式，采用不同的策略进行数据解析，最终都可以得到OPC UA节点可接收的数据格式.由诸多参考文献可知，设备中数据采集过程的编程语言也可能互不相同，采用传统的方式直接把数据传输至服务器进行解析，可能会造成大量采集代码的重写，或遇到不同的意外错误，设计一个中间层进行过渡，不仅有效实现了代码的模块化与可插拔性，还减少了OPC服务器的读写压力.最后，即使是不同的编程语言也可以写到一个OPC UA服务器建立的节点表中.同时发挥不同编程语言的优势，比如：C#相比于C++能更简单快捷的解析JSON格式的信息.

4.4 OPC UA 服务器和客户端的交互

OPC UA服务器与客户端之间的通信方式是请求-响应机制.启动客户端后，输入服务器地址和接口以连接服务器.连接成功后，客户端首先向服务器发送请求消息，该消息由OPC UA服务器处理，完成后，服务器向客户端发送响应.在信息传递过程中，传递的信息首先通过Schema格式进行验证，然后由通信双方进行分析以获得对方的响应.在不同的名称空间下，每个节点都被预先唯一地标记NodeID.客户端通过浏览服务遍历地址空间，向服务提交初始节点和浏览过滤条件，服务器通过引用返回连接到初始节点的节点列表.

5 接口设计与实验

为了验证本实验设计的接口技术的可行性，本实验采用的实验环境为Windows 10操作系统，在VS2013中使用C++语言，通过查找当前开源的OPC UA的函数库Open62541搭建了OPC UA服务器，以及完成对其节点的部署工作.在VS2017环境下使用了C#编程语言，设计了设计方案中的中间层，对传输格式进行转换.并且使用了VS2017建立了C#函数库支持的OPC UA客户端，作为客户端的监控系统.最后，将设计模型部署至生产车间，分别测试访问了沈阳中科数控公司的蓝天数控系统GJ430、日本发那科公司的FAUNC 0i-MateTc数控系统、武汉华中数控公司的HNC 818D数控系统、广州数控公司988TD数控系统、德国西门子840D SL数控系统等的内存信息采集系统设备信息，实现对车间数控设备的网络化监控.

5.1 数控设备信息建模

由于本实验对多台不同类型的数控设备进行了接口设计，为了方便查看获得的监视信息，采集了几乎所有数控设备类型中都一定存在的数据项.若某些数据项在数控机床中不存在，则对于数字赋值显示为0，对于字串赋值显示为null.根据OPC UA中数据格式的节点采集要求，建立设备的信息模型.

设备集中定义了所使用的抽象设备，该设备包含大多数类型数控系统所持有的必要信息，称为NC.该设备集作为OPC中的指向性节点，该类节点是为了更好的查找和管理机床模型中的数据信息，该节点指向轴类节点、状态类节点、通道诊断类节点和加工信息类节点等.每项设备节点一般包含速度、实际位置、编程位置、进给率、程序状态，执行状态、开机时间、切削时间、加工时间等.本文综合了多家厂商的数控设备的基础采集信息，设计了一个通用的机床信息模型进行描述，其OPC节点及变化如表1所示.

表1 采集信息模型

其中，ns代表了不同设备的命名空间，每个命名空间都属于特定的OPC UA规范，为了确保特定id唯一标识特定数控设备的特定节点，使用ns指明区别多个设备的名称空间id.例如，GJ430设备的ns=1，则其进给修调值的存储节点为(ns=1，id=14)；Siemens 840D SL设备的ns=2，则其进给修调值的存储节点为(ns=2，id=14)，其他设备均以此格式进行设计.表1以GJ430设备为例，去除了一些基本重复的采集项后，列出了本实验主要做的节点模型.

5.2 OPC UA服务器与中间层搭建

对于OPC UA服务器的建立，由5.1节设计的数控设备的信息模型，使用XML文件对其进行描述，然后根据XML描述文件，采用OPC UA SDK工具包，把源模型逆向工程映射至服务器模型，该操作可以简单明了的将模型文件转化为服务器中面向对象的类文件.接下来，对服务器配置一些启动所必要的参数，如：秘钥、端口号等.最后可调用UA_Server_run(server，&running)方法启动服务器监听程序，成功启动后可得到OPC UA服务器空间访问地址，以供OPC UA客户端进行数据的读取.本实验案例中，测试使用的访问地址为opc.tcp：//DESKTOP-486CJO0：48020/.

对于中间层的建立，如图4所示，在图中可选择当前需读取数据并存入OPC UA节点的数控设备，选择完成后，该程序调用厂商或第三方已经编写完成的读写子程序，把数据暂存至中间层，然后统一在中间层把数据写入OPC UA节点服务器中，完成多源异构数控设备的读取实验.

图4 中间层表示

5.3 网络节点访问测试

基于以上实现，在上位机部署OPC UA服务器和OPC UA中间层后，在其他上位机或本上位机部署客户端时，可以监控到当前系统数据.通过OPC UA的url可以直接在客户端查看各个数控系统的多项数据信息.如图5所示，为客户端的查看命名空间为6时，西门子数控系统的数据实时状态，包括该数控系统的位置坐标、进给速度、主轴速率、程序名、运行模式等.

图5 客户端状态

5.4 网络监控分析

数控设备的设备状态是加工工件过程中一个重要的参数，通过对机床运行状态的分析，确保数控机床的正常运转，能够提高机床的工作效率.本实验在使用相似的加工程序对多台设备进行测试后，以沈阳中科数控公司生产的GJ430型号的数控系统的加工数据为例，绘制了图6所示的实验结果.该图中的横轴表示时间，纵轴表示设备状态.监控人员可根据设备状态变化，及时调整工作计划，排查故障，或设置设备报警灯，根据状态变化提前预警.

图6 设备状态监控

5.5 采集数据准确性测试

为了测试并验证数据采集的正确性，分别采用了传统的读取方法和本实验设计的方法对GJ430数控系统中的数控程序驱动的z轴编程速度数据项作为实验对象进行读取，其中把采用传统的读取方法读出的z轴编程速度与本实验设计的方案读取的z轴编程速度进行了速度差比较.经比较后发现，在同一时刻，使用传统读取方式读取的z轴编程速度和使用本实验设计的系统读取方式读取的数据一致.经设计多次量化测试比较后，得到两种方法的数据项在精度上的误差约为10-6量级范围，采集精度已经完全达到要求，验证了本实验设计采集的数据的准确性.

另外，本实验测试了在任意时刻，中断数控系统正在执行的程序，在数控系统上读出的多个数据项和OPC UA客户端读出的数据项均一致.

5.6 数据时延测试

本实验还对请求和应答设置了时间戳，测试了从数据请求至写入OPC节点的时延，以此来观测系统的响应时间.选取的对象分别为5台不同厂家生产的数控设备的进给速度数据项在60秒内的延时误差的平均值.实验结果如图7所示.

如图7所示，可得采集的进给数据平均值都大约分布在2.46ms左右，然而传统的数据采集方式在经过测试后，请求延时测试结果稳定在3.2ms内.因此，时延测试验证了在添加中间层后，在网络稳定的情况下，完成加工过程的复原和诊断，该系统的延时基本可以保证需求.

图7 延时测试

5.7 系统性能测试

对于已经设计的系统程序，测试程序对于服务器资源的占用情况，分析其性能对于改善服务器资源配置至关重要.本实验中，使用了Windows系统自带的性能监视器，测试了24h内，5台数控设备同时运行5个加工程序时，OPC UA服务器处理数据时，CPU占用率和内存占用的情况.经实验测试后，可得其平均值为0.282，最大值为4.291，表明该系统稳定在一个较小的CPU占用率上，OPC UA服务器可承受更多的采集任务.初始数据以Byte为单位，在经过比例为10-6缩小后，测试结果保持在1.7M左右，相比于传统的服务器设计，占用的内存更少，同时，其证明了加上了中间层的设计后，由中间层完全进行OPC UA节点读写操作.OPC UA服务器只需解决服务启动的问题，承担的压力更少.

6 结束语

本文基于OPC UA协议，建立了采集系统的架构模型，通过 OPC UA 数据服务器访问接口进行数据采集，建立一个不依赖于OPC UA服务器的中间层接口，可以更方便的实现代码模块的分离，使得即使是不同编程语言采集的数据项也可以写到同一个OPC UA节点模板中，省去了重新编写代码实现相同功能的时间，也使得对于不同机器，更好的发挥编程语言库的优势，使得接口编写变得更为简单.同时，快速高效的 OPC 采集方法保证了数据的正确性和有效性[14]，为实现数字化车间管理奠定了基础.本文在研究分析 OPC UA技术和多类型传输格式的数据采集基础上，实现了对多厂商数控系统使用当前流行的OPC UA技术的数据采集，对实现车间管理系统具有重要的作用.