制造企业通常会根据自身IT/OT架构选择协议。 如果有一个SCADA/DCS系统,通常倾向于使用OPC或OPC UA。 然而,新起步的制造商,或是希望进行数字化转型的制造商不妨考虑MQTT/Sparkplug,并采用IIoT解决方案。
OPC UA
OPC Classes(经典OPC)于1996年发布,旨在将PLC特定的协议抽象为一个标准化的接口,从而允许DCS/SCADA等应用访问数据。 它最初是基于Windows环境开发,通过Windows服务器与局域网上的系统交换工业现场数据。 OPC使用客户/服务器架构,“OPC服务器”转换通信协议,需要设备数据进行应用的“OPC客户端”与“OPC服务器”进行数据获取。 随后,可扩展性、独立于平台架构(不限Windows)的呼吁导致了OPC UA的出现。
OPC UA于2008年发布,是对原OPC标准的更新,用于在工业自动化中安全、可靠的数据交换。
随着制造系统中引入面向服务的架构,在安全和数据建模方面出现了新的挑战。OPC基金会开发了OPC UA规范来解决这些需求,同时提供了一个功能丰富的技术开放平台架构,它是面向未来的、可扩展的和可延伸的。
OPC基金会
OPC UA旨加强工业设备与应用之间的交互,最近还在原有“客户/服务器”通讯基础中增加了“发布/订阅”功能。该规范还试图通过允许将服务嵌入到边缘硬件中来消除对Windows PC的要求。为了被更广泛采用,OPC UA是完全开放的标准。
OPC有许多限制,OPC UA试图解决这些限制。 但在实施OPC或OPC UA架构之前,需要考虑以下挑战。
- 复杂:对OPC UA最常见的抱怨是它的实施复杂。 OPC UA规范有1250页。许多公司没有实施完整的OPC服务器,即使他们这样做,也需要路由器、防火墙和VPN。 新设备必须被主动配置和连接,而不是自动发现。
- 沉重:当OPC服务器与客户端对话时,由于订阅不是通过异常报告,而用传统轮询/响应协议(除了极少数现代OPC UA支持订阅),它们是非常沉重的。 很多支持OPC的设备不能处理大量的订阅,这限制了系统中“数据消费者”的数量。 而且即使它消息包很重,OPC数据也只带有基本的标签和值 – 没有元数据或对象信息。
- 不灵活。车间正变得越来越多样化–有现代和传统的设备,不同的操作系统,网络架构,等等。OPC很难处理这些不同的数据结构和异质的设备。OPC重点是OT数据,该解决方案在大数据分析应用方面有缺陷,因为它只收集OT数据,而不是IT数据。
- 价格昂贵。当OPC UA被完全实施时,它非常昂贵和沉重。 该架构需要将OPC UA服务嵌入到产品中,这增加了成本和研发投产时间,增加了信息负担、CPU利用率、开发成本、运维成本。
- 缺少供应商支持。OPC已经存在多年,目前OPC UA的硬件供应商的参与度还不够高,只有少数OPC UA软件客户端可用。
- 与多个数据消费端的对接的能力。OPC架构努力向多个数据消费端提供所有的数据。 OPC UA服务器确实提供了一对一的能力,但没有做到一对多所需的真正解耦。此外,大多数实现不包括元标签数据,这再次意味着它不能直接以可用的格式将数据送到IT应用。
一个传统的OPC系统如上图所示,SCADA拥有为现场操控的数据(OT数据)。 当新的消费者要求OT数据时,新的应用程序或自定义代码被写入以获得SCADA的数据。 随着新的数据消费端的加入,集成管理成本很高,而且变得越来越复杂,不易改变。
使用案例:传统的离散制造和流程制造商是OPC的理想用例。 如果没有任何分布式资产,就很难有理由把OPC换成MQTT。 如果车间已有SCADA/DCS系统,并且它正在工作,通过OPC或OPC UA就可以工作。 然而,任何想要实施机器学习、人工智能或预测性维护等先进技术的车间通过OPC UA是不足够的。
深入了解MQTT协议
MQTT是1999年发明的一种传输协议,是一种轻量级的“发布-订阅”网络协议,允许多个数据消费者,是专为低带宽、高延迟或不可靠的网络的受限环境而设计。 MQTT是基于面向消息的中间件方法。 Sparkplug是一个开源软件规范,为MQTT客户端提供了一个整合数据的框架–定义了一个主题命名空间、状态管理和有效载荷,使数据对IIoT应用具有互操作性。
MQTT的发明是为了服务于多个“数据消费端”和多个“数据生产者”。为了服务于企业数字化转型,数据必须被解耦合,并在超出“企业内部架构”范围内进行处理。MQTT允许多个数据消费端。例如发布来自生产设备的数据,而多个应用程序可以消费这些数据,而且都是在同一时间。
Sparkplug的规范,定义了如何在关键任务、实时环境中使用MQTT。 Sparkplug为工业应用定义了一个标准的MQTT主题命名空间、有效载荷和会话状态管理,同时满足实时SCADA的要求。Sparkplug是一个免费开放的标准,并完全建立在20年来的MQTT使用经验之上。Sparkplug B规范定义了用于OT的标签值所需的上下文数据,也向IT提供数据。并使其100%可被主动发现,并易于消费。
利用MQTT与Sparkplug,可以在成熟的软件工具上通过简单的配置来消费OT数据,安全地弥合OT/IT之间的差距,并为数据科学家提供上下文信息,以使用大数据分析、ML和AI来获得洞察力。以下几点解释了MQTT如何解决OPC UA没有解决的痛点。
- 简单。MQTT规范有80页,Sparkplug60页。 开发人员可以在几天或几周内遵循规范并自行实现它。MQTT非常容易实现,因为设备可以被添加和自动发现,而且有大量的参考代码,使任何人都可以轻松地让MQTT运行。
- 轻量。MQTT只在例外情况进行报告,最大限度地减少了数据的占用,导致更有效的通信。协议的开销非常小,最小的数据包只有2个字节的开销。 有了Sparkplug,MQTT还包括基本的元数据,但仍然保持轻量级。
- 灵活。MQTT是基于发布/订阅模型,将数据发布者和消费者解耦,这意味着订阅者不需要知道谁提供他们所订阅的信息。 信息的有效载荷可以是任何数据格式,如JSON、XML、加密的二进制或Base64,这给协议带来了很大的灵活性。
- 成本效益高。由MQTT支持的IIoT为访问棕色设备上的数据提供了一个具有成本效益的解决方案。 MQTT可以将数据从传感器传输到设备(如PLC),再到边缘网关,然后再到工厂车间的SCADA/MES系统。
- 安全。MQTT以多种方式提供安全保障,首先是登录时需要客户的用户名和密码。MQTT使用最新的TCP/IP层安全,即今天的TLS。 其次,连接是远程发起的,因此在现场没有开放端口,只有主防火墙上的一个端口连接到经纪人。 访问控制列表(ACL)只允许已知的远程设备进行连接。
- 供应商支持。在硬件和软件方面,原生实施MQTT-Sparkplug的供应商数量正在迅速增长。 所有领先的云供应商、物联网平台、边缘计算平台、大数据和其他第三方应用都支持MQTT。领先的云供应商正在实施Sparkplug,给自动发现数据建模。
- 支持无限的数据消费者。通过MQTT转向发布/订阅模型,可以从“一对一”过渡到“一对多”的方式,鼓励创新,同时易于采用新技术。数据生产者以Sparkplug B格式将数据发布到MQTT服务器上。 MQTT服务器使那些有安全权限的人能够订阅数据。OT应用程序将订阅数据,而不是轮询数据。
使用案例:石油和天然气、遥测和能源领域的客户最先看到了MQTT的好处。 在今天的IIoT世界中,对广泛分散的资产进行大规模轮询式数据拉取是没有意义的。 MQTT允许任何数据消费者轻松订阅数据,pub/sub节省了带宽并简化了解决方案。然而,致力于OPC或OPC UA的离散制造商和流程制造商,在向云端发送数据并与大数据应用集成时,也可以实现MQTT的好处。
OPC UA和MQTT可以一起工作
OPC UA和MQTT实际上可以和谐地一起工作。 它们在传递数据的方式上可能是截然相反的。但仍有一些旧设备需要OPC服务器来共享数据,此时也是可以用MQTT的:在传感器连接到传统PLC的情况下,通过物联网平台可以连接并将数据转化为MQTT,以pub/sub模式发布到网络中,再链接到云和企业应用程序,或者通过物联网平台将其转化为OPC,提供到OPC客户端。
硬件供应商必须同时支持OPC UA和MQTT/Sparkplug,以便在新旧之间建立桥梁。OPC在受限的私有网络中仍有一席之地,在不需要多个数据消费者的点对点连接中也有一席之地,它在OT方面仍有一定的地位。 对于拥有私有网络的客户来说,OPC仍有一席之地,他们对增加新技术和连接工厂车间的新功能并不感兴趣。
然而,如果制造商可以选择对MQTT/Sparkplug支持的解决方案(参考数字基座:智工厂、智物联),那么MQTT的实施比OPC更简单、更便宜和更快。 使用MQTT允许客户接受更新的物联网技术和软件,如大数据、机器学习等。就像HTTP和HTML共同促成了互联网的快速扩张一样,MQTT和Sparkplug也是如此,为用户提供了一个现代的选择,以实现车间数据的互操作性。