Learn about the background and use of message queue telemetry transport (MQTT) in the industrial automation industry.
The History of Message Queue Telemetry Transport (MQTT)
MQTT was developed in 1999 by Andy Stanford-Clark with IBM and Arlen Nipper to connect measuring devices on oil pipelines to their SCADA (Supervisory Control and Data Acquisition) system via satellites. They developed this protocol because they needed something lightweight, bandwidth resourceful, and consumed little power to go through the satellite links.
In 2014, MQTT officially became an OASIS (Organization for the Advancement of Structured Information Standards) open standard. It was aimed to stay as an open-source implementation to ensure wide adoption in the machine-to-machine (M2M) industry.
In 2019, OASIS released the official updated MQTT 5.0 standard. Version 5.0 includes new features such as reason code, shared subscription, message expiry, and topic alias.
Today, MQTT has been adopted in many industrial sectors, including automotive, utilities, logistics, manufacturing, smart home, consumer products, and transportation, linking up millions of devices around the globe.
What is Message Queue Telemetry Transport (MQTT)?
MQTT, which stands for message queue telemetry transport, is a communication protocol that uses a publish/subscribe (PubSub) model for the Internet of Things (IoT) and Industry 4.0. It is very lightweight, performs on top of the TCP/IP stack, and is designed for connecting distributed devices that require minimal coding by the developers.
MQTT is bandwidth-efficient and is not resource-intensive. It can also run on secure sockets layer (SSL)/transport layer security (TLS)—a secure protocol built on TCP/IP—to ensure that all data messaging among devices are encrypted and secure.
PubSub Model
In the MQTT PubSub model, the clients are either message producer (publisher) or consumer (subscriber). The clients do not establish a direct link between each other and do not know each other’s location or IP address. Instead, they both connect to an MQTT broker, which merely acts as a traffic (messages) store and director, as indicated in Figure 1.
Figure 1. Publish/Subscribe Model in MQTT. Image used courtesy of the Behr Technologies
In this example, there are one publisher and two subscribers subscribed to the same publisher getting the same information. In many applications, however, many-to-many relationships are often seen, as described in Figure 2.
Figure 2. Many-to-many relationships in MQTT. Image used courtesy of the ResearchGate
The MQTT broker only sends the message it receives from the publisher to the subscribers who have subscribed to the MQTT topic. We will discuss the MQTT topic next.
The Internal of Message Queue Telemetry Transport (MQTT)
Message Queue Telemetry Transport (MQTT) Topics
In MQTT, the topic refers to a hierarchical UTF-8 text string that the broker uses to filter and funnel messages to each subscriber. The topic consists of one or more topic levels, and a forward slash delimits each topic level. All messages must contain a topic, and the subscriber must subscribe to the topic. Examples of topics are presented in the following formats (it is important to note that the topic is case-sensitive).
MyHouse/FirstFloor/Room1/Temperature
MyHouse/FirstFloor/Room4/Temperature
MyHouse/SecondFloor/Room2/Humidity
MQTT is a messaging protocol that supports asynchronous communication. It decouples the message producer and consumer in space by only knowing the broker’s IP address and port number to publish or subscribe. It also decouples the time by storing the message for clients when the network is disconnected. This makes the protocol very scalable in unstable networks such as cellular and radio networks.
MQTT sends connection credentials in plain text and therefore does not provide security measures and authentication itself. This is remedied by using TLS encryption with username, password-protected connections, and requiring the clients to provide a certificate that matches the broker’s certificate.
The default unencrypted MQTT port is 1883. The encrypted port is 8883.
Message Queue Telemetry Transport (MQTT) Quality of Service (QoS)
Quality of service (QoS) in MQTT is an agreement between the publisher and subscriber on the guarantee of delivering the message.
There are three levels of QoS:
- 0 – at most once, no acknowledgment by the broker
- 1 – at least once, the broker sends an acknowledgment back to the publisher
- 2 – exactly once, a handshake between the publisher and subscriber
When the 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 puts less burden on the bandwidth and is used when the connection is considered reliable. Using the highest level 2 guarantees delivery, but it puts more loads on the data transfer.
Message Queue Telemetry Transport (MQTT) Sparkplug B
Eclipse Foundation manages a Sparkplug protocol specification that is compatible with MQTT, in which MQTT is the communication protocol and Sparkplug defines the data structure. The specification is 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 implementations:
- Enforced state awareness. A publisher must publish a birth certificate upon connection, define all topics, and broadcast its online status to the subscribers through the broker. It also registers a death certificate with the broker to be distributed if disconnected from the network. Figure 3 depicts the process of establishing device communication with the MQTT broker.
Figure 3. Device Session Establishment in MQTT Sparkplug. Image used courtesy of the Eclipse Foundation [PDF]
- Payload definition. MQTT is data agnostic to function with any clients, but simultaneously burdens the subscribers to properly interpret the data. Sparkplug packs the MQTT payload with structured metadata so that any Sparkplug client can identify the message. The entire payload is then compressed to become a smaller footprint.
- Standard topic format. The topic in MQTT can obscure interoperability since different edge devices can use different naming conventions. Sparkplug defines a standard topic format to reduce inconsistency among 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, an increasing number of installations will be running in cloud servers such as Azure and Google Cloud. Hosting the broker on the cloud allows developers to start quickly, manage and monitor the broker easily, and scale up when more devices are required to be connected.
Security becomes even more important when data is going through the cloud. Developers must pay attention and configure and handle the secure connection, authentication, authorization, and encryption properly to maintain the security and integrity of the data.
Developed in 1999 to connect oil pipelines to SCADA, MQTT has always been used in industrial settings. It is a communication protocol used in various industrial industries. What have you used MQTT for?
Copyright Statement: The content of this website is intended for personal learning purposes only. If it infringes upon your copyright, please contact us for removal. Email: admin@eleok.com