Implementing IIoT from the Field to the Cloud

About this Webinar

There’s a new architecture revolutionizing the way oil & gas companies connect to their data. Discover how migrating from a typical poll/response, round-robin topology to a bandwidth-efficient field system using MQTT can decrease latency and help get critical data to your entire enterprise in an instant.

Webinar Transcript

00:00
Don: Welcome to today's webinar, Implementing IIoT from the Field to the Cloud: How to Leverage MQTT to Build a Better Architecture for Oil and Gas. My name's Don Pearson, and I will serve as the moderator and also make some opening comments as we get into today's webinar. We appreciate everyone's time and attendance today. Just a quick look at the agenda, what we were trying to do in putting this agenda together is get a variety of areas of expertise, both from the technology side, from the strategy side and architecture side, and from integrators. We'll talk about some case studies who have worked really where the rubber meets the road of really making deployments actually happen. And then also to bring it home with an actual demonstration, what we're calling Brownfield to IIoT in 30 minutes by Arlen Nipper. So we'll finish off with that and then move into a bunch of question and answer time at that point.

01:01
Don: I just wanna mention in terms of Inductive Automation, I think there's something certainly that we have pushed on as a company over the last, going on 15 years now. And that is instead of just kinda looking at what everyone else was doing in the industry, really focus on where we believed the industrial world was really heading, what were the trends and what should we be creating in the software as we look to where people need it to be and where we are going in the future, not stuck in the past. So I think it's pretty clear today that everyone can plainly see the importance of data and the way data is actually disrupting the business world, so that's one view of it. But frankly, I think it's having a really broad sweeping effect, one that I would, at least, comment on in terms of what Andy Grove, the late and former CEO and chairman of Intel, called a strategic inflection point. I think we're there in industry. It's really a point when the change is so powerful that it fundamentally alters the way business gets done. So I think what we're experiencing in the industrial world right now is a complete change in the order of things, and there's no place where a person will not be affected by it.

02:15
Don: It's certainly driven by a variety of technologies, disruptive technologies. Just listing a few of them right here, but if you bring those all together, I think chief among these would be what has become known over the last few years as the Industrial Internet of Things, or IIoT. Simple definition, IIoT, of course, is the application of IoT, or Internet of Things, to the manufacturing space, to the industrial world. It's also known as Industry 4.0. Really, IIoT is a network of intelligent computers and devices and sensors, and they collect and share huge amounts of data, and the goal of course is to increase the ability of management in organizations to make better decisions, run better organizations. It's gonna revolutionize manufacturing because it enables the acquisition and accessibility of far greater amounts of data and at far greater speeds.

03:11
Don: I think it's becoming abundantly clear that IIoT, or whatever acronym you choose to apply to it, is the way to go, but the real question is, how do you get there? One of the questions is, should OT, should Operations Technology, lead the way or should IT lead the way? I would think that if you just looked at conventional wisdom and you listened to a lot of the discussions of the consortia and the alliances and the groups getting together to talk about deployments of IIoT, you might say that IT should lead the way, it should be driven from the top down, 'cause IT's the place in organizations where a lot of enterprise activity is going on to date. But think about this, SCADA has already been doing IIoT for years before that term was even en vogue. For about 30 years, industries like Oil and Gas, also chemicals, pharmaceuticals and just manufacturing overall, have used sensors to improve their processes, basically integrating large amounts of data to arrive at better decision-making. I think that strongly suggests that OT should drive the implementation of IIoT, and it should not be the other way around.

04:23
Don: I think there's another argument in that direction, 'cause the goal here is to get more data, to do more with it, and to turn it into actionable information, and we need to take a little different approach than maybe what was taken in the past. Ultimately, I think we'll need a different architecture to really connect it all together and make it work. And to meet these new demands, we need to aggregate data up into the organization. Specifically, we need an automated process for delivering information from the sites to the corporate level. We don't want manually entered data. We need to get the data from our systems and send it in an accurate, standardized, efficient and secure fashion to make IIoT really work.

05:11
Don: If you think of companies and where they're starting and how they're doing this, or at least they're trying to, is if they try and attack the problem from the top down, they run into a paradox. The demand for a centralized enterprise system architecture, it's coming from the top, it's coming down, but it can't be built from the top down, it's gotta be built from the bottom up. Just think about it for a second. Just in simple analogy terms, have you ever seen a construction crew building a house from the top down? I mean it's absurd to even talk about that. No, you can't do that. You can't build anything good without a strong foundation. So to have a centralized system where you can gather up all of this plant data and do all of these great things you wanna do with it, you need an architecture underneath to support it all. In most companies now, there is a gap down at the plant level.

06:04
Don: At the top, they might assume that operations have all of this data and they can just get it from them and there's no problem with that, but they have not thought about where the data is actually coming from or who's verifying it. They haven't thought about the hundreds and hundreds of protocols, they haven't thought about all of the challenges of equipment, that some of it's new and some of it's 40 years old. So it's gonna be an Operations Technology level of expertise that gets the thinking going in the right direction. It's gonna require some careful planning and some investments of time and money to build it the right way and to build the foundation. The field and that plant become the pillars of a successful operation going forward. And in order to get that data in there, you have to connect the enterprise to make better decisions, you gotta have, obviously, this knowledge I'm talking about of Operations Technology and SCADA.

07:00
Don: So as we look at today and we go through some of the presentations today, I think the guiding thing is what we need is a practical, fully functional IIoT solution that combines proven operational technologies with the information technologies in a way that can actually bridge this gap between OT and IT. There's also a lot of hype about this IIoT, and hardly anyone really knows exactly where you start. We're not living in a greenfield world, we live in a Brownfield world, where do you start? How do you migrate? In some ways, it's causing some desperation, in some ways it's certainly causing some disillusionment. What we see happening is really the challenge of getting all this data is how do you confront what's very often called the... I've heard it written about and talked about, the four Vs of making IIoT a reality when you deal with large quantities of data? You have the volume of the data, you got the velocity of the data, you got the variety of the data, and you need to deal with the veracity of the data. You need to get to a single source of truth if you're ever gonna get to that fifth capital V of value. Everyone's trying to get value from IIoT, but if we don't handle the volume, the velocity, the variety and the veracity, we ain't gonna get value because you're not gonna get value if you get part of the data or you get it at the wrong time.

08:24
Don: I think in terms of looking at this and putting maybe a little perspective on it, what's happening is actually in IIoT, the environment is just... It's simply a replay of a very established pattern that's well depicted by what is commonly called the Gartner Hype Cycle. It goes like this. On the left column, the vertical axis of the chart represents expectations, the horizontal axis represents time, it divides up into five phases. You got the technology trigger on the left, the peak of inflated expectations in the hump in the middle there, the trough of disillusionment, then the gradual slope of enlightenment leading to what Gartner calls the plateau of productivity.

09:09
Don: The first phase is technology trigger, it includes the inception of the technology and the early adopters. Then it clicks into the second phase, peak of inflated expectations. This is where media hype gets really at a high pitch, reaches a crescendo, activity is really well beyond the early adopters, and then the negative press sets in. People start dealing with the reality of making it happen, and then they enter the trough of disillusionment, that slippery slide that reality has set in, you have less than 5% adoption, and we're starting to see second-generation products occur. Fourth phase is the slope of enlightenment. We see methodologies and best practices developing, we see third-generation products, now we're starting to see some out-of-the-box product sweeps developing to get to productivity. And then, as Gartner calls this, this phase, the plateau of productivity... Got about maybe 20%, maybe 30% of potential audience, they adopted the innovation.

10:10
Don: If you take all that hype and you break it down and evaporate it out, what we see that's left is a new architecture. And it's based on the practice of decoupling applications from an edge of network devices like you see in this diagram. But before jumping into that diagram, let's take a look and compare to that conventional system, if you will, conventional system architecture, where any application can interact with any device. When applications and devices are coupled, that creates problems. It creates problems with security, device resources, network resources, documentation, maintainability. It actually creates redundancies, and frankly, it's arcane. It's a mishmash architecture, it won't scale, it messes up bandwidth consumption, and it's hugely difficult to maintain, as I mentioned.

11:10
Don: So what's the mindset we're talking about? The mindset for the last 40 years has been connecting intelligent devices to applications using poll response protocols. That may solve the problem on day one, but what happens on day two? Somebody realizes there's more information in that device, but they can't get to it because the poll response protocol was programmed for a fixed data set on day one. As a result, in the extreme, over 90% of the valuable data gets stranded in the field. Let's compare that. Applications are decoupled from devices, device data gets published by exception to an MQTT broker. It can be Cloud or premise-based or hybrid. MQTT is a publish-subscribe protocol. It's very lightweight, bidirectional, and it enables message-oriented middleware architectures like you see here. The applications subscribe to the MQTT broker, the data is bidirectional. The MQTT provides stateful awareness, very critical.

