小言_互联网的博客

关于OPC UA Pub / Sub的两三事

293人阅读  评论(0)

OPC UA 技术解决工业现场数据通信标准不统一的问题,使得不同操作系统和不同制造商的设备之间可以进行数据交互,是实现工业4.0不可或缺的一环。

多年来,虹科工业物联网团队学习钻研国际先进OPC UA相关技术,已有丰富知识和经验, 为行业内诸多用户提供OPC/OPC UA从硬件到软件的不同方案,并致力于服务智能工厂和工业4.0升级改造项目。

Pub/Sub模式是什么

当OPC UA使用Pub / Sub(发布订阅)模式来进行通讯时,OPC UA程序之间不再直接建立连接并相互发送请求和响应,而是采用如下的方式进行通讯:

其中提供数据的OPC UA程序作为发布者,将消息发送到面向消息的中间件,而无需知道订阅方是谁;而对其中特定类型的数据感兴趣的另一方OPC UA程序,则作为订阅者订阅对应消息,并通过处理消息获取到想要的数据,在这个过程中,同样无需知道发布方是谁。

而这里的“面向消息的中间件”,指的是在分布式系统中支持收发消息的软件或硬件基础设施。至于具体来说是软件还是硬件,是什么软件,或者是什么硬件,就要看这个分布式系统是如何组织起来的了。

对于大部分使用场景,中间件的表现形式可以分为截然不同的两种:

  • 无代理形式,此时中间件是支持转发相关数据消息的网络基础设施,这种形式的典型通讯协议为UDP多播。
  • 有代理形式,此时中间件就是其中的消息代理,发布方和订阅方分别使用比如AMQP、MQTT等标准的消息协议与消息代理进行通讯。所有发布的消息会进入消息代理的特定队列,而订阅方通过监听这些队列获取消息。此外发布方和订阅方可能使用不同的通讯协议,在这种情况下,消息代理将充当翻译的角色。

为什么使用Pub/Sub模式

总的来说,在Pub / Sub模式下,作为发布方和订阅方的OPC UA程序在网络上被解耦开来,无论多少个订阅者对同一发布者进行订阅,都不会对发布者本身造成影响。这一特性使得Pub / Sub模式特别适合于那些在地理位置上需要独立性,或者对扩展性有要求的应用场景。

上面这样讲,大家可能还是有点懵,那我们就来假设一个具体的场景:我们有4个支持OPC UA的PLC设备,另外有两个边缘设备(我们假设都是边缘网关)需要分别和这4个PLC进行连接通讯,那么如果我们采用传统的C/S模式进行连接,连接关系将如下图所示:

图中每一条绿线代表一个基于TCP的OPC UA连接,采用传统的C/S模式时,每个服务端需要分别与每个客户端建立连接。在4个服务端与2个客户端之间建立连接,就已经需要建立4×2 = 8个连接了。可想而知,如果实际情况是两个边缘网关连着几十个PLC,那么将需要建立上百个连接,若画成图,线就恐怕多到看不清了。

建立与维护这种级别的连接数量对于配置较为现代的工控机来说,不是太大的问题,但对于性能有限的嵌入式设备,如PLC和小型边缘网关,又或者较老的工控机来说,这将是一笔不小的性能开销,进而又会对系统采样率造成负面影响。

此外,如此之多的连接,也会对管理带来额外的成本,比如说,当我们需要更换一个边缘网关时,就可能需要重新配置数十个PLC的OPC UA连接。

而如果采用新的Pub / Sub模式,那将会是下图这种效果:

此时作为发布端的每个PLC只需要配置好与中间件的连接,并设定好一个“话题”,而作为订阅端的边缘网关,同样只需要连上中间件,即可在相应的“话题”下获取到对应数据。

在Pub / Sub模式下,对于每个PLC而言,无论有多少个设备订阅它发布的信息,都不会增加其性能负荷(当然,相应地中间件性能负荷会增大)。

如此一来,便可以实现网络上的解耦,轻松实现点对多点的数据传输,降低系统的建立与维护成本,同时为未来的扩展提供极大的便利性:比如将来需要建立PLC到PLC的直接通信(M2M),则只需要为PLC更新固件,使得PLC除了发布信息外能够从中间件订阅信息即可,无需增加链路,也无需对网络其他部分进行改变。

此外,Pub / Sub模式也并非与原本的C/S模式互斥,同一个设备可以同时与别的设备建立C/S模式和Pub / Sub模式的连接。下面,我们借用OPC基金会规范说明书中的图来进行说明。

上图中,最下方的大方框是一个设备,同时充当了Pub / Sub模式连接的发布端和C/S模式连接的服务器端,OPC UA程序管理着一片地址空间,通过C/S模式与客户端A进行连接时,需要建立一个会话,并且为这个客户端特地准备一份它感兴趣的数据;而通过Pub / Sub模式和其他设备进行通讯时,则先将所有需要发布的数据统一发布到中间件,然后各个订阅设备则按需获取自己感兴趣的内容。

怎么实现OPC UA Pub/Sub模式

在讨论具体操作之前,我们应当注意,OPC UA规范中的PubSub模型,按照采用不同的中间件,有4种不同的实现方式:分别是UDP、专用以太网帧、AMQP、MQTT。

UDP指的是通过UDP的单播、多播、广播方式传输UADP(UA DatagramPacket,一种OPC UA专有的二进制数据格式数据包);专用以太网帧则顾名思义使用特殊的以太网报文类型来传输UADP;AMQP和MQTT则分别利用标准的AMQP和MQTT协议中间件传输数据。

目前直接支持OPC UA Pub / Sub模式的软硬件较少,若需实现,一般需要通过支持Pub / Sub模式的OPC UA SDK开发相应固件或软件来实现。

目前来说,开源的open62541 SDK在1.0以上版本有限地支持了该特性,仅支持UDP这一种方式,并且尚未通过OPC基金会的认证,因此仅建议在学习、科研等非生产环境使用。对于实际工业生产环境的客户,我们更加推荐使用商业版的SDK。

新品预告

广州虹科将于5月正式推出新版本的Matrikon UA FLEX SDK,该版本SDK将支持Pub/Sub模式的开发,具体来说包含了UDP和MQTT两种协议的实现方式,且通过了OPC基金会的认证,这使得原本就以高性能、低占用、高稳定性而著称的Matrikon UA FLEX SDK能拥有更强大的功能性和扩展性。

届时,您可以联系广州虹科获取为期一个月的新版SDK免费试用。基于MQTT协议的Pub/Sub模式实现,也使得OPC UA能利用上现有丰富的MQTT生态环境,进一步加快OPC UA乃至工业4.0的推广。


转载:https://blog.csdn.net/Hongke_IIOT/article/details/114261312
查看评论
* 以上用户言论只代表其个人观点,不代表本网站的观点或立场