How to use MQTT to overcome obstacles to IIoT integration

End users struggle with specific pain points around digital transformation in the traditional technology stack. While traditional communication technologies will continue to be in demand, pairing MQTT with existing offerings can give users a way to evolve.

Your customers are working to create a digital transformation in theircompanies. They want more data. They want more insight. More than just supporting their processes, they now need equipment that delivers useful information and easily integrates as part of a cohesive data network extending from plant floor to executive office.

However, there are many obstacles to creating the level of integration required to fulfill that vision. Moving a single I/O signal from the field to the cloud requires a technology stack that includes many layers and involves many players. Each layer adds complexity, which affects the overall security and scalability of the system, not to mention added labor and cost (Figure 1).

Fortunately, new technologies are coming to the fore that bypass the traditional technology stack. There are several key technologies for machine integration called MQTT, a lightweight, publish-subscribe communications protocol for the internet of things (IoT). Including MQTT as an interface option multiplies the reach of machine data, providing new options to end users and even making direct-to-cloud integration a possibility.

UNDERSTANDING THE PROBLEM

Design engineers have multiple options for providing an equipment data interface. Many manufacturers, particularly of smallscale or off-the-shelf equipment, may use printed circuit board (PCB) designs including a serial or Ethernet I/O interface. A programmable logic controller (PLC) or industrial I/O gateway included in the electrical panel of larger or semicustom equipment is another option that gives some flexibility. In the case of custom-engineered equipment, the end user might require the designer to use a specific fieldbus standard for sensors and transmitters that is compatible with their plant control network.

In all these cases, however, the end user faces a similar set of challenges with unlocking the full value of equipment data.

First, communication protocols themselves impose some limitations. Proprietary protocols, obviously, inhibit interoperability, even if the manufacturer supplies a client application for communication with their device. To enable true integration, the manufacturer needs to offer a custom communications driver that can be incorporated into other applications. However, even common industrial protocols, like Modbus/TCP or Ethernet/IP, have limited compatibility with IT systems — where data is in highest demand — and require further software and hardware support for integration. The most common approach requires the use of an open platform communications (OPC) server with drivers for each type of protocol in use on the plant network. No problem, right?

An unfortunate by-product of this model is that the more the network grows, the more congested it becomes. Poll-response communication protocols, like the ones mentioned, on control and corporate networks send frequent requests for information to maintain a sense of the state of the system and to act on the latest data. Additionally, business applications accessing field data through an OPC network may be competing with industrial SCADA (supervisory control and data acquisition) or historian applications on the control network for bandwidth, with each making its own connection to field devices and requesting the same data over and over again.

All these one-to-one connections also create security issues, for which traditional industrial protocols and equipment, like PLCs, lack native support (Figure 2). Additional equipment and networking, like VLANs and firewalls, are required to provide security after the fact. Unfortunately, with many different protocols in use, network protections become peppered with exceptions or become so restrictive that largescale integration is impeded.

Speaking of large-scale integration, these communications systems, of course, do not maintain themselves. Every controller, every gateway, every server and firewall, needs to be installed, configured, and updated over time, rarely by the same person. Not only does that mean more personnel handling operating system updates and security policy configuration, on, it also means more cost in software licensing and upgrades.

With the influx of data required for highly connected, intelligent plant environments, plant engineers are looking for more scalable solutions; and OEMs who are looking to the future need to consider a different set of integration offerings for their equipment.

Figure 4: As MQTT grows in popularity, more industrial devices are appearing with embedded MQTT publishing options (Pictured: Opto 22’s groov EPIC controller and groov RIO I/O gateway)

ENTER MQTT

MQTT, formerly MQ Telemetry Transport, was developed in the 1990s under IBM’s Smarter Planet initiative to provide bandwidthefficient I/O communications for distributed SCADA projects in the oil & gas industry. Beginning in the early 2010s, MQTT grew in popularity to emerge in recent years as the top IoT-specific protocol. Since then, it has been enhanced for mission-critical industrial applications through an additional specification, called Sparkplug B (SpB).

