What is the MQTT Communication Protocol?
The rapid proliferation of Internet of Things (IoT) and other similar distributed systems has increased the importance of data communication. The requirements of systems such as networks and devices with low bandwidth, high latency and poor security have created the need for a lightweight and reliable communication protocol. MQTT (Message Queuing Telemetry Transport) is a communication protocol designed to meet such a need. With its basic structure, MQTT minimizes network bandwidth and resource utilization on the device, while providing security and delivery assurance during data exchange. With this basic structure, MQTT is becoming increasingly important in the world of M2M (Machine to Machine) and IoT (Internet of Things). In this article, MQTT’s architecture, features, data structure, working principles, usage areas and advantages over other communication protocols will be examined in various sub-headings.
Architecture and Working Principle of MQTT Protocol
MQTT is a simple and lightweight protocol, based on a client-server model. The basic components of MQTT’s architecture are as follows:
Client: Devices that initiate and manage MQTT communication, sending or receiving data. Clients can run on many different platforms. There are two basic client roles in MQTT:
- Publisher: Devices that generate data and transmit it to the MQTT broker.
- Subscriber: Devices that subscribe to a specific topic. These devices listen to the data published on that topic.
Broker (Server): The broker receives MQTT messages and routes them to the desired clients. Instead of direct communication between clients, communication takes place through the broker. It is the research point that manages communication between clients. It acts as a central hub where clients receive and forward their messages to the target clients.
Topic: Topics determine the destination of the transmitted messages. It is a hierarchical structure in which messages are categorized. Clients can listen to a particular topic (subscribe) or send a message to that topic (publish).
Message: Data transmitted via MQTT. Each message is associated with a topic and forwarded to clients.
Clients cannot communicate directly with each other. Each client communicates through the Broker, i.e. each processor is connected to the Broker. Clients can act as Publisher, Subscriber or both at the same time. Publishers publish data with a certain “Topic” name and Subscribers subscribe to the Broker through this “Topic” name and receive the published messages, depending on the QoS (Quality of Service) level, the transmission and delivery of the message is provided through the Broker.
Clean Session
MQTT’s “Clean Session” is a feature that determines how the session between an MQTT client and an MQTT server is managed. The Clean Session feature determines the behavior of the MQTT client when it connects to an MQTT server and starts a session, There are two basic options:
Clean Session (1) Enable: In this case, when an MQTT client starts a session, the server deletes the previous session data of this client. This means that every time the client connects, the server treats it as a new session and does not retain any information from the previous session. This is suitable for applications that want to work with a clean and initial state on every connection.
Clean Session (0) Disable: In this case, when the MQTT client starts the session, the server retains the client’s previous session information. This allows the client to remember the topics it subscribed to and the messages it published in the previous session.
Mikrodev DCS, PLC and ViewPLUS SCADA products have MQTT Client support regardless of product family. The settings related to the Topic to Subscribe or Topic to Publish are made in the “MQTT Table Panel” section in the Telediagram / Microdiagram Programming Editor. In addition, parameters such as Client ID, Username, Password, Keep Alive, Clean Session, SSL/TLS can be set with the MQTT Config Block.
In Microdev RTUs and PLCs, the Topic to be published can be published in 3 ways. The use of these 3 methods should be determined according to the data traffic and the order of importance between the Topics. These methods are explained below:
-Periodic Submission: By applying a rising edge to the “Trig” input of the MQTT Config block, it is possible to send messages related to the blocks with periodic sending enabled at specified periods. It is also possible to assign a block to which periodic sending can be activated or deactivated instantly, thanks to this feature, data traffic related to periodic sending can be activated or deactivated without the need for reconfiguration.
-Sending on Change: In blocks where the change value and change type (Level / Percentage Change) are specified in the MQTT Table Panel section, sending can be provided when there is a value change exceeding the threshold value of the specified type. It is also possible to assign a block where you can instantly activate or deactivate the sending in the change, thanks to this feature, the data traffic connected to the sending in the change can be activated or deactivated without the need for reconfiguration.
-Sending with Trigger Blog: In addition to Periodic and Interchange sending, messages belonging to the selected block or block groups can also be sent depending on the block whose associated sending trigger block is selected.
Various configurations of the above mentioned sending methods can be made from the MQTT Table Panel section in the Telediagram/Microdiagram.
MQTT Data Structure and Message Architecture
MQTT messages consist of a header and a payload:
Header: The header contains the type of message (subscription, broadcast, etc.), QoS level and other communication information.
Data (Payload): Data is the actual content sent by the user. MQTT can carry any type of data, which makes it very versatile. In microdev RTU and PLC devices, the payload type can be selected. With the Payload type that we can add “Time Tag” to the data, the event record that occurs when the communication between Mikrodev PLC/RTU and ViewPLUS SCADA is broken for any reason, when the communication is restored, it is possible to fill the Database retrospectively by receiving time tagged data to ViewPLUS SCADA, it is possible to process and overwrite the data of past time periods. Thanks to this feature, ViewPLUS SCADA can create more logical and consistent reports. The ability to create a past event record thanks to the time tag can be called “Backfilling”.
MQTT offers various advantages in terms of connection and data security with the features included in the message architecture and examined in the following subheadings.
QoS (Quality of Service)
MQTT QoS (Quality of Service) is a feature used within the MQTT (Message Queuing Telemetry Transport) protocol to adjust the transmission assurance and correctness of messages. MQTT is a lightweight messaging protocol and is frequently used in IoT and other applications that require low bandwidth or power consumption. MQTT QoS levels determine what kind of assurance it provides in the transmission of messages and offers three different levels:
QoS 0 (At Most Once):
This level provides the lowest assurance of messages. Messages are sent with a guarantee of “at most once” transmission. That is, messages can be lost or delivered multiple times. It is suitable for situations where fast communication is required and lost data is acceptable.
QoS 1 (At Least Once):
This level ensures that messages are delivered strictly “at least once”. The sender sends the message to the receiver and the receiver acknowledges receipt with a “PUBACK” message to the sender. The sender can send the message again before receiving this confirmation.
QoS 2 (Exactly Once):
This level ensures that messages are delivered absolutely once and only once. The sender sends the message to the receiver and the receiver performs a series of handshake operations after receiving the message (PUBLISH, PUBREC, PUBREL, PUBCOMP). These operations ensure that the message is delivered strictly once. This level is used in critical applications where data loss or redelivery is unacceptable, but may require more bandwidth and communication time.
QoS levels are chosen according to the scenario in which they are used and the communication requirements. Higher QoS levels provide more communication assurance, but use more bandwidth and communication time. Therefore, it is important to choose the right QoS level depending on the needs of the application and network conditions.
Last Will and Testament
LWT is used to define a message to be sent when an MQTT client or server (broker) disconnects or an error occurs. This message may contain important information such as the last request or status of the device that lost the connection. The LWT feature increases the reliability of communication between devices and allows devices to better manage connection status. If a client loses its connection unexpectedly, it can specify a “WILL” message. This notifies other clients or the broker of the loss of connection.
Retain
The “Retain” feature of the MQTT (“Message Queuing Telemetry Transport”) protocol refers to the ability to store the last message on an MQTT topic. This feature ensures that when a client publishes a message on a topic, it is stored by the MQTT server (broker) instead of sending it to other subscribed clients. Thus, new clients subscribing to a topic can immediately receive the last stored message on that topic. The Retain feature of MQTT is implemented as follows:
- When a client broadcasts a message on a specific MQTT topic, it broadcasts this message and at the same time forwards this message to the MQTT server (Broker) for storage.
- This message is stored by the MQTT server and is not sent to other clients following that topic.
- When a client subscribes to the same topic or becomes a new subscriber, the MQTT server immediately sends the last stored message. This ensures that the client has the latest information about the topic.
However, the Retain feature needs to be used with caution, because when any client follows a topic, it receives the last stored message. Therefore, the Retain feature can lead to inadvertent access of sensitive or outdated data. Therefore, it is important to manage topics and messages correctly when using the Retain feature.
Security Principles in MQTT Communication Protocol
MQTT is secured by mechanisms such as SSL/TLS encryption and authentication. This helps to keep sensitive data secure. DM50, DM100 and DM500 series RTUs in Mikrodev DCS product line have SSL/TLS support. In addition, data security is taken to the highest levels thanks to structures such as QoS, LWT and Retain in MQTT.
Usage Areas of MQTT Communication Protocol
Home and Building Automation: IoT devices can be enabled to communicate with home and building automation systems.
Industrial Automation: Used in industrial applications such as factories, production facilities and energy systems.
Transportation and Logistics: Ideal for vehicle tracking systems and intelligent transportation systems.
Healthcare: Provides secure communication for medical devices and patient tracking systems.
Transportation and Logistics: Vehicles and transportation systems can share location and status information over MQTT.
Advantages of MQTT over Other Communication Protocols
Lightweight and Efficient: MQTT uses minimal resource consumption and low bandwidth, making it suitable for IoT devices and systems with low power consumption.
Broadcast-Subscriber Model: MQTT’s broadcast-subscriber model simplifies data distribution and provides a more scalable structure.
QoS Levels: MQTT can use QoS levels to determine levels of communication assurance, which increases the reliability of communication.
Wide Use Cases: MQTT has use cases outside the IoT, making it more universal.
MQTT is a lightweight, efficient, flexible and widely used communication protocol. It is used in a wide range of applications from IoT applications to industrial automation and has a number of advantages over other protocols, such as its lightweight nature and QoS levels. MQTT provides a reliable option for data communication. For this reason, it is considered a major player in the IoT and M2M world and will continue to grow and form the basis of IoT applications in the future.
You can transfer data, analyze data and generate reports between Mikrodev DCS, PLC and ViewPLUS SCADA products and ERP (Enterprise Resource Planning) or MES (Manufacturing Execution System) Systems.