12:23
Don: So you know the state of the network connection at all times, which is obvious to anyone in this... It's obviously vile in the industrial setting. So this architecture actually provides better security, better network utilization, it just has a whole host of other benefits. So if we take a look at IIoT, just quickly again in terms of the hype cycle, what are we faced with right now? Let's look at it again. Today, hype is at a maximum, and negative press has already kicked in. Things are on that slippery slope down toward the trough of disillusionment. The whole point, I think, of what we're trying to do, and you'll hear it talked about today, is we're talking about delivering IIoT now in real terms, Inductive Automation and the team that we're working with, frankly, as an IIoT solution that's really already over there to the right at the plateau of productivity.

13:16
Don: It can be an actual IIoT solution that's based on open standards and is proven in the real world and is proven in the real world today. And also, one I might add, that doesn't have to break the bank to actually make it be deployable. It's interesting when you start talking about hundreds of thousands of sensors and thousands of PLCs, RTUs, flow meters, whatever devices you wanna connect up, and you used a traditional licensing model, you are never gonna get that project out of the pending basket of some Chief Financial Officer in some organization. To make this really work, it has to be technologically possible and also economically feasible. And I think that, bringing back to this architecture, realizing the promise of IIoT can be realized right through this decoupled architecture.

14:05
Don: Now, what I wanna do, my task this morning was really to set the table for today's presentation we're digging into looking at case studies, both midstream and upstream, to actually have an opportunity to dig into some of the technologies. Now, if we're talking about getting information from the edge all the way to the enterprise so that data can provide insight for better decision-making, we have to look at the technology that's gonna get us there. When you deal with the edge, you're talking about, as I mentioned, maybe 40-year-old equipment, in some cases, hundreds of protocols, so we have to deal with data acquisition and the gateways that get us there, the implementation of a broker environment and the ability to reach the entire enterprise. So with that, I think what I'd like to do is turn it over to Kevin McClusky, he's Co-Director of Sales Engineering here at Inductive Automation, for something beyond the 30,000 foot level to dig in more to the technology and how we do it. And then we'll bridge into some case studies where people are actually doing it. With that, over to you, Kevin.

15:04
Kevin: Thanks, Don. Hello, everyone. So just a quick bit of background on me. So my name's Kevin McClusky, I am Co-Director of Sales Engineering here at Inductive Automation. I've been with the company about eight years, and I come from a technology background. And I'm a rubber meets the road type of person, so I'm sure you're sitting here wondering, "Okay, so... " Or thinking, "So that's great, we understand there's something that we need to do. How do we get there? What do we do? What does that architecture actually look like? And what's the connection from this concept that we've been talking about to an actual implementation?" So let me introduce the overall architecture, kind of an expanded view of what Don just talked about in terms of MQTT sitting in the middle of a number of different systems that are all connecting to each other.

16:03
Kevin: Right here, you can see that this is an architecture that has Ignition over on the right-hand side, and it has a plant floor, field devices, industrial applications, business applications all connected up through a central location. So through this slide, I'm introducing you to a couple of different concepts here. So Ignition, you've probably heard of Ignition already, you probably know who we are, Inductive Automation. Ignition's our software platform and so, that's showing that over on the right-hand side, and that's doing visualization, that's doing alarming, that's doing historian, it's doing logic processing and a variety of other things inside this specific architecture. If we're talking about the left-hand side here, and especially the bottom left, we're looking at field devices. So we're looking at RTUs, we're looking at flow computers, we're looking at PLCs, I guess that's shown on the upper side there... We're looking at any sort of field devices on the left.

17:07
Kevin: And then in the center, we have our message-oriented middleware. So what that means, MOM, message-oriented middleware, that means that you have messages that are coming to and from each one of these different points in this diagram, and then it's going through this middleware to send those messages back and forth. And that's going over MQTT. MQTT, Message Queuing Telemetry Transport, is a protocol that is a publish-subscribe protocol. You have all these different devices that are publishing, and then you have different devices, different systems, different endpoints that are subscribing as well. And all of those, essentially, are connected to each other through this type of methodology. It does mean that people who are listening, the subscribers, don't necessarily need to listen to everything that the devices are doing. Whoever's subscribing can choose what they subscribe to. Whoever's sending information out, it's such a lightweight protocol that they can send pretty much everything that they have and then leave it there, and anyone who actually cares about it can subscribe to it. So I'll circle back, I'll go into a little bit more depth on Ignition field devices and MQTT here in the next five minutes or so.

18:25
Kevin: So the Ignition platform, if you don't know about Ignition or you're being introduced to it for the first time in terms of an architecture, I'm sure you've heard of the Ignition platform before, but if you're being introduced to how it might connect up to something like this, and especially up to this new architecture, this is an architecture diagram that shows a little bit of that. So you have the Ignition gateway right there, which is our server piece of the software. You have the touch panels, you have designers, you connect up to databases, and then you're going to connect to devices. And if you're going through an IIoT architecture, if you're going through MQTT, then that Ignition gateway is going to be connected to an MQTT broker, which you can see right in the middle is shown inside that cloud. And that broker gives Ignition access to all of the different edge devices that are publishing information.

19:15
Kevin: It also gives access to any of the line of business applications that are connected up to that MQTT broker. So for example, big data's probably the best example there, but there are a variety of different examples of the types of things that can connect up to that. MQTT is a modern technology, and I'll talk a little bit more about MQTT in a second, but a lot of systems have access to MQTT, it's a broker for messages. And then MQTT, the edge devices are going to be sending that information up. Now, you can have Ignition sending information back to that broker as well to pass information through to those line of business applications in a variety of other ways to communicate over this too.

20:04
Kevin: I'm not really gonna talk much more about Ignition, so I think this is the best place for me to also mention that the reason that Ignition's an integral part of this architecture is really our licensing model. So we have a licensing model that says, we're not going to limit the number of tags, we're not going to limit the number of clients, we're not going to limit the number of pretty much anything inside Ignition. You run it on a server, you buy a license, you install it there, and then you have as many clients as the hardware will handle. So unlimited, completely, in terms of licensing for the clients, for the designers, and then, most importantly for this architecture, for the tags. If you have an MQTT broker that has data points for two million, three million, 10 million different data points, different tags that are out there, Ignition doesn't care. It can access all of those and you don't have to worry about having it licensed for different... Going from 1000 to 10,000 tags or something like that. It's all built into the platform.

21:09
Kevin: We're gonna have a couple of people who are showing off some projects, which are pretty cool projects, that all use a variety of different technologies that are... A number of them are largely based on IIoT. And just to give you... Just so that you have a little bit of framing, most of those are running Ignition. So the screens that you see when they're talking about how it's actually implemented there, they're gonna be talking about Ignition swarm. So if they mention Ignition, that's specifically what they're talking about. Ignition architecture right here, this gives you an idea of the modules that are inside Ignition.

21:50
Kevin: So if we take a look at that core module layer, you can see these are functionalities that are built into Ignition. So you install Ignition, you get a tag historian, vision reporting, a mobile module for iPhones, iPads, mobile devices, an alarm notification for enterprise alarming, sequential function charts if you wanna do logic inside Ignition, there's enterprise administration module. And each one of those different pieces of those different modules are pick and choose, so customers can choose which ones they want, which ones they don't want when they purchase Ignition. So any time you see an Ignition Gateway or anybody talks about it, they're generally talking about this type of functionality.

22:31
Kevin: Then the next piece here... And I'll go back a couple of slides. So over on the left-hand side, the field devices, if we talk about those specifically, these field devices, these edge devices right here, this is a small example of the types of edge devices that you can connect up to an architecture like this, and there are certain edge devices that talk IIoT natively. And the B+B SmartWorx, for example, those are devices that actually have some sensors and have physical wiring and they talk MQTT, they talk IIoT. And there are a variety of different devices that do connections to other devices that kinda do protocol conversions or allow you to take your existing infrastructure, your Brownfield infrastructure, and put it inside the MQTT IIoT type of infrastructure. One of those is Elecsys, as you see near the upper right there, it's the second, third one down. And we actually have Elecsys on this call as well, so they'll be talking a little bit about what they offer following up to my conversation right here.

23:42
Kevin: So great, we've got the edge devices, they're connected up to a central location. How do we go from those edge devices to something that is clean? This coupled applications and devices is the typical architecture that you have right now, PLCs connect up to SCADA, maybe SCADA forwards that data over to big data or ERP or MES. That MES makes some connections out to other IT systems, and it's all... Everything that you wanna do, you have to make a connection to some system that might connect to another system, or you need to make direct connections to systems that already have direct connections from other systems. So you can see on the left-hand side, you have lines and connections everywhere. On the right-hand side, that's cleaned up so much. So you have an MQTT broker in the middle that that's what you talk to in order to get your data, in order to communicate, in order to have that being passed back and forth.

