MQTT & Ignition

< Previous Video    |    Next Video >


Arlen Nipper discusses Ignition in digital transformation, looking at using a different architecture for OT infrastructures and demonstrating a superior solution. Arlen goes over legacy approaches, poll/response protocols, MQTT modules, middleware, and Sparkplug benefits.


Video Transcript:

Arlen: Regardless if you call it IoT, IIoT, or the umbrella term of Digital Transformation, one must look at using a different architecture than what we've been using for the last 35 or 40 years for OT infrastructures. So, the first thing we have to look at is, for 35, 40 years, we've been hard-connecting devices to applications with protocols, but we've got to look at technologies where we can decouple. We need to be thinking about connecting devices to infrastructure, not to applications.

The second thing is that, again, for the last 35 or 40 years, we've been hand-editing process variable tags based on this poll-response register value pairs. But in 2019, we've got the power to be able to provide a single source of truth for all of our process variable tags and metrics and information coming from all of our devices in the field. And lastly, we need to demonstrate a superior OT solution first. A lot of digital transformation projects start from an IT-down-to-OT perspective, but if we can't convince OT that this is a better, faster, more scalable, more secure, more available OT solution first and foremost, we'll never get to the goal of complete digital transformation.

So, if we look at the legacy approach, there is nothing wrong with the conventional way that we do SCADA. SCADA systems work fine. We connect them to our devices in the field, build out operational dashboards, and everything works great. But in a digital transformation world, we have IT and enterprise data needs. And they may require information, let's say, for analytics and big data that we're not polling for today. So now we've got to go to operations and say, "Please can you poll for information that you don't really need, because you're connected to the devices in the field, therefore you need to issue the poll for that information." So, we do that, and we're quite good at it, and we add the firewalling and maybe the applications that we need to do. There we go, job done.

And then another requirement comes along, where maybe we want a bit more data from other devices in the field from data that we've left stranded. And as this builds out, you can see that we're trying to make a SCADA host system, which was never intended to be message-oriented middleware. We're trying to make that look like message-oriented middleware. And everything finally gets so complex and so convoluted that basically innovation stops because the system becomes so customized and so brittle.

Let's look at using MQTT modules for Ignition, and how we might look at a different architecture. We have MQTT Transmission, which basically takes tags that are in an Ignition tag database and can publish them using MQTT Sparkplug. MQTT Engine, conversely, can subscribe to Sparkplug messages and automatically create Ignition tags. And then finally, we have a module called Distributor that provides us an MQTT server as an Ignition module. So, using those components, we're able to see where we could install MQTT Distributor, and we would have our MQTT server functionality. On the Ignition Gateway, we could install MQTT Engine. Now, it has an MQTT component that is Sparkplug and can subscribe to those coming through their MQTT server. And then finally, on the edge, we've got Transmission, which can take OPC-UA tags and convert those to Sparkplug messages from the edge of the network.

With those components, we take our devices out in the field, and we interface to those devices locally using high-speed polling, and now we can get information, not only the information that we were getting previously by polling over the network, but other information that was stranded, other data. We get an MQTT server infrastructure, and we can look at taking those networks and establishing our IP connections into a DMZ. Again, remember that for this infrastructure uniquely you only have to have one port open in the DMZ for one or a thousand remote clients. And now we make our inbound connections, so we have remote-originated connection from our edge-of-network devices into our infrastructure.

Now, at this point, the two key facts that we mentioned, first we need to decouple our networks. We're decoupled right now, we have devices connected to infrastructure. The second thing was a single source of truth. So, running Sparkplug on the edge of the network, taking conventional register value tags, and then adding all of the other metrics that all of the other data consumers and enterprises need. Now, looking at step number three, we need to demonstrate a superior OT solution. This is where we can plug Ignition Gateway in with Engine and literally discover the network in a few seconds, discover thousands of PLCs, tens or hundreds of thousands of tags, and those all be a single source of truth. Can you imagine 60,000 tags showing up that you don't have to edit, and give tag names, and engineering units and engineering ranges to?

So, we've basically satisfied those first three steps, decoupling, single source of truth, and a superior OT, but now you'll neatly, because we are decoupled, we can add another client that subscribes to another set of tags, and maybe using our Ignition Injector modules, be able to get data into cloud services, be able to plug in OSI’s MQTT Sparkplug Connector, so that those tags could show up automatically in an OSI PI historian, as we had other applications, being able to be serendipitous with the data and be able to plug and play for all of this information that's coming in, and now getting access to data that used to be stranded.

Using MQTT and Sparkplug, what are the benefits? Well, the first thing is that we've decoupled data producers from data consumers. And we're creating basically a one-to-many architecture with message-oriented middleware. We have auto discovery of all devices, and tags in the infrastructure, resulting in plug-and-play architectures. We're publishing context-rich data to all data consumers, so now we have a single source of truth of a one-process variable tag that's published that may have one, two, 10, or 100 data consumers. More than 80% bandwidth reduction compared to poll/response, so varied bandwidth-efficient going to the next point, which means that we could send more information using our currently available bandwidth. That gives us access maybe to 80 or 90% more data that used to be stranded in the field.

We get an order of magnitude faster response times with report by exception, better and easier security. We've leveraged TCP/IP and the fact that, with remote originated IP connections, we don't even have to have any ports open in the field, reducing our security exposure and footprint. We have continuous MQTT client session awareness so we know, in real-time, the state of all of our edge-of-network devices and all of the equipment behind those, and the future-proofing with easy migration and minimal application changes as we add other equipment and other applications to the infrastructure.