背景
经常有人会烦恼这个问题：我的上位机软件什么功能都有，也支持OPC UA了，现在项目上准备用OPC UA的方式来获取我的PLC的数据，但是我的PLC却不支持OPC UA，怎么办呢？有的人碰到这个问题后就开始了“病急乱投医”，听说哪里有OPC UA的SDK赶紧去了解要资料，最后问报价一个SDK可能要几十万不说，还需要自己做动辄几个月的开发，心想：这哪行啊我这项目等不了，我就想要个现成的解决方案来给我把这个OPC UA服务器搞上去就行……
这种情况不在少数。随着OPC UA逐渐在工业自动化应用中扮演重要角色，越来越多的应用场景下都在要求用OPC UA的方式去采集数据，这对于一些对OPC UA知之甚少的技术人员来讲是个不小的挑战，他们可能是工业现场的专家，熟悉多种多样的通信协议，但是现在可能连OPC Classic(区别于OPC UA的经典OPC)和OPC UA都分不清，花了不少时间了解之后去找OPC UA解决方案的供应商，一看没有现成的可拿来直接用的OPC UA服务器，但是有OPC UA SDK，看到SDK就感觉这应该是自己需要的，最后就出现文章开头出现的情况，然而事实上这些人都不是SDK的目标客户。
挑战
如果我现在需要用OPC UA的方式来采我的PLC数据，但是我的PLC不支持OPC UA，或者PLC没有购买OPC UA的授权应该怎么办？我的HMI比较旧只支持OPC Classic，但是我现在有新的OPC UA的设备需要读数据又应该怎么办呢？
解决方案
应该有初学者曾经尝试过用OPC Classic的客户端去连接OPC UA服务器吧（或者用OPC UA客户端去连接OPC Classic服务器）。然后发现根本搞不了，后来才明白这是两个不同的东西。可是如果现在有一个软件可以将OPC Classic的服务器或者客户端“包装”成OPC UA，让两头都是OPC UA了，那不就能完成通信了吗？
OPC UA Tunneller就是实现这样功能的软件。之前我们讲过OPC Tunneller解决的是OPC Classic通信里DCOM配置的问题。当OPC UA出现之后，它又新加入了打通Classic和UA通信鸿沟的功能。
如上图所示，在OPC Client这边加上一个OPC UA Tunneller后，左边整体可以被视作一个OPC UA Client与右边的OPC UA Server进行通信，反之亦然。
如此一来的好处就是如果实际应用中有需要用到OPC UA的情况，多了一种简单易用的选择。本身当我们描述OPC UA Tunneller功能的时候，我们说它可以帮助新的OPC UA功能去访问/提供数据向/给旧的OPC Classic功能，换一种角度来看，实际上它是给了旧的OPC Classic功能向OPC UA迁移的方法，不仅仅是说能够让OPC Classic组件和OPC UA组件建立通信这么直接，而是可以通过OPC Classic+OPC UA Tunneller的组合做到了让那些本不支持OPC UA的旧设备接入到OPC UA的网络中来。
现在正在被使用中的来自各家品牌的PLC有很多，那些最新的而且已经**了OPC UA服务器功能的PLC尚且不谈，实际使用中还有很多用了很多年的PLC，现在被计划接入其他组态软件或者工业自控平台，对于这些设备，我们只要在工业现场的Windows系统电脑里安装所对应品牌PLC的OPC服务器（其他兼容型OPC服务器对于不同品牌PLC也要分开授权，大同小异），然后再安装一个OPC UA Tunneller，OPC服务器通过IP连接到PLC，添加好数据tags，再将这些OPC服务器通过Tunneller包装后变成UA服务器，OPC UA客户端就能够与其建立起连接，整个过程只需要安装软件+**+配置，不需要做任何开发，甚至都不需要去深入了解学习OPC UA，这个目标就完成了。
结论
可以预见的是，从OPC向OPC UA的迁移是一个漫长且必要的过程，在这个过程中，那些遗留设备的去留将是实现工业自动化的痛点问题。本文前面所谈到的例子应该是不少读者正面临的问题和需求。OPC UA tunneller打通OPC Classic和OPC UA通信的能力必将在这一过程中扮演重要角色。