An Introduction to

MQTT

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.

    MQTT Architecture:

  • Allows a message to be published once and go to multiple stake-holding devices
  • Allows complete message decoupling between the producer of the data/events and the consumer of those messages/events
  • Allows data arranged by topic in a hierarchy with as many levels of subtopics as needed
  • Allows stakeholders to subscribe to a topic or subtopic
  • Allows users to use wildcards to specify topics of interest

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 has a lightweight code footprint, meaning devices require no more than a few lines of code to get up and running with MQTT and can be implemented in resource-constrained devices.
  • It’s speedy! MQTT operates in real time and with minimal delays.
  • MQTT has minimized data packets, it’s energy-efficient, making it perfect for devices that are battery-powered or have little CPU power.
  • It’s reasonably simple to use with its publisher/subscriber messaging.
  • MQTT is scalable and works well for small numbers of devices, as well as large networks of devices.
  • It solves the one-to-many problem that many other technologies struggle to implement.
  • MQTT easily traverses firewalls.
  • It provides separation between the producers of the data and the consumers of the data.

History

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.

MQTT Architecture

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.

    Under the Publish/Subscribe system, you can:

  • Publish the state of your switch under some topic—call it {Switch 01}.
  • Subscribe your machine, or any number of machines, to {Switch 01}.

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.

Like what you’re reading?

Subscribe to our Automation Education email series to learn the ins and outs of the top industrial protocols in a byte-size weekly format!

MQTT Broker

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.

Message Structure

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).

Fixed Header
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.