Follow + star the public account, don't miss wonderful content
Source | Blog Garden
The Internet of Things (IoT) is not just a new technology, but also the integration with old technologies, with communication being the key. Various communication methods are available, but different protocols play an important role in connecting a massive number of “things” to the Internet.
This article introduces two supplementary protocols for IoT: the local protocol Modbus for short-distance device connections and the scalable 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 using these two protocols together can provide IoT scale and connectivity for deeply embedded devices.
Figure 1. IoT (Internet of Things) gateways as supportive solutions 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 first appearance 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 adopts a master-slave model. 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, if 2-byte addressing is used, this limit can be significantly increased).
With RS-485, communication between the master and slave occurs in frames indicating function codes. These function codes identify the operations 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 simple response consisting of a set of bytes. Therefore, the slave can be a smart 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 the entire industry or SCADA systems.
2. Message Queuing Telemetry Transport
MQTT is an open, lightweight machine-to-machine protocol designed for IoT interactions. An MQTT network includes an MQTT broker responsible for coordinating 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 has very few requirements because it is designed for resource-constrained embedded devices. In addition to occupying less space, MQTT also provides excellent communication efficiency (even over low-bandwidth networks) and very little overhead (compared to protocols such as HTTP). In 3G networks, the throughput speed of MQTT is 93 times that of HTTP’s Representational State Transfer (REST).
MQTT indicates operations to be performed on specific topics with minimal methods, thus implementing a publish/subscribe model. Clients first connect to the broker before publishing or subscribing to topics. After completion, 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 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 changes 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 will then share the information with all users subscribed to that topic.
Figure 3. Simple interaction between Message Queuing Telemetry Transport clients
Note the topic structure shared here. It resembles a file system hierarchy, which simplifies the topic structure. This hierarchical form of resources 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 receive the status of all alarms, they can directly 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 can subscribe to all events under /home.
2.1 Quality of Service
MQTT allows for 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 acknowledgments are allowed.
QoS 2. The slowest yet most guaranteed level of service quality is level 2. QoS 2 indicates “exactly once” and includes a four-phase delivery handshake. This level is the slowest but the safest.
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 devices 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 adopts 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 like 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 featuring different input/output options and targeting various fields such as industrial and energy, transportation, and integrated industries. Despite their differences, they all include common manageability, supply, data, endpoint security, and runtime environment. 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 based on policies while tracking all changes to provide complete visibility and explainability for ongoing 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 important roles. The Intel® IoT Gateway provides a simple and secure way to build IoT for now and the future.
Original text: https://www.cnblogs.com/3echo/p/11612560.html
Disclaimer: The materials in this article are sourced from the internet, and copyright belongs to the original author. If there are copyright issues regarding the works, please contact me for deletion.
———— END ————
●Column “Embedded Tools”
●Column “Embedded Development”
●Column “Keil Tutorial”
●Selected Tutorials from Embedded Column
Follow the public account reply “Add Group” to join the technical exchange group according to the rules, reply “1024” to see more content.
Click “Read Original” to see more shares.
