I should have thought this through!

Enhancement to MQTT operation (Sparkplug B) has won me over – and getting run over by the bus of popular sentiment in automation is not the worst thing to ever happened to me. It’s not often that someone will go on LinkedIn and announce how they screwed up but that’s what I’m doing today.

Yes, I was wrong. But at least I find myself in very good company. You might recall this statement from Steve Ballmer, then with Microsoft:

"There's no chance that the iPhone is going to get any significant market share. No chance!"

Or this remarkable bit of stupidity in 1962 from an executive at Decca Records in the UK:

"The Beatles have no future in s show business. Groups are out;

 four-piece groups with guitars, particularly, are finished."

In my case, my ignorance goes back to a blog (https://www.rtautomation.com/enginerd-exclusive/) I wrote back in December of last year discussing this architecture:

I pompously described how Georgia Tech was wrong. How they had chosen the wrong bus architecture. I said yes, MTConnect, EtherNet/IP devices and Modbus devices could be enabled for OEE (Overall Equipment Efficiency), predictive maintenance and ERP with this architecture, but that they had missed the bus, so to speak, when they picked MQTT.

I went on to describe how the Open Process Automation Forum (OPAF) defines the exact same model as GTMI (Georgia Tech Manufacturing Institute) and claims the same benefits but uses the OPC UA architecture. I then said that OPC UA had two advantages over the GTMI architecture: 1) multiple secure mechanisms for end-to-end security from the north side (IT applications) to the south side (end devices); and 2) very sophisticated data modeling where those data models could be discoverable at runtime.

Over the years, I have been critical of the MQTT protocol. I am a manufacturing guy from way back and my technologies were always EtherNet/IP, Modbus TCP and PROFINET IO. There were several things I didn’t like about MQTT including:

• The broker was a point of failure and a single source with lots of data. It’s a very attractive component of a system to hackers.
• There was no definition of the payload. Both the clients providing the data to the broker and the clients receiving the data from the broker had to understand the content of the data.
• MQTT was designed for small payloads and applications with many devices, the opposite of the situation in many industrial applications.

Given these serious issues, I was not a proponent of the technology, I campaigned against MQTT and actively supported OPC UA as an alternative. On a pure technology to technology comparison, there is no question that OPC UA is superior.

But the market has spoken, and it hasn’t chosen what I proposed. In fact, the market has run from my advice. In fact, it has galloped, dashed, raced and hurried to do the opposite: implement MQTT by the boatload. So, today I capitulate and become an MQTT supporter.

What’s changed my mind? Is it that I realized the error of my earlier conclusions? No, it’s Sparkplug B.

Sparkplug™ provides an open and freely available specification for how native and gateway devices can communicate bi-directionally within an MQTT infrastructure in a more structured way. Sparkplug B, the second of two alternate payload definitions, resolves many of my earlier arguments. Between the enhancement to the operation of MQTT and my getting run over by the bus of popular sentiment in the automation industry, I am withdrawing my opposition and become a supporter of MQTT.

Figure 1 - Typical MQTT System

The Sparkplug B specification enhances the original MQTT specification in three significant ways:

AN ENHANCED TOPIC NAMESPACE

One of the advantages of MQTT is that a device can just define an arbitrary topic name like “Perfume Unit 4 Oven Temp” and start sending data. One of the disadvantages of MQTT is that a device can just define an arbitrary topic name like “Perfume Unit 4 Oven Temp” and start sending data.

With the Sparkplug™ specification, the Topic Namespace is much more well thought out and optimized for more serious application development. For data to be easily useful to other MQTT Client applications that want to consume data values, the Topic Namespace needs to be understood by everyone participating in the data exchange.

All MQTT clients using the Sparkplug™ specification will use the following Topic Namespace structure:

namespace/group_id/message_type/edge_node_id/[device_id]

Where

namespace is either “spAv1.0” or “spBv1.0” (the Sparkplug A and Sparkplug B).

group_id is an ASCII string reference to a logical grouping of nodes.

message_type element is an ASCII string which defines how the message is processed.

edge_node_id is the ASCII ID of the MQTT edge device or gateway device (i.e. Modbus RTU Master).

device_id is the ASCII ID of the end device that physically interfaces to the real-world input and outputs (i.e. Modbus RTU Slave).

MQTT STATE MANAGEMENT

One of the deficiencies of standard MQTT is that consumers of data from a broker are never aware of the state of the end device. In MQTT, brokers continue to make data available despite the state of the originating device. A broker provides data even if the end node has failed, and that’s a problem. Sparkplug B provides MQTT state management such that consumers of MQTT can be notified when a node is “born” and when it “dies.”

MQTT PAYLOAD

Classic MQTT does not define any payload format. A payload is simply a binary array of bytes of some size. The Sparkplug specification defines two payload formats, payload definition A (a Google Kura standard) and payload definition B (a model for industrial automation).

Sparkplug B defines how a payload is encoded and the data that is required. It provides support for complex data types using templates, datasets, rich metrics, historical data and more. (See the specification for more information.)

I have spoken many times to my team on how the best technology doesn’t necessarily win. Users often choose what they choose for other reasons. In this case, it’s the absolute simplicity of an MQTT solution: the fact that it has few options, little overhead, and is easy to use and understand.

Excuse me while I get back to eating my barbequed crow dinner with Steve Balmer.

John

PS – For more of my musings you might want to get my newsletter. Some get it digitally but others get it via the US Mail. For you younger folks, mail is text messages that are delivered by a guy (or gal) in a blue suit who drives a little clown truck like vehicle. You can get my newsletter by visiting https://www.rtautomation.com/company/newsletter/.