Ignition: IIoT That Works
Tap the Full Power of Data with New MQTT Modules59 min video / 43 minute read
About this Webinar
The Industrial Internet of Things (IIoT) promises to revolutionize manufacturing. Although there has been plenty of IIoT hype, there hasn't been an IIoT solution rooted in operational technologies and seamlessly integrated into the IT layer – until now. The IIoT is here, it works, and it's Ignition.
This webinar is about the new Cirrus Link MQTT Modules for Ignition. Don Pearson, Chief Strategy Officer of Inductive Automation, and Arlen Nipper, President of Cirrus Link Solutions and Co-Inventor of the MQTT protocol, discuss how the new Cirrus Link MQTT Modules for Ignition provide the ability to set up a secure IIoT solution with full-featured SCADA functionalities built in.
You will see, the Ignition IIoT solution combines the amazing development power, affordability, and scalability of the Ignition industrial application platform with the incredible efficiency of MQTT.
What you will learn:
- How to dramatically increase throughput and efficiencies
- Why self-learning data tags drastically cut development time
- How to create one data pipeline for the entire enterprise
- Why MQTT is uniquely suited to industrial control systems
- And more
Don: Well, good morning everyone, and welcome to this morning's webinar, Ignition: IIoT That Works, Tap the Full Power of Data with New MQTT Modules. I'd like to welcome everyone. To introduce myself, my name is Don Pearson. I serve as Chief Strategy Officer at Inductive Automation. I'll be moderating today's webinar. And we've also got some great panelists whom I will be introducing in a few minutes. We'll start by briefly introducing our company and our Ignition industrial application platform. And we'll get into the main content by introducing the new Ignition IIoT solution that we're rolling out today. We'll give an overview of the new MQTT Modules that enable the IIoT solution, and we'll go over the architectures that you can build with it. Then we're gonna show you a demo of the new modules and we'll close as we always do with the Q&A.
Don: Some quick company background, Inductive Automation was founded in 2003. We've been in the industry for 13 years. Since day one, we've been an independent company with no outside investors, and we're really pleased with the response our software has gotten from industrial organizations all around the world. Ignition is serving HMI SCADA needs of enterprises in over 90 countries now. And our integrated program is now beyond 1400 integrators that we get that we work with on a regular basis. If you want more information, you can certainly visit our website, inductiveautomation.com, just go to the About Us section, it gives quite a bit of detail about us, the industries we serve, and our background.
Don: Ignition is really trusted by thousands of companies, including 38 of Fortune 100 companies. It's been used in virtually every industry you can think of: Oil and gas, water, wastewater, food and beverage, government, transportation and packaging, and really the list goes on and on. There's a few reasons for that, I'm just gonna mention a couple six characteristics of Ignition. Really, it's often used for SCADA, but you have to say it's more than just SCADA, it's totally unique from traditional SCADA solutions. It has web-based deployment, and it features unlimited licensing, so you can have as many whatever tags, clients, connections to devices, concurrent designers, projects. It's really focused on being unlimited to unleash your innovation potential. Built-in security and stability, easy expandability through its modular architecture, rapid development and deployment, and of course, real-time control and monitoring.
Don: Now to introduce our panelists. Arlen Nipper is President of Cirrus Link Solutions. Arlen has 37 plus years of SCADA experience, including design and manufacture of complete SCADA system infrastructure implementations for Fortune 100 oil and gas companies. He is co-inventor of Message Queuing Telemetry Transport, MQTT, a SCADA message transport in conjunction with IBM. He actively helped make MQTT a leading IIoT protocol, and is most definitely an expert on the subject. But Arlen, I'd like you to take a minute and tell us a little bit more about yourself and about Cirrus Link.
Arlen: Thanks, Don. Well, like you said, I've been in the SCADA industry a long time. I worked for eight years for Koch Oil out of college and got a lot of background in real-time pipeline control systems. And then as you mentioned, the companies that I was CTO of were really in the SCADA infrastructure business, if you will. And after 25 years of doing that, and then we're getting the opportunity to work with companies like Phillips 66 and Williams Energy on a few projects where they wanted to actually start exposing data, I was able to work with MQTT. So really what Cirrus Link does is we're at the enablement of infrastructure, and it's this new Internet of Things Message-oriented middleware that is our focus, and that's why we developed the MQTT Modules for Ignition.
Don: Thanks, Arlen. And I wanna say at the outset, I really appreciate you taking time to be with us today, 'cause I think it's gonna be... It's certainly of high interest based on the number of people we have attending today, and I think it's a real timely topic. Travis Cox, Co-Director of Sales Engineering, Inductive Automation. He's here to assist and help answer questions as we move forward. Travis, a little background on you.
Travis: Yeah, I've been with Inductive Automation since the beginning, since 2003. So I've seen every iteration of our products. I'm certainly an expert on Ignition, and I've done lots of installations, and of course, I've trained thousands of people on the products. So I'm here to answer any questions relating to Ignition that we might have.
Don: Travis, thanks, I appreciate your time. So as it was mentioned, there's been a lot of talk about how the industrial internet thing is gonna revolutionize manufacturing, but I just have to comment that so far I think there's been maybe more hyped about the IIoT than actual solutions. No one has provided an IIoT solution based on operational technologies that seamlessly integrates into the IIoT layer, at least no one until now. Today, Inductive Automation and Cirrus Link Solutions are proud to launch an IIoT solution that combines all of the development power, affordability and scalability of the Ignition industrial application platform, along with the incredible efficiency of MQTT. But let's take a time to just discuss a couple of points. As probably everyone on this webinar knows, data is essential to inform decision-making. However, a lot of companies just aren't getting all the data that they need, 80% or more of their important data ends up being stranded in field devices or some machine on a plant floor somewhere, that's because they've got intelligent devices directly coupled to applications, which happens to kill innovation, and it creates these information silos throughout the enterprise.
Don: Also, different devices use different protocols for sending and receiving data, and it can take days or weeks to set up a system. Unfortunately, a lot of the proposed solutions for IIoT are being built from the top down, from IT down to the operations of it. Ignition IoT is the solution to this promise because it's quite different from other IoT solutions that are offered so far. And how is it different, simply put? Well, one way it's today, it works, and it works right now, but I think more importantly, what it does is, it decouples intelligent device protocols from applications in order to make data available to the whole enterprise. So it's not just talk, it's actually a real solution and it saves exponential amounts of time, as you're gonna see today. And we build it from the ground up, from the OT level, connecting up to the IT level.
Don: Some key elements of this solution are the Ignition industrial application platform and the MQTT data transfer protocol. So why is Ignition an effective platform for IoT? Well, one thing, as I said, it's got unlimited licensing, cross-platform compatibility and capabilities, and you can web launch it on your desktop or mobile device. It also features IT standard technologies and scalable server client architectures. It's also modular, which means you can configure the capabilities of Ignition just by adding the modules to it. And why is MQTT the right protocol for an effective IoT solution? Well, for starters, it's more modern and efficient, and the poll response data systems that were developed like 35 years ago, MQTT was developed in 1999, and it's quickly risen to become one of the most dominant IoT message transports. MQTT allows you to leverage message-oriented middleware or MOM technologies, which are IT solutions used to decouple these device protocols from the applications. But Arlen, we've had many conversations about this. You've been working with it since the beginning. Can you, with your background, put some more context around a brief explanation of MOM and why this is so important?
Arlen: Yes, Don. I've done a lot since I'm involved in a lot of the IoT consortiums and I give a lot of talks. A lot of people ask me, "Okay, Arlen, how is IoT different?" It's just an acronym. If you ask 10 people, you're gonna get 10 different answers. Why am I in the industrial space? Why is IIoT different from SCADA or M2M or telemetry or DCS? And I would say if there's one dominant factor that we're starting to realize is we have to decouple devices from applications, like you said. If I have a really intelligent flow computer or highly capable PLC, and I plug that protocol into a SCADA host, I've effectively stopped innovation, as you said, but by coupling IoT devices to infrastructure. So really message-oriented middleware is about connecting devices to infrastructure and connecting applications to infrastructure. Once we can realize that is the power, that's the disruptive notion here, then we can take that forward and really expand on what the possibilities of factory 4.0 or IIoT can be.
Don: I think that's great, that puts in context, and this slide is just for emphasis, decoupling and device protocols from application results in a lot of good things. Dramatic improvement in critical data update times, dramatic reduction of network bandwidth consumption and capture of operational intelligence stranded in field devices, things that we're talking about here. It also happens to be very secure and well-suited for remote sensing and control solutions. So there's nobody better than you to talk about MQTT, you were involved, you were a co-inventor of it. So tell us about why you developed it, who you initially developed it for, and put that in context for us, Arlen.
Arlen: Well, as you said, MQTT was developed in the late '90s, and it came off the fact, again, I was very involved with SCADA infrastructure, I had lived through the transition from multi-drop phone lines where we were all happy to get a 300 baud modem connection. Then DSAT technology started coming out, we started to have to use proprietary transports over VSAT, so now we had a quadrupling of the problem, we had proprietary call response protocols over proprietary VSAT transports, and it just was always a lot of work just to get a device connected to your SCADA system. So in the late '90s, we had some projects, as I mentioned, with Williams Energy and Phillips 66, where we had some real thought leaders that wanted to decouple all of this. There were things like SAP and line of business applications that wanted access to data that may not have been coming into the operational system.
Arlen: So I had the fantastic opportunity to work with Andy Stanford-Clark of IBM, and the goal there was to take at the time message-oriented middleware and use publish and subscribe technology, and knowing that we were working on unreliable networks that were bandwidth limited. We iterated through the big pub/sub messaging and basically came out with a form of publish and subscribe messaging, now known as MQTT, that was very efficient. And the way it's deployed and the way it's used in Ignition, right off the bat, you're gonna save 50% of your bandwidth on valuable networks, and then probably even more than that as you look at reports by exceptions technologies. So it really was invented for SCADA, for mission critical real-time SCADA. It's just ironic that it's taken quite a while for it to actually emerge in that market.
Don: Thanks, I really appreciate putting context. Now, let's take a look a little deeper. As we said earlier, a lot of valuable data get sidled off, get stranded in field devices, but what if business applications could use that left-behind data to make smarter decisions? With our solution, built in Ignition and MQTT, as described by Arlen, they actually can. By using MQTT to decouple intelligent devices from applications, you end up creating really a single super efficient data pipeline, and that data can be easily pushed from actually thousands of devices across numerous sites to a central location. And there, all your industrial and all your business applications can access what they want, when they want, how they want it. So it really sets up the perfect situation for an IIoT deployment that really gets that field data and plant floor data throughout the enterprise where it's needed. As the illustration shows here, it's a pup/sub thing that Arlen described, protocol as the central part of the solution. So, explain a little more how pub/sub works and what the advantages are over maybe more traditional polling devices.
Arlen: Okay. Well, as you can see in this diagram, basically what we're saying here is that all of the applications and the end-devices, the business applications, the plant floor, they're all MQTT clients. So if I can look at a PLC or a flow computer or a gas chromatograph or whatever, it can publish all of the interesting information that it has, not really caring who's going to subscribe to that information. Conversely, applications can subscribe to... Because publish and subscribe is a topic-based mechanism, applications can connect to the central MQTT server and subscribe to interesting information. So what that sets up is the ability now to have the serendipitous nature of data where before if I had a really good idea, I had to go to the operations manager and say, "Could you please add another Modbus poll, or an Allen-Bradley poll, or a DNP3.0 poll, an O poll? I know your operational system doesn't need it, but I would like for you to poll that information." And effectively, we started turning our SCADA systems into message-oriented middleware which they really weren't intended to be. So with the topology that you're showing here, I could literally plug Ignition into this MQTT server, try an interesting application today, and then unsubscribe and go away. I'm not changing the infrastructure for data consumer or data producer applications. And that's really the beauty of this architecture.
Don: Thanks, Arlen. And before we get into detail about the modules, I wanna emphasize that Inductive and Cirrus Link are taking a fundamentally different approach to IIoT. I think it's becoming clear here. A lot of other players in the IoT space, I don't know, they're writing white papers and starting consortiums and building alliances, and what we have done is get to the bottomline, at the OT level, and put a working IoT solution together. Because industrial organizations don't have the time to inspect our OT, they need to start to experience the IoT and put it to work now. I know there's a lot of talk and hype about the new data that IoT is gonna bring, but if you don't have enough knowledge really of the OT level, the operations technology level, and SCADA to get the data and get it properly, then you end up not knowing what you don't know. So our IIoT solution is rooted in operational technology, because we really do believe that building up from the plant floor, up from those field device levels to the enterprise level is the only way to make IoT work when you're talking about an industrial environment.
Don: Now let's look a little deeper into Ignition IoT solution by discussing the new modules that actually make this possible. Cirrus Link has developed three MQTT Modules for Ignition, namely MQTT Distributor Module, the MQTT Engine Module, and the MQTT Injector Module. The new modules add the power of MQTT to the Ignition platform. And we'll discuss the specific role that each module plays in that solution. The main module of the three is the MQTT Engine Module. The MQTT Engine Module adds functionality to the Ignition platform to bidirectionally communicate with edge-of-network devices securely via an MQTT server. This module eliminates the need to poll up the host. It uses edge gateways which push the proprietary protocol polling to the edge of the SCADA or telemetry network and creates a single pipeline for all your data.
Don: Now, we should explain a little bit what edge gateways are before proceeding. They are different from Ignition gateways. What they do is securely connect devices to the MQTT server, and they communicate to edge-of-network devices, like PLCs and RTUs, in their native protocols. So, Arlen, I think this is a point where I'd like to ask if you'd like to shed some understanding about edge gateways.
Arlen: Okay. Well, if anybody's looked at any IoT technology or IIoT technology, you'll always see this notion of an edge-of-network device. The fact of the matter is, as we sit here today, the 99.99% of the existing infrastructure that we're familiar with is already out there, we've gotta deal with it. And we deal with it in many ways. We do things like putting routers and network boxes out in the field and terminal servers and network arbitrators, when, if you combine all of this into a single device, that is basically an edge-of-network device. So, in the demonstration we're going to have today, the edge-of-network devices that we are using are provided by Elecsys. They're the RediGate edge-of-network devices, and they basically poll the end-devices in real-time. And if you think about it, that's really where the polling should be, is right by the device. And then, they establish and manage the connection over an MQTT client into the MQTT server, and are responsible for publishing information, all the registered information from those devices into the MQTT servers.
Don: That's great. Thanks. And there are some key benefits I should say about the MQTT Engine Module. It delivers increased data throughput and efficiencies, self-learning data tags, as you will see, exceptional redundancy and security, and automatic system health metrics. They're really huge benefits and I think deserve a little bit of further discussion. Using the MQTT Engine Module, you receive more data more frequently with less overhead. Because of polling, as Arlen described, polling at the edge-of-the network, it vastly increases the overall performance, it retrieves more data from PLCs, RTUs and other devices, and allows you to improve your system awareness and control. So, Arlen, just speaking of efficiencies, can you think of a project where you save a lot of time, something that exemplifies what this solution allows you to do?
Arlen: Well, to a very large extent Don, like you said, we've had this technology for 17 years, and I try to tell people... Basically, I was waiting for Ignition for 17 years, if you will. So, it's not like it's a new technology. We were able to do this quickly after creating MQTT, but it's really... When it was driven from IT down, we tended to lose... Sorry, everything became too complex. So, what we've tried to put together with the MQTT modules for Ignition, is hide a lot of the complexity. So typically, instead of a project taking multiple man months and even man years, we're able to go to a customer, identify the end-devices that they have and then be able to get a working solution that we can demonstrate in just a couple of days. So, we're literally talking about going from multiple man years to man days to realize the benefits. And then we can start talking about all of the other line of business applications. But I think when we were IT led, it was the cart before the horse. And to your point, you've got to have a working operational system before you can explore all of the other benefits of IoT.
Don: Thanks, Arlen. A couple more things about the engine. The module subscribes to the data from the edge gateways through MQTT servers. Upon initial connection, it automatically learns all the data tags, whether existing or newly created tags, and it instantly creates them in Ignition. The tags data values continue to get updated as new values are published. This produces a self-aware, dynamically updating IIoT solution that rapidly learns data tags and makes them available to the entire platform. The module, it's highly redundant and secure. TLS security closes all ports over the network connection between the edge gateways and MQTT servers, which closes off many attack possibilities. The edge gateway knows when it loses a primary communication path and moves to a secondary one, and it's aware of when the primary communication path returns. If an MQTT server fails, the edge gateway connects to the next available server, providing as many levels of redundancy as needed. That improves uptime with quicker failover and acknowledgement when issues arise.
Don: When the module creates tags for data, it also creates metrics to track system health. The metrics are historical data points that help diagnose issues like availability and of course, lost connectivity. Metrics are created for the end-device, edge gateways and the MOM infrastructure of MQTT servers in place. They can be viewed on pre-built screens, or clients can use the data points to build, just build their own screens.
Don: The second module of the three is the MQTT Distributor Module. It's an MQTT server launched by the Ignition Gateway, compliant with the 3.1.1 MQTT protocol OASIS Standard. It enables MQTT clients to securely connect, publish and subscribe data, which is supplied to operational and business applications anywhere throughout the enterprise. The MQTT Distributor Module, in conjunction with the MQTT Engine Module, provides the components for a self-contained MOM infrastructure from one Ignition Gateway, as was being described and shown in that earlier topology graph. So Arlen, what type of applications is the Distributor Module made for?
Arlen: Well, as you mentioned, we wanted to collapse a lot of the complexity in having to get a complete MQTT infrastructure up. So, by having the Distributor Module, in conjunction with the Gateway Module, that lets a customer have a complete MQTT solution: The MQTT server, the MQTT client, which is an MQTT Engine, and any devices that they've got. So, for a complete on-premise, let's just get this up and working. It was really important to have an MQTT server module inside of the Ignition Gateway. Now, of course, as you would expand that system, then you start looking at redundancy and probably scaling out to MQTT servers that ran on their own server as well.
Don: Great, thanks. Now, let's go to the third module, which is the series link MQTT Injector Module for Ignition. This module is an easy-to configure tool for testing the functionality and throughput of different IoT solutions that utilize MQTT and Ignition. They can emulate edge gateways by sending change data and configurable intervals as a way to simulate live PLC data. Each simulated edge gateway connects to an MQTT server, enabling the MQTT Engine Module to receive data.
Don: So that sort of looks into three modules, but now that we've explained those modules a little bit, let's quickly look at the three main architectures that can be built with them, and then we'll get over to Arlen's demo. The infrastructure of Ignition IoT is, it's flexible, it gives different enterprises the option to use the one that really just meets your needs the best. You can use MQTT modules to build a private on-premise network solution, a cloud-based redundant MQTT server solution or hybrid on-premise and cloud-based solution. All the different Ignition IoT infrastructures share four common elements: The Ignition platform, the MQTT Engine Module, an MQTT server, and the edge gateways.
Don: So, this is an illustration of the cloud-based redundant MQTT server architect solution. So, Arlen, give us some idea of what types of operations does this kind of architecture work best for?
Arlen: Well, we all realize that a lot of our existing customer base is going to wanna start with on-premise, but in a lot of the engagements we've had already with Ignition, customers are quite happy to prototype their systems with cloud-based architectures. So, if you look at this architecture and if you wanted to go basically test and put together a complete system infrastructure, you could do that all by spinning up the instances on the cloud. So in this picture, you've got the Ignition Gateway Module with MQTT Engine, which can be running on a cloud server along with redundant and multiple MQTT servers. Then once you've done that, you can use the Injector Module to basically simulate thousands of nodes, and then you could proceed from there. If you wanted to take that infrastructure on-premise, you could do that, or as people get more familiar with virtual private cloud technologies and the security involved there, many customers were quite happy to leave their infrastructure running on the cloud.
Don: Great, thanks. So let's go to the second architecture, private on-premise network solution. Give us an idea of what types of organizations is this a good fit for.
Arlen: Again, this is the typical customer base that we have now. Most customers, especially large oil and gas customers still want all of their server architecture on-premise. This shows that you can have diverse redundancy on your MQTT servers. Again, you can have as many as you want. We have some customers who have up to eight diversely located MQTT servers. The nice thing about MQTT Engine is, it understands the fact that it could be connected to N number of different vendors, MQTT servers, and still consolidates all that into the Ignition Gateway.
Don: That's great. So let's take architecture number three. You can also choose a hybrid on-premise and cloud-based architecture solution. What are some of the advantages of a hybrid approach?
Arlen: Well, here's where I think everybody is gonna ultimately end up on. I think most people will do PLCs on the cloud. They will do production release on-premise, but more and more people are looking at the advantages of cloud. And as people get more comfortable with the security and the scalability, then we're going to end up with these hybrid architectures where pieces of the solution are running on cloud, and pieces of it are still running on premise. And I think with these three architectural drawings that you've shown, it basically shows that customers can put together all sorts of hybrid models of the solution.
Don: Great, thanks. What we try to do here is just really bring you up to speed on Ignition as an IoT platform, the MQTT protocol, and now the new modules and some IIoT architectures. So, Arlen's gonna give us a 10-minute demo and basically show us how it all works. Arlen, I might turn it over to you here.
Don: And you can take it away and do what you've got planned. That's great.
Arlen: Okay, so just a quick screen check here. You can see my screen, Don?
Don: Yeah, I can see it perfectly.
Arlen: Okay. So real quick, I'm just gonna go through the topology of what we're gonna be demonstrating here. So, we have an edge-of-network device, the Elecsys Director that I mentioned before. One of them is in Kansas City, here in my office. One of them is in Folsom with Travis at Inductive. They're both connected to redundant two MQTT servers running on Amazon EC2 over a Verizon network. And then on another instance of EC2, we have Ignition Gateway running with an MQTT Engine that I will install, and then an EC2 EUS, which is in Ireland. We've got an MQTT injector, a director simulator module that will be showing you the scalability. So if you keep this architecture in mind, we basically have four real PLCs in the architecture. And right now, the important point, like I said before, is that those edge-of-network gateways are already connected, they're already publishing interesting data.
Arlen: So now, this is... Let's say that I went to Inductive's website and I clicked on the "Download Ignition," I installed it and I launched the designer, this is the view that I would have literally at that point. So if I look here, I've got some system tags, but really I don't have any tag providers. So what we're gonna do is we're gonna go into the Ignition Gateway, and we're gonna go to the module section. And again, if I installed Ignition, this is my introduction streaming screen that I would get. I would go to Configure, go to Modules. From here, I'm gonna install a module, and I'm gonna install MQTT Engine. Okay, at this point, what's happened is that if we look at the topology diagram, Ignition has just become aware through the MQTT Engine of these two MQTT server modules that are running in the cloud.
Arlen: So if we go back to our tag browser and refresh the tags, we can see now we have an MQTT Engine tag provider. Under that tag provider, you'll notice that it found two edge-of-network devices, the ARC demo devices in California or at Folsom, and it's found an Allen-Bradley DF-1 running over IP. And you can see the tags are already updating. And it found the device that I have here in my office. And as Don mentioned, notice that not only were these the folders created and all of the tags, we've also created all of the metrics for both the node and for the PLC connected to that node. So here I have complete metrics on when the device connected, when it disconnected, how many bytes is transmitted, is it currently online in real-time mode? And then most importantly, I go into the Modbus RTU here. It found all the tags.
Arlen: So now literally, in one minute, I can now go to a window on Ignition, grab some tags, drop them on the screen, and we've got these relay outputs tied back to the digital inputs. So if you're familiar with Modbus, what's gonna happen is, if we turn a relay on, it'll feedback to the input. That'll be pulled by the edge-of-network device and that will be brought back. And then let's just add a setpoint here and let's add a setpoint feedback. Okay, now if I go into run mode and click on the "Relay," then what you just saw was the time that it took to publish that command to the MQTT server, the edge-of-network device was subscribed to that server, it picked that up, converted it into a Modbus command and issued it to the PLC, which caused the status input to change, which was published back on report by exception. I can do the same thing here for setpoint, and then that will come back on the analog input channel.
Arlen: So you can see very, very quickly we're able to start building live screens just by installing MQTT Engine. Like we said, we've got the metrics available, so this is literally... This isn't a custom screen. This is because we exposed all of the tags from the edge-of-network devices, I'm able to display the field unit statuses, the edge device statuses, all of the metrics from both MQTT servers, as well as a browse tree for all my connected nodes. And if you notice here, I've got all of these status coming in and there's no polls going out of the Ignition Gateway. So, to make this a little bit more interesting, we also have a, I call it my Internet-of-Things view of the world screen. And each of these green squares represents one PLC that Ignition's picked up. So what we're gonna do is we're gonna go to that EC2 that's running in Ireland. And here we've got basically a very accurate swarm simulation of multiple directors with multiple PLCs connected. What I'm going to do here is, imagine that you wanted to connect 500 PLCs into your Ignition system, how long would that take to get them configured? So, we're gonna spend up to 500 PLCs here. We'll go back to our view of the world.
Arlen: So, what's happened here? So we go back into our tag viewer and collapse this, and we had the four PLCs. Well, now we'll refresh our tags, go into the MQTT Engine, look at device nodes. And now we have 100 directors with 500 PLCs all updating all of their data every five seconds. So we have just created 20,000 tags in Ignition, and all of them are available and all of the tags have been created and those are all updating in real-time. So now if we make it a little more interesting and go add a second swarm...
Arlen: So again, in another 15-20 seconds, we've got 1000 PLCs online with 40,000 tags all updating their data in real time. And now let's go back to the screen that we had, and let's see if that affected the throughput of our real PLC. So with MQTT, since it is so efficient, the bandwidth we are taking, no matter how many devices will be added to this infrastructure, really doesn't impact our update rate of the end devices. So if we go back into our browse tree, we can see we have 100 nodes on server one, 100 on server two. From a redundancy or a disaster recovery standpoint, let's go say, we lost an entire MQTT server. So let's go to swarm1, let's get a view here of the world. And I'm going to basically take the entire swarm1, I'm gonna tell if that server just went down, and you could see that all those connections dropped and the edge-of-network devices are going, "Okay, where's my next server?" They're all connecting back up to the redundant MQTT server, and so for a catastrophic failure of 500 PLCs here in less than 25 seconds, we had them all back.
Arlen: So now if we go back to our metrics, we can see that now all 1000 PLCs are going through a single MQTT server, and although this is interesting from say, a pipeline, a wide area SCADA network, where we can see our tags are all updating once every five seconds, which is for a system this wide, five-second update rate for wide area over cellular and VSAT is actually very good. But now let's take it to the next step and say, "Well, what would this look like on the plant floor?" So let's go back to swarm1 and let's change the published period from 5 seconds, let's change it to 250 milliseconds, go back to our tag view, and now we can see all of our tags for those 500 PLCs are updating four times a second. So let's go back to our screen that we designed with the real PLC, here we go, and let's send commands on that, send a setpoint command, and the system is still as responsive as it was before. So with that, that's the end of my demo, Don, I'll turn it back to you.
Don: Arlen, thank you very much, I totally appreciate it. And I'm just gonna remind everybody that we have a Q&A queue that's building up with your questions. I'm sure there's gonna be more after this demo. So please, we're gonna get to as many as we possibly can. Just a couple more points, just a couple points of emphasis, just as we wrap it up here. It's just worth reiterating that the decoupling of devices from applications makes Ignition IoT very unique, and as you just saw, very powerful. Decoupling your devices from applications not only lets you subscribe to data, decrease the strain on bandwidth, and increase data transfer speeds, but it also frees up your ability to innovate and achieve what you might call, as Arlen mentioned earlier, that serendipity of data, meaning you can have an idea today, and you're just free to try it out, go wherever the data takes you. And as we say it here at Inductive Automation, "Dream it, do it." And this kind of empowerment gives you the opportunity to do that. Alright, I apologize you had to wait for 17 years for Ignition, as you mentioned earlier, Arlen, but we're very happy to be working together with you right now, okay?
Arlen: It's been good.
Don: Yeah. So a couple things, benefits of IoT today: It empowers enterprises to realize the full power of their data and do it now. It's built on the power of the Ignition industrial application platform with our unlimited licensing and unlimited possibilities. It streamlines the data pipeline, increases data availability, improves throughput and instantly creates tags as you just saw. So it really fills the fundamental need that companies have to be able to access more of the data they need to make better decisions and have it go any place in the organization it needs to go.
Don: So Cirrus Link MQTT Modules for Ignition, they're available, they're available now, this is our release webinar. Frankly, we're really excited, we just can't wait to see what you are gonna do with these unlimited possibilities. By you, I mean, we got a lot of people here today who are really knowledgeable engineers and integrators, and these are tools in your toolbox now. You can download the MQTT modules at inductiveautomation.com. You can also download the full version Ignition and do it there for free and just get started.
Don: As we go into Q&A, I'm gonna answer a question that's already in the queue and always gets asked is, "How much does it cost?" As I said earlier, Ignition has an extremely, very affordable server-based pricing model. The Ignition software platform is priced by the server, offers unlimited tags, clients, and connections. All our pricing is right on our website as always. And we're also offering these new modules at a very reasonable price, right in the range of other modules on the HMI SCADA module set. It follows that server-based pricing model, which gives you amazing capabilities for expansion. So you got a lot of the IoT functionality at an incredible value and eliminates the usual economic barriers to deployment of systems like were described here. So the prices are listed here. But you can find a lot more information on our website. So with that, we'll open up the Q&A tab here and give an opportunity to sort of dig in.
Don: But I don't wanna say one thing for starters, Arlen, because I know this is a question that's also in the lineup. In the North American market, there's a lot of opportunities that are brownfield projects, and you mentioned all the equipment that's out in the field there, but where you're upgrading your existing legacy SCADA infrastructures, why is this solution with the MQTT in Ignition a good fit for those opportunities?
Arlen: Well, what it lets us do, again, most of the edge-of-network devices that we work with let us maintain a poll response from legacy SCADA systems. And the beauty here is that what we can do is we can start getting subsets and supersets of the data from the end devices and publishing that into Ignition. Let me give you an example. Let's say a Smart Tank transmitter has 4-20 milliamp output, but we know that most of the 4-20 milliamp devices out there are using HART protocol. Well, wouldn't it be cool to reach behind the PLC and start getting some of the HART process variables and publishing those into Ignition in parallel to while you're still polling on your legacy SCADA system? So I haven't had one opportunity where we didn't need to show a migration strategy and never lose any operational integrity. Again, going back to your notion that this has gotta be from ground up OT to IT, we've got to maintain an operationally safe mission-critical system while we put in this architecture.
Don: Great. Thanks, Arlen. Listen, I just gotta warn you, we have a lot of questions, which is wonderful. Travis is here with me, so we're sort of nailing as many as we possibly can. We'll use the time we have. And I wanna tell everyone go ahead and keep asking them. We're gonna get to all of them. If it isn't now, it's gonna be in follow up. But for starters, I'll start with, What are some industrial hardened end devices which have implemented MQTT?
Arlen: Again, Don, what we're using right now is the Elecsys. It has a very good line of industrial network gateways called the RediGate. We're starting to see other edge-of-network device manufacturers adopt MQTT. And a lot of interest, I think, in the actual PLC market is starting to adopt MQTT as well. But again, my notion is we have hundreds of millions of legacy devices out there, so for the next 10-15 years, let's face it, if you wanna play an IoT, you're gonna have to deal with the fact that there are going to be edge-of-network gateways. And then as modern equipment comes out that has this ability, they'll be able to be integrated into the infrastructure as well.
Don: That's great. I'm gonna try to keep throwing you questions, okay? MQTT, is it a standard or proprietary protocol?
Arlen: It's a standard protocol. When I originally worked for Arcom, when I worked on it, Andy Stanford-Clark, worked with IBM, and the very premise was it was going to be open. I had already done 25 years of trying to deal with proprietary protocols, and they're all on a trashcan somewhere that we don't know about. So we made it open, we pushed it to the Oasis Foundation for standardization, and we pushed it to the Eclipse open software in the pile project for anybody to download it and play with it.
Don: Okay, great. A question that I have is, Is MQTT... This is kind of a four-part question. And the first one is, How many MQTT remote devices can push data into Ignition? Does Ignition support send commands to MQTT-enabled remote devices? Can data views be customized for different users login credentials? And, How does Ignition handle host-server security for the MQTT listening socket? So that's a four-part question, if you can throw it out there.
Arlen: Okay. I'll try to get through those. Number one is that you saw sending commands, when I did the demo, we were turning relays on and off and sending setpoint commands. So, yes it is bidirectional indeed. The security is that I didn't mention it, I should have shown it in the diagram. All MQTT connections into the MQTT servers are using TLS. That's the other disruptive notion here is that there are no outbound connections from Ignition, so you can drop everything in a DMZ, and you end up with a single point of access.
Don: I threw four questions at you. Let me throw a couple of them towards Travis, okay? The third and fourth. Can data views be customized for different user login credentials and how does Ignition handle host-server security for the MQTT listening socket?
Travis: Yeah, those are great questions. For number three here, Ignition supports an unlimited number of projects. And for each project, you can specify who can log in to that project where authentication is gonna be used, if it's something in Ignition or Active Directory or database. And each user is gonna be assigned a list of roles. And based on those roles, you can lock down what they're allowed to see, whether it'd be an individual component on a window or the entire project or be in a particular screen, or whatever it happens to be, you can lock that down and have different views. And as Arlen was showing earlier, the tags are really just about figuring out what you wanna put on different screens and how you wanna represent that data. That last question we'll throw back to you Arlen, How does Ignition handle host security for the MQTT listening socket?
Arlen: Well, again, the MQTT distributor, which is the MQTT server running in Ignition, does implement TLS connection. So you actually have to download your certificates if you want a TLS version of that. Now, MQTT does have binary or an open version. It runs on port 1883, so you can pretty much choose your TLS at your organization for how you wanna do that security. Again, that's the beauty of MQTT. It in and of itself doesn't do the security, that's where you use TCP and how your organization does security.
Don: That's great Arlen. Thank you. And listen, I know MQTT and all of the depthly ones that may be new for some people here today as its application. Give us a context. Who else uses MQTT?
Arlen: Well, a lot of people. First of all, IBM again was very, very out there in the lead. And so all IBM middleware products support MQTT, but now if you look out on the landscape, I think every message or even middleware product out there now supports MQTT natively. When MQTT went viral was when Facebook posted that Facebook uses MQTT for their Facebook Messenger, which, gee, I wasn't thinking of Facebook 17 years ago when I worked on MQTT. And then of course, one of the new announcements is, now Amazon has a new AWS IoT service. And if you look at that, that's a native MQTT server implementation running as a service on Amazon.
Don: Great. Thanks, Arlen. Travis, I wanna throw this in your direction. Please explain the difference between Ignition client and MQTT client.
Travis: Yeah, that's a good question. As we were talking about here earlier, MQTT client is the engine module, the MQTT Engine Module for Ignition that subscribes to the interesting data that is in an MQTT server. So that is basically empower Ignition to look at that data. Ignition itself has clients, which are screens, views of that data that you're going to create with the designer in Ignition that you can launch anywhere in your organization. So any PC, mobile device, touchscreen, computer, you can see all that data that the engine module is getting from the MQTT server. So, that's a distinction between one is the data transport and getting it into Ignition, the other is the view of the data.
Don: Great, thanks. Thanks, Travis. So this is a question from Brad. I'm gonna throw it your way, Arlen. Which of the major industrial DCS, PLC, HMI vendors, ABB, Honeywell, Emerson, Schneider, Siemens, Yokogawa, have bought into this technology?
Don: I thought...
Arlen: There are implementations out there. We do know that in working with Schneider, we've done some major implementations with OASIS DNA, and we are talking to a lot of that population that you just mentioned. But again, I think that's one of the things is that people are trying to figure out what they wanna do, which protocol do they wanna jump on. And I think that what we've done here is really jumped out with Ignition and said, "Look, we're really tired of faffing around here, let's just go do this."
Don: Thanks, Arlen. I'm gonna try and squeeze in a couple more questions 'cause we're coming to the end of our hour and I wanna remind everyone, we're gonna get to your questions 'cause you keep asking them. And this is great, we're really excited for the interest in this. So a question for you, Arlen. What is the advantage compared to a message broker like Apache ActiveMQ or others that support MQTT?
Arlen: Well, it really is your infrastructure and how you wanna deal with it. If people are familiar with it, there's everything from the very well-tested Mosquitto broker that's been around for almost 15 years, to new implementations of Red Hat AMQ, Apache Message Queue. There's IBM MessageSight, there's IBM MQTT brokers, there's Amazon. That's the cool thing, is that we've got Ignition and MQTT Engine running in implementations where, well, we have four or five different brands of MQTT servers all working together.
Don: Arlen, thanks. I really appreciate you taking all the questions. Unfortunately, we've exceeded our hour here. I would like to go on further, but what I'm gonna tell all of our listeners is that we are gonna follow up and get to your questions. I'm promising your time, Arlen. Sorry about that, but there's a lot of interest here. But I wanna give you a chance to say any final thing you may wanna say in terms of the demo, the presentation, the MQTT modules you've created for Ignition and just any final thing you wanna say to the audience today.
Arlen: Well, it's been a pleasure. First of all, from my standpoint, I had no idea that MQTT would get the popularity that it did when we started down this path. I think myself, a lot of the developers that I've worked with, with Arcom and Eurotech and within Cirrus Link, everybody is committed to this. We feel like it's a very good architecture, the Open Source community, the Eclipse Foundation, the OASIS standards body. So this has really become a viral effort on the community I think, to pull operational technologies up into modern architectures where we can start actually using the data and quit spending all of our time trying to get data from point A to point B, and then our byte is gone.
Don: Yeah, that's a very good point. Listen, I just wanna say in wrapping up here, thank you to all of our attendees and for their interesting questions. Arlen, thanks again to you and your team there for all the hard work in bringing this together. We're very excited here in the Inductive Automation world and the Ignition community to be able to just expand the capabilities so that our common customers, the integrators and industrial organizations can go out there and really come up with solutions that really help get the challenges met that they have to face on a daily basis. So with that, we're at the end of our time. Thanks again everyone for attending. We're finished. Have a great day.