Message queuing telemetry transport (MQTT)

What is MQTT?

Message queuing telemetry transport (MQTT) is a lightweight open-source messaging protocol for devices and low-bandwidth, high-latency, or unreliable networks. IBM created it in the late 1990s, and it has become a crucial component of the Internet of Things (IoT) and Supervisory Control and Data Acquisition (SCADA) (opens in new tab).

The MQTT protocol operates on a publish and subscription model. This means that devices (known as clients) can publish messages to a broker (the backend system), which then distributes these messages to other devices that have subscribed to the relevant topics. MQTT's simplicity, efficiency, and ability to provide real-time communication make it an ideal protocol for a wide range of applications, from smart devices to industrial automation systems. Below is a detailed diagram of how the MQTT protocol operates with IoT devices:

The latest version of MQTT is 5.0 (opens in new tab), which introduced several enhancements over the previous version (3.1.1).

MQTT 5.0 and new features

Some of the latest features in MQTT 5.0 include:

• Reason codes: They provide detailed information on the success or failure of an MQTT action, aiding in better error handling and debugging.
• Properties: Allow metadata to be attached to MQTT messages, such as content type, message expiry intervals, and user properties, enhancing message customization and control.
• Session and message expiry: Session expiry enables clients to set the duration for which the broker should store their session state. Message expiry allows publishers to set a time after which messages are considered stale and should not be delivered.

Who uses MQTT?

MQTT is adopted across different industries due to its versatility. Here are some key sectors where MQTT is prominently used:

• Industrial automation: In manufacturing and production environments, MQTT monitors and controls equipment, ensuring smooth and efficient operations.
• Automotive: MQTT is used in connected car systems for real-time data exchange, including vehicle diagnostics, navigation, and infotainment.
• Healthcare: In medical devices and health monitoring systems, MQTT facilitates the real-time transmission of patient data, ensuring timely interventions and improved patient care.
• Energy and utilities: MQTT helps manage smart grids, monitor energy consumption, and control utility services.

Types of MQTT protocol messages

In MQTT, the primary operations are publish and subscribe. When a client wants to send data to the broker, it publishes a message to a specific topic. This action is called a publish. When a client wants to receive data from the broker, it subscribes to a topic or set of topics. By subscribing, the client indicates interest in receiving messages published to those topics. Once subscribed, the client will receive all messages published to those topics from that point on.

The data sent between clients and the broker are referred to as messages. These messages can vary, including sensor readings, log messages, telemetry data, heartbeats, or even commands that trigger actions. Along with the message, the publisher specifies a Quality of Service (QoS) level, which determines the guarantee of message delivery. The QoS levels are:

1. At most once (QoS 0): This refers to when a message is delivered according to the underlying network's best effort. Delivery is not guaranteed, and the message may be lost if the client or broker is unavailable (or offline). This level shouldn't be used for critical information.
2. At least once (QoS 1): This is when the message is delivered at least once to the receiver. The publisher sends the message and waits for an acknowledgment from the broker. If the acknowledgment isn't received, the message is resent. This ensures that the message is received but may result in duplicate messages. This is the most common QoS level.
3. Exactly once (QoS 2): This is when the message is guaranteed to be delivered and processed exactly once by the receiver. This involves a more complex four-step process between the publisher and the broker to ensure no duplication or loss of messages. This is the safest QoS level but also the slowest due to the additional overhead, and it is used only when necessary.

Users can choose the appropriate QoS level to balance the trade-offs between reliability and performance based on their specific application needs.

Example of MQTT

Let's consider a smart manufacturing facility with multiple IoT devices. This facility is a process manufacturing plant that produces petrochemicals. A key safety point at this kind of facility is measuring the overall temperature of assets and the environment. Below are the different types of devices that would be used at the facility and how they would be subscribed to MQTT:

