MQTT Keeps IoT System Design Simple

At a Glance:

As communication systems have improved and expanded in the age of IoT, the need for data security has increased.
The MQTT protocol can provide efficient and secure integrating industrial automation with the cloud using IIoT principles.
MQTT protocols also can help end-users achieve a more consumer look and feel to applications while maintaining the robustness needed in industrial settings.

Internet of Things (IoT) devices and apps are providing consumers with improved access to and control of their digital life. Common examples include residential smart systems like thermostats, appliances and garage door openers—each of which can be viewed and operated via a mobile device.

Naturally, those operating commercial facilities and industrial manufacturing sites would like to experience some of the same IoT benefits as personal consumers. There is a lot of useful data at these locations and these site operators could benefit from remote visibility into equipment status and alarms. Industry users are already familiar with traditional automation products which could offer some level of connectivity, but these products could be costly and difficult to design, implement and maintain.

In recent years, a collection of hardware, software and methods termed as the Industrial IoT (IIoT) has improved upon this situation. Industrial end-users will find it is now simpler and less expensive to establish remote connectivity using the IIoT by taking advantage of basic and workable solutions to make valuable information widely available.

The Key to Communications

Traditional industrial automation platforms have included specialized and robust programmable logic controllers (PLCs) and human-machine interfaces (HMIs) connected using various networking and fieldbus communication methods. Larger combinations of PLCs and HMIs may be called supervisory control and data acquisition (SCADA) systems. These elements were designed to deliver around-the-clock reliability and on-site visibility, but easy and secure integration and communication were much less of a consideration.

The situation has improved, first as industrial wired Ethernet media and protocols became practical for industrial use, and next as Wi-Fi gained sufficient performance to work well for industrial applications.

Today, many industrial protocols have matured or been developed over the past few years to work well for on-site automation system communications such as EtherNet/IP, Modbus TCP and OPC UA. However, these have been less well suited to deliver a good IIoT experience for IT, cloud and mobile networking systems.

Don Pham, senior product marketing manager, at IDEC Corporation.

MQTT-Enabled IIoT Architectures

Conventional automation products and protocols typically require a rigorous configuration and hierarchy to move data from a field sensor, to a field controller, to a site network, to a PC data server and then to the cloud. The resulting multi-layered architecture means these types of implementations can be complicated and expensive to create and manage.

To economically make industrial data available for all types of remote and mobile end-user access, a newer protocol and methodology was needed to meet the goals listed below, some of which may appear to be at odds with traditional computer networking requirements:

Suitable for small data payload sizes
Messaging model adapted for communications only on change
Data managed by simple “topics”
Means of handling connection status
Flexibility for adding connections
Security provisions

The protocol which has risen to prominence for addressing these issues is MQTT, which provides many features to meet the needs of IIoT users by compressing the architecture into just three roles (Fig. 1):

Publisher (device that creates data)
Broker (Server)
Subscriber (device that uses data)

Industrial-Friendly MQTT Features

Industrial automation devices which include MQTT capability are the latest answer for efficiently, economically and securely integrating commercial and industrial automation with the cloud using IIoT principles. These may be field devices which simply publish data, or more complex devices like PLCs which need to publish and subscribe to data.

While the network traffic associated with typical business computing is relatively large, this differs for industrial data packets which are most often small, and may change frequently or be very intermittent. MQTT is suitable for these types of small data payloads and consumes little communication message overhead; it is optimized to communicate (and use bandwidth) only as needed.

Most traditional industrial protocols follow a “poll and response” structure, where users must carefully arrange the source and destination, and also assign a polling rate which executes whether data is changing or not.

MQTT has improved the situation with a “publish and subscribe” or “pub/sub” model. For pub/sub, data producers publish data to a broker as the data becomes available. Subscribers notify the broker of what data they want, and the broker sends updated data to existing subscribers when it changes, or the latest available data to new subscribers.

Instead of predefining large data communications blocks, users instead configure “topics” to manage data “payloads.” A topic is constructed as a layered structure, which helps users organize the data in a logical and easy-to-understand manner (Fig. 2).

2. Users define easy-to-understand topics within MQTT as layered structures to manage and organize data payloads; a sample topic could be “site/area_1/temperature.”

Because IIoT devices connected using MQTT may be installed using less reliable network connections found in remote locations, an important feature of the protocol is how subscribers are notified if source data becomes unavailable. This “last will and testament” feature enables a subscriber to detect a disconnected publisher, so users can configure the system to act accordingly.

New subscribers can be added at any time, and each will immediately connect and receive the latest data and topic status. Both subscribers and publishers can dynamically be added or removed at will.

Another important aspect of industrial communications is security. Traditional industrial protocol implementations like Modbus TCP and EtherNet/IP simply allowed devices to connect and access each other using IP addresses. Once upon a time this was satisfactory, especially when such systems were air-gapped from the rest of the world.

For today’s highly-networked IIoT systems, MQTT is the protocol of choice. It relies on proven IT-based security measures. All communications are initiated by publishers in an outbound manner, which is allowed by most IT firewalls (and allows the firewall to protected against inbound threats). Centralized MQTT brokers ensure that only properly authenticated publishers can connect.

Putting MQTT Into Practice

All these features are becoming available in certain automation products. Some users will have targeted applications and may be reluctant to commit to complex automation platforms which offer MQTT. In some cases, MQTT-capable micro PLCs are becoming available so users can economically apply them and begin realizing value (Fig. 3).

3. Some micro PLCs, like the IDEC FC6A shown here, now incorporate the MQTT protocol so users can economically take advantage of IIoT connectivity.

After selecting MQTT-capable devices and PLCs, there is still some legwork to be done by users to establish the broker. The broker can be created using an on-site computer, or more typically established in the cloud via an internet connection. For simplicity and best overall connectivity, many users with internet connectivity will prefer cloud-based solutions. There are three approaches:

Full scratch
Subscribe to an IoT SCADA/dashboard service
Buy IoT SCADA/dashboard software

Technical users will find the full scratch option is the most work, but gives proficient end-users the most control and could yield long-term savings. For this method, a user would typically create their own cloud service based on a commercial cloud platform like Amazon Web Services (AWS), Google Cloud Platform (GCP) or Microsoft Azure. That means they need to develop:

An IoT device management function for authenticating, identifying and communicating with IoT devices via MQTT
A Rule Engine for controlling data to/from the IoT management function and the database
A database for storing all IoT data

The easiest approach for many users would be to subscribe to a SCADA/dashboard cloud service which already includes the above listed functions and is hosted on the virtual servers of a cloud platform. Once the broker is established, MQTT devices can immediately publish and subscribe to the broker, and users can configure associated applications for viewing and reporting the data (Fig. 4).

4. Most users will find it easiest to use a SCADA/Dashboard cloud service for connecting MQTT-capable field device data and PLCs for remote monitoring and reporting.

A third option in the middle of the previous two is for users to buy the IoT SCADA/dashboard software and to instantiate it on a local or cloud-based server. The resulting functionality can be much like the cloud service, but this option gives the user more control and perhaps some cost savings.

IIoT Using MQTT Keeps it Simple

Typical consumers are familiar with mobile apps which let them interact with many types of devices and systems. Commercial and industrial end-users are looking for similar advantages. As these users begin incorporating IIoT methods to securely gain remote access to their assets, they will find MQTT-capable devices and micro PLCs are available to help them. Modern IIoT products and features are much simpler, easier to implement and less expensive than traditional SCADA methods.

Don Pham is the senior product marketing manager at IDEC Corporation and has more than 15 years of detailed experience with industrial automation products, including PLCs, HMI touchscreens, machine safety and sensors.