- QoS 0 – At most once: This level delivers messages without requiring an acknowledgement from the receiving client. It is the fastest and requires the least overhead but does not guarantee message delivery. It is suitable when timely delivery is more critical than accurate delivery, such as with environmental sensor data that updates regularly.
- QoS 1 – At least once: At this level, messages are delivered at least once to the receiver by sending a PUBLISH packet to the MQTT broker with the QoS 1 flag set. The sender stores the message until it receives an acknowledgement from the receiver with a PUBACK packet as an acknowledgment that it has received the message and taken responsibility for delivering it to the appropriate subscribing clients. If an acknowledgement is not received it assumes that the PUBLISH packet was lost in transit and therefore resends the PUBLISH packet. This could result in the broker receiving multiple copies of the same message if there are issues with the network, leading to potential duplicates on the subscribing clients' side.
- QoS 2 – This is the highest QoS level, providing guaranteed delivery of messages exactly once. This is achieved through a four-step handshake process between the sender and the receiver. The process begins with the sender publishing a message, which is followed by a PUBREC packet from the receiver acknowledging the receipt of the PUBLISH packet. The sender then responds with a PUBREL packet, indicating that it has received the PUBREC and is releasing the message. Finally, the receiver sends a PUBCOMP packet back to the sender to confirm the completion of the exchange. This sequence ensures that messages are not lost or duplicated during transmission. It provides the most assurance but also introduces additional overhead, making it suitable for operations where message duplication or loss cannot be tolerated, like financial transactions within industrial processes.
Efficiency
Unlike traditional client-server models, MQTT utilizes publish-subscribe model allows for efficient message distribution and decouples the producer and consumer of the message, resulting highly efficient, scalable, and flexible systems. Here's why this model is beneficial:
Decoupling of Devices
In the publish-subscribe model, the producers of messages (publishers) are decoupled from the consumers of messages (subscribers). This means that devices do not need to have specific knowledge about each other, such as subscribers' identities, locations, and IP addresses—an advantage in dynamic industrial environments where devices may often change or move. Consider a manufacturing plant where various field components such as sensors, actuators, and PLCs need to communicate effectively. In traditional systems, these devices would be tightly coupled, requiring direct and often complex interactions. However, with the publish-subscribe model, each device operates independently. For instance, a temperature sensor in the plant can publish its readings to a central broker without needing to know which PLCs or other devices will use this data.
The central broker, which acts as the nerve center of this communication paradigm, manages all data subscriptions. PLCs or other interested parties can subscribe to the temperature readings and receive updates automatically from the broker. This setup eliminates the need for constant polling of devices for new messages, thereby reducing network traffic and increasing scalability.
Scalability
The broker-based architecture allows for effortless scalability. Many devices can publish their data to a broker, and an equally large number can subscribe to topics of interest, without requiring point-to-point connections between devices. Furthermore, the broker can manage a vast number of concurrent connections. As demands grow and more devices connect to the network, the broker merely needs to handle additional publish requests and manage new subscriptions, all without the need for individual clients to manage multiple connections themselves. For instance, in a manufacturing setting with a multitude of sensors and actuators spread across the facility, each sensor can publish its readings—such as temperature, pressure, or speed—to a specific topic managed by the broker. PLCs, which are programmed to respond to certain thresholds or changes in the environment, can subscribe to these topics. When a sensor's reading crosses a predefined limit, the specific PLC receives this information through the broker and can take appropriate action, such as adjusting a control valve or shutting down a conveyor belt.
Efficient Bandwidth Usage
Since clients only receive messages they are subscribed to, bandwidth is not wasted transmitting all data to all devices. Control messages can be as small as two bytes, and message headers are also kept to a minimum size to ensure that network bandwidth is used as efficiently as possible. Each device gets only the information it needs, which conserves network bandwidth and reduces unnecessary data traffic. For instance, in a factory where predictive maintenance and flexible manufacturing are critical, the use of Pub/Sub can support the production of highly configured goods. Devices like sensors and actuators no longer need to send their data to a master PLC for processing. Instead, they publish their data, such as temperature readings or cycle times, to a message broker. The broker then distributes this information to all subscribed entities, which could include other PLCs, monitoring systems, or even cloud-based analytics platforms.
Flexibility in Data Routing
Topics in MQTT facilitate sophisticated data routing. Publishers send messages to topics that subscribers listen to, and the same message can be delivered to multiple subscribers, offering great flexibility and the capability to implement complex communication patterns without additional programming on the devices themselves. The model also allows for shared subscriptions, where messages can be load-balanced among multiple subscribers within a subscription group. This feature further enhances the flexibility of the Pub/Sub model by allowing efficient message distribution even when there are numerous subscribers. In the realm of smart homes, for instance, the pub-sub model is instrumental in enabling sensors to communicate with actuators, such as turning on lights when someone enters a room. This example underscores the model's capability to streamline interactions within an Internet of Things (IoT) ecosystem.
Two-Way Communication
Through subscriptions, devices can not only publish data but also to listen for commands and updates. This bidirectional communication is achieved through subscriptions, where devices can subscribe to specific topics and receive relevant messages from the control system or other devices. For instance, consider a scenario where a temperature sensor in a smart home setup is designed to monitor the ambient conditions of a room. This sensor acts as a publisher, periodically sending temperature readings to a designated topic within the pub-sub system. An air conditioning system, equipped with the capability to subscribe to specific topics, listens for updates on the temperature topic. When the temperature sensor publishes a new reading indicating that the room's temperature has risen above a certain threshold, the air conditioning system, as a subscriber, receives this message. It then processes the information and responds by adjusting its settings to cool the room down to the desired temperature.
Real-time Communication
The broker acts as a central hub in the publish-subscribe model. When a publisher has a new message to send, it publishes this message to a topic on the broker. The broker then handles the delivery of that message to all subscribers who have previously subscribed to that topic. Since the broker maintains persistent connections with both publishers and subscribers, messages are pushed out as they arrive without waiting for subscribers to request them, in contrast to polling mechanisms. This immediate forwarding of messages reduces latency and ensures near real-time communication. Subscribers can express interest in specific topics, and the broker will ensure that they only receive messages published under those topics. For instance, in an industrial setting, sensors on a conveyor belt might publish readings to the topic "conveyor/speed," and only the necessary control systems, which are subscribed to that topic, would receive those messages.
Example - Industrial Sensor Monitoring
Consider a manufacturing plant with various sensors that monitor equipment status and environmental conditions. These sensors act as publishers and send data continuously to topics such as "temperature/sensor-1" or "equipment/machine-3/status".
An MQTT broker manages these topics. If the temperature regulator system subscribes to "temperature/sensor 1", it immediately receives updates whenever the sensor publishes new temperature readings. In case a threshold is exceeded, the system can instantly react by activating a cooling system; similarly, if a machine reports a fault condition under "equipment/machine 3/status," the maintenance team’s monitoring system, subscribed to that topic, gets alerted so they can quickly address the issue.
Adaptable to Various Network Conditions
The model fits well with harsh network conditions common in remote industrial sites, due to its ability to support event-driven architectures and asynchronous parallel processing, which are essential for improving performance, reliability, and scalability. This is particularly beneficial in remote industrial environments where network conditions can be challenging and unpredictable. The Pub/Sub model simplifies communication by removing the need for point-to-point connections, instead relying on a single connection to a message topic that manages subscriptions and message delivery. In scenarios where network architecture may change, such as in remote industrial sites, Pub/Sub supports asynchronous message delivery, ensuring reliable message delivery even when the message broker's topic architecture changes. This builds elasticity into the system, as the business logic does not depend on the number of active publishers and subscribers at any given instance.
The pub/sub model plays a crucial role in both predictive maintenance and flexible manufacturing by facilitating real-time data exchange and increased flexibility. This model allows for asynchronous communication between services producing messages and those processing them, with latencies on the order of 100 milliseconds. In industrial networks, the pub/sub paradigm is gaining traction through emerging standards like Message Queueing Telemetry Transport (MQTT) and OPC Unified Architecture (OPC UA) with extensions for time-sensitive networking (TSN).
