A Brief History of Manufacturing Connectivity
In a modern smart factory, it is not uncommon for hundreds or even thousands of data points to be generated every second. This data can come from a wide range of sources, including production machines, sensors, and other industrial devices. With the increasing use of connected devices and the Internet of Things (IoT) in manufacturing, the amount of data generated is only expected to increase.
As a result, the amount of data generated by manufacturing industries on a daily basis can be quite large, potentially reaching into the millions or billions of data points. The challenge for manufacturers is to effectively manage and make use of this data, so that they can gain insights into their operations and improve their competitiveness.
What have manufacturers done so far to utilize this data?
Over time, multiple applications were invented to consume these data points to generate insights:
- SCADA (1970)
- Manufacturing ERP (1980)
- MES (1992)
- AWS (2006)
- etc.
However, sending Industrial data to these applications was difficult because different devices on the plant floor used different communication protocols. There were even differences in protocols between different device manufacturers (ex — Siemens and Mitsubishi PLCs). This created a growing need for a standardized method of communication.
How did we try to fix this?
There are two protocols that attempted to achieve interconnectivity through slightly different approaches: OPC-UA and MQTT. Note that there are other protocols but these two are the most widely recognized and adopted in the manufacturing industry.
OPC-UA
In 2008, the OPC Foundation, a foundation with 890 members including Rockwell, Microsoft, ABB, Siemens etc., developed the OPC-UA standard for open communication between industrial equipment. The goal of the OPC-UA standard was to define a message format that is open and platform agnostic. The typical implementation looks like this:
There is an OPC server that connects to edge devices like PLCs. This communicates with the application that needs the data which is called an OPC client. An example of your OPC client is your SCADA or MES system.
The picture above is how an OPC-UA message is formatted. OPC-UA is a toolbox of features. When you build a client or server, you will have to select which features you need. For instance, there are companion Information Models that are like drivers for certain devices (ex-the CNC companion spec can be activated to extract data from a CNC machine). There are also core information models like A and E which enable alarms and events etc.
The problem with this is if you want to achieve total interconnectivity, you need a tool that uses everything in the standard so it can talk to any client. This tool doesn’t exist. In addition, a lot of the features are contradictory which means that you can only have one or the other. You can make a product that only uses some of the elements of the standard that cannot communicate with another product that uses other elements of the standard.
The standard’s lack of documentation also makes it difficult to implement. It is only available to the members of the OPC foundation at a cost, making it an entry barrier for small and medium enterprises. Finally, it is a heavy protocol that consumes a lot of bandwidth.
This makes us question, is there something better out there?
Let’s revisit the past, a decade before the invention of OPC UA, to trace the birth of MQTT.
MQTT
In 1998, a company named Philips 66 needed a lightweight protocol to communicate with their remote stations and retrieve data in real time. To develop a solution, they approached an engineer named Arlen Nipper and asked him to collaborate with their IT manager. The IT manager was working with IBM’s MQSeries at the time and explained that MQ series was the new world of IT. Using MQ series, a sender application can publish a message to a specific topic (without worrying about who will consume it), and any receiver application that is interested in that topic can subscribe to it and receive the message. MQ series was a messaging middleware platform that essentially abstracted the connection between a sender and a receiver. Arlen wondered if this concept could be applied to Industrial data as well.
In 1997, a visionary from IBM named Tim Holloway was wondering the same thing. His “Argo project” explored this idea of publishing OT (operational technology) data without worrying about who the subscribers are.
Arlen eventually met Tim, who introduced him to IBM engineer Andy Stanford Clark, and together they developed MQTT.
With MQTT’s publish-subscribe architecture, industrial applications can send data to a broker without worrying about who will consume it. Now you can have the ERP, Historian, SCADAs and all the Industrial devices openly communicating with each other in real time.
This is the equivalent of having everyone present in a room and communicating with each other in real time
The implications of this are huge. With the ability to gather information from various sources such as ERP, SCADA alarms, operator data, raw material consumption, accounting data, etc., you can develop machine learning algorithms that can provide real-time suggestions for process improvement. You can now calculate Overall Equipment Effectiveness (OEE) with more precision, thanks to the availability of all the relevant data. Your ERP inventory counts will no longer be outdated, and you can automate the process of creating optimal manufacturing schedules.
OPC UA even came up with a publish subscribe specification in 2018 built on top of MQTT and listed the reasons why it was superior to their previous client server architecture.
Sounds great. What’s the catch?
The great thing about MQTT is that you can send anything over the protocol.
The bad thing about MQTT is that you can send anything over the protocol.
It was difficult for industrial applications to consume the data from multiple sources without processing it first . Different device manufacturers structured their MQTT messages in different ways.
Everyone is present in the room and communicating in real time but they are speaking different languages.
The solution to this problem emerged in 2016 with the invention of the SparkPlugB specification. This specification defines how to structure the topics in an MQTT message in a standard format. This helps with autodiscovery and enables plug and play applications. To see a concrete example of this, see my article on Microsoft Azure’s implementation of SparkplugB:
Medium.
Everyone is present in the room and communicating in real time using the same language.
Other features of SparkplugB include state management (ex- birth and death certificates) and the means to define a topic namespace. Though the SparkplugB specification is new, it is gaining adoption among vendors of Industrial equipment including Opto 22, Canary Historian, Phoenix Contact etc. It has also been adopted by the cloud vendors AWS and more recently, Microsoft Azure.
Wrapping up
In conclusion, the amount of data created by manufacturers, and the number of applications invented to consume this data has created the need for interconnectivity. MQTT and OPC UA were created to address this challenge, however both have their limitations. The advent of Sparkplug B has made MQTT a more robust solution to this problem. I look forward to watching the evolution of these protocols and hope to see continued increase in the adoption of Sparkplug B among industrial vendors.
