The Internet of Things (IoT) isn’t just about new technologies: It’s also about integration with older technologies, a key attribute of which is communication. The available methods of communication are diverse, however, and numerous protocols play a role in bringing the plethora of “things” to the Internet. This article explores two complementary protocols for the IoT: Modbus, a local protocol for short-distance device attachment, and Message Queuing Telemetry Transport (MQTT), a scalable Internet protocol that enables global communication for the IoT.
Modbus is a serial communications protocol that first appeared in 1979 and is the de facto standard protocol for connecting industrial devices. MQTT appeared 20 years later, but bringing these two protocols together gives deeply embedded devices the scale and connectivity of the Internet. Figure 1 illustrates the general relationship between these protocols while introducing the enabling solution for connectivity: the IoT gateway.
Figure 1. The Internet of Things (IoT) gateway as an enabling solution for IoT communication Let’s explore Modbus and MQTT to see how they differ and how they complement each other for the IoT.
Modbus
Since it first appeared in 1979, Modbus has evolved into a broad set of protocols over a variety of physical links (for example, RS-485). At its core, Modbus is a serial communications protocol that follows a master–slave model. A master sends a request to a slave device, and the slave returns a response. In a standard Modbus network, there is one master and up to 247 slaves (although 2 byte addressing can significantly expand this limit).
With RS-485, communication between a master and a slave occurs in a frame that indicates a function code. The function code identifies the action to perform, such as read a discrete input; read a first in, first out queue; or perform a diagnostic function. The slave then responds, based on the function code received, with a simple response indicated by a set of bytes. Slaves can therefore be intelligent devices or simple devices that represent a single sensor.
From this description, you can see the simplicity of the Modbus protocol, but its openness as a protocol has popularized it as a de facto communication protocol for industrial or SCADA systems.
Message Queuing Telemetry Transport
MQTT is an open, lightweight machine-to-machine protocol designed for IoT interactions. An MQTT network contains an MQTT broker, which mediates interactions among MQTT agents. The agents are publishers, which publish information for consumption by subscribers (see Figure 2).
Figure 2. Actors in a Message Queuing Telemetry Transport network
The requirements for MQTT are minimal as it’s designed for resource-constrained embedded devices. In addition to a minimal footprint, MQTT was designed for communication efficiency — even over low-bandwidth networks — and minimal overhead (compared to protocols such as HTTP). Over 3G networks, MQTT throughput has been measured at 93 times faster than Representational State Transfer (REST) over HTTP.
MQTT implements a publish/subscribe model with a minimal set of methods that indicate the action to be performed on an identified topic. Agents connect to a broker, then publish topics or subscribe to topics. When finished, an agent disconnects from the broker. MQTT methods are defined as:
Connect - Establish a connection to an MQTT broker.
Disconnect - Tear down a connection from an MQTT broker.
Publish - Publish a topic to an MQTT broker.
Subscribe - Subscribe to a topic from an MQTT broker.
Unsubscribe - Unsubscribe to a topic from an MQTT broker.
Figure 3 illustrates a simple interaction between a publisher and subscriber using an MQTT broker. As shown, a producer of information connects to an MQTT broker. Similarly, a consumer of information connects to the MQTT broker. The consumer subscribes to a topic, defined here as /home/alarms/1/status. This example topic identifies the change in status of a home’s alarm system for zone 1. When the producer has information to share, it publishes a message to the broker, which then shares the information to all subscribers of this topic.
Figure 3. A simple interaction between Message Queuing Telemetry Transport agents
Note the structure of the topic being shared here. It looks similar to a file system hierarchy, which simplifies the organization of topics. This hierarchical form of resources is also popular in protocol architectures such as REST.
MQTT even allows a form of wildcards to simplify the subscription process. If a subscriber wanted the status of all alarms, he or she could simply subscribe to /home/alarms/+/status, which would notify the subscriber of any alarm status changes. The complete subtree could also be subscribed with the topic /home/#, which would subscribe to all events under /home.
Quality of Service
MQTT permits the definition of quality of service (QoS). Three levels of QoS exist in MQTT:
QoS 0. This level means “at most once” delivery (best effort). Messages are not acknowledged, which makes this a “fire and forget” approach.
QoS 1. This level means “at least once” deliver. A subscriber may get the message more than once, but the receiver is allowed to acknowledge receipt.
QoS 2. The slowest but highest guarantee QoS level is 2. QoS 2 means “only once” and involves a four-stage handshake for delivery. This level is the slowest but also the safest of the QoS levels.
Your choice of QoS level is based on the data and the importance of their delivery.
Message Queuing Telemetry Transport Brokers
With the growing popularity of MQTT as an enabler of IoT, you’ll find MQTT in open source apps and a number of products. One comprehensive IoT solution that includes MQTT is Intel® IoT Gateway solutions.
This family of products enables secure interconnections among sensors, devices, and the cloud. These prevalidated and application-ready platforms include manageability; security; and a wide variety of connectivity options, such as ZigBee*, cellular networks, Bluetooth*, USB, Wi-Fi*, and of course protocols such as MQTT and Modbus.
Based on market needs, you’ll find three variants of the Intel® IoT Gateways, with different input/output options and focuses on industrial and energy, transportation, and combined options. Even with these differences, however, all include common manageability and provisioning, data and end point security, and runtime environments. Each runs on the secure and stable Wind River* Linux*.
A key benefit of Intel® IoT Gateways is the McAfee® Embedded Control security technologies. McAfee® Embedded Control handles changes to the device based on policy while tracking all changes to allow complete visibility and accountability for a continuous audit trail.
Summary
MQTT and Modbus help advance the IoT in a complementary way. Using Modbus as a local interface to manage devices and MQTT as a global protocol to expand the reach of those devices’ data, each serves an important role. The Intel® IoT Gateways provide an easy and secure way to build the IoT now and in the future.
Additional Reading
Visit the Intel® IoT Gateway web site to learn more.
Explore the IoT gateway offerings to compare features and necessities.
Login to leave a comment below. If you are not registered go to the Intel® Developer Zone to sign up.