24:40
Kevin: So this provides a number of advantages for the system overall, and if we go through some of the highlights of these benefits, one is that it decouples the devices from the applications. So if you have Ignition sitting over on the left-hand side, it's doing an application for all the data there. And we think that's great. Everyone should use Ignition, Ignition's fantastic. That said, if you have other applications that are over there that speak MQTT natively, you can connect them up to the MQTT broker. You don't have the application have that tight connection over to the device, which makes the device more accessible to everyone. It provides a superior OT solution because MQTT has a few benefits.

25:31
Kevin: That really helps with the network utilization, helps with a variety of other things. Arlen Nipper is going to be talking a little later in this presentation, and he'll be going over some more of those benefits as well. It's a single source of truth, you don't have two or three different systems all polling the same device with slightly different poll rates where that device might give back slightly different information, or worst case scenario, one of them has scaling off, things are wrong inside that communication, and then you have two different, completely different values and completely different reports that come from two different locations that all are supposed to be reporting the same thing. So if you have that data going through message-oriented middleware, you have a single source of truth, you're always going to get the same value for the same tag at the same time.

26:17
Kevin: Plug and play functionality, as soon as you have that broker set up, if you connect up a system to it, it's going to be able to see what's inside the system overall. A good example of this is if you have a broker that has 1000, 10,000, 100,000 tags inside it, you take Ignition and you point it at it, and you hit the save button. In about five minutes from the installation of Ignition, not even from configuring your project, but after you have it installed, you can go in, you can figure that, you point it at the server, you go into the designer, you can see everything that's inside that system without configuring a single tag, they just pop in. And it also eliminates cut-overs. So the idea behind this is a lot of systems you have to do... When you're moving from one version to another, when you're moving from one set to another, one type of system to another, you're going to have the device communication built into that system, and so all of the communication back and forth, if you take that system down, you're taking down that device communication.

27:22
Kevin: If you have message-oriented middleware, if you have an MQTT broker that's sitting there, that's doing the communication brokering, and you can have that set up in a redundant factor and you can have multiple different servers there if you need to, that is a completely separate section. So that takes the device communication out of the application server. So if you're updating that and if you're upgrading, it's just going to connect up to the same broker that exists right there. So cut-overs are a lot easier. You don't have to worry about your communication architecture and infrastructure going down if you just take down the system or you upgrade the system that's doing... That's using that data... So I'll turn it back over to you Don, that's the information that I had to present to everyone here. Hopefully that clears things up a bit in terms of architecture, and the next week we will be presenting are going to show off some of the things that are done with that architecture.

28:23
Don: Great, thanks Kevin. And I know... I see Tim Carr's name up here. He's Director of Sales with Elecsys Corporation, RediGate product line. I just wanna say one thing about Tim, or even about back to what was mentioned by Kevin, is that when you talk about equipment that may approach at the extremes, half a century old, it's hard to even say that, but I've heard stories like that to new. You delve in a Brownfield world and you've got hundreds of different protocols. The ability to get data into the enterprise, and the architecture that Kevin is describing is no small task. It can be sort of brushed over by folks trying to come from the top down. I think this is another reason to say we need to go from the bottom up. So if you really think about this, it's really a question of what is it really gonna take to get the data in there in volume? Because if you leave data stranded at the edge of the enterprise, you're not gonna get the value you're trying to get to, you won't get the insight. We're trying to go from edge to insight, we're gonna have very poor insight if we can't get that data. So with that, we wanna at least... Tim can least tell a little bit about what they're doing, how they do it at Elecsys to accomplish that. So, Tim?

29:37
Tim: Thank you, Don. I appreciate that. Yeah, I just wanna speak for just a couple of minutes about the core features of our edge devices, and then we'll hand it back over to the panelists for some real-world applications that Kevin had alluded to. First of all though, the RediGate industrial grade gateway serves as a data concentrator, a protocol converter, a communications management system as well as an added layer of field data security. Our report by exception, data management, opens up added bandwidth by sending up only the data that has changed. Basically, the elimination of stale data traffic reduces latency across the network giving operators more real-time control over their devices. If you're out there and you're considering integrating Ignition into your enterprise, here are a couple of features and benefits that you can take advantage of right out of the box with a RediGate line.

30:39
Tim: Basically, Elecsys offers over 60 industrial protocol drivers as well as store and forward functionality with Cirrus Link's Sparkplug B. MQTT initiated open VPN for remote access and ethernet IP, user definable tags to MQTT so that you can maintain your tag names from the field all the way up to Ignition. What Elecsys has done for the past 20 years in the Oil and Gas pipeline industry is reduce our client's bandwidth consumption and data latency by over 80%. With an MQTT middleware-oriented architecture, we have also given our customers the ability to run live data in parallel during critical migrations and SCADA cut-overs. That's basically the RediGate line in a nutshell. And with that Don, I'll hand it back over to you and we can talk about some of these real-world applications.

31:33
Don: Tim, thanks a lot. I appreciate you getting down to the real world of connectivity and access to various protocols because that gets overlooked, we're not building from the ground up, we're not building a solid foundation, and we're not getting acquisition of data solved and being frugal with bandwidth also solved. So thanks for that presentation. I think with what you just said, we'll go to the real world. Greg, as I introduce you, you represent the real world. How's that for a challenge for you Greg?

32:05
Greg: I don't think anybody has ever accused me of that. But go on.

32:05
Don: Greg Tink is the co-founder of Streamline Control Solutions. He possesses more than 20 years of management consulting experience, he's an accomplished technology professional with a diverse experience delivering business solutions across all verticals of the Oil and Gas industry. So with that I'll turn the controls over to you, Greg.

32:27
Greg: Thank you, Don, but that was a nice... Someone wrote something nice about me. That's really nice.

32:34
Don: It took a lot of work. It took a lot of work, Greg.

32:38
Greg: Yeah. That's right.

32:38
Don: Okay.

32:38
Greg: Yeah, thanks for saying I represent the real world as well. I appreciate that. So Streamline started back in 2011, we're a management consulting and solutions integration company based out of Calgary and Denver now. And we started with the vision of helping companies manage the collision between operational technology and OT and IT. So we really believe in this architecture and the benefits. Right from the beginning, we bought into MQTT and Ignition and the architecture as a whole, because we feel that companies need to think differently, and we feel that technology leadership is required in the industry, and the architecture gives us that ability to talk about that.

33:30
Greg: So today, I'm gonna talk about two case studies, which we're really excited about, both our Brownfield projects both require leadership and a different way of doing things, and integrating legacy technology. One is a midstream company, and you can see up on the screen already Plains Midstream, Plains Midstream Canada, and we started with them quite early along with Arlen Nipper, based on the conversation around, Okay, how do we look at network performance and how do we improve bringing data back and integrating that data into different systems, and the MQTT architecture was seen as a way to do that. So ultimately, and I'm paraphrasing over the few years sort of what their objective statements were, but they wanted to provide and Plains Midstream with a functional forward-looking operational messaging architecture and standards for controls and data gathering that align with growth opportunities of the enterprise and corporate direction.

34:41
Greg: Ultimately, they wanted to prove that the new MQTT-based architecture could help use technology to de-risk the business around leak detection and network performance, which Tim spoke to and I can, I have a bit of a story about that and the benefits there, manage costs, improve decision-making and access to data, ultimately turning data into knowledge quicker so that they could get it in their hands, trust that data and then do something with it on a bigger scale and improve asset management, and the focus around asset management. The legacy architecture that we were dealing with, specifically with Plains Midstream, centered around the OASyS SCADA system from Schneider Electric. And you can see on the little diagram here, it's very similar to what Kevin was presenting, and in fact, my next slide is a direct copy from one of the slides that Kevin was presenting. But the company and everybody around midstream operations with these big SCADA systems like OASyS are used to the idea of you put it in and then you leave it for five years and you don't really wanna innovate and do anything around it because it's so costly to upgrade and the term forklift upgrade comes up a lot, and people are used to that.

36:01
Greg: And your protocol drivers are directly built into SCADA, they're written with, again, for each upgrade, there's a lot of... Because there's some longer time between upgrades and you wanna leave these things alone, you don't really do anything with them, and so you do forget from upgrade to upgrade what was done, and so you end up doing a lot of re-work. The various assets and variety of legacy systems are tied into it at Plains Midstream because they've grown through acquisition, so as they grew, you know the different technologies that are out in the field, or there's a wide variety and there's really no reason why you would wanna go on and swap those out. It's gonna cost you a lot. So there's a lot of companies that are sort of stuck like that, where they wanna innovate, they wanna do different things, they wanna consider different technology, but because these things are so tightly coupled, you really can't scale and you can't really do anything about it.

