1 简介

在工业物联网(IIoT)时代,OPC/OPC UA作为一种统一的通信架构,解决了互通性和标准性的问题。OPC Classic的访问规范都是基于微软的COM/DCOM技术,这会给新增层面的通信带来不可根除的弱点。本文概述了目前使用DCOM时可能会遇到的几种问题,并提供可能的解决方法。最后通过一个和Tunneller连接的对比实例来给出一个新的选择。

2 常见问题

通常来说,OPC Server与OPC Client 建立DCOM连接时可能会有各种各样的问题和麻烦,这些问题一般可以分为两类。

第一类就是配置上的问题,如果发现OPC Client和OPC Server无法建立通讯,那么你可能需要检查Windows服务里OPC Server是否被禁止、用户名密码是否匹配或者OPC Enum是否有匿名访问权限等,这类问题都是二者建立起连接的要素不全引起的,可以通过查看设置来排查错误建立连接。

第二类就是操作不当以及DCOM本身的缺陷造成的问题,例如当OPCClient和OPC Server无法建立通讯时,可能是因为OPC Server先从当前登录用户启动运行,然后OPC Client是以Windows服务方式在System账户空间内运行,此时Client检查不到Server在运行所以建立不了通信。还有可能是因为两台远程相连的PC的网络曾经断线后又重连,这时二者建立的连接被断开后无法复原了,这都是比较常见的问题。

针对上述网络断线重连导致连接不稳定的问题,这里给出一个对比实例,观察使用 Tunneller连接来进行通信与DCOM通信在网络断线重连时受到的影响。

3 工具

硬件:

l 两台PC(OPC-1和OPC-2),一台做客户端,一台做服务器端。

软件:

l MatrikonOPC Explorer

l Matrikon OPC UA Tunneller

l Server for Simulation等做服务器的软件

4 实例步骤

1.    首先确保可以通过在OPC-1上打开OPCExplorer连接到NetworkNeighborhood->OPC-2->Matrikon.OPC.Simulation.1server的方式将OPC-1和OPC-2建立起DCOM连接,反之亦然,如图4-1所示。

OPC DCOM连接不稳定的解决方案_工业通讯

                                                                              图4-1 检查网络连接

2.    在两台PC机上分别打开MatrikonOPCUA Tunneller Configuration Panel,选择Classic Client to Classic Server项打开配置页面,如图4-2所示。

OPC DCOM连接不稳定的解决方案_OPC DCOM_02

                                                                                  图4-2 打开UA Tunneller

3.    打开 Tunneller Server Gateway Configuration页,确认Encryption功能处于未选中状态,然后点击Apply。这一步一定要在两台PC机上都进行确认否则将无法建立任何连接。如图4-3所示。

OPC DCOM连接不稳定的解决方案_广州虹科_03

                                                                                   图4-3 取消勾选加密功能

4.    回到OPC-2里,在UATunneller的对话框里打开TunnellerClient-Side Gateway Configuration页面。点击“+”图标来添加一个新的Tunneller连接,如图4-4所示。

OPC DCOM连接不稳定的解决方案_OPC DCOM_04

                                                                                   图4-4 添加新的Tunneller连接

5.    从下拉菜单中选择OPC-1然后点击OK,连接结果将会展示在左侧面板,如图4-5所示。

OPC DCOM连接不稳定的解决方案_OPC DCOM_05

                                                                             图4-5 连接后的展示

6.    打开 OPC Explorer,你会看到OPC服务器都部署在Localhost下了,而且此时两台机器的OPC服务器通过Tunneller建立了连接,如图4-6所示。

OPC DCOM连接不稳定的解决方案_OPC UA_06

                                                                                     4-6 Explorer已部署

7.    在Localhost下,选择并连接到Tunneller:OPC-1:Matrikon.OPC.Simulation.1,如图4-7所示。

OPC DCOM连接不稳定的解决方案_广州虹科_07

                                                                                       图4-7 连接成功

8.    创建一个标签组(点击Add Tags)并且从此服务器添加所有的Random数据项,如图4-8所示。

OPC DCOM连接不稳定的解决方案_OPC UA_08

                                                                                图4-8 随机数据项展示

9.    在Localhost下面的Network Neighborhood使用DCOM管理连接到OPC-1的上述同一服务器,并且同样地创建一个标签组然后将此服务器所有的Random数据项添加进来,如图3-9所示。

OPC DCOM连接不稳定的解决方案_OPC DCOM_09

                                                                             图4-9两种方式两个组

10. 由上图可以看到,在OPC-2的OPCExplorer里能看到两种方式连接到OPC-1的simulation服务器的OPC组。而且两种方式的组里OPC项都是good质量。

11. 下一步我们使用Windows实用程序来断开两台PC的网络连接。可以看到断开网络连接后,本机与OPC-1的OPC服务器的DCOM管理链接已被破坏。而Tunneller连接还依然保持连接,但是此连接下所有项的质量变为bad,如图4-10,4-11所示。

OPC DCOM连接不稳定的解决方案_OPC UA_10

                         图4-10 断开网络连接

OPC DCOM连接不稳定的解决方案_OPC UA_11

                                                                             图4-11 断开连接后的结果

12. 观察到对比结果后,重新建立网络连接。可以看到DCOM方式连接并没有自动恢复,而Tunneller连接下OPC项的数值,质量以及时间戳都恢复更新了,如图4-12所示。

OPC DCOM连接不稳定的解决方案_OPC UA_12

                                                                            图4-12 恢复连接后的结果

5 总结

从上述实验可以看出,如果使用Tunneller连接来代替DCOM的连接方式,在出现网络断开连接的情况下,OPC Server和OPC Client的连接不会被直接摧毁,通信数据会暂时保持原样并停止通信。当网络重新连接后,连接会恢复正常,通信数据也会得到更新。这样一来就大大提升了通信的稳定性。此外可以看到Tunneller除了可以用于OPC Classic的通信之外,还能用于UA和Classic的通信,在现在的OPC通信架构里有着广泛的应用前景和优势。

本文转自广州虹科自动化团队微信公众号“工业通讯”!