Communication: Choosing the Right Tool for the Job

As automation technologies increasingly use networking protocols and programming languages from IT, the industrial communication palette is expanding. Suppliers are looking for the best way to leverage the communication protocols for their manufacturing customers. Though no best method has yet shaken out, most suppliers agree that this is as it should be at this point.

There are many protocols connecting industrial devices to IT and Industrial Internet of Things (IIoT) platforms, but the biggest two jockeying for position are MQTT and OPC UA. Even as they acknowledge that MQTT seems to be the preferred method for moving IIoT information to IT systems, many vendors say the decision between MQTT and OPC UA is not “either/or,” but “both.”

MQTT (message queuing telemetry transport) is a bidirectional, lightweight event- and message-oriented protocol enabling devices to communicate efficiently across constrained networks to back-end systems, says Benson Hougland, vice president of product strategy at Opto 22.

OPC UA is more commonly used for machine-to-machine communications between multiple controllers from different vendors at the control level. It also provides a mechanism to move data between enterprise-type systems and the kinds of controls, monitoring devices and sensors that interact with real-world data, Hougland adds.

The protocol can also be used for supervisory control, eliminating the use of Windows-based intermediate systems to streamline the data transfer process from the field and control levels to the management and enterprise levels, according to the National Institute of Standards and Technology (NIST).

The Edge, IIoT and MQTT
MQTT’s popularity has grown to the point that it’s winning out in the IIoT world as the de facto standard for device-to-cloud communication, says John Crupi, vice president of engineering system architecture at Greenwave Systems. For IIoT applications, where data is being transported among different types of devices with different operating systems and constrained hardware footprints through varying network architectures, the MQTT protocol is a good fit, Hougland says.

In fact, most suppliers are now on board with MQTT for IIoT applications, says Aravind Yarlagadda, product line executive at Schneider Electric. The protocol features a publish/subscribe messaging pattern, quick communication between applications and low overhead—all of which make it appealing. It’s also versatile. The protocol can be used with everything from a simple 8-bit Arduino or Raspberry Pi to a multicore PC or Amazon Web Services, he adds.

Also, adding MQTT to a newly designed device is generally easier than embedding OPC UA into a device, Yarlagadda says. The MQTT protocol is more lightweight than traditional OPC or OPC UA, and is therefore able to move supervisory control and data acquisition (SCADA) information much faster across a system while using less bandwidth than those traditional protocols. This is important in IIoT applications, where devices could be deployed in remote locations with network constraints such as low bandwidth, high latency, data limits or generally fragile connections, Hougland says.

One of the greatest benefits MQTT offers for IIoT applications is that it’s an open protocol and OASIS standard. This means system developers can adopt MQTT as a communication protocol in their designs no matter what operating system (OS) their systems are built around, Hougland says.

Axon Predict uses MQTT to move information from edge devices to the cloud. Source: Greenwave Systems​

Greenwave Systems’ edge analytics software Axon Predict, released earlier this year, performs analytics at the level of smart devices that sit at the edge rather than pushing data to the cloud for processing. It uses the MQTT protocol to move information from the edge to the cloud, Crupi says.

“MQTT has a nice mechanism to define data and topics. That’s what Amazon is using for its cloud and what IBM is using for Watson,” Crupi adds. “So that’s our choice and that’s the choice happening in the industry.”

OPC UA
OPC UA, which has an established foothold on the plant floor, continues to make inroads within IIoT platforms, says Travis Cox, co-director of sales engineering at Inductive Automation.

The OPC Foundation is also actively working toward increased adoption of OPC UA. In spring of 2016, the OPC Foundation announced support for its own publish/subscribe communication functionality—a key performance aspect of MQTT. This functionality will complement OPC UA’s client/server architecture and will be critical to supporting the integration of cloud-side IT protocols. Also, the foundation made the OPC UA standard open source to make it more accessible and help increase adoption.

In 2016, Microsoft worked with the OPC Foundation to expand its product support of the OPC UA open-source software stack, which enables integration with Microsoft Azure IIoT and the Universal Windows Platform. This cooperation between the two organizations includes enablement of remote command and control, as well as data analytics capabilities in the cloud.

