There are several different architectures and protocols that can be used to gather data on the factory floor. The two most common protocols are very different, which makes them worth comparing for their effectiveness in IIoT – OPC UA and MQTT/Sparkplug.
IIoT Protocols: Comparing OPC UA to MQTT
Arlen Nipper, President and CTO | Cirrus Link
Many manufacturers have chosen a protocol based on the existing architecture in their environment. If they have a SCADA system, they tend to use OPC or OPC UA. However, new manufacturers or those looking to digitally transform should consider MQTT/Sparkplug to solve modern challenges and adopt an IIoT solution that can handle any number of data producers and consumers across the enterprise with ease.
OPC UA
OPC classic was released in 1996 and was designed to abstract PLC-specific protocols into a standardized interface to allow SCADA systems to access the data. It was originally developed for Windows, and traditionally requires a dedicated Windows PC to exchange OT data with legacy systems on a local area network. OPC uses a client/server architecture where the OPC server converts the hardware communication protocol, then any program that needs to connect to the hardware becomes the OPC client. However, a call for scalability and a platform-independent architecture led to the development of OPC UA.
OPC UA is the next generation standard from the OPC Foundation, released in 2008 as an update to the original OPC interoperability standard for secure and reliable exchange of data in industrial automation. According to the OPC Foundation, “With the introduction of service-oriented architectures in manufacturing systems came new challenges in security and data modeling. The OPC Foundation developed the OPC UA specifications to address these needs and at the same time provided a feature-rich technology open-platform architecture that was future-proof, scalable and extensible.”
OPC UA aims to expand interoperability to the device and enterprise applications and recently adds publish/subscribe to the original client/server communications infrastructure. The spec also attempts to remove the requirement for a dedicated Windows PC by permitting a server to be embedded into an edge product. The OPC Foundation open sourced the OPC UA standard to increase adoption.
OPC has a number of limitations, which OPC UA tries to solve. Consider the following challenges before implementing an OPC or OPC UA architecture.
Complicated: The most common complaint about OPC UA is how complicated it is to implement. The OPC UA spec is 1250 pages. Many companies don’t implement the full OPC Server, and even if they do it also requires routers, firewalls and VPN. New devices must be configured and connected rather than auto-discovered.
Heavy: When an OPC server talks to a client, since the subscriptions are not reported by exception but traditionally use a poll/response protocol (other than a very few modern OPC UA implementations), they are very heavyweight. A lot of devices that support OPC cannot handle a lot of subscriptions which limits the number of data consumers on the system. Even though it is heavy, OPC data only comes with basic tags and values – no meta data or objects.
Inflexible: The shop floor is becoming increasingly varied – with both modern and legacy devices, different operating systems, network architectures, and more. OPC has a hard time handling these varied data structures and heterogeneous devices. The focus is on OT data and the solution falls short for big data analytics applications, since it only collects OT data and not IT.
Expensive: When OPC UA is fully implemented it is very expensive and heavy. The architecture requires embedding an OPC UA server into products which increases the cost and time-to-market, increases the footprint size, CPU utilization, development costs and ongoing support costs.
Lack of Vendor Support: OPC has been around for many years, but many IIoT technologies do not come with native support for OPC connectivity. Microsoft is the only cloud vendor that uses both OPC UA client-server connections as well as the new OPC UA publish-subscribe connections. Hardware vendor participation has been lackluster and there are only a few OPC UA software clients available.
Struggles with Multiple Data Consumers: OPC architectures struggle to supply all of the data to multiple data consumers. An OPC UA server does provide one-to-some capabilities but does not do the real decoupling needed for one-to-many. In addition, most implementations don’t include meta tag data, which once again means it falls short on getting data to IT functions in a usable format.
(7).png)
Figure 1: Traditional SCADA systems isolate OT data and can’t handle multiple data consumers
A traditional OPC system is shown in Figure 1, where SCADA owns the data path that was built for operations, or OT data. When new consumers request OT data, new application or custom code is written to get the data out of SCADA. As new data consumers are added, a brittle enterprise of applications is built that is costly to manage and becomes too complex to change.
Use Cases: Traditional discrete and process manufacturers are the ideal use case for OPC. Without any distributed assets it is harder to make a case for switching OPC out for MQTT. If the shop floor is already built as a SCADA system and it is working, then OPC or OPC UA work as well. However, any shop floor that wants to implement advanced technologies such as machine learning, AI, or predictive maintenance will have a hard time with OPC UA. It was not made for these modern challenges.
A Deeper Look at MQTT
MQTT is a transport protocol invented in 1999 as a lightweight, publish-subscribe network protocol that allows for multiple data consumers and is designed for constrained devices and low-bandwidth, high-latency or unreliable networks. MQTT is based on a message-oriented middleware approach. Sparkplug is an open source software specification that provides MQTT clients with a framework to integrate data – defining a Topic Namespace, State Management, and Payload to make the data interoperable for IIoT applications.
MQTT was invented to serve multiple data consumers and multiple data producers. In order for Digital Transformation to be successful, data must be decoupled and provided over an enterprise-wide solution architecture. MQTT allows for multiple data consumers (Figure 2). Companies can publish the data from a manufacturing asset and multiple applications can consume it, all at the same time.
(5).png)
Figure 2: The basic MQTT architecture allows for unlimited clients over a publish/subscribe protocol.
Cirrus Link recently created a specification within the Eclipse Tahu project called Sparkplug that defines how to use MQTT in a mission-critical, real-time environment. Sparkplug defines a standard MQTT topic namespace, payload, and session state management for industrial applications while meeting the requirements of real-time SCADA implementations. Sparkplug is an open standard that is license-free to use and builds on 20 years of experience of how to use MQTT. The Sparkplug B specification provides the context data needs to define a tag value for use with OT, also providing data to IT, making it 100% self-discoverable and easy to consume.
Utilizing MQTT with the open-standard Sparkplug allows OT data to be consumed with simple configurations on proven software tools that securely bridge the OT/IT gap and provide contextual information for the data scientists to use Big Data Analytics, ML, and AI to gain insight and increase productivity and profit. The following points explain how MQTT solves the pain points not addressed by OPC UA.
Simple: The MQTT spec is 80 pages and Sparkplug adds another 60. Developers can follow the spec and implement it on their own, within a few days or weeks. MQTT is very easy to implement since devices can be added and auto discovered and there is a great deal of reference code that makes it easy for anyone to get MQTT running.
Lightweight: MQTT reports by exception, minimizing the data footprint and leading to more efficient communications. The protocol overhead is extremely small, the smallest packet has only 2 bytes of overhead. With Sparkplug, MQTT also includes the essential meta data with no additional work required, and still keeps it lightweight.
Flexible: MQTT is based on a pub/sub model that decouples data publishers from consumers, which means subscribers do not need to know who provides the information to which they are subscribed. The message can be in any data format for the payload, such as JSON, XML, encrypted binary or Base64, which gives a lot of flexibility to the protocol.
Cost-Effective: IIoT powered by MQTT provides a cost-effective solution for access to data on brownfield devices. MQTT can transport the data from a sensor, to a device (such as a PLC), to an Edge gateway, and then up to the SCADA/MES system on the factory floor.
Secure: MQTT provides security in several ways starting with client usernames and passwords required to login. MQTT uses the most current TCP/IP layer security available which today is TLS. Next the connections are remote originated, so no ports are open in the field and only one port at the main firewall is connected to the broker. Access Control Lists (ACLs) only allow known remote devices to connect.
Vendor Support: The number of vendors natively implementing MQTT-Sparkplug, both on the hardware and software side, is growing rapidly. All of the leading cloud vendors, IoT platforms, edge computing platforms, big data and other third-party applications support MQTT. Progressive cloud providers are implementing Sparkplug to give auto discovery data modeling.
Supports Unlimited Data Consumers: Moving to a publish/subscribe model with MQTT enables the transition from a one-to-one to a one-to-many approach, encouraging innovations while making it easy to adopt new technologies. Data producers publish the data in Sparkplug B format to an MQTT server. The MQTT server enables those who have secure access to subscribe to the data. The OT application will subscribe to the data instead of polling for it.
Use Cases: Customers in oil & gas, telemetry and energy were the first to see the benefits of MQTT where it was originally invented. Polling widely dispersed assets for their data does not make sense in today’s world of IIoT. MQTT allows any data consumer to easily subscribe to the data and pub/sub saves bandwidth and simplifies the solution. However, discrete and process manufacturers who may be committed to OPC or OPC UA can also realize the benefits of MQTT when it comes to sending data to the cloud and integrating with big data applications.
OPC UA and MQTT Can Work Together
It is important to note that OPC UA and MQTT can actually work together harmoniously. They may be polar opposites in the way they move data around, but there are still old devices that need an OPC server to share data and there is a way to use MQTT to overcome the challenges presented. With a sensor connected to a legacy PLC, IoT platforms can connect and translate that data into MQTT, move it across any type of network in a pub/sub model, and then either send it to the cloud and enterprise apps, or some IoT platforms will translate it back into OPC for legacy OPC clients.
Hardware vendors have to support both OPC UA and MQTT/Sparkplug, to bridge between the old and the new. OPC still has a place on a constrained, private network and for a point-to-point connection where multiple data consumers are not necessary, and it still has a stake hold on the OT side. OPC still has a place for a customer with a private network who is not interested in adding new technologies and new capabilities for a connected plant floor.
However, if a manufacturer has a choice of purchasing devices that support pub/sub with Ignition Edge or native support for MQTT/Sparkplug, an MQTT implementation requires less effort, less money, and less time than OPC. Using MQTT allows customers to embrace newer IoT technologies and software like big data, machine learning, and more. Just as HTTP and HTML worked together to enable the rapid expansion of the Internet, so does MQTT and Sparkplug, providing users with a modern option for interoperability of data on the shop floor.
The content & opinions in this article are the author’s and do not necessarily represent the views of ManufacturingTomorrow
Comments (1)
Featured Product