37:03
Greg: So ultimately, what we implemented and what we're still implementing is a new architecture, and it's a little bit more than that. It's a new way of looking at data and moving data from the field, the arc... It is really all about the architecture. The Plains Midstream, when you're talking about performance, because we see the technology benefits and business benefits on the left-hand side. One of the benefits that sort of falls into both is the performance that Tim talked about, and the Elecsys' RediGates are a huge part of the solution and the architecture. When we turned it on for the first time in the first console, there were actually a few accusers. We were accused of faking the performance because the data that was coming back was coming back so quickly that they'd never seen it that way before.

38:01
Greg: The polling cycles that they were going through because of the size of their operation, they were waiting in some cases for 15 minutes to get that data back, and now we were substantially cutting that time down to under 10 seconds in some cases, so they immediately were looking at it and saying, "Well, that's not possible." Because they've never seen it before. Cirrus Link is... You know Arlen Nipper is gonna talk later on in the presentation here. Cirrus Link has provided expertise, but also the MQTT broker Chariot that they're using in the middle to move data around and it's tied directly into the Ignition system that... What they've been able to do already is in the Ignition systems, see what's happening on their network, the broad network, the PLCs, faster than they were before and faster than in a lot of cases, than the networking companies that support Plains Midstream are able to... Able to see it.

39:00
Greg: So they're uncovering things that they didn't even realize they were gonna uncover with that, and as well, the OASyS SCADA system is no longer the only SCADA or the only system that can get the data directly from the field devices. It becomes one of many different systems that can access that data, and it's no longer in a position where it becomes the middleware and the bottleneck, which SCADA systems were never meant to be. So it's been a really exciting journey with them, and we're expanding it to the next level where we're including terminals into the MQTT architecture and bringing data back from that, different types of asset groupings. And as well, expanding along to move to different types of IIoT scenarios where we just need to get that data back so that different types of groups in the corporate head office can see the data as well.

39:56
Don: Greg, thanks so much. I totally appreciate you getting down to a little bit of the real world. You were the voice of the real world, thank you. Now we've got another voice in a similar vein, which is Kyle. And Kyle Chase is Chief Technology Officer at Kymera Systems. I would say... I don't know, Kyle, I think I met you more than a decade ago. He was a very early adopter of even the legacy products here at Inductive Automation, and has become an extreme expert. He already came with a lot of expertise, he's added to that in terms of deployment of Ignition across a variety of industries. But I guess particularly up there in Alberta, there's a tremendous amount of Oil and Gas work that Kymera has done. I think we're gonna hear about an upstream example here and get a little different perspective on it. So with looking at upstream SCADA and this kind of an architecture, go ahead, Kyle Chase. Take it over.

40:52
Kyle: Thanks, Don. Yeah, I've been working with you guys for quite a while, it's always a pleasure. So the system that I'm gonna discuss today is for a growing upstream producer in Canada. They have assets in the Denver area as well as Saskatchewan, Alberta and BC, so Western Canada. So they've grown through acquisitions, they've been acquiring a bunch of different companies, which means they have a very diverse field of hardware and equipment. And they decided they wanted to create a corporate SCADA system a couple years ago, but they never really knew how to approach it. So when we came up to them and showed them what Ignition could do, kind of our plans for MQTT as well as what's coming down the pipe from Ignition in the future, they essentially jumped right on right away.

41:46
Kyle: So a few of the goals for the system, they want to bring all their data inside of their business network. All of their systems as they were, and as most of them still currently are, are separate silos of data. So they'll have a plant site that doesn't really have any network connectivity, and none of that data is getting shared inside of the corporate environment. We wanted to consolidate the different protocols into a single protocol. It just helps us integrate everything together into one standard platform. We wanted to build redundancy in the system, so we didn't want a point of failure from the cloud architecture. And we wanted to secure access to the remote assets in an easy-to-manage way, so we didn't wanna have to configure VPNs at every location and have to maintain those tunnels for day-to-day operations.

42:42
Kyle: So some of the challenges at the site that would prevent that from happening are essentially low bandwidth to site and troublesome networks. There's a lot of 3G cellular network connectivity, some of it's not very reliable, especially in Saskatchewan or some of the remote parts of Alberta. There's also a lack of communication infrastructure on-site, so there's no VPN connections back to a central server, there's no access control, there's none of that hardware on site. There's a mix of public and private IP addressing. So most of their sites are behind a Bell or Telus or Softel public IP address, which means that we can access it directly without using relays, and a big portion of some of their bigger fields are serial-based networks.

43:37
Kyle: So some of the ways that we felt we could achieve these goals, or the ways that we are achieving these goals, especially when it comes to consolidating different protocols, we're using the Elecsys hardware to provide a direct link from field devices to the MQTT broker. So we're using the Elecsys' RediGate to communicate to the sites using their... To devices using their native protocols, and we're converting that to MQTT and pushing it to our brokers. We're also using Ignition edge on a few sites that need an HMI as well to do roughly the same job. All of the data is being delivered to the broker and it's being delivered to the applications in their environment in a standard way. So currently, that's including Ignition and also a data mart application for moving data into their analytics packages. And we also realize that we can use open source reference designs to help standardize other applications. So one of those applications would be giving access to our vendors through Modbus, and so we're working on developing a gateway that will convert Modbus addressing back into MQTT for them to gain access using their existing tools.

44:55
Kyle: So when it comes to building and revamping the system, we're using multiple brokers to throw out messages between the field devices and the applications. That's built into how the whole architecture works. Each instance of Ignition runs from the same set of brokers, so they all have the same data coming in. And all of the business and client applications can be served from multiple Ignition servers about increasing and network-hosted devices. So we will be having some applications built into Ignition for integration into some of their other applications that currently don't support MQTT, and this just means that we can fire up a third or a fourth version of Ignition to do that job without having to increase our network traffic to the devices.

45:43
Kyle: So an example of that would be Ignition collecting, formatting and delivering data to FTP sites for some of their analytics packages to consume. We also have future plans to integrate with their business databases in moving data back and forth. And the other lines of business applications will integrate with, again, the brokers in the future without needing to have Ignition in the middle. So when it comes to securing the remote assets, again we're Elecsys' RediGate and Ignition edge, as well as SSL-encrypted tunnels to and from the brokers. This prevents us from needing a VPN for the flow of the messages from the site to the broker. Again, the connections are also made from the site to the server, not vice versa, which allows us to block off our inbound firewall on our network devices, and it's one less attack vector for hackers to get in on. And we can also establish VPN connections from the host that will send the traffic down to the device to tell the device to VPN back into our infrastructure. So if we do need network-level access to the site, we can accommodate that as well.

47:02
Kyle: So when it comes to the low bandwidth at the site, you guys have heard some of this already, MQTT will report by exception the data as it changes. We're also able to tune the threshold of when we wanna transmit, so that'll mean putting in dead bands, slowing our local polling. And the data is also being compressed between the edge device and the broker. Again, just another way to save a bit of data. When it comes to recovering from an outage, obviously all of these sites are stand-alone, the history is very important for some of the analytics that we're gonna be running. So there's new development in the Sparkplug B protocol, which Elecsys and Ignition edge both implement that allows for buffering of the history data. When the site reconnects to the broker, the history data is then transmitted to the broker, and then Ignition will consume those history messages to backfill its historian, which then allows us to get up-to-date reports, trends and historical records.

48:00
Kyle: So here's an example of the site, or one of the applications as it is now. So we've got about 250 sites, we can see the status. Red in this case means they shut the site down temporarily. Green means that it is active. And blue means we're having some form of intermittent communication issues. And here's just another instance of a screen that we created for them for them to see their information. And that's it for me.

48:30
Don: Kyle, thanks. I totally appreciate you taking the time between you and Greg to really at least take a look at bringing this down to the real world of how things are operating, where they're going, and what people are actually doing in the real world with this new architecture. So what I'm gonna do right now as I'm introducing you, Arlen, is let you take over and turn it over to you. Arlen Nipper was mentioned a couple of times in the process, and his company, Cirrus Link Solutions. He's President and CTO of Cirrus Link Solutions. He's the co-inventor of this pervasive computing technology we're talking about about MQTT. He's been an inventor over the last 40 years in the SCADA and embedded computing experience. He's been in the forefront of innovation and industrial M2M and IIoT industries. As I mentioned, he is co-inventor of MQTT. He's been a prominent figure in creating its rapid adoption and its use in the Oil and Gas industry.

49:34
Don: We appreciate the opportunity to work with you, Arlen, and with that, I think I'm... Arlen's gonna... Basically, the topic he's talking about is the Brownfield to IIoT presentation. I really thank you for being willing to participate. I've seen him talk about this evolution before. And Arlen will then take us into the opportunity to leave... We're trying to leave... We're leaving about 15, 20 minutes for Q&A. So if I don't believe I said it before, you have a questions tab on your... That you can look at in terms of your own computer, to your screen there. So please type in questions, we'll get to as many questions as we possibly can and get to them. If we don't get to them, we'll follow up afterwards and do that. So with that, Arlen Nipper.

50:19
Arlen: Thank you, Don, I appreciate that. Don, I'm assuming everybody can see my screen?

