Inductive Automation Blog
Connecting you to ideas, tips, updates and thought-leadership
from Inductive Automation
Lauren and Shay sit down with the Co-Inventor of MQTT, and CTO of Cirrus Link Solutions, Arlen Nipper to discuss selling MQTT. Arlen talks about how the addition of MQTT modules creates a more efficient SCADA system and how that solves current system issues and creates an infrastructure ready for digital transformation. Arlen discusses the partnership between Inductive Automation and Cirrus Link Solutions, the MQTT modules, the key selling points, the Sparkplug specification, and the guiding principles of utilizing Ignition and MQTT. And we get to see Arlen do a demo!


Lauren: Welcome back to our sales and marketing series. Today's topic is selling MQTT. I'm Lauren.
00:14
Shay: And I'm Shay. We're sitting down with the co-inventor of MQTT, CTO of Cirrus Link Solutions, Arlen Nipper.
00:21
Lauren: We'll be talking with him about how the addition of the MQTT modules creates a more efficient SCADA system, and how that solves current system issues, and creates an infrastructure ready for digital transformation.
00:33
Shay: Arlen, thanks for being here today.
00:34
Arlen: Thank you.
00:35
Shay: We're really excited to talk a little bit about the partnership between Inductive Automation and Cirrus Link. Can you kinda touch on what that relationship looks like?
00:44
Arlen: Literally, it was on a project with Plains Midstream pipeline, they were using MQTT, it was a legacy product, and we just didn't have any tools. We didn't have any way to... It was a black box. And so we went to a lot of IA's competition, and we say, "Hey we've got this idea of something we could do with MQTT." "No, Arlen, thanks, but we've got smart guys, they're gonna come out with our next IoT strategy." Then it was somebody in Calgary that said, "Hey have you ever heard of Inductive Automation?" I said no. And so I called and got a meeting, this was about four years ago, flew out, I met with Travis and the team for a day, I said, "You know, I've got this idea." and they go, "Great, We're open, we've got an open SDK, we're based on Java." And that was what myself and our developers at Cirrus Link knew.
01:43
Arlen: So literally, just from a prototype, I flew home Friday evening, and by Sunday morning we had a prototype working. I demoed it to Steve Hechtman, and he goes, "Oh, this is awesome." So in his keynote he mentioned that, "Oh, you should go see what Arlen's gonna present, this MQTT thing." So that was when I did the first demo of MQTT. We had only Engine, we had one module, MQTT Engine. And we demonstrated discovering 300 PLCs, and I think it was like 30000 tags in less than 10 seconds. And that's kind of where, right after that, during that show, I talked with Steve and Don. And so, Cirrus Link are still a independent... We're a privately owned company, but we are one of only two strategic partners to Inductive Automation. And really our product line are developing best-in-class modules that you can plug into Ignition to give it the MQTT capabilities.
02:45
Shay: So I had never heard that story. That's really awesome. I think it goes to show the power of MQTT. And now your module stack with us has kind of grown. So can you speak to what Cirrus Link modules you have available in Ignition and how they work?
03:01
Arlen: The first module is MQTT Transmission, and it's a MQTT client that knows two things. It knows about the internal structure of an Ignition tag. So if you think about when you go into Designer and you're designing your folder structure and you're bringing tags into Ignition, and then you're giving those tags properties, you're giving them a tag name, engineering units, engineering ranges, maybe a documentation, well that creates an internal tag in Ignition. Well, MQTT Transmission knows how to take that tag, convert it into Sparkplug B format and publish it using MQTT. Now, the next module that you would wanna look at is the MQTT Distributor Module. So, MQTT Distributor is an Ignition module, but literally, it just sits there to be an MQTT server, so really easy to download it and to install it and manage it.
03:56
Lauren: So when you say server, are you referring to the same thing as an MQTT broker?
04:01
Arlen: Yes, for 25 years, they were called data brokers and when we took MQTT through the OASIS-standards body, so that was IBM, Microsoft, Red Hat, Cisco, to get actual international certification for MQTT, it was funny in the meetings, there was like a half-a-day argument, "Is this an MQTT server? Is it a broker?" So, officially I try to stay with the term MQTT server, but everybody in the world knows it as MQTT broker, so those are interchangeable. And then finally, MQTT Engine is kind of the reverse of Transmission, in that it knows about Sparkplug B messages. And when they arrive, again, we're talking about post and subscribe. So, when they arrive, Engine is able to take that tag, and if it doesn't already exist, inside of the Ignition database, it can actually create tags on the fly. So with Transmission, Engine, and because of Sparkplug, we basically have self-discovery of tags.
05:05
Lauren: So you started to touch on some of the main selling points of this infrastructure, but we thought it would be fun to kind of put you in the hot seat and take you through some of the key selling points. Make sure you've got all your bases covered.
[chuckle]
05:18
Arlen: Okay.
05:18
Lauren: Are you ready?
05:18
Arlen: I'm ready.
05:19
Lauren: Okay. Is it bi-directional?
05:21
Arlen: Yes.
05:22
Shay: Is it Pub/Sub?
05:23
Arlen: Yes.
05:23
Lauren: Is it statefully aware?
05:25
Arlen: Yes.
05:26
Shay: Is it secure?
05:27
Arlen: Definitely.
05:27
Lauren: Is it fast and efficient?
05:29
Arlen: Very.
05:30 Shay: Can you do store-and-forward, with zero data loss?
05:33
Arlen: Yes.
05:33
Lauren: Oh, we're sold.
[laughter]
05:39
Shay: I know a lot of our customers are looking to use Ignition along with MQTT to do their own digital transformation. So what are the three tenets that you often speak to that are kind of guiding principles to help our customers through that process?
05:54
Arlen: The first year that we came out basically it was all about decoupling. My notion is that poll response protocols, or proprietary protocols are the biggest hindrances to digital transformation. So the first tenet is we should look at decoupling wherever possible. What I mean is we should be connecting devices to infrastructure, not to applications with protocols. So if you think today we take a perfectly good PLC and then we basically hard-code it to an application using a protocol. Now, we can expand that, but typically what will happen from an operational standpoint, is nobody will ever change that. It's gonna be the way that it is. The second thing is that we came out the year after, after we got Sparkplug specification out, is being able to provide a single source of truth. If you think about what we do today, everything is a register-based protocol.
06:51
Arlen: So we have a register, it's 40,012, it's got a value of 160. What is that, 160 degrees, 160 gallons? So what do we do? We manually click on that tag and we start to give it properties. We give it a tag name. We give it engineering units. We may have to scale it. We may have to give it engineering ranges, and those are all manually entered. And then if you wanted to use that same 40,012 again, you've gotta do it again and again and again. And editing tags, keeping them up to date, it becomes a pretty much a full-time care and feeding of a SCADA system over the entire life of the project. But providing a single source of truth using MQTT and Sparkplug, we can publish that information one time with all of the properties, and we basically created a SCADA object. So instead of just a register, we're publishing an object that then has state for the rest of its life as far as usefulness.
07:51
Arlen: And then the last thing that really comes out is that we're finding out that digital transformation really is not IT down to OT. We've got to give the operational departments, the SCADA departments, we've gotta give them the tools and the technologies to put together an infrastructure that is digital-transformation ready. So the third tenet is: Be able to show your customer a superior operational system, first and foremost. That empowers them to do what they're good at: That they have the paradigm expertise at the operational level. With Ignition there and with MQTT, now they will be Cloud-ready going forward.
08:35
Lauren: So what does a solution like that actually look like?
08:40
Arlen: The first solution was we were very oil-and-gas centric or very remote SCADA. So we were quite happy if we could get a PLC, and maybe a flow computer publishing information over MQTT very efficiently into Ignition as a SCADA host system, but it's gotten much larger than that. I remember, it was funny, we were happy when we could get 500 tags and then 5000 tags, and now we have customers that have systems, some of the larger ones, 6.5 million tags. So all of these solutions, you ask me, "Arlen, what did you think a typical solution would look like?" but the customers are taking Ignition and all these capabilities and they're doing stuff that we didn't even think about.
09:26
Shay: And that's incredible. So MQTT is really awesome. I think we all, in this room, know the power of MQTT, but where does Sparkplug B come into play? Where does the Sparkplug specification, I should say, come into play?
09:38
Arlen: In working with the customers with Inductive Automation, we found that the industry was very fragmented. So we had a lot of OEMs that were looking at MQTT, we had a lot of service providers looking at MQTT. The only problem was nobody was doing it the same way. And so, for all of the advantages of MQTT, we were losing any sort of interoperability. So here, about three years ago, myself and the development team at Cirrus Link sat down and said, "Look, we've been doing MQTT ever since it was developed. We've got some best practices, things that have worked well." So we sat down and we wrote a specification, we called it Sparkplug, and Sparkplug basically does three things: One, it defines a topic namespace that can be used in MQTT, that makes sense in industrial applications. The second thing that we did was we looked at the best way to represent process variables inside the payload.
10:38
Arlen: Now, up until this point, everybody's been using JSON, all the Cloud providers that use MQTT. And I don't wanna say there's anything wrong with JSON, but we live in a world where, yeah, we may have some customers that have high bandwidth, but we have other customers that are using VSAT, using spread-spectrum radios, using cellular, and my notion is that in our world, bandwidth is neither free nor is it unlimited. So we kind of took a middle-of-the-road approach, and we used a technology called Google Protocol Buffers that let us build a data model that makes sense for process variables. So really very similar to what an Ignition tag looks like, in that it lets you give it a tag name, engineering units, engineering ranges, description, maybe asset tags. And then we wrap that in this Google Protocol Buffers schema and that defines a payload that really anybody can implement.
11:38
Arlen: So we've got a known topic namespace, we've got a known payload, and then the last thing that you've got to have if you're doing mission-critical, real-time SCADA with MQTT, is you've gotta have state. Now, Andy and I built stateful awareness into MQTT. You know if an end device is connected and you know when it's disconnected. But nobody had defined what topic are you gonna use for your death certificate. So Sparkplug lays out all three things. It lays out a well-known topic namespace, lays out a payload representation that is process-variable centric, and it tells you how to deal with state of your connected devices. And with that, you really have everything that you need and we're hoping that Sparkplug now, it's in the Eclipse Foundation. We're hoping it becomes a very highly adopted standard.
12:29
Lauren: That's really exciting. But we've got all of these basics coming together. Now, where do we actually see these being used? Where can we see this applied?
12:39
Arlen: I would have said it started in what I would call wide area SCADA. So, oil and gas, water and wastewater, electric utility, anywhere where you've got long distances and you're using expensive communication networks. And it did prove out. So, some of our first customers were oil and gas, water and wastewater. But I think that we're seeing it expand out. Now, I would say that from the conventional, one of our big use cases now is in solar, monitoring solar farms and things like that, and then going out into electric utilities. And a lot of our customers, even in logistics, in automotive, in pharmaceutical, in manufacturing, are looking at the tools on Ignition and going, "Well, wait a minute, if I could go and connect this to my PLCs on my plant floor and then give them tag names and give them properties and publish that into my operational system on the plant floor and then from there I could go on to all of my cloud service providers." So, we're going back to that actual single source of truth, where we're publishing it from the edge and then all of the data consumers, all the way up and down, get the same single source of truth.
13:54
Shay: This has kind of become a buzzword. In the last five years, we've heard a lot of folks talking about IIoT, about digital transformation, but we're not seeing a lot of folks do this successfully. So, why are people struggling so much with this?
14:09
Arlen: We should enable OT. And a lot of these approaches, again, industry says, there's gonna be OT or IT to OT convergence. But, let's face it, they each have their own specialty too. And so for operational, I don't care which industry you go in, there is tribal knowledge, there's experience, there's certain things that you know. For example, what is a 4-20 milliamp loop and how does a limit switch open on open and a limit switch close on close, open on close, work on a motor operative valve? Those are things that you've got to know in those sectors. So, again, for successful digital transformation, I think we have to attack it at the infrastructure level. One of the notions that I've got is that, currently, most of the existing OT infrastructure is not conducive to digital transformation. So, if we can provide OT with the tooling and the technology to create an infrastructure that's IT-ready to begin with, but then it actually makes a better SCADA system, then I think it's a win-win and you will see successful digital transformation projects. But it's gotta start from OT first.
15:25
Lauren: That's an exciting proposition. Who would you say MQTT is really for?
15:32
Arlen: It's almost just assumed. Anywhere I go, IT are already using it. IT have known what pub/sub is. They've known message oriented middleware, and I would bet that all of the IT departments are already using MQTT. But you ask me who... We invented it for real time SCADA systems. So, you can say what you want about it, but it's got, uniquely, it's got all of the mechanisms built in, like the last will and testament and things like that, continuous session awareness that are uniquely for operational systems.
16:08
Arlen: If they are using, again, wide area SCADA, I think it is absolutely evident that MQTT would give them a faster infrastructure and they would be able to bring back more data. If you think about... We did a survey with Chevron here are several years ago and they were looking at a booster station or a tank farm location. How much data is actually available? If you look at smart transmitters like heart transmitters, if you look at PLCs, if you look at flow computers, gas chromatographs, and you know the figures are anywhere from 80 to 95% of valuable data we're leaving stranded in the field today.
16:53
Arlen: Now, that may be limited. But if an integrator can tell a customer that if they're using MQTT they can save 80 to 95% of their bandwidth that they were using, then the way you can look at that, that's 80 to 95% more stranded information that the integrator could be bringing back for that customer. Now, the other thing. Now, the integrator can show the customers that not only is that coming into your Ignition system for a better OT solution. Oh look, we've got injector modules for AWS and for Amazon and Google Cloud and IBM Watson and SAP Leonardo. So, now they've done more than just do a SCADA system, they've put together an infrastructure for their customer that can scale.
17:39
Lauren: So, I think that says it all. It's the easy option.
17:42
Arlen: It is. It's the easy button.
17:44
Shay: Yeah. [chuckle] So, we've gotten to look at the different modules that are available. We've talked through MQTT and Sparkplug. If I have a customer that's coming to me and asking me, "Shay, how can we apply digital transformation to our systems today or how can we get to industry X.0?" What are your recommendations for that? How do I do that?
18:05
Arlen: Download it. Do it today. Because everything that we've talked about, uniquely, Ignition, I can download a full Ignition Gateway, I can download Ignition Edge and I can run it in trial mode for as long as I want. So, the way I would suggest getting started is you could start download Ignition Edge, put it on a Raspberry Pi, put it on any Linux-based or Windows-based embedded computer, connect it to a PLC. And just see how easy it is to use the tools that Ignition Edge has to bring tags in at the edge and give them context, just give them tag names, engineering units, engineering ranges. Well, now, we've talked about Distributor, that MQTT server/broker, that I can install on my Ignition Gateway running in trial mode, so now my Edge can connect, my Edge MQTT can connect to my Distributor. Now, I'm connected. And now my Engine Module on my Ignition Gateway can subscribe to that data and all of those tags that I've got in Edge are now showing up in my Ignition Gateway.
19:05
Arlen: Now, from there, I can see that I've got a single source of truth, I can see that I've got self-discovery, all the tags are created automatically, but now I wanna take it to the next step. So I could get a Injector Module for AWS or Azure or IBM Watson or Google Cloud Platform and I can see those tags go there at the same way in real time. So when we do demonstrations, we show everything happening at once. So the demo now is 1,800 devices, 150,000 tags with over half updating faster than once a second, and all of that being discovered in less than 10 seconds going into Ignition, into AWS, into Microsoft, into IBM and into Google Cloud Platform.
19:52
Lauren: Well, now you've gotten us all fired up and excited. Can you show us a quick demo?
19:57
Arlen: Sure.
19:57
Lauren: Alright.
20:00
Arlen: Okay, Lauren and Shay. This is a very high-level demonstration of some of the capabilities of the MQTT modules for Ignition. Now, what I'm showing in my browser right now is Ignition Gateway, and probably all of the modules that everybody are already familiar with, but you'll noticed down here at the bottom that we have some of the Cirrus Link modules installed. And one of the ones that we're gonna be looking at here is MQTT Engine, and when we install that we get a tab that let's just go in and look at the configuration for MQTT Engine. Now, notice right now it's disabled, but once we enable it, we're able to define two available MQTT servers that MQTT Engine can connect to.
20:43
Arlen: Now, also as part of the demonstration, we have Ignition Edge running on an embedded computer. Now, that has fewer Ignition modules installed, but it's got the Cirrus Link in MQTT Transmission Module along with the EFM Emerson ROC Driver. So if we take a look at our dashboard, I basically built a topology drawing, if you will, of our infrastructure. So this is our Ignition Gateway connected to both Greengrass Core or Azure Edge from the MQTT Transmission Module. I'm showing the Cloud Injector modules that could go to any of our cloud services. And here, we're showing MQTT Engine Module that's not enabled yet, but will be and connecting to two available MQTT servers. Now, before I enable Engine, note that although we have a tag provider, MQTT Engine, let's go in here and look and notice that we don't have any UDTs, and we don't have any Edge nodes and therefore really no tags. So if we look at our total system tag count, we have 192 tags, but what we show down here, is all of these devices, both real devices, real PLCs, flow computers, smart transmitters are connected into the infrastructure representing over 2,000 devices and also representing over 170,000 tags.
22:16 Arlen: So what we're gonna see is once we plug in Engine, how long it will take to discover all the devices, all of tags and all of their metrics. So I'm going to enable MQTT Engine here, in this small web browser, I've embedded in the designer. Now, note, when I hit the change, we'll just wait and see how long it takes the system to discover what's out there.
[pause]
23:00 Arlen: Boom, a few seconds later, we have discovered over 2,000 devices and 179,000 tags. Now, notice that as Engine was discovering those tags, we were also able to provide those tags in real-time, to services like Greengrass, Azure Edge or any of the cloud services. So let's go over here and see what we discovered. Remember, the Engine folder was empty so we're gonna refresh our Edge nodes, and we can see here that we discovered our embedded computer running Ignition Edge connected to a flow computer out in the field. We'll see here that in our pipeline group, we discovered five groups with 20 stations each. Each one of those having a line with a unit PLC, and we can see here that we didn't know about this entire unit just a few seconds ago. Now we know it's here, and we can look at our case pressure and we can see that it has a zero to 50 kilopascals. So we discovered all of that in just a matter of seconds.
24:09 Arlen: Now, if we go back to our Edge, now this is the Designer for Ignition Edge running at the edge, connected to this FloBoss 107 flow computer. Now, notice that we also defined a UDT to make those process variables from that flow computer easier to work with from the standpoint of a human being, not needing to know all the enumerations and everything for a flow computer. So that we can come back to our Ignition dashboard, go to that same folder structure, the same folder structure got published and we can see here that we also got that UDT published. So literally through the power of Ignition, we could open a new design window, we could have created a template for that UDT. So that once any of these data types, any of these complex data types were discovered, we literally can go into our Meter-Config, Meter Run number 1, drag that UDT, drop it onto the screen, and we basically have created a live configuration screen that could be replicated over and over and over again.
25:27 Arlen: So again, not everything that... Not great detail on everything that we can do with the MQTT modules, but I think a very high-level demonstration and just demonstrating some of the power of what we can do with the MQTT modules.
Ignition Edge Changes
As you know, Ignition Edge is a line of lightweight, limited, low-cost Ignition software solutions designed specifically for embedding into field and OEM devices at the edge of the network. Ignition Edge has been extremely popular, however, some of the limitations, such as no Gateway scripting or 3rd party OPC-UA access, have been too restrictive at the edge. Inductive Automation continuously listens to our customers and we are excited to announce some changes and additions to Ignition Edge that will start in December of 2019 to address these pain pints. In this session, we will cover the Ignition Edge changes and additions and answer any questions relating to Edge.