Modbus is a serial communication protocol that first appeared in 1979 and is the standard protocol actually used to connect industrial devices. MQTT has been around for 20 years, but combining these two protocols can provide deep embedded devices with the scale and connectivity of the Internet of Things.
The following diagram illustrates the general relationship among these protocols:
As a supporting solution for IoT communication, let's now take a look at Modbus and MQTT to understand their differences and how they complement each other in the IoT.
Modbus
Since its first appearance in 1979, Modbus has evolved into a comprehensive protocol set supporting multiple physical links (such as RS485). The core of Modbus is a serial communication protocol that adopts a master-slave mode. The master sends requests to the slaves, and the slaves respond. In a standard Modbus network, there is one master and up to 247 slaves (however, this limit can be significantly increased if 2-byte addressing is used).
With the help of RS485, communication between the master and slave devices occurs within frames that indicate function codes. These function codes identify the function to be operated, such as reading independent inputs, reading from a first-in first-out queue, or executing diagnostic functions. Then, the slave device responds based on the received function code, and the response is relatively simple, indicated by a set of bytes. Therefore, the slave device can be an intelligent device or a simple device with only one sensor.
From this description, you can see that the Modbus protocol is quite simple, but its openness as a protocol makes it the de facto communication protocol for the entire industry or SCADA systems.
Message queue telemetry transmission
MQTT is an open lightweight machine to machine protocol designed specifically for IoT interaction. The MQTT network includes an MQTT broker responsible for coordinating interactions between MQTT brokers. Proxy is a publisher responsible for publishing information for users to use (see figure below).
Factors affecting message queue telemetry transmission network
MQTT has very few requirements because it is designed specifically for embedded devices with limited resources. In addition to occupying less space, MQTT can also provide excellent communication efficiency (even through low bandwidth networks) and very little overhead (compared to protocols such as HTTP).
MQTT can implement the publish/subscribe pattern by using a minimal set of methods to indicate the operations to be performed on a specific topic. The agent first connects to the broker and then publishes or subscribes to a topic. After completion, the agent disconnects from the broker. MQTT method definitions:
Connection - Establish a connection with the MQTT broker.
Disconnect - Disconnect from MQTT broker.
Publish - Publish a topic on MQTT brokers.
Subscription - Subscribe to topics from MQTT brokers.
Unsubscribe - Unsubscribe the topic from MQTT broker.
As shown in the following figure, the figure illustrates a simple interaction between publishers and subscribers using MQTT brokers. As shown in the figure, the information creator (producer) is connected to the MQTT broker. Similarly, information consumers connect to MQTT brokers. Consumer subscription topic (defined here as/home/arms/1/status). This example topic can identify the status changes of the alarm system for Zone 1 on the homepage. When the creator has information to share, it will post a message to the broker, who will then share the information with all users who subscribe to the topic.
Simple interaction between message queue telemetry transmission agents
Please note the topic structure shared here. It is similar to the hierarchical structure of a file system, which can simplify the structure of topics. This type of resource hierarchy is also commonly seen in protocol architectures, such as REST.
MQTT even allows the use of wildcards to simplify the subscription process. If a user wants to obtain the status of all alarms, they can directly subscribe to the topic /home/alarms/+/status, which notifies the user of all changes in alarm status. The entire subtree can also be subscribed to using the topic /home/#, which allows subscription to all events under the directory /home.
Service Quality
MQTT allows for the definition of Quality of Service (QoS). There are three levels of QoS in MQTT:
1. QoS 0. This level represents "at most once" delivery (best case scenario). Messages are not acknowledged, making it a fire-and-forget method.
2. QoS 1. This level represents "at least once" delivery. Users may receive messages more than once, but those who receive them are allowed to acknowledge receipt.
3. QoS 2. The slowest but most guaranteed level of QoS is level 2. QoS 2 represents "exactly once" and includes a four-phase delivery handshake. This level is the slowest but the most secure.
The QoS level you choose will depend on the importance of the data and its delivery.
Leave a Reply