50:26
Don: Yes, we can see it just fine here.

50:28
Arlen: Okay, great. So everybody's already mentioned this, so one of the things that we're looking at... Again, like Don said, I've been doing SCADA since 1978, and I came out of Oklahoma State and went to work for Amoco really first, and I got put in a SCADA system in 1978. And ironically, 1978 is when Modbus came out. So here we were almost 40 years ago, and the SCADA system that I helped install looks very similar to the way that we put in SCADA systems today. Yeah, the equipment was a little bit older, it was a DEC PDP-11 that ran the SCADA host software, and we had 300 baud multi-drop phone lines, but hey, we were polling, using Modbus, we were getting the data back, we were putting that up on the screens. So here we are 40 years later, and we're pretty much still putting SCADA systems together the way that we did over the last 40 years. Cirrus Link, because of working with Inductive Automation and in the past doing a lot of work with MQTT, we did a lot of consulting with customers wanting to try to figure out how to migrate... To a new and more modern topology and technology.

51:50
Arlen: And we go in and we do due diligence with these customers, and you find out, and it's already been mentioned that they've acquired their SCADA systems. The SCADA system was put together by an engineering group that no longer exists, and they say, " Arlen, we wanna start migrating. But where do we start, how do we get started?" And one of the thoughts is that we make it difficult for stuff. We as an industry, we have new innovative ideas coming in, we have new computer engineering graduates, we have data scientists, we have electrical engineers, and they come into our industry and what do we do? We give them 40-year-old tools and say, "Good luck." And you start digging down into that and trying to figure out where to start?

52:36
Arlen: Protocols are complex, they're rigid, they're all. There are 4011 different versions of Modbus out there. Trying to get your hands on the development and debugging tools, sometimes it's almost impossible. So how do you take this and move it into... The concept that I've got now, is that if I have the graduating class, the 2017 computer engineers, data scientists, electrical engineers, you put them all in a room and they just graduated, and say, "Okay, how many of you guys know Allen Bradley df1 protocol? Raise your hands." How many have ever heard of Modbus? How many know how OPC UA works? But if you ask that same audience, "How many of you have a Raspberry Pi in your dorm room and you've got Node-RED running and you're already using MQTT to turn the lights on and off with?" I'll bet almost the entire room would raise their hand. So what we're talking about is how do we take modern viable technology and make it viable for real-time SCADA systems?

53:47
Arlen: So I tell them when I do this presentation, if you don't remember anything from the entire webinar today, try to remember these two things. If we are really going to get to true IIoT, the first thing we have to start thinking about and get a mindset is that we've got to come up with technologies that let us connect our devices to infrastructure, not to applications. It's already been said previously in this presentation, but we have to stop taking really intelligent devices and then connecting them to an application with a protocol, because again, day one is great, but going forward it tends to turn into a spaghetti network nightmare. And the second step is that if we do that, to get to the next step, as Don was saying in the evolution of arming the OT folks, the SCADA folks with the ability to push IIoT from the bottom up, well, we've got to be able to show that SCADA manager, that DCS manager, that factory floor automation manager that this solution is going to be superior, it's going to be faster, more scalable, more reliable, more durable than the existing legacy approach.

55:05
Arlen: Because if you can't show that what motivation do they have to move to a new technology? One of the things I will point out, just to set the field for where we're at in this migration is that every year, the Eclipse Software Foundation does a survey of 2000 IoT product developers across consumer, commercial and industrial market sectors, and one of the survey results is what messaging protocols do you use for IoT solutions? Now, if you consider that HTTP is great, CoAP is great, but those are stateless message protocols. You can't convince Joe, who's the SCADA manager that you're gonna control a valve with HTTP and say, "Well, most of the time the command will get there, some of the time we'll get the response back." No, we've got to use a stateful for protocol like MQTT. In the 2017 survey, MQTT now is up to 57%. So what we're talking about is applying technology that's broadly available and broadly known into the OT sector.

56:19
Arlen: So what is it? We've been talking about this, what's anatomy? How does this all work? So really, it's very simple. There's two components. You have to have an MQTT server, also notice MQTT broker and an MQTT client. Now, Kyle has already said this, is that the cool thing about MQTT is it's a remote originated connection. So the first thing that happens is that the MQTT client comes up and establishes a session with the MQTT server. Now the contract that he's got with that as he establishes that session, as he literally gives in the session establishment, gives the broker a death certificate. And what that means is that he says, "If I should die off of this TCP IP network, could you please deliver my death certificate for me to anyone that's interested. And that's how we get continuous state awareness with an MQTT SCADA infrastructure. Is that at all times an ignition? Ignition is watching for any death certificate that comes from any client, and that's the way that he manages the state of the edge of a network device as low as all the tags that are associated with those devices.

57:36
Arlen: Now, once that session has been established, a client can publish any information that he thinks somebody might be interested in. Doesn't matter who, he knows what he has, so he can publish all that information and he can subscribe to any information that he might be interested in. Now, at this point in time, we have an MQTT infrastructure, it's not very interesting, but it is an infrastructure. Now, it gets more interesting if you say, "Okay, well, let's add another client that could be ignition and he can subscribe to everything that's being published by this other client." But unlike a typical SCADA system, if that client goes away, it doesn't mean that the data stops flowing into the infrastructure. So this is what we're talking about, is connecting devices to infrastructure and then connecting applications to infrastructure, so that we start getting a real-time, yet loosely coupled SCADA system.

58:39
Arlen: Now, to do this, we did a specification called Sparkplug. And Sparkplug basically defines in this space how we're going to structure the MQTT topic name space, how we're going to publish that information in the context of we're targeting real-time control systems, so we know we're talking about things like PLC registers and flow computer reports and smart sensor process variables and things like that. And we pushed out the spec in June of last year and made it openly available and freely downloadable and referenced implementation code in C, Java, JavaScript, and Python and Node-RED. But by September of last year, there were almost a dozen OEMs that showed up at the ICC Conference in Folsom last year that had downloaded the specification, implemented it, and we were able to demo it connecting directly into Ignition.

59:45
Arlen: Now, what does this look like? Well, we said, "Let's try to get that migration strategy, that Brownfield to IoT solution, in 30 minutes." So we start with a very typical legacy infrastructure, and then we may add a problem. We have some stranded IO out here, we've always meant to get to this stranded IO but never could quite justify it. Now, what you do is go to Inductive Automation's downloads site, and you download the MQTT modules. So distributor, I've got a small MQTT server that's running actually on Ignition. MQTT engine is an MQTT client that, on the one side, understands the Sparkplug specification for how we're formatting these MQTT messages. And on the left side, it knows how to create and manage Ignition tags. And then there's MQTT transmission, which is kind of the reverse of that. MQTT transmission can see any existing OPC UA tags, memory tags, UDTs that might already be in an Ignition system, and it can publish that out to an MQTT infrastructure using the transmission's specification.

1:00:56
Arlen: So let's solve just one problem in a migration strategy, so let's pick up this isolated IO. So we go to one of the ecosystem partners. So we have this isolated IO out here, we never quite got to it, so we go to B+B SmartWorx and we get a SmartSwarm box, and it connects to industrial wireless sensors. When we configure that gateway, we point it at our MQTT server, and automatically all of the tags for all of the process variables, all of the network metrics for the wireless network, all of the metadata from the gateway automatically shows up in tag folders within Ignition. So that problem is solved. And maybe we just set and we run in this mode for a while, but we've got kind of a migration strategy going, so the next thing we might look at is that the customer goes, "Well, gee, Arlen, I've got a fairly expensive level transfer out here, it talks HART protocol, but the only thing I'm picking up is one of many process variables coming out the 4-20 milliamp loop to a PLC." But I know this tank level transmitter can give me the water cut at the bottom of the tank, I could pick that up. I know this transmitter has a temperature, so I could pick up the temperature of the product. I know that it knows when it's been recalibrated or if it has a sensor full.

1:02:20
Arlen: So we worked in conjunction with Magnetrol to build a gateway that knows the HART protocol on one side and can publish that MQTT. So now we can run these in parallel, have the 4-20 milliamp coming in off the PLC, having all of the digital information coming in automatically into Ignition, already into tags, or we might decide that that poll process can go away. Elecsys, as Tim was saying, we use Elecsys as a migration strategy. So their RediGate product can sit out here at the network as an end point, and we can maintain our OPC UA polling. But at the same time, on the right, this is the same Elecsys Gateway, but now it's setting locally and can poll the PLC or the RTU or the flow computer pretty much in real-time because it's a local connection, and then just publish the information it changes to MQTT.

