制造企业通常会根据自身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也是如此，为用户提供了一个现代的选择，以实现车间数据的互操作性。
