Will Messaging Eliminate Proprietary Protocols?

Amid all the change that’s taken place in the industrial automation sector over the past two decades, one constant has been the protocols required to connect systems and devices. Despite the many changes adopted by the protocol organizations to support easier device communications and interoperability, end users are increasingly demanding even simpler ways of connecting the variety of devices and systems operating in their facilities—particularly as interest in the Industrial Internet of Things (IIoT) heats up.

Driving this push for increased openness and interconnectivity has been the explosion of personal computing—whether in its desktop, laptop or mobile iterations. People have seen that, to connect to the Internet, they don’t need a particular brand of computer or smartphone. All they need is HTTP. And the same effect HTTP had on creating the Internet of People appears to be coming to the IIoT via MQTT.

A basic explanation of MQTT (message queuing telemetry transport) is that it’s a bi-directional lightweight event- and message-oriented transport allowing devices to communicate efficiently across constrained networks to backend systems. To help understand MQTT and its industrial applications better, I spoke with Arlen Nipper, president and chief technology officer at Cirrus Link, a provider of machine-to-machine communication technology. Nipper also happens to be one of the co-developers of MQTT.

“Most IIoT connection methods today use poll-response protocols,” says Nipper. “Meaning that you have to connect the application to the device.”

While this has been fine for most plant floor uses, problems arise as other sectors of the business request access to the information in plant floor devices for visualization applications or IIoT initiatives.

“Your flow computer has more than just the 4-20 mA flow rate data that the plant floor is using,” explains Nipper. “It also has end-of-batch tickets, audit trails, orifice plate calibration coefficients, etc. But since operations is already polling that device with its application for the flow rate data, when you look to add other polls it’ll not only be difficult to do, it’ll also upset the plant floor polling cycle.”

MQTT helps avoid this issue by having the plant floor device transmit all its data to an MQTT server on a constant, real-time basis. Then you connect your applications—as many as you want—to the MQTT server to access whatever data you need from the device without connecting directly to the device itself, thereby avoiding any effect on its operation.

MQTT’s origins and future trajectory
Though MQTT is not yet a common industry term, it’s nothing new. “I co-invented MQTT while working on a pipeline project for Phillips 66 in 1999,” Nipper says. He points out that Phillips 66 has been running 20,000 miles of high-pressure liquid pipelines for 18 years using MQTT with 99.999 percent availability. “MQTT was developed for use with real-time SCADA systems, and it’s the only thing still remaining from that original 1999 project with Phillips 66. The pipeline operations have since undergone numerous device and instrument updates, as well as installing new ERP systems—but the same MQTT infrastructure has been in use all this time.”

Further boosting MQTT is the fact that it’s been adopted by Facebook for its Messenger app and Amazon with its Echo product.

Solidifying the case for MQTT in industry is the fact that it has state—which is something HTTP and CoAP do not have. “This ensures a high level of confidence that MQTT works in a control system environment,” says Nipper. “Stateful alternatives to MQTT like DDS and AMQP are too complex and have too much overhead to leverage VSAT and cellular communications paths.”

Cirrus Link announced a partnership earlier this year with Inductive Automation to bring Cirrus Link MQTT modules to Inductive Automation’s Ignition platform. According to Inductive Automation, this allows users to set up their own IIoT system on a secure MQTT message-oriented middleware (MOM) infrastructure. A MOM is essentially an MQTT server.

Don Pearson, Inductive Automation’s chief strategy officer, says he’s seen a big shift in interest in Ignition over the past year since the release of its Ignition Distributor and Transmission MQTT modules. “This shift reflects a heightened interest in businesses wanting to make IIoT a reality. We’re seeing companies looking to expand their edge of the network capabilities to facilitate this and that’s put the Ignition platform with MQTT squarely in the focus of more companies and automation suppliers.”

Both Pearson and Nipper hint that several new automation technology partnerships will soon be announced around the use of Ignition and its Cirrus Link MQTT modules.

“We expect MQTT to become the de facto standard for IIoT communications,” adds Pearson.

Back to the premise of whether messaging will replace protocols in industrial networking, the clear answer is “no,” at least in the near term. And it will likely be “no” in the long term as MQTT is not positioned to replace industrial networking communications wholesale. The current focus for MQTT is on application-to-device connections as a means of decoupling devices from apps via MOM. While this is critical for IIoT, it also makes a lot of sense for easing industrial network traffic issues on an everyday basis.