MQTT eases development of software for Industrial Internet of Things

Serving as a universal message transport for Industrial Internet of Things (IIoT) application development, MQTT can be used to decouple devices from applications, thereby freeing infrastructures from any single operating system, application, or hardware platform, according to explanations offered at Inductive Automation’s Ignition Community Conference 2016.

By Mark T. Hoske October 12, 2016

MQTT, a standard message transport mechanism, is helping to accelerate Industrial Internet of Things (IIoT) software deployment, according to Arlen Nipper, co-inventor of MQTT (with IBM) and others commenting at Inductive Automation’s  Ignition Community Conference (ICC) 2016 in Folsom, Calif. Nipper, president and chief technology officer of Cirrus Link Solutions, last year demonstrated how Message Queueing Telemetry Transport (MQTT) could be used to connect to 300 PLCs over a mobile phone hotspot. This year MQTT is integrated into Ignition 7.9 to ease integration with available edge-of-network and native MQTT devices. Since presenting a TED Talk about using MQTT as an IIoT enabler, Nipper said the talk has been viewed almost 50,000 times. But using it still makes sense even if the IIoT application never touches the Internet. 

Enabling IIoT in two ways

MQTT enables IIoT in two steps:

1. Decoupling: MQTT allows devices to be connected to the infrastructure as needed, not to specific applications.

2. Superior operations technology (OT): MQTT allows proponents of IIoT software upgrades to demonstrate an OT solution superior to the legacy approach.

Complexity impedes innovation, Nipper said; and protocols are difficult if not impossible to change or extend. Development tools and debug tools are expensive, and choices are limited. Technologies are now in silos, and access is limited to a few individuals. 

Real-time provisions

The Sparkplug MQTT specification defines how to use MQTT in a mission-critical, real-time environment, defining the topic namespace, payload definition, state management with high availability, redundancy, and scalability, Nipper said. Reference implementations are available in C, Java, JavaScript, Python, and Node Red. While HTTP is used more widely as a messaging transport, he said, HTTP cannot control valves, for instance, because it has no state.

Nipper said MQTT use has expanded rapidly in a year since the MQTT Engine was introduced a year ago, with the Sparkplug specification, device ecosystem, MQTT servers, tools and applications, topologies, migration strategies, and enabling IIoT software and devices. MQTT servers are available from Cirrus Link, Mosquitto, Microsoft, AWS, IBM, Red Hat, HiveMQ, and numerous other message-oriented middleware providers. Clients include Ignition from Inductive Automation, Sparkplug, Java, JavaScript, Python, MQTT.fx, and Node Red (visual tool for wiring IoT). Device ecosystems using MQTT, as shown at the ICC, include B+B SmartWorx (Advantech), Elecsys, Hilscher, Magnetrol, Moxa, Opto 22, and Tyrion Integration.

Among the messaging standards in use, according to the Eclipse Foundation IoT Developer survey, as cited by Nipper, MQTT is near the top with 61% HTTP, 52% MQTT, 21% CoAP, and 19% HTTP/2, among others. The MQTT server and client architecture enables users to connect, subscribe, and publish, facilitating easy real-time implementation over gateways and native devices.

Because of the way the architecture works, Nipper said, there’s very little fear of any upgrade because there’s no moment of cutover terror. Its ability to work already has been demonstrated. "Philips 66 hasn’t had a cutover in 16 years."

More products using MQTT

In addition, MQTT is enabling out-of-the-box replacements for conventional technologies, Nipper said. With an MQTT Server, Distributor, Engine, and Transmission, just drop in a Smartworx gateway from B+B SmartWorx and add a few wireless sensors, and tags just start showing up.

Magnetrol has a HART gateway call Bluebox, enabling often unused additional process variables and diagnostic capabilities in HART-based systems.

Elecsys moves systems from bandwidth inefficient poll-response communications to a more efficient publish-subscribe architecture.

Hilscher has a NodeRed module offering connectivity to EtherNet/IP, Modbus, and Profinet Ethernet communications.

Opto 22, with a wide range of isolated I/O, exports tag names from Opto 22 into Ignition software. Moxa gateways and modems use the MQTT Sparkplug specification natively.

The Tyrion Nucleus device builds discrete I/O in a briefcase-sized demo package.

Nipper showed a topology diagram illustrating why device-to-protocol communication is never optimal. Tomorrow there always will be something new requiring revisions, meaning end-users and their partners cannot keep innovating with traditional architectures. By decoupling devices from applications, vendors connect using networking and security built into MQTT servers, and all connected communications are managed in one spot.

"We must show superior operational technologies, or we will never get to an IIoT-enabled infrastructure," Nipper said. By providing superior OT solutions, he said, like Ignition software, software can be developed, tested, and upgraded offline, a strategy that makes sense when pushing IIoT technologies into the enterprise.

Applications include leak detection, measurement, asset management, historians, manufacturing execution software (MES), enterprise resource planning (ERP) software, product lifecycle management (PLM) software, and analytical software engines for Big Data analytics, including Storm, Spark, Hadoop, and IBM Watson IoT. Ignition isn’t the only data consumer, he noted.

In a stage demo, Nipper showed how a HART device using MQTT pulled in tags automatically. RevB of the Sparkplug specification will be for smart edge device for data transport protocols (DTPs). 

MQTT questions, answers

In the question and answer session after his presentation, Nipper said the advantage of MQTT use for system integrators or others implementing related tools is that effort that would have been spent on connectivity can now be spent on adding value to the application.

He also noted that a lot of supervisory control and data acquisition (SCADA) applications "cannot use OPC UA because of the bandwidth required. OPC UA connects a device to an application, which is not what we need."

MQTT publish/subscribe

As also explained at ICC, Ignition 7.9 software uses MQTT so that users can decouple applications from devices and enterprise resource planning (ERP), analytics, Big Data, and SCADA, and MES software functionality can connect with programmable logic controllers and other intelligent devices.

Steve Hechtman, founder and CEO of Inductive Automation, said MQTT is an enabling technology within the Ignition software; the MQTT Broker allows apps and devices to publish and subscribe through the cloud as needed. The MQTT functionality is one of the technologies, Hechtman said, that puts Ignition 10 years ahead of other automation software platforms. "We don’t care about the IIoT hype; we just want to get the job done," Hechtman added.

In practical terms, that means faster response time in a digital oil field application, explained Don Pearson, chief strategy officer for Inductive Automation. An 8,000 km pipeline in Canada is doing an Ignition project using MQTT, Pearson said. Previously, if a valve opened, 15 minutes later, pipeline operators found out if it was open. Now they find out in 15 seconds, he said.

Mark T. Hoske, content manager, Control Engineering, CFE Media,


Key concepts

  • MQTT uncouples devices and applications.
  • Many devices and types of software now integrate MQTT technologies.
  • Simpler integration enables more value-add and more frequent upgrades without fear of cutover.

Consider this

Are infrequent upgrades for fear of breaking something limiting your ability to innovate and stay nimble?

ONLINE extra

View the IIoT, Industrie 4.0 page

See other coverage on MQTT linked below.

Original content can be found at Oil and Gas Engineering.

Author Bio: Mark Hoske has been Control Engineering editor/content manager since 1994 and in a leadership role since 1999, covering all major areas: control systems, networking and information systems, control equipment and energy, and system integration, everything that comprises or facilitates the control loop. He has been writing about technology since 1987, writing professionally since 1982, and has a Bachelor of Science in Journalism degree from UW-Madison.