What makes MQTT different? Efficiency. Cirrus Link Solutions, the company that developed the SpB spec, reports an 80-95% reduction in bandwidth consumption by users who move to an MQTT infrastructure.

MQTT achieves this efficiency using a radically different communication model from other protocols used for industrial applications and IIoT. Rather than establishing multiple one-to-one connections between master applications and slave devices, and then polling those devices repeatedly for information, MQTT establishes a shared server, known as a broker, as the endpoint for all field devices and applications (Figure 3). Devices publish data to the broker, but they do so only when a change occurs in a given process variable—a feature called report by exception. Network applications can connect to the same MQTT broker, subscribe to updates from any device, and the broker will deliver them as they occur. If a device goes offline, the broker also delivers that notification to any subscribers.

This publish-subscribe communication model allows for reliable, many-to-many communication with reduced network traffic overall, making MQTT the kind of scalable infrastructure that plant engineers are looking for.

MQTT is also inherently more secure than traditional protocols. With the MQTT broker as the single node in charge of routing all traffic, data access rights for the entire network can be managed in one location. And because MQTT connections are established by the device client, not the MQTT server, there is no need to create firewall exceptions for inbound MQTT traffic, even from outside the company network. With the addition of SSL/TLS encryption, MQTT traffic can be safely routed over public networks, and in fact, is the standard for all the major cloud IoT platforms, like Amazon Web Services, IBM Cloud, and Microsoft Azure.

But it is the OEM who unlocks the full potential of MQTT for end users, because direct support for MQTT in field devices and equipment produces the simplest integration experience.

GET ON THE BANDWAGON

Fortunately for manufacturers, MQTT was designed for use with resource-constrained devices, and as such, has a simple specification with a small in-memory footprint. Open source reference implementations of MQTT and Sparkplug B are available in many programming languages through the Eclipse Paho and Tahu projects, and can be incorporated into PCB firmware without royalties.

For manufacturers that use a dedicated gateway as a customer data interface, there are also MQTT-enabled controllers and I/O gateway options available (Figure 4). This approach can be used to combine communication functions with real-time control or visualization in one device, but it also has the advantage of tailoring data processing and publishing to end user requirements with greater ease. Where a firmware-based approach might require downtime to flash update memory, industrial controllers often support online editing.

Regardless of which approach you opt for, don’t overlook Sparkplug B compliance. Many MQTT device implementations fall short of this critical mark. SpB guarantees that a device uses a standard data format and encoding, improving interoperability, and that it publishes critical state information, improving reliability for mission-critical settings.

WHAT’S IN IT FOR ME?

There are also direct benefits to OEMs who provide MQTT support. Just like your end users, you might be interested in extracting useful information from your installed equipment base but likely face a similar set of complications.

Typically, monitoring remote equipment requires creating exceptions in local firewalls to permit outside connections through to the equipment. This can raise security concerns with end user IT groups. However, because MQTT connections are always deviceoriginating, it’s possible to establish secure connections to the outside that are transparent to your customers’ IT policies.

MQTT-enabled equipment can be pre-configured to establish a connection to a remote MQTT broker that you control, allowing you to securely monitor equipment usage for billing, regulatory, or troubleshooting purposes. This monitoring can be performed without requiring modifications to your customers’ local security measures and can be done in parallel to their own data collection. If you opt for a metered cellular connection, instead of piggybacking on your customer’s network, you can reduce your own transmission costs thanks to MQTT’s low bandwidth requirements.

Other scenarios are possible as well, like using a shared MQTT broker connection to exchange data between multiple pieces of equipment or provide equipment with live data from external web services. In one case, for example, wind farm operators can use the spot price of electricity to automatically adjust the output level of individual turbines.

LEAD THE CHARGE

End users struggle with specific pain points around the scope of digital transformation and the obstacles inherent in the traditional technology stack. Traditional communication technologies will continue to be in demand for some time, of course, but by pairing MQTT with your existing offerings, you give your customers a way to evolve. As the industry continues to shift in response to the demand for more data, tools like MQTT give designers the opportunity to position themselves at the front of that transformation.

Josh Eastburn, Director of Technical Marketing