MQTT’s Role in the IIoT
The Industrial Internet of Things (IIoT) takes data from your factory floor and shares it with a server (local or a cloud service), offering greater efficiency for network use and enabling better access to and better sharing of data for your entire organization. This data can then be analyzed and used to boost profits, improve processes, reduce downtime, and much more. The MQTT protocol, an emerging IIoT protocol with established cloud compatibility and a lightweight, efficient nature for transporting large amounts of data, is one of many IIoT protocols used to convert factory floor data into an IIoT-friendly format.
MQTT stands for Message Queuing Telemetry Transport. It is an extremely simple and lightweight publish/subscribe messaging protocol, designed for constrained devices and low-bandwidth, high-latency, or unreliable networks. The design principles are to minimize network bandwidth and device resource requirements while also attempting to ensure reliability and some degree of assurance of delivery. These principles make the protocol ideal for the emerging “machine-to-machine” (M2M) or “Industrial Internet of Things” (IIoT) world of connected devices and for remote applications where network connectivity and bandwidth are at a premium. It was first developed by IBM in 1999 and is now an open standard that has become widely implemented across a variety of industries.
MQTT breaks this down into three distinct participants of an MQTT network, though some hardware can be dual-purpose, serving more than one function.
- Publisher – Sensors, PLCs—anything creating data. Sometimes called a "Server" or "Edge Device".
- Broker – The middleman device that manages incoming and outgoing data, which can live on a local device or a managed cloud service. The broker can also be referred to as a "Server".
- Subscriber – The end user of the data. This can range from a high-end ERP management program that tracks information for control and data analytics, to a website that simply displays real-time operational facility data, and anything in between. Also called a "Client".
In systems of the past, only the clients and servers were present. The new team player is the broker, and it is this function that separates MQTT from traditional SCADA systems. The broker allows a great number of users to:
- Publish data to the broker
- Subscribe to data in the broker
The publisher/subscriber model allows MQTT clients to communicate one-to-one, one-to-many and many-to-one. Maple Systems HMIs are the perfect device for the edge of network gateway in any of the three roles. Our Advanced and cMT products support all three functions of the MQTT protocol, enabling them to communicate with a wide array of PLCs, sensors, and more, regardless of the machine's protocol. With support for over 300+ PLC and controller protocols, Maple HMIs convert that data into the universally accepted MQTT protocol, then send it to a broker (hosted locally or in the cloud) for use by IIoT applications. This makes Maple Systems HMIs the perfect edge gateway to the IIoT.
To fully realize benefits of the IIoT, data transmitted by the HMI or “edge gateway” must be presented to upstream IT applications in a way that is flexible, modular, and efficient. The MQTT feature available on all Maple Systems Advanced and cMT products exemplifies the power of this protocol. MQTT is organized into topics which can contain single data points or a group of related data. Topic names are assigned to the variables or tags they wish to publish to the broker. Topics are the titles, or addresses, used to organize data in MQTT protocol. The HMI can be configured to transmit data from a specific topic whenever a change occurs, or on a periodic basis, lowering the bandwidth required for connection.
MQTT allows topics to be broken down in intuitive ways. A single data point can be assigned to multiple topics and one topic can contain more than one data point. An application can subscribe to all topics on a single HMI, creating an application monitoring one specific machine. Or, if a parameter, say temperature, exists on many machines, the programmer can use a topic "wild card" enabling them to instantly subscribe to the same parameter across all machines. This enables efficient and easy detection of abnormal conditions across an entire installed base of machines.
A fundamental advantage of MQTT is that data is sent to a central "broker" instead of being directly transmitted to multiple clients such as remote interfaces or management software. The MQTT broker is responsible for maintaining client connections and sending/receiving messages. Client devices, edge gateways, and IT applications (or publishers/subscribers in MQTT language), are freed up to focus on producing and consuming data. This division of labor greatly enhances scalability. As overall system sizes grow, the CPU resources and bandwidth requirements of the edge gateway remain static. In addition, MQTT is a lightweight protocol. A popular broker implementation consumes only around 3MB of RAM with 1000 connected clients1
. This small footprint means the HMI can be configured as both an edge gateway and an MQTT broker, reducing the need for additional hardware.
For the controls engineer looking to incorporate an edge gateway into their system, the HMI configuration process could not be easier: simply create an authenticated broker connection, then select the tags you wish to publish. Point and click to organize tags into topics for your specific application, download the project to the HMI, and you're up and running.
Cloud Data Center Support
An MQTT broker (or server) is responsible for all message exchanges, and no MQTT architecture is operational without one. However, all the tasks involved in deploying a centralized MQTT server can make it seem like daunting job: shortlisting a suitable MQTT server, deciding on server location, installation, testing, tuning, maintenance, traffic control, and addressing security concerns. But MQTT is compatible with many of the major cloud services on the market. Fetching PLC data and pushing it to loT hubs like Amazon Web Service (AWS) and Microsoft Azure is simple. Using cloud services to deploy a secure MQTT server not only requires little manual set up, but can also be more cost-effective than setting up from scratch. In addition, taking advantage of the analytic features from cloud providers such as advanced data analysis, cloud computing, and database storage tools can offer further insight into your data.
Supported MQTT Features
Our easy to use configuration software provides users maximum flexibility when it comes to MQTT configuration. Among the adjustable options are QoS, retain messages, customized username/password length, TLS/SSL support, support for V3.1.1, support for JSON and RAW data payloads, support for multi-layered topics and wildcards...etc., all of which are in place to ensure compatibility with most MQTT brokers/servers.
Additional cMT Features
We are also one of the first to roll out support for the AWS loT Device Shadow service. This innovative service, which creates a virtual representation of the actual device in the cloud, can be considered an example of a Cyber-Physical System of Industry 4.0. In practice, the virtual device in the cloud closely tracks the states of the actual device and reports its status to the HMI. The HMI is able to set the desired states of the virtual device even if the actual device is disconnected from the network, which effectively achieves remote control of the actual device, as the virtual devices' states are synchronized to the actual device as a default rule on reconnection. In this manner, AWS loT Device Shadow service overcomes the problem with MQTT alone: the difficulty of implementing remote control.
Additionally, cMT products support the Sparkplug B MQTT payload specification. Sparkplug is a specification for MQTT enabled devices and applications to send and receive messages in a stateful way and is supported by Inductive Automation Ignition Platform utilizing the Cirrus Link MQTT modules. Sparkplug provides a mechanism for ensuring that remote device or application data is current and valid by using device lifecycle messages such as the required birth and last will & testament messages that must be sent to ensure the device lifecycle state and data integrity. The Sparkplug specification provides the necessary details for any MQTT enabled device to connect to MQTT servers and integrate with zero configuration into Ignition via the Cirrus Link MQTT Engine Module or other Sparkplug supported applications.
Send your data to the cloud today with MQTT!