MQTT, open SCADA publish/subscribe protocol is getting what it needs to go industrial

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.