MQTT, open SCADA publish/subscribe protocol is

getting what it needs to go industrial

MQTT is now the most commonly used messaging protocol above HTTP.
By Ian Verhappen
Dec 06, 2019

Message queuing telemetry transport (MQTT), developed in 1999, is a publish/subscribe message lightweight
protocol based on TCP that is now the most commonly used messaging protocol above HTTP. The reference
architecture is very simple, and is based on client/server. The client is generally a sensor that “publishes” the
information to the server (broker) that receives the information and dispatches it to the subscribers. MQTT
protocol uses a many-to-many paradigm, and the broker decouples the publisher to the subscriber and acts
as a message router with every message a discrete chunk of data, opaque to the broker. MQTT’s
publisher/subscriber model enables clients to communicate one-to-one, one-to-many and many-to-one.

Every message is published to an address, known as a topic. Clients may subscribe to multiple topics. Every
client subscribed to a topic receives every message published to the topic. The MQTT specification does not
dictate any particular Topic Namespace, nor does it dictate any particular payload data encoding, though
MQTT topics are hierarchical, like a filing system (e.g. sales volume/flow/corrected). Wildcards are allowed
when registering a subscription (but not when publishing), thus allowing whole hierarchies to be observed by
clients.
MQTT also supports three quality of service levels: “fire and forget,” “delivered at least once,” and “delivered
exactly once.” To prevent excess traffic when a device knowingly disconnects, MQTT clients can register a
custom “last will and testament” message to be sent by the broker if they disconnect.
MQTT also has support for persistent messages stored on the broker. When publishing messages, clients
may request that the broker preserve the message. Only the most recent persistent message is stored.
When a client subscribes to a topic, any persistent message will be sent to the client. However, unlike a
message queue, MQTT brokers do not allow persistent messages to back up inside the server.
MQTT brokers can require username and password authentication from clients to connect, and to ensure
privacy, the TCP connection may be encrypted with SSL/TLS.
As a machine-to-machine (M2M)-oriented protocol, MQTT is designed to be lightweight, and it has two
drawbacks for very constrained devices:
Every MQTT client must support TCP and therefore, always holds a connection open to
the broker, which can be a problem in high-packet-loss/computing environment.
MQTT topic names are often long strings, which make them impractical for 802.15.4
industrial wireless environments.
These shortcomings are addressed by the MQTT-SN protocol, which defines a UDP mapping of MQTT and
adds broker support for indexing topic names.

MQTT is an OSI Application Layer (Layer 7) like HTTP, and as a carrier, requires tagging such as HTML or XML
for web pages to represent the data. MQTT for SCADA applications have Sparkplug, which provides an open
specification for how edge-of-network (EoN) gateways or native MQTT-enabled end devices and MQTT
applications communicate bidirectionally within an MQTT Infrastructure.

The Sparkplug specification defines an MQTT Topic Namespace, payload, and session state management that
can be applied to the SCADA/IIoT market sector. To meet these requirements, the specification is based on a
lightweight, bandwidth-efficient, low-latency payload encoding architecture.
MQTT-enabled infrastructure requires that one or more MQTT servers be present in the infrastructure.
Typically, there will be only one primary SCADA/IIoT host node responsible for monitoring and control of a
given group of MQTT EoN nodes. The SCADA/IIoT host node is any MQTT client application that subscribes to
and publishes messages defined in this document.
The Sparkplug Topic Namespace define nine message-type elements:
Using these defined messages host SCADA/IIoT applications can:

Discover all metadata and monitor state of any EoN/Device connected to the MQTT
infrastructure.
Discover all metrics, which include all diagnostics, properties, metadata and current
state values.
Issue write/command messages to any EoN/Device metric.
The above standards are all available and open, with Sparkplug from Cirrus Link Solutions, while Eclipse
Foundation has released an open-source implementation of MQTT called Mosquitto, while OASIS
maintains Advanced Message Queue Protocol (AMQP). Do they define a fully open solution? Not quite. We
mere humans still need to interact with the data, which typically requires an HMI though several hardware
and interface suppliers to support these protocols. I have also heard rumors of an end user-driven group
similar to OPAF being discussed to support an Open SCADA standard.
References:
Sparkplug MQTT Topic & Payload Definition Version 2.1, Cirrus Link
Solutions, https://s3.amazonaws.com/cirrus-link-
com/Sparkplug+Topic+Namespace+and+State+ManagementV2.1+Apendix++Payload+B+format.pdf, April
2019
MQTT Version 3.1.1 Committee Specification, http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd02/mqtt-v3.1.1-
csprd02.pdf