How MQTT Works

< Previous Video    |    Next Video >


Arlen Nipper goes over the definitions and components you need to understand about MQTT architectures, including publish-and-subscribe, publishing on a topic, topic namespace, payload, MQTT brokers, and MQTT clients.


Video Transcript:

Arlen: To get started on how MQTT works, the first thing we need to do is look at some of the definitions and the components that we're going to need to understand about an MQTT architecture. So again, as we pointed out, taken as a whole, the components and semantics of an MQTT architecture really comprise what's called OT-aware message- oriented middleware. It's event-driven network infrastructure that applies to IT solutions as well. Now, some of the key technology components to understand are, well, the notion of Publish and Subscribe. Pub/Sub messaging is where publishers of messages are not programmatically tied to any particular subscriber. This decoupling of any one data producer to many potential consumers is a key concept to understanding the advantages of an MQTT infrastructure.

So Publish and Subscribe gives us that decoupling that we need in SCADA infrastructures. The second thing we need to understand is a Topic. So in a Pub/Sub infrastructure, data is published on a Topic or a hierarchical/delimited number of elements that lets us either tune in or tune out of the information that we're interested in consuming. Now, if we take a Topic and define that in a hierarchy. We can call that a Topic Namespace. And a Topic Namespace is a definition or a schema of the Topic elements that we want to standardize on. For example, in a pipeline SCADA system, the Topic Namespace could be defined as a group ID, a note ID, and a device ID. Using a schema, then actual MQTT topics might be something like Pipeline1/Booster Station 47/Pump PLC and you could see where you could subscribe to either all of Pipeline 1 or all of Booster Station 47 or specifically down to a pump PLC. So that's our Topic Namespace. Now under that, we have the Payload, so we define Pub/Sub as publishing messages and those messages have both a Topic and a Payload.

Now uniquely, MQTT defines a Payload as a simple array of bites, i.e., it's Payload-agnostic, there's no notion of a particular Payload encoding such as XML, JSON, CSV a binary Modbus response, a Google Protocol Buffer or any sort of legacy register value pairs. Based on the solution, a Topic can define a particular type of Payload encoding. Now, this unique aspect of MQTT has led to its adoption across a broad spectrum of markets and applications, from Facebook Messenger to Ignition. All MQTT infrastructures have to have an MQTT server or sometimes referred to as an MQTT broker. The MQTT server is responsible for delivering the Topic Payload messages from MQTT publishers to MQTT subscribers. MQTT clients, each device or application in an MQTT infrastructure needs to implement an MQTT client.

The MQTT client is responsible for establishing a connection session to the MQTT server, issuing subscriptions on the topics they're interested in, and publishing information that other consumers might be interested in. And finally, the definition of MQTT state. In real-time, OT infrastructures is critical that the state of MQTT client connections be known at all times. Since data can be published by exception, the state of a connection guarantees that process variable data is good quality, or we know it's stale. So taking those definitions into consideration, let's look at a very simple Publish and Subscribe example. In this example, we have the MQTT client components that we defined before, and we have an MQTT server. First thing an MQTT client does is connect to an MQTT server. So the left client has connected and the right client can connect. Now the left client can subscribe to any sort of information he wants to.

Now, in MQTT, a subscription pound sign is called a wild card subscription. So you could subscribe to anything that might be published to that MQTT server. Then the right client can publish a message. And he's gonna publish that on a Topic. So we're saying that the Topic is Hello/World. And the Payload that he's going to publish as an ASCII string saying, "Hello from a client." He publishes that message to the MQTT server and the MQTT server processes that incoming message by looking up any subscribers on that specified Topic. Well, we had an MQTT Client that subscribed on wild card, so he said he wants everything that comes in, the MQTT server then delivers that message, the Topic "Hello World" and the Payload, the ASCII string of hello from a client.

So that's a very simple but very good example of how publish/subscribe works on both the Topic and the Payload. Now, looking at the MQTT client state management, we had the same components, where MQTT client connects, but we'll see what happens in that connection request that he provides a user name, a password, and a last will and testament. Now, that last will and testament is basically defined as a message that has a Topic, in this example, is PLC07/DeathCert, and a Payload, PLC07 is Offline. Once that connection is established, that last will and testament is saved inside of the MQTT server. It's not published anywhere, and we'll see where it's used here in a moment.

Now, the other MQTT client can connect and he can subscribe to a death certificate by issuing a Topic of +/DeathCert and he's basically saying, "I'm interested in any client out there that's going to publish a death certificate." So now, we have two clients connected in good shape to an MQTT server. Nobody's gone offline, we're publishing, we're subscribing, but all of a sudden, we lose the IP connection to that MQTT client. What happens is that the MQTT server detects the MQTT connection has been lost and publishes the last will and testament message to the client that subscribed to it. So now, that client knows that PLC07 is now Offline, so that is how state management works in MQTT.

Now looking at an overall MQTT architecture, we have our MQTT server, we have a client, and that client may represent data coming from RTUs or PLCs out in the field. So, that client connects to that MQTT server, establishes its connection, then subscribes to information that he might be interested in, and then can start publishing any process variable, any metric, any diagnostic, that he thinks anybody might be interested in. Now, notice at this point in time, we've got a complete infrastructure, our client is publishing information, and we're really not caring who consumes that. There's just no other consumers there right now. So we'll add another consumer by another client connecting and subscribing to information that he's interested in.

And now, we can see that the information being published is, to the MQTT server, is now available to that client in real-time. Also notice that this is bidirectional and the client can publish on a command Topic any time so that MQTT is bidirectional. Now, we can continue. We add two additional MQTT clients. Now notice here, uniquely, now, we've constructed a one too many architectures where one client is publishing a process variable, let's say, a pressure, and all three clients that have subscribed to that are being informed. So as we build out this infrastructure, we add more clients that publish interesting information, more clients that subscribe to that. And what we end up with is a real-time, state-aware, secure, SCADA infrastructure.