1:03:21
Arlen: Now, I can run in parallel comparing my polling results with my MQTT, and when everything checks out 100%, then that poll crisis could go away. And to Greg's point, this is the strategy that we use in migration of planes midstream from pure poll response to MQTT with no loss of operational integrity. They never had to take their system down to do the migration. Another of the ecosystem partners is a company called Hilscher, and Hilscher has been in the Profinet, Ethernet/IP, CAN bus, EtherCAT chip business for many, many years. They've come out with a gateway now that can actually set behind the PLC network and in promiscuous mode actually pick up tags that are flowing back and forth on their industrial network and publish those tags in real-time using MQTT. So maybe that poll process goes away. Opto 22, pretty much dominant in the solar farm and wind farm automation sector. They have implemented Sparkplug and it will be on all of their new products going forward. That poll process could go away. Moxa... Again, pretty much any communication cabinet you open, you're gonna find some sort of Moxa router or switch or cellular gateway. And they do MQTT natively, so maybe that poll process goes away. And then finally, we've got the Ignition edge, which means that any viable and industrial embedded computer in the field can be a MQTT node on the network as well.

1:05:08
Arlen: So if we take that and let's kinda do a summary. Remember we had two points. Let's connect devices to infrastructure and let's provide a superior OT solution. So first thing is with this ecosystem and technology, let's decouple everything and let's add some security. To Kyle's point, the thing that's 180 degrees out of what we're used to, is that instead of a SCADA system or OPC UA servers setting here making outbound connections through firewalls, through all these different networks, we're establishing a remote originated connection. There's no open ports out here to even get to. So 50% of all of the concerns of cyber security are taken care of at that point and then we get to use best in-class TLS security apply to our TCP networks for encryption, authentication and then placing our MQTT servers inside of a DMZ, and we end up with a single point of access control.

1:06:17
Arlen: Now, notice that at this point in time, we have real-time information flowing into an infrastructure. There's no application that is driving that. So step number two is let's supply the superior OT solution, that's where we plug in Ignition. Now, notice that Ignition is not the primary application, is just a client. It's a very important client, but now we can do interesting things like have this notion of how primary and primary because the edge network devices are publishing all this information, so all of the clients get to see that. So we can have tests in Dev, we can have a primary SCADA system watching one part of the field, we can have another primary that's watching another part and they can all be watching all of that information in real time.

1:07:10
Arlen: So we could stop right here and go home, we provided the customer with a better SCADA system. But now since this decouple, we can start looking at interesting things like best-in-class applications that could plug in or unplug. We can start looking at providing that data to other line of business applications that come in and subscribe to the information. And then ultimately with the adoption of MQTT by pretty much every IT and software vendor out there, we're looking at being able to connect into Microsoft Azure, IoT Hub, IBM Bluemix, AWS IoT and ultimately get to this, the pundits promise and to Don's point, somewhat in the trot disillusionment of what can big data do for me, what can I do with predictive analytics and machine learning and big data?

1:08:05
Arlen: And so hopefully, at that point, we decoupled to the point where we can provide access to that. So having said all of that, let's actually see this working. Okay. The infrastructure that I've got here is, I've got Ignition running on Amazon EC2 instance, and since I'm logged into that right here and I have two Chariot MQTT servers also running on Amazon virtual machines in different availability zones. So very quickly, just so everybody can look at this is we can look at the modules that we have installed on our Ignition gateway, and these are all the modules that you get if you went to Ignition, downloaded it, installed it and then you'll notice down here that we've also downloaded, installed MQTT distributor and MQTT engine.

1:09:00
Arlen: Now, when we installed the engine module, we got a new configuration tab in Ignition. And we see here that we've told Ignition and it's MQTT engine component. We've told that you have three MQTT servers that you have access to, and we just configure them here. So here's our two MQTT servers sitting on Amazon, and here's a local MQTT server running locally on Ignition. So now let's open... We would launch your designer from here, I've already got it opened, we would launch it and then we would open the designer, so let's see what that looks like. So again, with the designer, it's very typical for everybody that's used Ignition out there to take a look at this, but now we start looking at, well, what did the MQTT engine provider?

1:09:50
Arlen: So if we look at the... Get this here. If we look at our tags, we see that we've got a new provider here called MQTT engine, and before we even start looking at the devices, what infrastructure information do we get from this? So remember, we had three MQTT servers defined, so when the MQTT engine starts up, it actually starts giving us a view of the infrastructure and how it's working. So from here, I'm already getting metrics of my MQTT servers. The latency is in milliseconds, and that's the latency between the MQTT servers that are running in Amazon and the Ignition gateway. So from there, we can start building out an infrastructure diagram that gives us metrics. So we can see how many devices we have, how many are online, how many are offline in real time.

1:10:57
Arlen: We can see the state of our MQTT infrastructure. So now we can go into the next part of the MQTT engine, and that's the edge nodes. And so I've got Elecsys, I've got pretty much the entire ecosystem of OEMs that are doing MQTT. So let's look at this Elecsys Director, which is actually sitting right in front of me on my desk and this is a RediGate and it's connected to Old RS232 Modbus PLC but it's polling at 100 milliseconds. But even though it's polling the bullions that fast, no data is going over the network until something changes. Now, this is a cellular connection connected up to Amazon, so I'm going to publish a command to turn off a relay and that status is tied back in through my 10001. So I turn off that relay and turn that one off and that one off. You can see that, pretty much, I've got what looks like hardwired real-time performance but yet I'm going over cellular up to cloud, over to Ignition and back down to the design and just running here on my desktop.

1:12:11
Arlen: Now, because of the DAS certificates and the way that we've designed MQTT implementation, if I reach over here and unplug the power to that PLC, just like you were polling, all the tags go stale, we know when the device failed. And then if I plug it back in, the director's gonna poll for all those registers and when it has them all, it's gonna republish them. Now, notice that I unplugged the PLC, so the relays went off. Let's turn them back on.

1:12:46
Arlen: Now, again, I've got folders here for hard transmitters, for Hilscher, I've got an Inductive Automation edge running on a Raspberry Pi, I have the Moxa group here but let's go in to see how this actually happens if we create a device. So what we're gonna do is... As you can imagine, for the large customers like Phillips 66 and Plains Midstream, it was good to have the ability to show people what this would look like at scale. So we developed an application called a swarm simulator and this accurately simulates edge of network devices in the field with PLCs so that we can start looking at what the performance looks like at scale and how Ignition can automatically learn the infrastructure.

1:13:35
Arlen: So if you look at my browser over here, you'll notice that there's no folders here called swarm, so we're gonna go to our device simulator and we're literally gonna go out in the field and we're gonna pretend we just turn on an edge of network device with two PLCs connected to it. We just toggle this state. It's gone online. It's connected to MQTT server 1. So, now, let's go over, "How did Ignition know that?" It connected into the broker, it published a birth certificate. Now, if I refresh my tag folder, look, I have a new folder here. It's got a new edge of network device with two PLCs with all of their Modbus registers updating once every five seconds. That was all automatically learned as soon as that device connected.

1:14:25
Arlen: So, again, because tags are our friend in Ignition, we've designed a way to look at the metrics for every learning device. It creates another green square on this dashboard. So what I'm gonna do now is, "How long would it take us to learn 200 additional PLCs?" So we're gonna do that right now. So we're gonna see how long it takes Ignition to learn 200 PLCs, have them all established, have all of the tags and everything's available in Ignition for start designing with and going to all of our dashboards, and our historian, and our business applications.

1:15:11
Arlen: And so now, 10 seconds later, let's go back to our tag browser and, again, we only had one device, one edge of the network node, so let's refresh the swarm directory. Now, we have 100 and each one of those has two PLSs updating all this information once every five seconds. Now, depending on your industry, that five seconds, you may go, "Well, gee, that's pretty slow. How about 250 milliseconds?" So, again, with the simulator, we can come in here and say, "We'll change our publish period," and we'll change it to 250 milliseconds. So, now, we have 200 PLCs with all of our tags learned and all of every tag, every Modbus tag, here is updating four times a second. But if we go back to the real Elecsys device connected to the PLC, did that slow down our commands with all of that traffic coming in? No, it didn't. Now, you can look at this... And let's go back to our topology tree. You can see here that 108 of those nodes are all connected to MQTT server 1. That's kind of bad. What would happen if that went down? So I'm logged into the virtual machine that's running this MQTT server and I'm gonna kill that server. And when I do, how long is it gonna take Ignition to realize, change these squares from green to gray and then try to recover the system?

1:16:45
Arlen: So I'm gonna kill that server right now. We've learned all of that and now, because we're using message-oriented middleware, we can go back to our tree and see that we... Real-time, we see the state of our broker and real-time, we see all of the edge of network devices are coming back on another available broker. Now, we bring back our infrastructure. That updates in real-time in Ignition. We're back to... We have our redundant brokers, everybody's recovered and we're back up and running. So with that, Don... That's a real world demo and I'm sure there's a lot of questions there and we can get to those but, Don, I'll let you take it back from there.