• Temperature sensor: This sensor reads the temperature of a specific machine, and the device publishes the temperature data to the topic 'asset1/temperature'.
• HVAC system: This sensor is subscribed to 'facility/temperature' and adjusts the heating and cooling of the entire facility floor based on the received internal temperature readings. In this example, HVAC systems for a petrochemical plant are complex because they need to adjust for high temperatures and have robust filtration systems to manage any chemical fumes during the manufacturing process.
• CMMS mobile app: The maintenance team's computerized maintenance management system (CMMS) app subscribes to 'asset1/temperature', 'facility/temperature' and 'facility/alerts'. In this case, the first subscription displays the current temperature of a specific asset, 'asset1', and the second one displays the overall facility temperature. Since high asset and facility temperatures can impact asset performance, it's important that the maintenance team has visibility. The last subscription is for the maintenance team to receive any critical alerts regarding the facility, including asset failures, critical failures, chemical detection, air quality, smoke detection, etc.

Message queuing telemetry transport (MQTT) versus hypertext transfer protocol (HTTP)

While the MQTT protocol and hypertext transfer protocol (HTTP) are widely used for communication, they serve different purposes. MQTT is ideal for IoT applications requiring efficient, real-time communication with numerous devices over constrained networks. While HTTP remains the protocol of choice for traditional web applications where request/response interactions are predominant.

Below is a table to help you understand the key differences between the two communication protocols based on functionality and features:

Functionality and features	MQTT	HTTP
Communication model	Uses a publish/subscribe model, ideal for many-to-many communication.	Uses a request/response model, suitable for one-to-one communication.
Efficiency and design	Lightweight and designed for minimal bandwidth usage, making it efficient for low-power devices.	It is more resource-intensive, since it includes additional headers and is designed for web applications with ample bandwidth.
Real-time communication	Provides real-time communication with low latency, as messages are pushed to clients.	Typically has higher latency, as clients need to poll the server for updates.
Quality of Service (QoS) levels	It offers three QoS levels to ensure message delivery (at most once, at least once, exactly once).	Does not have built-in QoS levels; reliability depends on the underlying TCP/IP protocol.
Connection state	Maintains a persistent connection, allowing continuous communication.	Typically uses short-lived connections, requiring re-establishment for each request.

Benefits of MQTT for IoT, SCADA, and predictive maintenance (PdM)

MQTT is widely regarded as the best protocol for IoT, SCADA, and is growing in importance for PdM for several reasons. Let’s review why MQTT excels in these areas:

1. Lightweight and efficient: MQTT’s protocol overhead is extremely low, making it suitable for devices with limited processing power and memory. The small packet size reduces bandwidth usage, which is crucial for IoT devices often operating over constrained networks. This is especially important when a facility has multiple IoT devices, SCADA systems, and programable logic controllers (PLCs) reading data.
2. Scalability: MQTT brokers can efficiently manage thousands of connected devices, making it ideal for large-scale IoT deployments. Additionally, SCADA systems often involve numerous sensors and control points. MQTT’s ability to handle many devices makes it highly scalable for such environments. This scalability also provides a comprehensive view of equipment health and performance for PdM.
3. Persistent sessions: MQTT can maintain session states and manage offline messages, ensuring devices receive messages even after reconnection. This makes MQTT extremely reliable for message delivery. MQTT’s session model supports a decentralized architecture, allowing efficient management of data flow and control commands in complex SCADA systems. It also enables proactive maintenance actions without being physically present.
4. Bi-directional communication: In the context of MQTT, bi-directional communication allows devices to both publish messages and subscribe to topics. This enables a two-way exchange of information between devices and systems, which is crucial for many IoT applications.
5. Security: The MQTT protocol supports Secure Sockets Layer/Transport Layer Security (SSL/TLS) encryption, which ensures data confidentiality during transmission. Clients also initiate a connection to the broker using Transmission Control Protocol/Internet Protocol (TCP/IP), with the option of SSL/TLS encryption for added security. These security features are especially important when dealing with IoT devices on a facility floor.