With automation suppliers like Siemens and Beckhoff continuing to push the envelope with applications that communicate via OPC UA, the protocol remains healthy, Cox says. “PLCs will still be a big use for OPC UA, as will sensors, while MQTT will be used to deliver data to the cloud,” he says. “Those two major standards should be able to work together.”

Those in industry will continue to use gateways, middleware and RESTful APIs (application programming interfaces that define functions to be performed using HTTP) to bridge the communication gap between the physical electrical signals industrial assets use and the digital systems of the Internet.

The Ignition platform with an integrated OPC UA server offers connection across hundreds of protocols. Its API facilitates interaction and data sharing between applications as well as the development of drivers for protocols such as MQTT. Ignition Edge MQTT turns any device, touch panel, rack-mount server or client terminal into an edge gateway, with a limit of up to 500 tags, Cox says.

Inductive Automation and Cirrus Link, a provider of machine-to-machine communication technology, formed a partnership to bring Cirrus Link MQTT modules to Inductive Automation’s Ignition platform. 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.

There’s been a big shift in interest in Ignition over the past year since the release of its Ignition Distributor and Transmission MQTT modules, according to Don Pearson, Inductive Automation’s chief strategy officer. “This shift reflects a heightened interest in businesses wanting to make IIoT a reality,” he says. “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.”

Many automation experts use OPC UA when they need to get data from programmable logic controllers (PLCs) and sensors into existing SCADA systems and manufacturing enterprise systems (MESs). They’re also keeping their eyes out for OPC UA adoption by IIoT platform providers and the open source community, Cox says.

Siemens’ MindSphere, for example, can receive information via Siemens’ Simocode pro motor control system using OPC UA, which offers a communication interface via the industrial Ethernet for automation and monitoring systems. Acting as OPC UA clients, such systems can access operating, service and diagnostics data on Siemens’ Simocode pro for Profinet and transfer control commands via the integrated OPC UA server.

Beckhoff has introduced products like its SOA PLC, which combines logic functions with OPC UA services for standard communication.

Schneider Electric’s Yarlagadda expects to see more vendors—including his own company—adopt OPC UA for edge control applications.

The case for using both
Opto 22 uses MQTT for applications that demand higher performance and lower overhead for data transmission, Hougland says. “Where performance isn’t as important and the sizing and chunking of data is larger, we’ll use OPC UA,” he adds.

But Hougland agrees the OPC UA protocol isn’t going anywhere soon. “There’s too much legacy infrastructure out there that uses OPC, and I don’t think people are going to tear out expensive equipment just to use a new protocol,” he says.

To that end, Opto 22 last year released a RESTful API and server for its industrial programmable automation controllers (PACs) to transfer data from real-world manufacturing assets directly into IT systems like onsite databases and the cloud without having to use protocol converters, OPC servers or gateways. Adding a RESTful server and API to PACs enables secure access to legacy physical assets, while minimizing the integration time and cost associated with IIoT application development by eliminating the need for protocol converters, gateways and middleware.

There is no need for there to be an impasse or divide between OPC UA and MQTT, reaffirms Stephen Briant, technology manager at Rockwell Automation. Customers don’t necessarily see the behind-the-scenes methods that ensure protocols communicate and work across platforms as that information moves up from sensor to analytics tool, he notes. “We use the best tool for the job.”

Rockwell must ensure that the information and context is preserved and incrementally added from the sensor to the machine, on up to the MES, Briant says. “We see a series of communication protocols that need to each be ideal for its own purpose to get information from sensors up to the cloud,” he says. “Some of those we get a say in using, some of them we don’t. We have to work with them all. Some are likely to be a communication protocol optimized for the plant, like OPC UA, and then as we talk to the cloud, the cloud providers are typically using MQTT.”

Automation suppliers will likely continue to choose the best protocol for each particular application, meaning that both protocols will continue to coexist—each with its own strengths and weaknesses. The automation experts will need to best understand which protocol to call upon for the job at hand.