1:17:35
Kevin: Thank you, Arlen. This is Kevin McClusky, for a second, from Inductive Automation. I thought I'd actually start out with a couple of questions that are directed over to you, Arlen, so I'll just pass this one first. By the way, everyone who's on the call, please submit some more questions. We're about to open up the Q&A time here. But this first question, to Arlen, "Magnetrol developed the HART gateway. Do you know of anyone working on something similar for Foundation Fieldbus devices to gather non-process data, like diagnostics?"

1:18:15
Arlen: No, I don't. We do work with the Fieldcomm Group. Again, I was very... The reason we kinda picked HART, is that I was actually HART communications board of directors for eight years. There're 45 million HART devices out there and I think less than 1% of them are connected in providing information. But no, I don't know if anybody is doing a Foundation Fieldbus gateway but Cirrus Link would. If anyone has any recommendations, please get a hold of me and I will contact them.

1:18:54
Don: Thanks, Arlen. I really appreciate this. We're actually gonna officially open up the Q&A session right here. I know Kevin just did one of the questions, so thanks to all of the presenters for presentations now. As we look at the evolution here.There's Q&A at the end of the presentation, I guess. Okay. That other question, Arlen. It happens to be addressed directly to you and I also wanna reiterate to all of our attendees that we've got a few minutes left. We'll probably end early. We're not gonna take more time for questions, but there's a question directed to Arlen. Magnetrol developed the HART gateway. Do you know of anyone working on something similar...

1:19:39
Kevin: Actually, we already did that.

1:19:41
Don: That's the question you did. Okay. Good. Two questions here. This is a two-part question, Arlen. Do you have a recommended cloud service? Part number one. Part number two, does data flow from a device to ignition to the cloud is the data going from the device to the cloud and then picked up via ignition? That's a guy named... Coby has that question. I'm seeing other questions coming in. I do wanna reiterate that now is the time. If you have questions, go ahead and enter in. We'll get to as many as we possibly can over the next 10 or 15 minutes. Go ahead, Arlen.

1:20:15
Arlen: To answer the question, the devices are connected directly to the MQTT servers in the cloud or on premise and ignition is connected to those. If you remember my topology diagram, all of the devices are decoupled. They're only connecting to infrastructure.

1:20:42
Don: Thanks, Arlen. We got another question here from Adam. This can go to anybody here so Greg, or Kyle, Tim, to Kevin. What is the best way to get an alert through ignition alarming when a node device goes down, is there anything already in place figured for all nodes, current, and future?

1:21:04
Don: I'll let Kevin answer that. Anyone else can add into it too.

1:21:10
Kevin: Sure. We have quality codes on all of the different tags that are inside an ignition, and you can certainly do alarming based on any quality code that's coming in. Those quality codes are going to be available and you can set up a specific tag and specific alarms when that quality changes. In addition to that, there are some other tags. You could do some alerts when the connected device count changes from the MQTT engine module. You could do some alerts just based on the other statuses that you get through the tags there as well.

1:21:45
Don: Thanks, Kevin. Anyone else wanna add anything else to that?

1:21:52
Arlen: All of the metrics that I was using to do the sparkle chart were exactly what Kevin was saying. Those are diagnostics that every time MQTT engine sees another device, it creates a whole list of tag metrics just to monitor that. Again, I think Greg alluded to it that we're actually able to see network problems that at Plains Midstream before the network guys do.

1:22:23
Don: Thanks, Arlen. I actually have a question here from Manny. I just wanna comment, Manny, I know you were here in Sacramento recently, but I happen to know you live in India which means it's the middle of the night there and you're actually on our webinar. I think you're gonna get the persistence award, Manny, when I talk to you next. With that being said, unless he happens to be in California right now. Arlen, this is from Manny, if a customer in the Oil and Gas downstream area have regional terminals from where distribution takes place and they have Honeywell automation, what are the areas we can introduce IoT. How do we get started? How do we introduce IoT?

1:23:07
Arlen: When he says Honeywell, I mean, Honeywell... I'm assuming that's probably that's probably something like a TVC3000 type DCS System. There are many areas and to Greg's part, we're actually looking at this for Plains Midstream as well, is going in and starting picking up those pieces of equipment and putting in appropriate edge of network or ignition edge components out there in the plant so that we can start getting a view of that information outside of these silos of implementation. I would love to talk to him further and we can get a strategy for putting a migration strategy together.

1:23:49
Greg: I can speak to that a little bit too. There's water, wells, for wastewater, and tank monitoring, and engine monitoring that we're working with. We're also looking at putting inexpensive devices on fuel like for remote fueling stations and propelling which we've done. Flaring, where you have some sort of sensor required that might be helpful. A big thing we're looking at right now is a series of... As far as a solution goes is bringing together some truck ticketing and concepts so that you know with more accuracy what possible or over short problems are on delivering through trucks through terminals. It's virtually anywhere where you have information or maybe a PLC or even the lack of measurement right now and the data is either orphaned or you're just not measuring it. Those are good cases for low-hanging fruit where you can bring data back and maybe you don't need it in the SCADA system, maybe you need it for analytics, and so you can shoot it right off into the cloud as well. And to Arlen's point, too, yeah, I'd love to talk further about some of those ideas.

1:25:20
Don: Thanks, Greg. Here's what I think I'll let you maybe comment on, Kevin. What's the status of Inductive making a Cloud version of Ignition for multi-tenant hosting?

1:25:29
Kevin: We actually have quite a few customers who are doing multi-tenant hosting in the Cloud today. So the way that that works is you take the Ignition installer, you get a Cloud server, you install it on there. Windows, Linux, Mac, doesn't really matter which. You buy a license from us and then we have a conversation, there's this specific Cloud hosting agreement, but we don't actually charge you anymore for that right now, to do that Cloud hosting. And so we have a wide variety of integrators and users who are all doing Cloud hosting, multi-tenant Cloud hosting with Ignition today.

1:26:06
Don: Good, thank you. Go ahead.

1:26:08
Greg: And the cool thing is too, if you look at Plains Midstream, it was on the Cloud for a while and then they decided to go on premise and that worked out really well. We're gonna have to have multiple instances set-up, and you can spin these things up quickly to show what can be done really quickly as a proof of concept, and it works really, really well.

1:26:32
Don: That's great. That's good. Thank you. And just as a... I have a question for you, I'm gonna throw it to you, Kyle, to give you a chance to comment 'cause I know that you have introduced Ignition, this new architecture, a new approach to a number of customers. I just wondered if you might share just a thought or two, when you're introducing something for the first time, how do you approach it? What usually enters into it? Is it really just someone trying to solve a pain point? We're talking about the ability to deliver it right now, but you're also talking about people aren't gonna eat the whole element in one bite. How do you migrate in terms of how you approach talking to people about this?

1:27:12
Kyle: Yeah. There's usually two different routes. If the company knows they wanna go this route, then we go straight into the architecture and design phase. But if we're going in to a company that's really not sure what they wanna do yet, we'll make sure we find a pain point or a chink in the armor, as we call it, especially if they have a large existing SCADA system. And from that point in time, we'll see, "How can we solve that problem with Ignition? How can you solve that with MQTT? How can we solve... "Using the tools that we have, we've got databases, security, all that stuff that fits into this architecture. From that point in time, we solve one problem. And then once we solve one problem, that they can do with their other SCADA systems or their other applications, then all of a sudden, the ideas start flowing, they'll have two or three more things they wanna solve. The next thing you know, all the development is going into Ignition and nothing's really going into their existing SCADA system. So that's kind of how we've done in the past. It's such a different paradigm over old SCADA that I don't know why anyone would ever want to develop a new application using old SCADA methodologies.

1:28:25
Don: Thanks, Kyle. Arlen, this is a nudge from the earlier answer that you gave. It says, "Arlen did not say if there was a preferred Cloud service." I don't know if you wanna say if there's a recommended preferred Cloud service, or if it doesn't matter, or any other additions to that last answer you gave a bit ago.

1:28:45
Arlen: We have been running across all three. We're running on AWS probably for the longest, but we have instances in Azure, we have instances in IBM Bluemix. We don't have one in Google Cloud Platform yet. I will have to say, the whole 18 months that we ran three Ignition gateways and six MQTT servers on Amazon doing proof of solution for Plains Midstream, that was what just blew them away, we had 100% availability. I just see it as it's gonna be inevitable that maybe not multi-tenant but I think they're definitely all looking at it. And so really, I don't think there is a preferred one. It's probably who do you deal with? If you're a Microsoft shop, probably Azure. If you like Amazon, probably Amazon. And if you have... And IBM. They're all very viable.

1:29:44
Don: Thanks. Here's another question about security. "Do you use SSL Security for the MQTT traffic for your current customers? Does this add much complexity or network overhead?" Since it says current customers, I guess any of you can respond to that. Whoever wants to go first.

1:30:12
Arlen: Well, Plains Midstream rolled out day one using SSL. That's over a VSAT system. Once the session is established, we don't see that much more overhead. I don't think you really have a choice. You've got to provide that level of security. But yes, everybody that... All of the new projects are going out or just out of the box they're using TLS Security.

