MQTT and IIoT Explained
The Industrial Internet of Things (IIoT) was the 800lb gorilla in the room in 2019. It's been talked about with ever more frequency since 2010, and it will probably be a more years before it reaches any level of full maturity—and this is a good thing. Because connected devices, low bandwidth communication, and data you might not have had access to otherwise could now be informing your business decisions.
More devices mean you can easily pull in data about the weather, utility usage, and other useful information. But, this also means more work with reporting and analysis to gain insight and value from this data. Regardless, access to data as IIoT tools are improved is good thing as it allows you to review and discover new connections. So, how do we get from where we are today to a fully mature ecosystem of devices, data, and decision making?
Enter MQTT
Back in 1999, Andy Stanford-Clark from IBM and Arlen Nipper now of Cirrus Link sat down and hammered out the MQTT (MQ Telemetry Transport) protocol. They defined a low bandwidth way to send data from remote or edge devices to central SCADA systems, other devices, or wherever it needs to go. Each system has at least one "broker" acting as a central hub for data to pass through (and along) to any subscribers. When data changes on the edge devices, the devices publish the data to the brokers, and the broker pushes the updated values to subscribers.
MQTT leaves a lot of the work up to the people implementing the protocol. It requires defining a topic definition—how to spell out what devices and data are communicating. The topic definition also needs to define a generic payload of data, which requires additional structure applied by the developers. At this stage, we have a new protocol, MQTT, which gives us a low bandwidth way to send data, but still requires that we spend time developing our actual implementation on top of the specification. If everyone is developing their specific applications independently, we could end up with systems that don't communicate with one another. This is good because we can set up networks with less bandwidth for the same amount of information being passed from remote devices. But, MQTT lacks since it doesn't provide any additional structure over protocols like Modbus, OPC, etc.
Along Came Ignition
Inductive Automation released the Ignition platform in the early 2000s with the goal of making it simple to get data out of PLCs and into databases. The "unlimited everything" licensing model turned the rest of the automation industry on its head. You no longer needed to worry about tag counts, client licenses, or anything else for a growing system, you got it all with one purchase. Inductive Automation also took a modular approach with Ignition, meaning you could easily add precisely the functionality you need without spending a lot on features you might never use. When Inductive Automation disrupted the marketplace, they opened the floodgates for data in an automation system. When you are no long limited by tag counts, you are merely limited by your capabilities and imagination.
Looking back on the last 10-15 years, it is almost like Ignition and MQTT were destined to integrate. Ignition makes it easy to integrate as much data as you can throw at it, and doesn't make you think about limitations. MQTT does the same thing—while reducing the overall bandwidth requirements—making it cost-effective for getting data into Ignition. The only hurdle is building a definition of how the data should be structured. This means working with suppliers to implement the definition into their products, and making it simpler to get this data into Ignition.
The First MQTT Modules for Ignition
Arlen Nipper and Cirrus Link rolled out the first MQTT modules for Ignition, including the Sparkplug B specification. This was a game-changing moment for MQTT in the manufacturing world. Now, not only do you get the power of MQTT (combined with the power of Ignition) but you also get AUTOMATIC tag generation, with a definable structure. This is powerful. You can write PLC code as you would have before, you get instruments like before—then commission and implement everything the same way you always have—and you use devices that support Sparkplug B. Now you get all of that data into Ignition with no extra work. Just set up your system, connect everything, and your information is already available. Add a new piece of equipment? The data is already there through MQTT and Sparkplug B. Build a new production facility with Sparkplug B enabled devices? There’s no additional work requited to add your information. Reports can be populated with no extra work, and all of your analysis tools are ready to go. All you needed to do was put everything on the network.
This is the Future of IIoT
This is truly the power of IIoT—it doesn't simply use devices you never had before, sending data to your control system—it makes implementation simple, adds value, and reduces the overall workload. MQTT uses what you already have, gets more value from it, all with a streamlined approach to the human and technological bandwidth required. Winning with IIoT is using the best tools for the job and improving those tools, enabling you to do more amazing things. That is the power of IIoT.
Updated - 6/20/2022