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所示。
图4-1 检查网络连接
2. 在两台PC机上分别打开MatrikonOPCUA Tunneller Configuration Panel，选择Classic Client to Classic Server项打开配置页面，如图4-2所示。
图4-2 打开UA Tunneller
3. 打开 Tunneller Server Gateway Configuration页，确认Encryption功能处于未选中状态，然后点击Apply。这一步一定要在两台PC机上都进行确认否则将无法建立任何连接。如图4-3所示。
图4-3 取消勾选加密功能
4. 回到OPC-2里，在UATunneller的对话框里打开TunnellerClient-Side Gateway Configuration页面。点击“+”图标来添加一个新的Tunneller连接，如图4-4所示。
图4-4 添加新的Tunneller连接
5. 从下拉菜单中选择OPC-1然后点击OK，连接结果将会展示在左侧面板，如图4-5所示。
图4-5 连接后的展示
6. 打开 OPC Explorer，你会看到OPC服务器都部署在Localhost下了，而且此时两台机器的OPC服务器通过Tunneller建立了连接，如图4-6所示。
4-6 Explorer已部署
7. 在Localhost下，选择并连接到Tunneller:OPC-1:Matrikon.OPC.Simulation.1，如图4-7所示。
图4-7 连接成功
8. 创建一个标签组（点击Add Tags）并且从此服务器添加所有的Random数据项，如图4-8所示。
图4-8 随机数据项展示
9. 在Localhost下面的Network Neighborhood使用DCOM管理连接到OPC-1的上述同一服务器，并且同样地创建一个标签组然后将此服务器所有的Random数据项添加进来，如图3-9所示。
图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所示。
图4-10 断开网络连接
图4-11 断开连接后的结果
12. 观察到对比结果后，重新建立网络连接。可以看到DCOM方式连接并没有自动恢复，而Tunneller连接下OPC项的数值，质量以及时间戳都恢复更新了，如图4-12所示。
图4-12 恢复连接后的结果
5 总结
从上述实验可以看出，如果使用Tunneller连接来代替DCOM的连接方式，在出现网络断开连接的情况下，OPC Server和OPC Client的连接不会被直接摧毁，通信数据会暂时保持原样并停止通信。当网络重新连接后，连接会恢复正常，通信数据也会得到更新。这样一来就大大提升了通信的稳定性。此外可以看到Tunneller除了可以用于OPC Classic的通信之外，还能用于UA和Classic的通信，在现在的OPC通信架构里有着广泛的应用前景和优势。
本文转自广州虹科自动化团队微信公众号“工业通讯”！
