Historically, industrial automation was isolated to local pieces of equipment or manufacturing locations. This was especially the case for remote operating locations such as pumping stations (see Figure 1). However, with the proliferation of consumer digital services delivered via mobile devices, Wi-Fi and high-speed cellular networks, many engineers are looking for similarly improved remote access capabilities with their industrial automation systems.
In recent years, mobile capabilities, remote access and more powerful edge computing options are being added to industrial control systems, devices and connectivity platforms. These technologies have created the industrial internet of things (IIoT) — networks of secure, internet-connected devices and systems working together to solve industrial problems.
One technology in particular, the MQTT communications protocol (formally known as MQ Telemetry Transport), has been gaining traction for IIoT applications because it securely and efficiently integrates devices, such as remote instrumentation and flow controllers, at the far edge of communications networks.
This article traces MQTT from its birth in the supervisory control and data acquisition (SCADA) industry to open source IoT and back to industry via the Sparkplug specification. The following briefly outlines what these technologies do, explores why they are so effective for industrial automation and IIoT tasks and identifies some helpful tools for getting started with them.
A brief history of MQTT
In 1997, ConocoPhillips (now Phillips 66) installed a TCP/IP VSAT infrastructure — for remote, satellite-based communication — as the transmission backbone for a SCADA system monitoring pipelines. Most SCADA systems require constant communications with field systems, and since VSAT carriers charged for each byte of data transmitted, the standard continuous poll-response communication protocols for SCADA were proving to be cost-prohibitive.
IBM Pervasive Computing partnered with SCADA engineering firm Arcom Control Systems to develop a solution to more effectively use the network for real-time pipeline data. The protocol they developed — later called MQTT — allowed telemetry data from remote sensors to be transmitted more efficiently and made it available to other areas of the organization (discussed later in more detail).
MQTT client code was released into the public domain in 1999. Ten years later, MQTT became available under a royalty-free license, and in subsequent years, v3.1.1 was adopted as an OASIS and ISO/IEC standard. MQTT has grown to become one of the most popular IoT-specific protocols for developers (see Figure 2).
It is used by or with popular consumer and enterprise applications such as Facebook Messenger, Raspberry Pi, Amazon Web Services and other major cloud computing services. It also makes smart energy, health and banking services possible.
All about the bandwidth
What is it about MQTT that has made it suitable for everything from SCADA host applications to millisecond chat services to home automation and smart enterprise infrastructure?
Think of it this way: When you are heading to lunch, you might send out a tweet with your plans. Friends who follow you on Twitter might see your tweet and respond back to coordinate a group lunch. So, with only intermittent communication and without knowing the details of anyone’s location or device, your whole group can meet. MQTT does something similar for data.
Due to the often-critical and always-on nature of flow control systems, constant communication has traditionally been required between devices. Once in service, traditional communication protocols poll devices cyclically at a predefined rate, and each device responds back with all of its data, even if nothing is changing in the field. This is called a poll-response model. It is great for maintaining a constant awareness of connection states, but it consumes a lot of data transfer capacity, or bandwidth.
MQTT uses a publish-subscribe model to significantly reduce the required bandwidth. In this model, each device on the network transmits (publishes) data only when it changes. All that data is sent to a central server, which is like a radio station, broadcasting updates but only to other network clients that have tuned in (subscribed) to receive these updates.
Clients, which can be software applications or other field devices, subscribe to only the data they need. Instead of requiring constant chatter, communication happens as needed, and state awareness is maintained with only a small heartbeat from each device over a persistent, secure connection.
What this means for remote equipment and IIoT applications is that even low-power devices on low-bandwidth networks can form smart integrated systems. They can scale up to millions of connections easily, and all data published by each device can be subscribed to by any number of client applications, such as maintenance databases, performance monitoring tools, inventory and financial systems, or cloud-based analytics platforms.
Sparkplug takes it to the next level
In parallel with MQTT’s development, one of its co-creators started Cirrus Link Solutions, which created an additional specification called Sparkplug to enhance MQTT for mission-critical applications. Sparkplug adds three requirements, each with corresponding benefits:
Standard topic namespace
MQTT devices publish data to an MQTT server as “topics” instead of address-based tags. Subscribers select the topics they want from the MQTT server and get updates on changes. A topic can be named almost anything, which provides a lot of flexibility but can make it difficult to manage large networks, especially if they include devices from many different vendors. Sparkplug ensures interoperability and discoverability by defining a standard naming format for topics.
Enhanced state management
The MQTT standard includes several mechanisms for staying aware of the state of each connection, but there is no guarantee that every vendor takes advantage of each mechanism. Sparkplug requires and expands these functions so the state of each client and its data can be shared from the time it joins the network, effectively ensuring all participants are always aware of the whole system state.
Data-rich payload
As a transport protocol, MQTT does not care what data it transmits, which contributes to its flexibility but requires each subscriber to know what the data format is in advance. Sparkplug defines a standard payload format, letting each subscriber know how to use any data it receives, whether it is user-defined data types (UDTs), datasets, historical data or file data; all of which can be enriched with useful metadata without compromising bandwidth.
MQTT and Sparkplug in action
For industrial automation and IIoT applications, Sparkplug combined with MQTT delivers a comprehensive solution. MQTT creates an efficient data-sharing infrastructure built on top of the industry-standard security protocols used with TCP/IP. Using Sparkplug-compliant clients ensures data payloads are organized and usable, with data and connection quality reported in real-time. See an example of a MQTT network in Figure 3.
The following examples show what this looks like in small- and large-scale applications.
Example #1: Simple remote data collection
A hydraulic fracturing operation in the Permian Basin uses a small group of mobile pump control skids for water management. Each skid is equipped with an IP radio device for local communication and a cellular modem for connection to a wide-area network (WAN). Telemetry data from the skid’s sensors and genset controller are gathered by an Opto 22 groov EPIC industrial controller, which normalizes the data and acts as a gateway to publish changes in pump status to the MQTT server.
Since each skid has only a few dozen data points, the integrator who designed the system chose to use a simple data connectivity tool called Node-RED, which is built into the EPIC. Node-RED is used to publish data to an open source MQTT server, Mosquitto, running in a cloud-hosted virtual server. Regardless of where the skids are located on a given day, they can relay data to the cloud for historization and analysis, and the entire network of pumps can coordinate control by subscribing to each other’s status.
Example #2: Distributed multisite SCADA
A geographically dispersed, multinational corporation hired high-cost networking consulting companies to build complex poll-response networks over leased circuits, metropolitan area networks, virtual private networks (VPNs), and more, to aggregate data from their many remote sites, such as plants, tank farms and warehouses. In some cases, the remote sites did not have the required IT staff to manage these connections, and the prospect of maintaining this network was becoming less feasible as growth and complexity increased.
To address these and other issues, this company is moving in a different direction. They have installed an enterprise-grade SCADA solution called Ignition, which can also act as an MQTT server for their global network. With low-cost, no-maintenance MQTT clients at each of their remote sites publishing production and status information on change via Sparkplug payloads, data collection across the globe can be managed by one IT group at corporate headquarters. Ignition also supports historization and redundant MQTT servers with automatic failover groups for robust fault tolerance.
Had they started with MQTT from the beginning, they could have leveraged existing public networks, since MQTT can apply user authentication requirements and transmit securely using SSL/TLS encryption and certification.
Conclusion
Unlike the common SCADA protocols of the past, MQTT relies on a publish-subscribe architecture that decouples data-producing devices from data-consuming applications and permits flexible, lightweight networks that facilitate data propagation across the organization. Because of this, remote equipment can be cost-effectively integrated into a smart network, creating new possibilities for management, engineering, operations and maintenance functions. These networks are inherently more secure and easier to design, deploy and maintain than networks built on the traditional poll-response communication models.
When looking to implement MQTT for equipment, engineers will find many open source tools available, such as those mentioned here. However, for mission-critical applications, engineers should evaluate the need for interoperability, real-time state management and rich data provided by Sparkplug-compliant hardware and software. These features may be particularly beneficial when integrating equipment from multiple vendors or retrofitting brownfield applications, and they are essential where scalability and fault tolerance are concerns.
Josh Eastburn is director of technical marketing at Opto 22. After 12 years as an automation engineer working in the semiconductor, petrochemical, food and beverage, and life sciences industries, Eastburn works with the engineers at Opto 22 to understand the needs of tomorrow’s customers. He is a contributing writer at blog.opto22.com.