1:30:38
Greg: Yeah, I would agree. And I actually can't think of any sort of performance hits because of that at all. I think we're past with the types of bandwidth we can get in a lot of cases. And the fact that we get so efficient using the MQTT on using and managing bandwidth, I think it's in fact not an issue. It's almost the reverse. It becomes simpler and more efficient.

1:31:09
Don: Great. Thanks.

1:31:10
Kyle: Yeah, I would agree. I mean, we're using SSL encryption between our broker and our devices as well. It was super simple to turn on. I mean, we're using public CAs on our certificates, so our deployment might be a little bit easier than using an internal CA, but everything was without a hitch on our side.

1:31:33
Arlen: And to that point, Kyle, Plains Midstream has an internal certificate authority, and that actually... They put in the certificate authority and it's all on prem and it's all worked flawlessly.

1:31:49
Don: Thanks. One thing, there's a couple of more questions in the queue here, and I'm gonna give everyone an opportunity to sorta say a final two cents worth, but before we do, because part of the reason for doing this was to give some real world examples of what innovators are doing like Streamline and like Kymera, and also, what is happening in the architecting and the background of the technology from Kevin and Tim and from Arlen. We're gonna have a live event. It's gonna be in Houston. Here's a slide that tells you about it, and so before I go to let anybody make, I'm gonna ask each of you to make any final comments you may wanna make. If you don't have any, that's fine, but really the goal of our attendees today was to get some takeaways for how IoT is actually playing out in the real world. Particularly with the folks on Oil and Gas in terms of today's case studies, so if you have any final words for people, how they can continue on this journey, it's a blend of audience today from integrators and end users.

1:32:55
Don: If anyone's interested in someone from their team or themselves attending a live event where we're gonna be able to dig in, we'll have some customers actually coming in and speaking. It's gonna be August 17th at the Marriott Marquis in Houston, and more information will be available, but here's the sort of a save the date for you. With that, as we're sort of getting close to wrapping up, I'm gonna ask each of you if you have any final things you wanna say about it. I'll start with you, Tim, and then we'll just kind of wrap up and finish off our day. So with that, any final comments at all from you, Tim?

1:33:28
Tim: Yeah, Don, thank you. Yeah, one of the things that I just wanted to point out or reiterate is that to do this proof of concept, to enter into this type of architecture, you don't have to tear down what you currently have, and so that's what makes it such a nice topology to test. So again, we're all out here and these integrators are willing to help you, and I love to hear from anyone about getting this type of system set up in there to run in parallel with their current system.

1:34:02
Don: Thanks, Tim. Thanks, Tim. Kyle, how about yourself? Any final thoughts Kyle? If you're on.

1:34:13
Kyle: Sorry, I was muted.

1:34:15
Don: Unmute yourself. I'm sure what you said was absolutely brilliant, but you're gonna have to say it again.

1:34:20
Kyle: As I was just saying, I've been doing this for about 12 years, building wider data networks, that's about 138 years less than Arlen. But going back on all the systems we've ever built, typical response systems, I just don't see any reason to ever go back to that methodology with MQDTA and current technologies. We can retrofit Brownfield, it helps us integrate with Enterprise, increases security, it eases deployment and logistics. It's definitely the way that we're pushing not only for upstream, but also for downstream solutions at the flat level as well. So it's definitely the technology that we are using moving forward.

1:35:05
Don: Thanks. Thanks, Kyle. Greg, your thoughts.

1:35:09
Greg: Yeah, I guess my one final comment, taking it back to our approach, and one of the things that it's exciting to actually see is we can go from the strategy and objectives and how to align the tactical work back to the strategy, and we can do it really quickly and start showing returns very quickly with this architecture. And it's exciting because we're in a position where we're leading and allowing companies to innovate, so it's things like this that I think we get excited about because we feel like we're right in the center of moving companies forward in a new direction, as opposed to, hey, let's just do it the old way and see if we can make it work. And I think companies, like I said before, really need to start moving in that direction because oil prices are never coming back to where they were before.

1:36:06
Don: Thanks Greg, and I would concur on that. I think one of the things that's really exciting with Inductive Automation is that we feel like we're right in the center of a lot of transformations going on. Steve, our CEO, was giving a little presentation to some of our new staff the other day, and they were asking him in terms of why he does it, whatever, and one of the things he said, which is truly how he thinks, he said, "I'm having more fun that I've ever had in my life, this is fun. We're bringing solutions, a new way of doing things, and really helping people solve problems, and I think there isn't any reason to go back." It's really just helping people. How do they migrate their thinking as they migrate their technology and migrate their teams to approach this view a little bit differently. Kevin, your final thoughts?

1:36:52
Kevin: Sure, yeah, so coming from a perspective of working at Inductive Automation here for the last eight years and working in the industry for quite a while, this transformation that we're seeing in terms of how companies work and in terms of, largely, in terms of the IT systems and the OT systems coming together. It's not going anywhere, it's just moving forward and it's marching forward, and it's gonna be marching forward with or without us, right. So regardless of what technology is being implemented, there are certain companies and certain integrators and certain end users who are going to get on board, and there are certain users who are going to be using old technology until they're kind of pulled to the lawn kicking and screaming. And we've seen this with quite a few technology transformations in the past, but this is happening and it's happening right now, and it's real, and it's interesting with all the conversations I have with IT folks, how much they want this and how much business.

1:38:00
Kevin: People who are in charge of businesses and people who are in charge of organizations are really pushing for getting this data, getting it in and getting it in today. And with all my experience, I really feel like what we're presenting here, this solution is a fantastic solution today to bring this in. Whereas, pretty much everything else out there is... It's pretty difficult to implement. This is easy, it's available right now, and it's all standard technologies.

1:38:31
Don: Thanks, Kevin. Just before I turn it over to you Arlen and to give some final thoughts from yours, I see a note here from Charlie Hendrickson. So I'll just make sure we adjust your question too Charlie and welcome. Is there a good resource to find business applications that natively support or through means of a plug in the MQTT protocol? So I'm asking you to sort of wrap up Arlen, but you might wanna at least answer that question too, as far as a good resource. And also to other people's questions here, yes, their presentation will be made available in recorded version. You have contact information of all of the speakers, right on your screen right now. There's a couple of other questions about getting the individual Ignition Demo Project. We'll have the full recording available for folks and you can contact any of the people on the screen if you have any more detailed questions. With that, Arlen, your final thoughts.

1:39:26
Arlen: Okay. Well, first to answer the question, the Eclipse Software Foundation, so if you just Google Eclipse IoT, there's a huge amount of MQTT resources there. If you had any application and your IT guys said, "Hey, I wanna plug in and watch your pressures, or I wanna get the reports from your flow computers," then literally you could go to our website, Cirrus-Link.com, and you could go, and download the C reference implementation code or Java, or JavaScript, or Python, and have that client up and running in probably half a day. And then of course, then there's all kinds of exciting stuff that we're gonna be talking about in September about what Amazon is doing for this tooling, what Microsoft is doing for this tooling. So I think the plethora of applications that are going to plug into MQTT and made natively aware of that are gonna be... It is taking off. Like Kevin said, "There's no stopping it now." So in the final wrap up, Don, you kinda stole my thunder.

1:40:40
Don: Sorry.

1:40:41
Arlen: That is the comment that I've heard from customers and from integrators, and from the OEM providers, like Benson Hougland at Opto 22, he said, "You know Arlen, you guys are making this market. You're making it fun again. Now, the only problem I had with it is that it's been almost 20 years ago since I kinda co-invented MQTT, but then I just kinda had to wait for 18 years for Inductive Automation to come along." So, that was the only disappointing part.

1:41:13
Don: Hey, you gotta realize those people you're talking about were in high school back then.

1:41:19
Arlen: And again, just the amount of press. The fact that we've been able to write articles for Control Engineering, we have a quarterly webinar. For anybody that's interested, Control Engineering has IIoT for engineers and I'm part of that quarterly webinar where we just talk about IIoT technologies, and what's coming. People prototyping this stuff on raspberry pies and being able to get their hands on the technology. That's what's exciting to me is we're enabling a whole generation l ready know how this stuff works. Imagine how they're gonna be able to innovate if they can go to a company that embraces this technology.

1:42:07
Don: Yeah. That is what makes it exciting. So listen, Arlen, Kyle, Greg, Jim, Kevin, thanks so much. Thanks so much to all of our attendees. If you have other questions, you have contact information. Part of the reason for doing this and actually extending it for an hour and 50 minutes here, was we realized we wanted to talk about customers in one day, in a variety of viewpoints, and get a chance to take a deeper dive. So hopefully, we've accomplished that. We appreciate your time. I know it's a valuable time you invested, and hopefully some of the information will be useful to you as you progress forward on this journey. With that, thanks everyone for attending and we are concluded.