The Message Queuing Telemetry Transport (MQTT) is one of the most popular methods of moving data throughout the factory floor and into cloud applications. Much like Modbus TCP, MQTT uses a client/server relationship between devices. One of the biggest differences between MQTT and nearly every other industrial protocol is the publish/subscribe architecture.
One of the biggest challenges MQTT is designed to overcome is the challenge of publishing small pieces of data in volume to many stakeholder devices that are limited by unreliable networks, low bandwidth, and high latency.
Another primary difference to note between MQTT and other industrial protocols is that it utilizes a central server (known as a broker) to facilitate communications between devices. A broker receives the information from the servers and matches the information to consumers by topic subscriptions. The information is distributed to every consumer that matches the topic. If no consumer requires the information, the information is discarded. More information on the broker to follow.
MQTT works very well in environments with dynamic communication environments where large quantities of data need to be made available to tens of thousands of devices. The following qualities allow MQTT to be successful:
MQTT is a protocol that runs over TCP/IP and is used to transport lightweight messages between devices. As manufacturing begins to invest deeper and deeper into the Internet of Things (IoT), the more prevalent MQTT will become on the factory floor. MQTT was created by Andy Stanford-Clark or IBM, and Arlen Nipper of Eurotech. The goal in creating The MQTT protocol was created with the purpose of connecting oil pipelines over unreliable satellite networks. A new protocol was needed—one that was lightweight, bandwidth-efficient, and data agnostic.
In 2011, the founders of MQTT donated MQTT to Eclipse to support a project called Paho. The goal of Paho was to provide open-sourced implementations of MQTT in a variety of programming languages for clients. It has since grown to include most new, old, and emerging applications, including the IoT.
To best understand MQTT, the publish/subscribe architecture, and the MQTT broker, we must have an understanding of MQTT topics. Consider this: you have a switch connected to a device, and you wish to use it to change the state of a light which is attached to a different device. Now, with a more traditional protocol, you would probably just connect them directly. But what if you wanted to add new devices with more lights? What if you wanted them to all be triggered from the exact same switch? You are going to need a lot more connections and triggers. In other words, things are about to get overcomplicated very quickly.
Whenever a message is published with a matching topic, the broker will relay that information to all subscribing devices. In this case, you will be able to control the state of a light on any number of subscribed devices. You can have any number of different topics with each one having different clients. This flexibility and scalability make it ideal for IoT communications.
MQTT’s publish/subscribe model offers many benefits that trump those of traditional poll-and-response protocols. The central server, known as the broker, is responsible for eliminating insecure client connections, scaling the number of device connections, managing client connection states, and reducing network strain.
But what is a broker exactly? It is simply software running on a computer, either on the manufacturing site or in cloud applications. You can think of the broker as being almost like a post office within the MQTT network. Say you want to send a birthday card to a friend. When your mailman picks up your card, he doesn’t deliver it directly to your friend. Instead, the letter gets taken to the post office and then delivered to your friend.
The same is true for messages within the MQTT network—they must first be sent to the broker before reaching their destination, the client device. The biggest difference here is that instead of sending that published message to a specific address, the message gets forwarded to all devices that are subscribed to that topic. Clients can share up to five brokers. In this model, there is not a direct connection between each client, but rather one outbound connection from the client to the broker. Because of this, every device is interconnected via the broker.
MQTT is not a text-string-based protocol. Rather, it is a binary-based protocol that uses bytes as control elements. MQTT also uses a format that includes both commands and acknowledgement of commands. Some basic commands include Connect, Subscribe, and Publish. The MQTT packet format consists of a two-byte fixed header, a variable header (not always), and a payload (not always).
The fixed header field consists of the control header and packet length fields. The control header is simply one byte long, while the packet length field ranges between one and four bytes. Within the control header is the eight-bit Control Field. The first four bits determine the command or message type field, and the last four bits act as control flags. The packet length field describes, well, the length of the message being sent. It also specifies how much of the message is useful information.
Variable Length Header and Payload
The variable length header can be thought of as preliminary information that allows you to understand the context of the information that you are looking for. Consider the following scenario: you need to learn the balance of your checking account and you don’t have an electronic means of doing so. You will likely have to call your bank’s customer service number and give them some of your information: your SSN, date of birth, address, etc. This allows the bank to locate your checking account and find the information you are looking for. In this example, the checking account balance is the payload. It’s the meat and potatoes of the message being sent.