KEB Technology, MQTT

MQTT – modern data transmission for Industry 4.0

Jonathan Bullick | January 2nd, 2021

About MQTT protocol

Message Queue Telemetry Transport, or MQTT, was developed by Andy Stanford-Clark of IBM and Arlen Nipper of Arcom in 1999. The protocol is meant to be used in situations where a small code footprint is required, and the network capabilities are limited – like in small devices or automation systems with widely distributed components. It’s lightweight and uses minimized data packets to efficiently send information between several receivers.

This type of protocol clearly isn’t a new development, but the explosion of Internet-connected devices and Software as a Service (SaaS) has made it extremely relevant and attractive to systems engineers and software developers.

There are many frameworks and open-source platforms that have implemented MQTT. The crux of the Internet of Things is that data is stored and managed in a secure location that the user can access on demand without needing to host it themselves. You couldn’t ask for a better application for MQTT protocol.

Smartphone apps, like Facebook Messenger, need to be small, fast, and efficient enough to avoid draining the user’s battery and data plan which is why they chose to use MQTT as a model for sending data between users.

In 2015, Amazon Web Services announced AWS IoT, a cloud platform based on MQTT. It’s easy to set up, and has nearly unlimited potential uses. With Amazon’s slick, familiar AWS interface and established presence in the tech world, AWS IoT is a great way for new developers to become familiar with cloud-based applications and the pub/sub method of data transmission.

How MQTT transmits your data

Model of pub/sub messaging protocol

MQTT is a publish/subscribe (pub/sub) messaging protocol that works on top of the TCP/IP protocol. A broker is used to connect clients that are subscribed topics to clients who publish messages to those topics. Many clients may be subscribed to the same topic, and each can use the published data differently, as the application requires. For example, the data could be added to a database, emailed, posted to social media, or saved as a text file. The pub/sub messaging architecture contrasts the more traditional request/response architecture. The request/response model requires all devices to be connected, which significantly increases data traffic.

Topics in MQTT are easy to establish and subscribe to. Nothing needs to be configured – simply publish the message and the topic is created. Topics are arranged in hierarchies similar to a filesystem and the protocol is able to recognize two wildcard values (+ for a single hierarchy, # for all remaining levels), so information can reach a range of topics with only one message.

Subscribers receive information from the broker

For Quality of Service (QoS) MQTT recognizes three levels: QoS 0, QoS 1, and QoS 2. For example, with Qos 0 the client fires off a message to the broker without acknowledgment that the message was received. With Qos 1 the client can send a message until the broker acknowledges the message has been reiceved. The strength of this mechanism is that MQTT can guarantee the delivery of a message and possibly resend the message in high latency networks. Higher levels of QoS are available with other protocols, but in the interest of keeping the transmission fast and latency low only these are used.

Another feature of the protocol allows the developer to create a message to attach to the client with instructions for what the broker should do in the case of an unexpected disconnect. The authors describe this feature as the “last will and testament” message. If no ping request or information is received within the set time limit indicating a loss of network activity, the LWT is executed.

The simplicity of the protocol’s operation is one if its greatest assets. Turnover of personnel is a reality in most industries, as are tight deadlines, scope creep, and constantly changing technology. By using MQTT in an application a developer is choosing a protocol that will be simple to install and maintain, and easy for new personnel to learn. In addition to the efficiency of straightforward data transmission, MQTT has several advantages in IIoT settings.

Diagnostic equipment used in waste water treatment facilities can communicate with monitoring devices and data loggers using IIoT.

MQTT for IIoT

The phrase “Internet of Things” was coined in 1999 – the same year Stanford-Clark and Nipper developed the MQTT protocol. But the idea of cloud-based services or operations was developed nearly two decades before that. If the Internet could send messages between two computers, it could surely be used to send messages between other types of machines.

Each new machine that gets added to the Internet of Things highlights engineering’s capability to build and embed CPUs in to the things we use every day. As the CPUs get smaller and faster, the lightweight properties of MQTT become a greater advantage. With limited overhead and minimized data packets, the CPUs resources can be used on other functions rather than devoting it to communication.

Flexibility in data types is another big advantage. This is the reason MQTT can be used in so many types of applications. Once the subscribed client receives the data message, it can do whatever the programmer wants with the data. The publish client also has flexibility in the type of data they will send – binary, JSON, XML, etc. – so the subscribed client doesn’t need to use resources to edit or convert the data before they can use it.

Another benefit is the availability of cloud-based platforms developers can use to build out their MQTT applications. IoT has a lot of appeal in its ability to keep data in off-site, third-party locations, potentially saving the integrators and end users the costs of building and maintaining their own server. Popular platforms like Amazon Web Services and Microsoft Azure can handle the message broker part of the equation as well as hosting and storing data from the application. Using familiar services from established tech companies means the integrator has access to a wealth of knowledge from the company itself, as well as many other users who share their tips and tricks online.

The Industrial IoT and secure communication

Security is an important consideration for IoT devices in an industrial setting. Though it may add overhead to the data transmission, keeping networks secure is worth the extra bulk for many system engineers. Even with its small code footprint and small packet size MQTT is capable of some authentication and security features that allow for data integrity and authentication. However it’s worth noting these features are not required for data transmission.

Whether security functions must be implemented or not is defined by the message broker. It’s up to the client to provide the functionality depending on the broker to which it will ultimately transmit data.

KEB’s Router – An Important Tool for Industrial Cloud Applications

KEB’s MQTT client implements the highest data security features as standard. The C6 Router can use TLS, SSL, authentication, and authorization security features when communicating with the broker. Authentication – usernames and passwords, identifiers, certificates – and authorization – publish and subscribe permission settings – are done on the application layer. TLS and SSL settings are done on the transmission layer. By default, data is sent over non-encrypted TCP, but TLS can be used if encryption is required.

There are many consumer and commercial uses for IoT, but its use in manufacturing is what’s powering the fourth industrial revolution, or Industry 4.0. At KEB we design and build products that will get clients into the modern industrial world with all of the right technology. Each component of the C6 automation line is ready to network with other KEB products or integrate into an existing system, and we’re constantly making improvements based on industry innovations and trends.