MQTT Sparkplug Specification

< Previous Video    |    Next Video >

Sparkplug is a specification that defines how to use MQTT in a mission-critical, real-time environment. Arlen Nipper walks through what Sparkplug can do for you in terms of operational data, advancing from legacy register/value information to a single source of truth at the edge. Arlen breaks down MQTT Sparkplug architecture, failover, redundancy, and scale.


Video Transcript:

Arlen: The MQTT specification does not dictate any Topic Namespace convention nor does it define any Payload representation. The flexibility of the Topic Namespace and the fact that the Payload is data-agnostic are key factors in the adoption of MQTT. Solution providers can create Topic Namespace and Payload definitions that best suit their applications. But looking at this from an OT perspective and looking at OT solutions using MQTT four years ago, there's no standard way that SCADA process variable topics and payloads were defined. Many OEM hardware providers and software service providers were using MQTT, but each with their own definitions of topics and payloads. The result was that even though it was an MQTT infrastructure being used, there was no level of plug-and-play or interoperability between the solutions on the market. More importantly in the OT application space, very little consideration was given to how best manage the built-in-state awareness of MQTT using well-defined last will and testament topics and payloads.

Four years ago, a specification was developed called Sparkplug. Sparkplug is a specification that defines how to use MQTT in a mission-critical, real-time OT environment. It defines a standard MQTT Namespace that's optimized for industrial application use cases. It defines an efficient MQTT Payload definition that's extensible but that's been optimized for SCADA, tag and metric representations. It defines how best to use the MQTT state management in real-time SCADA implementations. And lastly, it defines some high-availability MQTT architectures addressing both redundancy and scale.

So although the Sparkplug specification is available for download and to be able to look at all the components of it, let's look at one aspect of what Sparkplug can do for us. So here we're showing a Modbus register of 40,027 with a value of 1256, and this is the way that we've been dealing with operational data for the last 35 or 40 years. So I get this value into my dashboard and now I've gotta give a context, so I double-click on this tag and I give it a tag name, maybe it's Suction Pressure. I know that it's a raw value so I have to scale up for 4 to 20 milliamps. I have to give it an Engineering Units Low, Engineering Units High. I'm gonna convert it to a floating point. So there's all of these metrics that for every tag we have to double-click and edit, and that's for if our SCADA system has 60,000 tags, that's 60,000 separate edits that we have to do.

But with Sparkplug, we can now advance from Legacy/Register value information to a single source of truth at the edge. So taking the same value, and being able to represent it from an Edge device that implements MQTT Sparkplug, we can see now that when we subscribe to this tag, we actually have a tag name that says this is Suction Pressure. We have process variable engineering units of PSIA. We have an engineering range of 0 to 100, and we know this process variable is a floating point. The current scale value is the process variable that's being published along with UTC millisecond timestamp of when that process variable was read and when it was published via MQTT.

So looking at our architecture, now with Sparkplug, we still have our central component of our MQTT server infrastructure, and we still have clients, MQTT clients at the edge, but if this was on Ignition Edge and it was connected to PLCs, RTUs, flow computers, now we could establish our connection, connect into our MQTT server, subscribe to information that we're interested in, and then start publishing all of those process variables using Sparkplug. Now, this is decouple so we're publishing that information in not really caring who's going to subscribe to it but will add another MQTT client that's running on an Ignition gateway that can connect and subscribe to Sparkplug information being published by one or more Edge devices, and as soon as that subscription is issued, we can receive those Sparkplug payloads. Now, what that results in is basically immediately learning our tag tree. So you can imagine if it was one Edge device or a thousand, the fact that your device is learned, your tag hierarchy is learned and all of your tags are learned automatically, you've eliminated man months, if not man years of tag configuration. And when those tags change in the field, they're automatically reflected in a new publish from the edge of-network devices.

Now realize we've defined commands as well in Sparkplug so that now when my host wants to issue a command, this is bidirectional in all manner as far as for a typical SCADA system. So now we'll look at adding some other clients that are interested in that information, and they can subscribe. Now, imagine the fact that they get that same rich context of those information. So now we can add multiple clients, multiple consumers of data and we're self-defining all of the tags. So again, as we build out this infrastructure, it's secure, we don't have to have any ports open on any of the clients out in the field, it's a mode-originated connection. As you can see here, it resulted in a real-time, one-to-many OT architecture.

Now, looking at the Sparkplug definition of failover, redundancy, and scale, we do have this notion of, in an operational system, we need to know that there is one application that is issuing commands that is the primary host. So in this architecture, we show Ignition as a primary host with two available MQTT servers with three Edge clients connected. Now, if we would lose our network connection from the primary host to MQTT server number one, we want to tell those clients out in the field that one of our primary applications is no longer connected to that server that we're publishing information to, so they know to disconnect from that MQTT server and connect to another available MQTT server in the infrastructure that is connected to our Ignition gateway.

Conversely, if that MQTT server went away, again, we would recognize that our MQTT session went away and be able to walk to other available MQTT servers. So using MQTT as our OT infrastructure, having high availability, redundancy, and scale is simply a matter of adding one or more MQTT brokers to your infrastructure.