Source | Blog Garden
The Internet of Things (IoT) is not just about new technologies but also the integration with older technologies, with communication being key. Various communication methods are available, but different protocols play a crucial role in connecting a vast number of ‘things’ to the internet.
This article introduces two complementary protocols for the IoT: the local protocol Modbus for short-range device connections and the scalable internet protocol ‘Message Queue Telemetry Transport (MQTT)’ that supports global communication for IoT.
Modbus is a serial communication protocol that first appeared in 1979, and it 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 supportive solution for IoT communication. Let’s look at Modbus and MQTT to understand their differences and how they complement each other in IoT.
1. Modbus
Since its inception in 1979, Modbus has evolved into a comprehensive set of protocols supporting multiple 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, and the slave responds. 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 RS-485, communication between the master and slave occurs in frames indicating function codes. These function codes identify the operation to be performed, such as reading discrete inputs, reading FIFO queues, or executing diagnostic functions. The slave then responds based on the received function code, with a relatively simple response consisting of a set of bytes. Thus, the slave can be a smart device or a simple device with just 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 the entire industry or SCADA systems.
2. Message Queue Telemetry Transport
MQTT is an open, lightweight machine-to-machine protocol designed for IoT interactions. An MQTT network consists of an MQTT broker that coordinates interactions between MQTT clients. Clients are publishers responsible for publishing information for users (see Figure 2).
Figure 2. Factors in the Message Queue Telemetry Transport network
MQTT has minimal requirements because it is designed for resource-constrained embedded devices. In addition to occupying little space, MQTT also provides excellent communication efficiency (even over low-bandwidth networks) and very little overhead compared to protocols like HTTP. In 3G networks, MQTT’s throughput speed is 93 times that of HTTP’s Representational State Transfer (REST).
MQTT uses minimal methods to indicate operations to be implemented on specific topics, thereby implementing a publish/subscribe model. Clients connect to the broker before publishing or subscribing to topics. Once done, clients disconnect from the broker. The MQTT methods are defined as follows:
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 shows a simple interaction between a publisher and a subscriber using the MQTT broker. As shown, the information creator (producer) connects to the MQTT broker. Similarly, the information consumer (consumer) connects to the MQTT broker. The consumer subscribes to a topic (defined here as /home/alarms/1/status). This example topic identifies the status change of the alarm system for area 1 on the home page. When the creator 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 Queue Telemetry Transport clients
Note the topic structure 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 it a fire-and-forget method.
QoS 1. This level indicates ‘at least once’ delivery. Users may receive the message more than once, but acknowledgment is allowed.
QoS 2. The slowest but most guaranteed level of service quality is level 2. QoS 2 indicates ‘exactly once’ and involves 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.
2.2 Message Queue Telemetry Transport Brokers
With more IoT systems adopting 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 uses 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, each with different input/output options and tailored for various 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 McAfee® Embedded Control security technology. McAfee® Embedded Control can handle device changes according to policies while tracking all changes, providing complete visibility and explainability for continuous audit trails.
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 the range of devices, both play significant roles. The Intel® IoT Gateway provides a simple and secure way to build IoT for now and the future.
Original: https://www.cnblogs.com/3echo/p/11612560.html
Disclaimer: The material in this article is sourced from the internet, and the copyright belongs to the original author. If there are copyright issues, please contact me for deletion.
