Comparative Analysis of IoT Gateway Protocols: MQTT and Modbus

▼Click on the image below to search for【Internet of Things】 to access a plethora of practical IoT projects we’ve prepared for you.

The Internet of Things (IoT) is not just a new technology, but also an integration with old technologies, with communication being the key. The communication methods available vary greatly, but various protocols play a crucial role in connecting a vast number of “things” to the internet.

This article introduces two supplementary IoT protocols: the local protocol Modbus for short-distance device connections and the extensible internet protocol “Message Queuing Telemetry Transport (MQTT)” that supports global communication for IoT.

Modbus is a serial communication protocol that first appeared in 1979 and is the standard protocol used to connect industrial devices. MQTT emerged over 20 years ago, but combining these two protocols can provide IoT scalability and connectivity for deeply embedded devices.

Figure 1. IoT (Internet of Things) gateways as a supporting solution for IoT communication. Let’s take a look at Modbus and MQTT to understand their differences and how they complement each other in IoT.

Comparative Analysis of IoT Gateway Protocols: MQTT and Modbus

1. Modbus

Since its introduction in 1979, Modbus has evolved into a comprehensive set of protocols supporting various physical links (such as RS-485). The core of Modbus is a serial communication protocol that operates in a master-slave mode. The master sends requests to the slave, which replies accordingly. In a standard Modbus network, there is one master and up to 247 slaves (however, this limit can be significantly increased with 2-byte addressing).

With RS-485, communication between the master and slave occurs in frames indicating function codes. These function codes identify the operations to perform, such as reading discrete inputs; reading FIFO queues; or executing diagnostic functions. The slave then responds based on the received function code, and the response is fairly simple, indicated by a set of bytes. Thus, the slave can be either an intelligent device or a simple device with only one sensor.

From this description, you can see that the Modbus protocol is very simple, but its openness as a protocol makes it a practical communication protocol for entire industries or SCADA systems.

2. Message Queuing Telemetry Transport

MQTT is an open, lightweight machine-to-machine protocol designed for IoT interactions. An MQTT network consists of an MQTT broker, which coordinates interactions between MQTT clients. Clients are publishers responsible for publishing information for users (see Figure 2).

Figure 2. Factors in the Message Queuing Telemetry Transport network

MQTT requires very little because it is designed for resource-constrained embedded devices. Besides occupying minimal space, MQTT also offers excellent communication efficiency (even over low-bandwidth networks) and very low overhead (compared to protocols like HTTP). In a 3G network, MQTT’s throughput speed is 93 times that of HTTP’s Representational State Transfer (REST).

MQTT can indicate operations to be performed on specific topics using minimal methods, thus implementing a publish/subscribe model. Clients first connect to the broker and then publish or subscribe to topics. Once done, clients disconnect from the broker. The MQTT methods defined are:

Connect – Establish a connection with the MQTT broker.

Disconnect – Disconnect from the MQTT broker.

Publish – Publish a topic on the MQTT broker.

Subscribe – Subscribe to a topic from the MQTT broker.

Unsubscribe – Unsubscribe from a topic on the MQTT broker.

Figure 3 illustrates the simple interaction between publishers and subscribers using the MQTT broker. As shown, the producer connects to the MQTT broker. Similarly, the consumer connects to the MQTT broker. The consumer subscribes to a topic (defined here as /home/alarms/1/status). This example topic can identify the status change of the alarm system for area 1 on the home page. When the producer has information to share, it publishes a message to the broker, which then shares the information with all users subscribed to that topic.

Figure 3. Simple interaction between Message Queuing Telemetry Transport clients

Note the structure of the topics shared here. It resembles a file system hierarchy, which simplifies the structure of topics. This hierarchical resource form is also common in protocol architectures, such as REST.

MQTT even allows the use of wildcards to simplify the subscription process. If a user wants to get the status of all alarms, they can simply subscribe to /home/alarms/+/status, which will notify the user of all alarm status changes. The entire subtree can also be subscribed to using the topic /home/#, which subscribes to all events under /home.

2.1 Quality of Service

MQTT allows the definition of Quality of Service (QoS). There are three levels of QoS in MQTT:

QoS 0. This level indicates “at most once” delivery (best effort). Messages are not acknowledged, making this a fire-and-forget approach.

QoS 1. This level indicates “at least once” delivery. Users may receive the message more than once, but the receiving party is allowed to acknowledge receipt.

QoS 2. The slowest but most guaranteed level of service quality is level 2. QoS 2 indicates “exactly once” and includes a four-stage delivery handshake. This level is the slowest but the most secure.

The QoS level you choose will depend on the data and the importance of its delivery.

2.2 Message Queuing Telemetry Transport Broker

As more IoT applications adopt MQTT as a supporting protocol, you will find MQTT appearing in many open-source applications and products. The Intel® IoT Gateway solution is one such comprehensive IoT solution that employs MQTT.

This series of products supports secure interactions between sensors, devices, and the cloud. These pre-validated application-ready platforms support excellent manageability, security, and various connectivity options, such as ZigBee*, cellular networks, Bluetooth*, USB, Wi-Fi*, and of course, protocols like MQTT and Modbus.

Intel offers three versions of the Intel® IoT Gateway based on market demand, each with different input/output options, targeting different fields such as industrial and energy, transportation, and integrated industries. Despite their differences, they all include common manageability, supply, data, and endpoint security, as well as runtime environments. They all run on the secure and stable Wind River* Linux*.

The main advantage of the Intel® IoT Gateway is the embedded control security technology from McAfee®. McAfee® Embedded Control processes device changes based on policies while tracking all changes to provide complete visibility and explainability for continuous audit trails.

Conclusion

MQTT and Modbus can complement each other to enhance IoT performance. Using Modbus as a local interface to manage devices and MQTT as a global protocol to extend device reach, both play important roles. The Intel® IoT Gateway provides a simple and secure way to build IoT for now and the future.

This article is reproduced from:https://www.cnblogs.com/3echo/p/11612560.html

Recent Courses: