经常有人会烦恼这个问题:我的上位机软件什么功能都有,也支持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通信的能力必将在这一过程中扮演重要角色。