前言
上周我们给大家展示了使用OPC Tunneller完成OPC通信的方法，有了Tunneller以后我们不再需要进行繁琐的DCOM的配置，也能正常的进行OPC通信。同时也谈到了如果OPC Tunneller的优点仅仅只是简化OPC通信连接的过程，那么它对于那些OPC通信经验丰富的技术工程师来讲并没有什么吸引力，反而是额外的成本支出，所以今天就来看一下使用Tunneller连接对比DCOM连接的另一大优点——稳定性更高。
我们的合作伙伴之前已有发过本次实验的Matrikon虚拟机教程步骤：OPC DCOM连接不稳定的解决方案
今天我们还是用两台真实的WIN10操作系统的电脑，通过连接到同一个网络的方式，来复现一下本次对比实验。
软硬件需求
硬件需求：
两台电脑，一台做OPC服务器，一台做OPC客户端，两台电脑IP地址在同一网段下，本例的操作系统都是WIN10。
软件需求：
1.MatrikonOPC Explorer（做OPC客户端）
2.MatrikonOPC Server for Simulation（做OPC服务器)
(都是免费的测试软件，可以从matrikonopc.com获取)
3.OPC UA Tunneller（带有OPC Tunneller功能，需要购买授权，试用版可从matrikonopc.com或者hohuln.com获取）
DCOM方式
DCOM配置请参考我们之前的文章。
做好之后然后在客户端打开OPC Explorer，左侧菜单栏里下面的远程主机添加server，输入服务器的主机IP地址，并选择模拟服务器”Matrikon.OPC.Simulation.1”。点击右侧Connect进行连接。
Tunneller方式
服务器端和客户端的Tunneller配置可参考我们上周的文章。
在客户端的OPC Explorer的localhost列表下找到需要连接的远程主机的TunnellerOPC服务器。点击右侧Connect进行连接。
创建组
给两种方式建立的OPC通信分别创建一个GROUP,分为group1和group2，并且分别向组里添加模拟服务器中的所有Random分组下的数据标签，以便观察。如下图所示，group1和group2中的所有的数据标签不停的在刷新。
从上面两张图可以看到两个group中的数据标签其实是一样的，而且现在两组数据的数据质量（Quality）都是”Good”。可见当连接完成后，两种连接方式下的OPC通信是一样的。
出现特殊情况
在实际使用的场景下，可能会出现一些误操作或者不可抗力的停机断网的意外发生，哪怕恢复的比较及时，也会造成不同程度的损失，对于OPC通信而言，出现任何中断情况，Tunneller连接方式和DCOM连接方式的结果是不同的，为了展示这种区别，现在我们将服务器端连接的网络断开。
然后马上客户端这边的电脑上OPC Explorer会出现卡顿，并提示DCOM连接错误了。
关闭此窗口后还能发现DCOM连接下的group2已经不见了，但是上面Tunneller连接下的group1还在，查看后发现，group1的数据标签依然可见，只是数据质量（Quality）变成了”Bad”，并且没有刷新了，时间戳停止在断开连接的时间点上。
接下来重新把服务器端的主机连接回网络。马上可以看到Tunneller方式下的group1里的数据标签恢复正常刷新，数据质量也变回了”Good”。但是DCOM方式的原group2并未能恢复，需要重新进行添加。
结论
从这个简单的实验即可看出Tunneller连接的稳定性要强于DCOM连接的，由于人为的误操作或者网络波动造成连接的短暂断开是可能发生的，使用Tunneller连接方式将使工程师无需担心短暂的计划外的断开连接，因为它可以随时自动恢复。可以将损失降到最小，如果网络出现了故障也可以通过数据质量的变化和数据更新的停止来提醒工程师进行错误排查。而传统的DCOM连接方式遇到类似问题会直接销毁所有的客户端数据访问的配置，恢复之后需要工程师重新添加分组和标签，相比起来这种方式非常的麻烦。由此可见Tunneller连接方式相比DCOM连接是更加稳定且方便的。