Most, if not all, industrial organizations are currently looking at strategies and technologies to use for their digital transformation journey. Many acronyms have been coined to describe the notion of the underlying technologies for Digital Transformation including the Industrial Internet of Things (IIoT), Industry 4.0, Digitization, or Machine to Machine.

Regardless of the acronyms you want to use, the ARC Advisory Group defines digital transformation as: “The transformation of industrial products, operations, value chains, and aftermarket services that are enabled through the augmentation of people and knowledge, through the expanded use of sensors, data and analytics.”

The notion of digital transformation is fantastic, but we’ve seen a huge gap between the “promise” and the “reality”. The reality is that we have more than 45 years of existing Operational Technology (OT) devices, protocols, and infrastructures that will be in place for at least the next decade. That legacy installed base is throwing companies into the classic Gartner Hype Cycle called the “Trough of Disillusionment.”

Consider these insights from the World Economic Forum:

• “84% of business leaders expect the IIoT to disrupt their operating models within the next 5 years.”
• “7% of these leaders have a comprehensive IIoT strategy.”
• “73% of these leaders admit to having none at all.”

We’ve got a problem!

Digital transformation can only become pervasive across the industrial sector when the technology provided by the Internet of Things matches the technology that drove the Internet of People. If we look back and think about how the explosion of the Internet of People took place, it was squarely based on two open technologies:

• HTTP: Open technology that defined the transport of data.
• HTML: Open technology that defined the “context” of the data being transported.

What this article explores is using the same model and applying it to the Industrial Internet of Things. In this context, we’ll look at the following technologies:

• MQTT: Open technology that defines the transport of data.
• Sparkplug: Open technology that defines the “context” of the data being transported.

MQTT has taken the lead

If you Google MQTT, you’ll see that it has emerged as a dominant IoT message transport for:

• AWS IoT
• Google Cloud Platform
• IBM Watson IoT
• Microsoft Azure IoT Hub
• SAP Leonardo

All of these services are providing native MQTT connectivity for the purpose of ingesting IoT machine data for Digital Transformation. More and more device manufactures and solution providers are implementing MQTT-based products. The awareness of MQTT as a simple, efficient, and massively scalable architecture was made apparent when Facebook adopted MQTT as the backbone message transport for Facebook Messenger eight years ago: “One of the problems we experienced was long latency when sending a message. The method we were using to send was reliable but slow, and there were limitations on how much we could improve it. With just a few weeks until launch, we ended up building a new mechanism that maintains a persistent connection to our servers. To do this without killing battery life, we used a protocol called MQTT that we had experimented with in Beluga.

MQTT is specifically designed for applications like sending telemetry data to and from space probes, so it is designed to use bandwidth and batteries sparingly. By maintaining an MQTT connection and routing messages through our chat pipeline, we were able to often achieve phone-to-phone delivery in the hundreds of milliseconds, rather than multiple seconds” (https://www.facebook.com/notes/facebook-engineering/building-facebook-messenger/10150259350998920/)

The Eclipse Foundation has been running a survey over the last five years asking the developers of IoT/IIoT devices, solutions, and services about what message transport protocols they are using in their solutions.

The results

So on the face of it, it appears that MQTT was developed for IT and IoT solutions. The reality is that actually is not the case. MQTT was developed specifically to solve OT problems first and foremost.

MQTT is not a bleeding edge technology just developed in the last few years around the hype of IoT. It was actually developed over 20 years ago to solve an industrial problem that Phillips 66 was trying to address as it migrated from a legacy poll/response infrastructure over dedicated 300 baud 4-wire modem circuits to more modern TCP/IP networks for its mission-critical, real-time, pipeline SCADA system.

The original design goals of MQTT for Phillips 66 were that it would be: simple, efficient, stateful and open.

Simple

When MQTT was first being developed, the hardware platforms available on the market for remote edge computing were very minimal. The 8-bit microprocessors with 64 kilobytes of memory were the norm. With these constraints, MQTT had to be simple to implement with minimal compute resources. Even in 2019, Arduino microcontrollers provide complete MQTT communication stacks.

Efficient

Early VSAT system providers charged for every byte of information sent and received. The MQTT transport had to provide minimal overhead on the network. Once an MQTT session is established, there is only a 2-byte overhead in messages being published.

Stateful

If you’re providing infrastructure for mission-critical, real-time infrastructure, the “state” of the MQTT TCP/IP connection is critical. MQTT has a mechanism called “Continuous Session Awareness,” which provides real-time state information of the MQTT connections.

Open

In the late 1990s SCADA/DCS/Telemetry products where mainly based on proprietary legacy poll/response protocols. For MQTT to be useful to the industry as a whole it was understood that when it was released, it needed to be a completely open specification that anyone could implement for free.

With today’s awareness of Internet security issues, one might look at the MQTT requirements and ask where the security is specified. The simple answer is that the MQTT specification is based on top of TCP/IP.

The issues of cybersecurity were almost non-existent in 1998, but TCP/IP has withstood the test of time and best practice security can be applied to any MQTT infrastructure. Also note that since MQTT is a “Remote Originated” TCP/IP socket connection, edge devices and application clients do not even have to have any TCP/IP ports open. This is a huge reduction in the overall cybersecurity footprint.

Backed by international standards

Before we proceed to the payload definition for MQTT it would be good to mention the standards that are in place for MQTT from an international standpoint.

The first standards body that the MQTT community engaged was the OASIS standards body. OASIS has ratified MQTT as an International standard: https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt.

MQTT has been ratified by ISO/IEC as well:
https://www.iso.org/standard/69466.html

Sparkplug: industrial strength MQTT

An important aspect of MQTT is that the specification does not specify the message Topic Namespace nor does it define a required message payload data representation. That means that with MQTT you can publish any type of data on any topic. It could be a binary message from a PLC, a JPEG image or a JSON string. MQTT leaves the encoding and interpretation of the payload to the solution provider.

As MQTT-based solutions have started to migrate to critical IIoT solutions from device OEMs to solution providers, the need to specify the Topic Namespace and payload representation became very evident. The industry needed a specification allowing multiple vendors of MQTT-based hardware and software to interoperate efficiently. The Sparkplug specification does just that for the IIoT market.

The Sparkplug specification was originally developed by Cirrus Link Solutions to help define how best to get started using MQTT for OT and SCADA applications.. Very simply, the Sparkplug specification defines:

1. A well-known MQTT Topic Namespace so that publishers and subscribers of information know the Topic Namespace in advance for interoperability.
2. A binary payload optimized for industrial process variables. The Sparkplug specification acknowledges that industrial infrastructures do not have unlimited bandwidth and must work well over VSAT, radio, and cellular infrastructures as well.
3. How the state management in MQTT works, and how to effectively use it in SCADA/DCS/ICS solutions to know the state of all MQTT clients in real time.

The entire Sparkplug specification and all of the reference implementation code written in C, Java, Javascript, Python, and Node Red has been contributed to the Eclipse Foundation and a complete open-source project. The Eclipse project is called “Tahu.” More information can be found at: https://projects.eclipse.org/projects/iot.tahu.

Conclusion

Digital transformation in the industrial sector is not going to happen overnight. The fact that 40 years of brownfield OT infrastructures, protocols, and solutions exists means that migration strategies will need to be developed and put into place addressing the complexity of these OT systems. Given the pervasive use and knowledge of MQTT in the IT space and the adoption of the Sparkplug specification by device OEMs and solution providers in the OT space, the enablement of digital transformation can be achieved!

The MQTT Specification

https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt

Arlen Nipper, President and CTO of Cirrus Link Solutions