Beyond OPC UA’s solid stance as the most widely recognized and used protocol standard to connect industrial devices of all flavors to the edge or cloud for Industrial Internet of Things (IIoT) applications, there are number of other protocols vying for wider use in the industrial space. These protocols include MQTT, AMQP and CoAP, among others.
While attending the Ignition Community Conference (ICC)—Inductive Automation’s annual user event—more than one person indicated to me that they believe MQTT is winning this race. Hearing such comments at ICC is not entirely surprising considering that Inductive Automation is closely partnered with Cirrus Link Solutions, the president of which, Arlen Nipper, is one of the co-inventors of the MQTT protocol.
Read more about Arlen Nipper and MQTT.
But I regularly hear a great deal of support for MQTT from a variety of automation technology companies—ranging from large hardware and software concerns, such as Schneider Electric, to suppliers specifically focused on data collection and transmission, such as Moxa.
Key aspects to MQTT’s rise in the IIoT space were highlighted in an ICC presentation delivered by Travis Cox, co-director of sales engineering at Inductive Automation. Those aspects include MQTT’s:
- Access control lists—control over who can access an MQTT topic and which operations are allowed are both defined in the MQTT server;
- Payload—the actual content of an MQTT message can be XML, JSON, text, images, etc., which makes it very suitable for diverse industrial applications;
- Stateful awareness—this is a critical factor in the industrial control space. MQTT issues birth and death certificates upon new client connections on the network and when connections are lost, respectively;
- Publishing process/bandwidth use—upon connection, MQTT initially publishes everything about the connected device to the MQTT broker. After that initial burst of data, MQTT only publishes information as data from that device changes. This is key to the low network bandwidth requirements of MQTT, in addition to its small seven-byte header.
Dealing with data
The Big Data access so key to any IIoT application means that industry must connect devices to infrastructure, not connect devices directly to apps, said Nipper in his presentation at the ICC. This move is often referred to as decoupling devices from applications. “IT made this move years ago with software oriented architectures; now industry is doing it with MQTT,” he said.
Read more about this concept of decoupling devices from applications.
Critical advantages provided by this decoupled approach include “efficient bandwidth utilization—you can send more data over the same bandwidth; enabling a single source of the truth for tags and associated projects—before Ignition with MQTT, half of project costs would be spent finding and renaming finding tags; providing plug-and-play functionality; and eliminating SCADA system cutovers,” said Nipper. “For 20 years Phillips 66 has been running old and new systems in parallel using MQTT, which allows them to morph over one system at a time as the new systems are verified to be performing properly.”
Explaining that the evolution of IIOT will not be a downward move from IT to OT, Nipper said the move will be more about “empowering OT with tools to execute an OT to IT migration. Ignition is one of those tools because it’s more than HMI/SCADA—it’s an MQTT to OPC UA bridge; it’s an OT to IT bridge that, in addition to HMI/SCADA, also includes MES and OEE as well as edge and cloud connectivity.”
Getting to the HART of the matter
Also speaking at ICC, and further highlighting the advances Inductive Automation and MQTT are making in the industrial space, was Kenny Heidel of Magnetrol, a supplier of industrial flow and level measurement and control technologies. Heidel noted that Magnetrol relies heavily on use of the HART protocol in its SmartLevel transmitters. The HART protocol enables Magnetrol transmitters to contain advanced diagnostic information as well as software to help the device troubleshoot itself. Despite all these capabilities, Heidel said that, in most applications, users typically only implement one variable for transmission via HART—the current output, “leaving all the rest of the information on the device.”
Given this reality, Magnetrol, as an OEM, wanted a way to trend all the data in its transmitters via an easily accessible infrastructure to help the company transform its reactive service model to a proactive one. Heidel said the goal for Magnetrol is to continuously monitor and improve measurements in real time for its customers 24 hours a day. To do this, Magnetrol realized it would need an edge-of-network device that could communicate with its devices and convert the resulting information into MQTT messages that could be published over any available network connection.
This led to the company’s development of its BlueTech gateway. The gateway uses Inductive Automation’s Ignition with MQTT to monitor process conditions continuously in real time and provide historical trends for up 350 tags per Magnetrol device. It also supports up to six dashboard screens per device to relay all of the data and analysis it provides.
The gateway is able to deliver all of this data by “converting transmitter information into MQTT Sparkplug tags that are immediately discoverable by the Cirrus Link MQTT Engine Modules for Ignition as native Ignition tags,” said Heidel.
Read more about how Sparkplug works.
As an OEM, BlueTech gives us the “big picture of what’s happening in the application,” said Heidel. He added that the cloud-based BlueTech gateway is secure because the data flow with MQTT is only outbound; plus, the technology uses a GRE encrypted tunnel to the cloud and firewalls for connections to mobile and desktop devices.
“Level output plays heavily into the efficiency of our customers’ processes,” said Heidel. To correct any output errors requires knowing when it's a problem with the transmitter or the setup. “Using Ignition and MQTT helps us identify and correct these issues. And the 24/7 data logging has allowed us to move from being reactive to proactive” as an OEM to help our customers.
Heidel highlighted several customers across various industries for which Magnetrol has begun using its BlueTech dashboard. Those companies include:
- A food ingredient manufacturer that had a problem with its bulk solid grain bin. This bin would alarm inadvertently causing personnel to lose faith in the accuracy of the level transmitter. “With the BlueTech gateway monitoring the bin, we were able to identify specific settings in the device that were causing the false errors. The manufacturer now receives virtually zero false alarms,” said Heidel.
- A steel company with a large quench pit outfitted with passive Magnetrol technology for level monitoring experienced problems due to the unavoidable collection of debris in the quench pit. Installing a “non-contact radar level transmitter with BlueTech allowed us to get continuous output from the device and make adjustments for the debris so that the transmitter could ignore it and deliver precise level measurements,” Heidel said.
- A chemical processing customer of Magnetrol’s uses tall, narrow vessels to contain a number of various chemicals. These chemicals have varying dielectrics which affect level transmitter performance. “With BlueTech, we’re able to determine the correct setup of the level transmitters in these vessels for each different batch, so that the processes can be more efficiently run with accurate level readings,” he said.
- One of Magnetrol’s power producing customers used a specific gravity-dependent level transmitter to control a high-pressure steam boiler. The company was experiencing accuracy issues with the transmitters, which led the customer to add too much water to the boiler. Heidel said BlueTech was used to confirm the accuracy of a new guided wave radar transmitter through all ranges of the boiler’s operation. This saved the customer a substantial amount of money that it had been spending to treat excess water for its boiler that it did not need to add.
Leaders relevant to this article: