Learn about the application of Message Queuing Telemetry Transport Protocol (MQTT) in the industrial automation industry

History of Message Queuing Telemetry Transport (MQTT)

MQTT was developed by Andy Stanford-Clark with IBM and Arlen Nipper in 1999 to connect measurement equipment on oil pipelines to their SCADA (Supervisory Control and Data Acquisition) systems via satellite. They developed this protocol because they needed some lightweight, bandwidth-rich, and low-power protocol to use over satellite links.

MQTT officially became an OASIS (Organization for the Advancement of Structured Messaging Standards) open standard in 2014. It aims to remain an open source implementation to ensure widespread adoption in the machine-to-machine (M2M) industry.

In 2019, OASIS released the official updated MQTT 5.0 standard. Version 5.0 includes many new features: such as reason codes, shared subscriptions, message expiration, and topic aliases.

Today, MQTT is adopted by many industrial sectors, including automotive, utilities, logistics, manufacturing, smart home, consumer goods, and transportation, connecting millions of devices around the world.

What is Message Queuing Telemetry Transport (MQTT)?

MQTT, which stands for Message Queuing Telemetry Transport, is a communication protocol that uses the publish/subscribe (PubSub) model for the Internet of Things (IoT) and Industry 4.0. It is extremely lightweight, executes on top of the TCP/IP stack, and is designed to connect distributed devices requiring minimal coding from developers.

MQTT is bandwidth efficient and resource-neutral. It also runs over Secure Sockets Layer (SSL)/Transport Layer Security (TLS), a security protocol built on TCP/IP, to ensure that all data messages between devices are encrypted and secure.

Publish-Subscribe Model

In the MQTT PubSub model, clients are either message producers (publishers) or consumers (subscribers). Clients do not establish direct links between each other and do not know each other's location or IP address. Instead, they all connect to an MQTT broker, which only acts as a traffic (message) storage and director, as shown in Figure 1.

Figure 1. The publish/subscribe model in MQTT. Image courtesy of Behr Technologies

In this example, there is one publisher and two subscribers subscribing to the same publisher to obtain the same information. However, in many applications, you will often see many-to-many relationships, as shown in Figure 2.

Figure 2. Many-to-many relationships in MQTT. Image courtesy of ResearchGate

An MQTT broker only sends messages it receives from publishers to subscribers who have subscribed to MQTT topics. We'll discuss MQTT topics next.

Internals of Message Queuing Telemetry Transport (MQTT)

Message Queuing Telemetry Transport (MQTT) topics

In MQTT, a topic is a hierarchical UTF-8 text string that the broker uses to filter messages and deliver them to each subscriber. A topic consists of one or more topic levels, each separated by a forward slash. All messages must contain a topic, and subscribers must subscribe to that topic. Topic examples are presented in the following format (it is important to note that topics are case-sensitive).

My House/First Floor/Room 1/Temperature

My House/First Floor/Room 4/Temperature

My House/Second Floor/Room 2/Humidity

MQTT is a messaging protocol that supports asynchronous communication. It decouples message producers and consumers in space by publishing or subscribing to messages knowing only the IP address and port number of the broker. It also decouples time by storing messages for clients when the network is disconnected. This makes the protocol highly scalable in unstable networks such as cellular and radio networks.

MQTT sends the connection credentials in plain text and therefore provides no security measures and authentication itself. This can be addressed by using TLS encryption with a username, password to protect the connection and requiring the client to present a certificate that matches the broker's certificate.

The default unencrypted MQTT port is 1883. The encrypted port is 8883.

Message Queuing Telemetry Transport (MQTT) Quality of Service (QoS)

Quality of Service (QoS) in MQTT is an agreement between publishers and subscribers on guaranteed message delivery.

There are three levels of QoS:

0 – at most once, agent is not sure

1 – At least once, the broker sends an acknowledgment to the publisher

2 – Exactly once, handshake between publisher and subscriber

When a publisher publishes a message to an MQTT broker, it determines the QoS level for that message. When the broker forwards the message to a subscriber, it also sends the same QoS set by the publisher.

Level 0 is less taxing on bandwidth and is used when the connection is considered reliable. Using the highest level, 2, guarantees delivery but increases the load on data transfer.

Message Queue Telemetry Transport (MQTT) Sparkplug B

The Eclipse Foundation manages a Sparkplug protocol specification that is compatible with MQTT, where MQTT is the communication protocol and Sparkplug defines the data structures. This specification was chosen for real-time and mission-critical industrial applications by adding new requirements and features on top of MQTT.

Sparkplug B adds three main requirements to the MQTT implementation:

Mandatory state awareness. A publisher must publish proofs when connected, define all topics, and broadcast its online status to subscribers through the broker. It also submits proofs to the broker for distribution if it is disconnected from the network. Figure 3 depicts the process of establishing device communication with an MQTT broker.

Figure 3. Device session establishment in MQTT Sparkplug. Image courtesy of the Eclipse Foundation [PDF]

Payload definition. MQTT is data agnostic and can run with any client, but at the same time adds the burden that subscribers will add data. Sparkplug packages the MQTT payload with structured metadata so that any Sparkplug client can identify the message. The entire payload is then compressed into a smaller footprint.

Standard topic format. Topics in MQTT can obscure interoperability because different edge devices can use different naming conventions. Sparkplug defines a standard topic format to reduce inconsistencies between clients and enable them to correctly interpret the data.

Edge-to-Cloud Connectivity

MQTT is cross-platform. The broker can be installed and run on Windows, Linux, and other platforms. Going forward, more and more installations will run on cloud servers such as Azure and Google Cloud. Hosting the broker on the cloud allows developers to quickly launch, easily manage and monitor the broker, and scale when more devices need to be connected.

Security becomes even more important when data passes through the cloud. Developers must pay attention to and properly configure and handle secure connections, authentication, authorization, and encryption to maintain the security and integrity of the data.

MQTT was developed in 1999 to connect oil pipelines to SCADA and has been used in industrial environments ever since. It is a communication protocol used in a variety of industrial sectors.