If you are getting involved at all with the industrial Internet of Things (IIoT), you are bound to see a new acronym being used all over the place: MQTT. While MQTT is fairly new to automation, it has been around for more than 20 years. It was originally developed as a protocol to get data from remote oilfields, but until recently, it never gained much adoption outside of this niche application. It is now emerging as one of the main protocols for digital transformation projects for manufacturing.
MQTT stands for Message Queuing Telemetry Transport. It is a client server publish/subscribe messaging transport protocol, considered to be a lightweight messaging protocol for sending small packets of information in limited bandwidth applications. At its core, it is considered an OASIS standard at the heart for IoT connectivity.
In the late 1990s, there was a need for a lightweight communication protocol that would be able to transmit data from remote oil sites with extremely low connection speeds, perhaps as low as 300 baud. The strategy was to take advantage of capabilities already offered in the transport layer, which used the TCP protocol. The proposed application protocol would remove any redundancy that added to the transmission payload. It also needed to be stateful, and only report by exception. With these constraints in mind, Phillips 66 worked with Arlen Nipper from Cirrus Link Solutions and Andy Stanford-Clark from IBM to develop what is now known as the MQTT protocol.
While automation companies were approached with the MQTT protocol in the early 2000s, its only other commercial use was with the Facebook Messenger and Apple Messages applications. The main feature that was of interest is that the protocol ensures a state and quality of the data. When a sender was typing, the receiver would then see the now-all-too-familiar three dots on the screen. It was also used in some home monitoring and weather data applications, but at that point, the use of MQTT was rather limited.
In the mid-2010s, Arlen Nipper once again approached automation companies to promote the use of MQTT. There was an emerging need to get additional manufacturing data aggregated without significant network demand. However, there were some additional capabilities that needed to be developed in order to gain acceptance in manufacturing. Cirrus Link Solutions, along with Inductive Automation, proceeded with the development of what is now the Sparkplug standard, which includes attributes necessary for automation, namely a defined set of topics, a standard payload, and message compression.
MQTT uses a structure that is similar to the folder structure of a computer. I will use the Windows desktop as an example. The desktop has a folder called My Documents. In My Documents, there is another folder called Family, and in that folder is a folder for each family member. The path to my folder would be Desktop/My Documents/Family/David. I would save (publish) all of my documents to David. Anyone who wanted to read my documents would open (subscribe) to David.
Devices that use the MQTT protocol will publish and subscribe to a similar topic path called a namespace. Much like a computer, it is organized from most general to most specific. The higher the level I subscribe to, the more data I will receive. There are also wildcards that can be used to help define a topic path. An asterisk (*) includes everything from the current level and below. A plus (+) moves the path one level lower. I have included a couple of examples further down in the article.
The ISA-95 standard is well understood within manufacturing. It describes a standard model and terminology for the interface between enterprise and control systems. While it is generally realized as a hierarchy, starting with an ERP at the top and devices at the bottom, the standard mainly deals with manufacturing data and how it should be structured. Because MQTT uses a topic namespace, these can be readily aligned with ISA-95 hierarchy. It is recommended that a topic namespace should follow the Enterprise, Site, Area, Line, and Cell when it is constructed. The root folder of the publisher/subscriber should also exist at the proper level. For instance, a PLC that controls a cell should publish its data in a topic of Enterprise/Site/Area/Line/Cell. If a process historian is specific to an area, it should subscribe all data at the Enterprise/Site/Area level.
One of the common questions arising from the use of MQTT is what happens when there is a loss of connectivity. There are several options that can be used to mitigate these situations. A common solution is to use a "store-and-forward" method. For example, SCADA systems that are at the control layer will continue to collect data until the connection to the MQTT broker is resumed. It should be noted that when the broker connection resumes, the timestamps of all of the stored data remains intact.
MQTT also supports the use of backup brokers. While there is a primary broker, if this connection is lost, the connected nodes will automatically switch to another broker. The relationship is generally configured through an application (like a SCADA system) that supports this feature.
Another solution is achieved through the use of clustering. This is typical for applications that cannot afford any loss of data. A common setup is to have several MQTT brokers arranged in a cluster. All of these brokers are aware of each other and will share messages within the cluster. When connectivity is lost, publishers and subscribers of data will seamlessly route data to another broker without any loss.
It is a common for an enterprise application to use data from all of its plants. For this scenario, MQTT supports the use of bridging which is similar to a store-and-forward system. In this architecture, one broker will publish or bridge some or all of it namespace to another broker. Put another way, a plant broker would bridge to an enterprise broker. Both the published topics and namespace structure can be defined. This both limits the amount of data published and provides context for the receiving broker.
Publishing all data as-is with an asterisk (*) and not defining any structure is the simplest way, but this may result in a lot of unnecessary and potentially confusing data. In order to provide some data context, a topic can be added to the beginning of published topic namespace. For example, Enterprise/Site could be added to the plant Area/+/Cell namespace, which would result in Enterprise/Site/Area/+/Cell being sent to the Enterprise broker. The result is the Cell level data from all Lines would be available from this system (notice the use of the + wildcard).
All of these scenarios can be deployed. A SCADA system can use store-and-forward to an MQTT cluster. There could be primary and backup clusters, but this would likely add unnecessary complexity. Finally, a plant cluster can bridge to an enterprise cluster to maximize the integrity of the data. This is great for enterprise analytics and machine learning, as these require significant amounts of good-quality data.
One of the main concerns with sending and receiving manufacturing data across the internet is that of cybersecurity. While the only way to truly be secure is through the use of an air gap, this will prevent the ability of an organization to digitally transform. One of the key benefits of MQTT is that of security. While other communication protocols require the opening of network ports, MQTT only requires an outbound connection to the broker. Plants are not required to open any inbound ports, which is very attractive to IT organizations.
In future articles, I will explore common applications with MQTT. While the protocol is meant to be fairly plug-and-play, there will likely be interest in additional technical details. Business leaders may want to consider how MQTT will affect their current digital transformation efforts. And, of course, engineering leaders will definitely want to know how MQTT will impact them.
In closing, MQTT should not be considered a replacement to existing architecture. Aligned with Industry 4.0 requirements, it leverages what is already in place. There will continue to be a need for OPC UA and other protocols, as they are more verbose for control applications. However, when it comes to aggregating significant amounts of data, MQTT makes for an excellent choice.
This article is a product of the International Society of Automation (ISA) Smart Manufacturing & IIoT Division. If you are an ISA member who is interested in joining this division, please log in to your account and visit this page.