It’s very telling about the state of the automation industry when we can call OPC-UA legacy technology. While other technology like Ignition’s Perspective module finally brings us into the current decade, industrial automation technology is fighting really hard to to get to where the rest of the world was ten years ago. Yes, there is inherent risk tolerance and it doesn’t make sense to migrate to every new technology under the sun, still the automation industry moves at a slower pace.

With the Industry 4.0 marketing engine in place, MQTT has been at the forefront of everyone’s mind for a few years and is beginning to gain traction. While not every use case can benefit from MQTT, there are many places it can be used in place of OPC-UA, or other protocols.

How do OPC-UA and MQTT Differ?

OPC-UA is built on a client/server architecture while MQTT is built on a publish/subscribe architecture. With OPC-UA, you will have OPC-UA clients on your network that talk to OPC-UA Servers—also on the network. OPC-UA requires a persistent connection and will use bandwidth as the clients poll the server to see what the data has changed and needs to be brought across to the clients. With MQTT, the data is “pushed” out to MQTT Brokers that can subscribe to particular MQTT topics to limit what data they ingest—or they can subscribe to all topics and get all of the data from an MQTT source.

The Problem is “Paying For What Goes Through the Pipe”

MQTT is designed to do exception-based reporting, with a publish/subscription model—meaning you get data from the source when it changes. OPC-UA is also exception-based, but utilizes polling. The OPC-UA clients poll the servers for data, and the servers will make data available when it changes. Generating data from the source vs. a client/server polling architecture gives you huge performance and costs gains by reducing your overall bandwidth. This is very handy on systems utilizing cellular modems with costly data plans, as well as bandwidth costs for cloud-based hosting providers like AWS or Azure.

The hurdle to using MQTT in the manufacturing world is that most hardware in manufacturing plants is 5-10+ years old and doesn’t support MQTT out of the box. The more recent Sparkplug B specification makes leveraging MQTT for industrial data even easier, but the hardware in your plant is probably even further behind the curve for using it.

To overcome these hurdles, you need a tool to get your legacy equipment integrated with the power of Industry 4.0 technology—without having to replace your controls system.

Such a tool would need to check all of the following boxes:

• Connects to devices using any protocol

• Converts realtime data from a polled or client/server protocol to report by exception for MQTT, utilizing a deadband setting to further limit the data if it is only changing in tiny amounts

• Packages the data into Sparkplug B payloads

• Collects and stores data in a local database enabling store and forward capability

• Accepts writes from SCADA systems to send data back to the devices where the data originated

• Runs on any computer on your network

• Generates tag lists from the devices without requiring hours of configuration

• Connects to any MQTT broker

• Handles every birth, rebirth, death, etc. messages for the MQTT protocol

• Works on full-fledged internet connections, cellular modems, even local intranets

The Solution: IgnitionCoil

Our team kept running into problems where MQTT was an obvious solution, but the impact of replacing hardware was too much to stomach. We needed a better way. Enter IgnitionCoil.

IgnitionCoil solves these problems by running a lightweight suite of software tools on just about any computer on the network, including on some PLCs.

It communicates with legacy equipment using OPC-UA, (or any other protocol you might have like Modbus, Ethernet-IP, OPC-DA) parses a list of tags from the system, then packages it up into a Sparkplug B stream and sends it out to an MQTT broker. While it can work out of the box with any broker like Mosquitto, HiveMQ, AWS Sitewise, we like to pair it with Cirrus Link’s Distributor Module for Ignition since most of our customers are using Ignition for its many other benefits.

Under the Hood with IgnitionCoil

IgnitionCoil runs as a service on any given machine. This can be a server, an industrial PC, or even a Raspberry Pi, or groov RIO or EPIC from Opto22. IgnitionCoil talks to whatever devices are on your network, grabs the data you want from them, packages it up into the Sparkplug B format, then pushes it out to your MQTT Broker.

IgnitionCoil stores history either locally to the machine IgnitionCoil is running on, or on any database on the network giving us full store and forward capability, with the added benefit of being able to retrieve records from in the past should you need them down the road.

You can even write data back from your system to IgnitionCoil and update data on your local devices.

Think about that, you can use a PLC with OPC-UA or even Modbus, send data to a remote server with MQTT, do something on that machine, send a value change back to IgnitionCoil and have it change a setpoint on your PLC—all without having to replace any hardware.

Get Your Motor Running

IgnitionCoil is a powerful tool. It enables any device to be a first class citizen of any modern industrial data collection system. It gives you store and forward capable historical data collection, and lets you integrate and interact with your controls system without having to replace costly PLC hardware.

Going back to the list above, IgnitionCoil checks every box.

Get Started Now

If you have even briefly thought about using MQTT at your facility and didn’t want to get into the costly upgrade process for MQTT capable hardware you should give IgnitionCoil a try. We’re here to help.