How Ignition is Enabling the Future of Oil & Gas

Speakers

Alainia Spencer

SCADA Lead Architect

Techneaux Technology

Geoff Daily

Chief Revenue Officer

Bifrost MetaSCADA

The oil & gas industry relies on SCADA for all its major production activities. But oil & gas companies often have large-scale, complex requirements that require unique solutions to not only monitor the field, but also integrate that data throughout the enterprise. Attend this session to learn how Ignition is meeting the unique requirements of oil & gas companies with Techneaux and Bifrost.

Transcript: 

00:00
Chaz Cooper: Hello, I'm Chaz Cooper from Inductive Automation. I'm a Software Support Engineer, and today I'm gonna be introducing Alainia Spencer and Geoff Daily. They are gonna be presenting how Ignition is enabling the future of oil and gas. Alainia Spencer is a Lead SCADA Architect with more than 15 years of experience in the oil and gas industry, known for her creative approach to system design and integration. Alainia possesses strong problem-solving skills lead and leads large-scale projects in teams focusing on enhanced implementation of advanced SCADA solutions for real-time monitoring and control. She ensures that all solutions meet technical requirements and aligns with strategic business goals. And she's led implementations of some of the most advanced Ignition implementations of oil and gas in the world.

00:53
Chaz Cooper: Geoff Daily is the co-owner and Chief Revenue Officer of Bifrost MetaSCADA, which delivers the world's first MetaSCADA solution that supercharges SCADA data. Geoff has been involved with numbers of technology startups across a variety of industries for 15 years. His expertise is helping define and develop the social infrastructure that is needed to spur the adoption and use of innovative technologies, which includes people, processes, and perspectives. Please welcome Alainia and Geoff.

01:29
Geoff Daily: You can keep applauding. It's okay. Sorry, sorry, I just couldn't help myself. Thank you all for being here today. We've almost made it to the end. I think of another great Ignition community conference. Very excited to talk about the intersection of Ignition and oil and gas. I think really there's an opportunity here that the industry is waking up to. Before we go a little further in talking about the presentation, to tell you a little bit more about Techneaux, if you're not familiar with us, we've been in business since 2010. We're up to about 100, 160, 170. We are growing kind of fast at the moment, so it's hard to keep track of it. Our largest group is what we believe to be the most experienced oil and gas SCADA integrator in the country. We've got about 60 people in that. We have a group that does industrial controls, a group that does remote well site communication, a group that does IT, and my group, which is actually Bifrost, not Bio-frost; I'm just gonna clarify that. It's a reference to the Norse mythology, the rainbow bridge that connects all the worlds.

02:20
Geoff Daily: So what are we doing here today? Let me tell you. So we believe the industry is facing a choice over the next few years, either refresh your old SCADA system or build a new SCADA system. I also just realized I probably should have used the red pill blue pill image here instead, but that's okay, another time. Modern SCADA offers a lot of potential for oil and gas to improve performance, ease of use, repeatability, expandability, and data integrity. All of these are particularly important in the oil and gas space. From a performance and ease of use state, a lot of oil and gas companies right now, their SCADA systems are not able to keep up with the pace of business. And so the people who are doing their jobs, are having to click buttons and wait for multiple minutes in order to actually get the information they need.

03:00
Geoff Daily: Repeatability and expandability, it's hard to imagine an industry where that's more important because of how fluid oil and gas is. The acquisitions of this field being sold, bought and sold to that field, this company being bought and sold to that company, the ability to have a SCADA system that can grow with your company as it evolves is extremely important as well. And data integrity. I mean, oil and gas produces probably about as much data as anyone and also has some of the most challenges with getting good data because you're dealing with lots of different devices. You're dealing with comms issues in the fields. You're dealing with SCADA issues, IT issues. It really becomes a challenge to get that data integrity that you need in order for all your downstream data consumers to be able to actually get quality analytics.

03:39
Geoff Daily: Because in order to get quality analytics, you need quality data in the first place. But modern SCADA isn't easy. Let's not kid ourselves here. This is not a plug-and-play type of industry. What we're talking about here is requiring a SCADA... An oil and gas SCADA initiative requires not just the right tools, but the right people with the right experience, the right approach, buy-in from all the stakeholders, and quite frankly, a little bit of patience, because this is not something that gets done overnight on that front. So today for our presentation, rather than just talking in abstracts, we wanted to go ahead and focus our presentation on a particular case study so that we can show you some real-world examples of some of the things that are possible through the combination of Ignition, Techneaux, and Bifrost.

04:24
Geoff Daily: So this case study is gonna deal with a large, multi-billion dollar midstream operator. They had an old SCADA system that they needed to upgrade, and they wanted a high-performance Ignition system, not just a regular old Ignition, but one that really was kind of pushing the envelope. They had a lot of complex requirements, being a large, sophisticated organization. And they had a lot of high demands for reliability because they were really trying to build a new data infrastructure that will allow them to move into the next 10–20 years of their organization. And just to give you a sense of the scale, we're talking half a million tags, hundreds of screens, dozens of clients, thousands of alarms, hundreds of devices. This project was what, like 12 integrators, I believe, on the Techneaux team over a year. We believe it's one of the most sophisticated Ignition deployments in oil and gas that has happened to date. So it's something we're really quite proud of.

05:13
Geoff Daily: So to start with, we're gonna talk about five main categories. Migration, standardization, alarms, integration, and I just, and I just blanked on the other... We'll see it here momentarily, my apologies. So starting with migration, before you can even get started in getting Ignition set up in an oil and gas environment, oil and gas SCADA systems are almost never greenfield. You're not starting from nothing. You have an existing system that you're having to build a new system alongside of. And just getting that data from the old system in the new system is not easy. Legacy SCADA systems are notorious for not being great at getting data out of the system at all, and certainly not at any sort of high rate of volume with high data integrity.

05:54
Geoff Daily: Oil industry data in particular is very rarely standardized. So you're having a kind of, even if you can move the data, you got a big mess; you're having to kind of work through 'cause you don't want to take a bunch of messy data and then throw it into a new system and still have a bunch of messy data on it. And as a comment I made earlier about the need to be able to stand up a system while another system is running, oftentimes you have to actually be able to run these critical systems in parallel so that you can make sure your new system is working before you turn the old system off. And being able to run those things in parallel in a way that keeps everything in sync is not a minor challenge.

06:28
Geoff Daily: That's why for the Bifrost component to this, we have a managed ETL solution called Flow. We call it Industrial Strength ETL for Signet Ignition. It's basically high-performance middleware with integrated monitoring and support. And we used this solution to do the migration from Signet to Ignition and also the integrations on the other side. So I'll come back to the stage in a little bit to talk about the thing that we're really good at, which is the integrations. The migration was just something that we did to kind of help the project move along. So with that, I'm gonna hand the stage over to Alainia. I believe she's arguably one of the best oil and gas Ignition experts in the country. And she's gonna talk you through some of the really cool things that were built for this customer.

07:07
Alainia Spencer: Cool, thank you, Geoff. So we'll start off with standardization. So we all know that this is probably the most important piece of the project that we need to make sure that we get correct. So, so much data that we had to grab from the Signet system kind of go through that data, do that analysis, that initial analysis, and figure out, Hey, what do we have here, right? We need to build our UDT templates, and we need to understand what's the best data model and how can we flow. So the Midstream company in question, they basically had Allen-Bradley for all their PLCs. So we basically kind of followed the AOIs and created our UDT templates based off of that. They also had some Modbus devices, and for their measurement, they'd had some Totalflows and some Emersons for the most part. So we're dealing with four protocols here. As you can kind of see, we came out with our UDTs. We have our analogs. We have our PIDs, our motors. You see, we have our meter gas UDTs for our gas metering. Something that I do wanna highlight here was that every item in our system was a UDT. There were cases where we just had maybe one single data point, maybe an ambient temperature, but that temperature had nothing associated with it. There was no alarming. There was no bypass. Maybe we had a status that was coming in to the system, but there was really nothing associated with it, right?

08:32
Alainia Spencer: Most people would probably just say, "Okay, I'll just go ahead and just create a single OPC tag. I'll bring that data in." We decided not to go that route. As you can see, we have the concept of an analog single tag, a digital single tag. We made that an actual UDT, and we did that for two reasons. One, we wanna make sure everything's standard across the board. All of our UDTs had the same parameters across the board for everything, no matter what type of UDT it was. And number two, most of you guys know it's a lot easier to make an update to a template rather than having to go find these thousand different tags throughout the system and try to make updates to them. So it was a clever idea, and I think it worked really well for us. So once we have our UDTs, we kind of started our actual graphics, right? We called them SVOs, standard view objects. I'm just gonna highlight a couple that we developed. Here at the top, we can see our radar plot. Each graphic was basically driven by a UDT, right? So the animations, the text that you're seeing, the alarming, all of that information was basically pushed from my UDT into our standard view objects. All of the objects also had a nice right-click context menu where users can view trend information, and also if there was any type of pop-up associated with that particular object, users could just left-click and a pop-up would show up. I'll show some of that in a bit.

10:08
Alainia Spencer: Here's a couple of more objects. Here we have at the top, which is a pattern recognition object; it's called a vertical profile. At the bottom, we had a couple of different ways of showing analog values kind of depending on what that information was, kind of depend on what we decided to use on that screen. Something cool all the way over to the right. We did create an object specifically for our tank level so that we can show a top level as well as the interface level, so that was pretty cool as well. Here we have our digital objects, right? So reading a boolean zero or one that basically would show the string of what that actually means. Is that normal? Is that alarm? Is that running? Is that stopped? You can see here we have a couple of little lamps. So we adopted the lamp principle. And what that meant was if something is in its normal state, it would show up as a white background. So you know that that's normal for that particular piece of data. And if something showed up in a gray background, then we know that that's not the normal state of that item.

11:08
Alainia Spencer: So we use this a lot for things like a compressor run status. Here we have a couple of our string objects that we developed, and at the bottom we had a couple of variations for our PIDs. You can see the process variables, your operating set points, the modes, things like that. And then one thing to highlight: where we were able to, we did try and use template repeaters throughout our system. This worked well specifically for metering, right? So those things, meters, all have the same data; it was easy to use a repeater, and that worked out pretty great. Alright, so custom tag attributes. So I'm gonna say most of the legacy systems that I've dealt with there's always been some type of limitation as far as how much metadata you can populate on a given tag, and so I absolutely love the fact that I can add as many custom tag attributes as I want when it comes to Ignition. So we definitely use this feature a lot, just to name a few. I mean, we use this for data management, and we also use it for data integration, so a couple that I would probably highlight here is this ACM mapping field. So it's very common in the oil and gas industry.

12:29
Alainia Spencer: Specifically, I'm gonna say the example that we use it for was for Totalflows, right? So users are the operators. We have devices in the field that the total flows have trend data information. And we're using AutoSol to gather that information, and we're putting that data into an AutoSol database. So how do we get that information from the AutoSol database into Ignition? So what we did was we created that custom field, that ACM mapping field, which essentially consisted of a table and a column. And so we used the Bifrost functionality. Bifrost basically took the information, found that information from the AutoSol database, and basically did a match and pushed that historical data into the Ignition historians so that the operator can see that high-resolution data. We use things like PiDeck. Does that information need to go into the Pi system yes or no? And obviously a couple of other things just to highlight things like units, maybe some tag descriptions high and low set points, and things like that.

13:40
Alainia Spencer: Alright, so document tags. I'm not sure how many of you guys use document tags, but we highly utilize document tags a lot throughout the system. So a lot of times most people will use SQL to house their metadata. We didn't go that route. We had four edge Ignition gateways, and we also had a full-blown Ignition gateway. And they all basically had to; we wanted to make everything standard across the board, regardless if that was an edge site or a full-blown Ignition gateway. So the concept that we came up with was, we created a script. And that script basically, it would go in and it would scrub every UDT instance, and it would grab the parameters from those UDTs and it would store it in a document tag. So that document tag basically consists of a JSON.

14:35
Alainia Spencer: So it had a key, which was the tag path, and within that key on the attributes of that would consist of basically every attribute, every parameter, and then the information that was actually set up on that UDT instance. So that's where we housed all of our metadata. And so we did that across the board. It did not live in SQL. And that actually helped us do things like, for this particular use case, the midstream company, there was a lot of requests for like, tabular data; they wanted to see maybe all of their meter datas and then their totals. They wanted to see maybe comm stats within a grid things like that so what we did was we had other scripts that would look at that metadata tag and we would set filters, so let's say I wanna set a filter and I wanna grab all of my meter information. I had a script that would filter, grab all the necessary tags, get all of the necessary current value information, and then store it in another document tag. That made it really easy for things like our tables. This table is really just essentially bounded to one of those document tags. Made it really, really easy. We didn't store that data in SQL. Everything was done within the document tags. And then I really like these grids because they have that nice drop-down subview feature. The operators really like that.

16:07
Alainia Spencer: Alright. Next is our use of... I'm sorry; give me one second. Use of our data set tags. So there's always a need in the oil and gas space to show data that is relevant to maybe another piece of data. So maybe I have a meter, and I wanna show some. I wanna show the valve that's related to that meter. Or maybe I have a meter that I have some tank data that I also wanna show with that meter. And it's like, how do you do that? How do you show data that's in another UDT? I wanna show it all together, and I don't wanna hard code that. So we came up with the concept of an associated data. So this was a data set tag. And inside of that data set tag, we just had basically columns. And each column represented what that item was. So here you see we had some NGO tanks that we wanted to show with the meters. You see we have a valve control section that we want to show with the meters. And so each column would be the item that we wanna show, and then the row would actually consist of a tag path, and so this made it really easy for us to do things on screen without hard coding, just having to call that data set tag and maybe just using the lookup function and grab that tag path, and then show that relevant information. Same thing on the grid, we were able to pull up grids and have data shown from different UDT instances.

17:44
Alainia Spencer: And last but not least, style classes. I just wanna highlight that. Absolutely love style classes. A lot of those SCADA systems, legacy SCADA systems, there wasn't anything like this, right? So we use style classes across the board, right? We wanted to make sure that everything had the same fonts. We wanted to make sure that everything had the same colors based off if that was a label is that a process variable. We wanna make sure that things are uniform across the board for everything. Most importantly, we also use it for things like alarming, right, the colors that we're using, the priorities, if something's acknowledged, unacknowledged, so for animations and things like that. All right, so interfaces, right? So I'm gonna say this. We were inspired by the high-performance HMI handbook. We tried to follow this to the T as much as we could. However, in all situations, there's sometimes where, you know, operators wonder a certain way, and we had to make a couple of tweaks. But for the most part, this is what we followed, and we were inspired by this. Two big pieces here: clarity. Big thing, we wanna make sure that things, graphics on our screen are easy to read. We wanna make sure there's no unnecessary detail on the screen.

19:10
Alainia Spencer: And we wanna make sure that alarming and abnormal situations are clear and easy to distinguish. And the last big thing is consistency. We wanna make sure that the graphics are standard across the board. We know that operators may change geographical locations. We wanna make sure that we are consistent, and so that if that does happen and maybe have to change another to another site, the operator doesn't have to relearn the system. Everything was consistent. He knows how the alarming works. He knows the graphics that we use. And we wanna make sure that the objects behave in a manner that functions and is standardized across the board. So bad example. This is definitely not HPHMI. I don't think anyone really knows what's going on here. There's lots of colors. It's hard to understand the data flow. I'm not sure what the process is.

20:08
Alainia Spencer: It's cluttered, and I don't know; just a lot going on here. So we kind of look at this screen like, oh, well, I can see the gray backgrounds right here. That's used to minimize the glare. There's no unnecessary animation. If I look at this screen, I don't see any alarming. Nothing really stands out. The color is only used for displaying alarming, and the layout of the screen is pretty consistent. I can look at the screen and just easily kind of determine. I can see there's this compressor run status that's not running right now. But other than that, there's nothing that's really glaring or pops out on the screen. Another important thing to use our concept of the HPHMI is your icons and your colors. So we wanna make sure that we associate alarming with not only a color but also an object. Because we do have operators who could be colorblind. So pairing those two was very important. And so navigation. Navigation is a big part. So we have our L1 screens.

21:21
Alainia Spencer: So that's your broad overview. You walk in; this is your most important information for your facility, your L1. There's no control, just an overview. Your L2s consist of control specific areas and products. So you get a little bit more detail, but not necessarily the actual process flow. And you can control if needed from an L2. Then you drill down to that L3. That L3 is your flow diagram. So this is the actual process of the field. This is the facility. This is your pipes. This is all the equipment that is associated with everything. And then your L4s, which is your details and your individual transmitter information, and this is where you can actually do your controlling. Maybe tune some P&IDs. Maybe do some set points. put things in and out of bypass, and so I'll go over a couple examples of how these screens actually are laid out. So we have the L1, as you can see high level. It's a high-level overview. We have some important pumps that may need to be looked at. We have some important tank levels here. We have a couple of capstones, some generator statuses, to see if things are running or not. Some of our important motors. So just at high level, an operator can see this is his most important data for that particular facility. And if he needs to drill into some more information, he can drill into an L2, which looks something like this.

22:49
Alainia Spencer: So this is an example of a startup screen. So this is all the important valves that are associated with startup, the pumps, and then all of the P&IDs that are associated. So a user can come here; he may not need to actually see the process flow, but he still can come here and possibly do some controlling. He can get to his face plates from here, and you get a little bit more information. And then we drill out to an L3. So this is your P&ID drawings. So this is where you can see your process flows. You can see what belongs to that facility. You can see where everything's at. It was a challenge using the pipe tool. So I'm very excited to hear that drawing tool is coming out in 8.3 'cause we had some challenges, but we made it work. So this is another example of an L3, and I have one here. It's just the utilities and tank strings that we put together for the company. So last one is the L4. So this is what pops up. This is how the users can actually do controls, so this is just an example of a PID pop-up where they can come do some tuning, they can see some trend information, they can put things in and out of manual mode, they can do set points, they can change their outputs and then we also have another one, which is just our analog pop-up that we put together, you can put things in and out of bypass you can change your set points you can do your trends so just an example of what those L4s would look like.

24:27
Alainia Spencer: Next, alarming. Alarming is very important. So I talked about that earlier. It's a color and a shape. So we had alarm levels from one through four. There actually is a concept of an alarm zero, where actually it's not an alarm; it's a diagnostic. So level zero is a diagnostic; it's for informational purposes. So we did not actually indicate that on the screen, just because of the fact that it's not really something that the operator needs to pay attention to or needs to catch his eye per se. It's just for information. So we had a one through four. We had a one, your lowest priority, purple. We have a level two with the square level three triangle a little bit more important but not the highest, but then you see the red, we know that something's on fire. We have a level four, a diamond-shaped, highest priority alarm. Here's just a couple of examples to show how easy it is to determine or depict when something is in an abnormal state based on the objects that we built out, so at the top you can see we have a nice multi-level indicator with a chart. And we have some of our analog indicators, which is the normal state. And then at the bottom, you can easily tell that something's not in that desired range.

25:51
Alainia Spencer: Something's outside of those high, low set points. So just a picture and kind of show you the difference and how easy it is to kind of see when something's not in that normal state and when something needs attention. Here's our vertical profile. Here's another one. This one, really easy. You can see in the first picture that process variable is that line is just consistent. We know that this is normal, but if you look to the left of that, I'm sorry, to the right of that, you can see that that process variable needs some attention because there's a lot of just different shapes going on. So this is a pattern recognition object; you can really, really see that the pattern is not right. And then another thing I wanna kind of highlight so we did put together a solution for our alarm roll-up functionality, and I did hear that in 8.3 it's gonna be something that they're coming up with now, so I'm excited about that where that we'll be able to actually have that built in but that wasn't out, so for us we created a solution that essentially would look at a UDT. We had a parameter that would say what L3 screen that was on. And basically, putting two and two together, we created a process where it would get the highest active alarm, and we would use this for our navigation. And so what you're looking at here, you can see an operator can easily see, hey, I have a level four alarm somewhere in this IOC dropdown.

27:33
Alainia Spencer: Because on that dropdown that's all of our L3 screens, and then I also see that I have a level three alarm under this process screen, and so the one that's currently dropped down, you'll notice that we do have a level three there and we also have a level two but the one that's actually shown on the top navigation is the level three because it's it goes off of the highest active alarm. So the three is the highest, and we can easily depict which screen that would take us to that actual alarm so that the operator can get investigate to figure out what's going on and what is that currently that we have an alarm, and I'll turn that back over to Geoff.

28:15
Geoff Daily: Thank you; that was great. Yeah. I'll also give a shout out in the front row. Here we have some of our other great Techneaux members who are involved in this project. You guys wanna wave your hands real quick. I'm putting them on the spot. Very significant project. I'm also curious, just by raise of hands, what operators do we have in the room right now? Who's an oil and gas operator? Curious. I know there's at least one, because I met you yesterday. And then who do we have integrators in the room? Okay, excellent. Cool. 'Cause I wanted to let you know that this part of the presentation, we're gonna be speaking to both audiences because we think we both can benefit from what Bifrost has to offer. So first off, it's important to note that we are not how you would normally think about an ETL solution. Typically in the market, you are being sold tools that then you have to go figure out how to use yourself or black boxes that don't necessarily meet you where you are.

29:05
Geoff Daily: What we are is a little bit different because we're our tool with integrated support monitoring included all in it. And everything that you need is basically turnkey for it. Some of the characteristics of our ETL solution flow. One is our software actually operates on premises or in a network. We knew a lot of oil and gas companies didn't necessarily want their data gonna go in all over the place. Now we can obviously connect to the internet if anyone wants their data to go that direction, but it exists inside of your control network to maximize performance and security.

29:33
Geoff Daily: It's also self-healing, so our software is state-aware on a per-datapoint basis, so we know if the data has actually made it from the source to the destination, and if it hasn't, then we make sure to get to make it so. That is very important for a couple reasons. One, outages. The current standard typically is only picking up the most recent current value. So when there's an outage, when that outage gets resolved, it's just picking up the most recent current value, and you now have a data gap that some poor person has to go dig and find the needle in the haystack on that. For us, we're constantly scanning historical data. So and we know where we left off during the outage. So when the outage is resolved, we just pick back up where we were before. Another thing that's unique about that is our ability to do the word we've come up for is back-serting. Sometimes data comes in out of order from the devices, and we're actually able to then put it in the right order on the destination automatically through our software. The modularity of it is usually you think of modularity from the perspective of being able to add additional connectors easily, and that is part of our value proposition. Once we have the data going from Ignition to another system, adding another destination is relatively trivial for us.

30:35
Geoff Daily: But modular also, we're doing a lot of interesting things where clients sometimes have unique cases where they need to have some additional functionality built. And because our software is effectively a bunch of workers in serial, we're able to build additional workers that have unique functionality to them. One example was we have a, we call it Heimdall internally. We like the Norse mythology on that. And we realized that we're state-aware on a per-data point basis, but not every data point updates at the same frequency. So our guys built some code to learn what the frequency of each data point is for when it's updated and then only pull the data with relative to that frequency, which dramatically lowers the load on your network which is a really important thing in the oil and gas world. The other main characteristic, as I've already mentioned, is the fact that this is a monitored ETL solution, so that means we have outage detection, we have KPI reports we have someone on our team who's keeping an eye on this, and quite frankly, sometimes we're finding outages before the customer even knows there's an outage and resolving it. That's part of the value proposition you get from our service, and it's fully supported. That's from the design at the beginning all the way to the ongoing basis. Part of the challenge with this SCADA ETL space is that in order to do it right, you have to have knowledge of SCADA, oil and gas, IT, software development, data structures.

31:49
Geoff Daily: It's a very diverse skill set that most oil and gas companies and even integrators can sometimes have challenges to be able to properly staff those capabilities to be able to rapidly respond. And oftentimes those people are busy doing other things. So you don't wanna pull them off the higher-value work to do the lower-value, effectively plumbing, is what this is. And the reason I wanna ask the question about operators and integrators at the beginning is that while Bifrost has grown up inside of Techneaux, we are a part of Techneaux, we are also happy to work with other integrators as well. In many ways, I find it kind of interesting the parallels between Ignition's origin story and Bifrost's origin story. Ignition came out of a systems integrator that was looking for a solution to a problem that they couldn't find the market so they went and built it that's the exact same thing that happened with Bifrost; we had customers time and time again struggling with this these SCADA ETL challenges.

32:41
Geoff Daily: So we went and built a solution for ourselves internally, bringing it back to this particular case study. The integrations that we're powering on an ongoing basis for this customer one is the Signet to Ignition, as I mentioned earlier, that's still operational. As we're standing up all the different Ignition integrations, we think that one is particularly unique. As far as we know, there is no other good solution for keeping Signet and Ignition in sync with each other when you're trying to run them in parallel.

33:08
Geoff Daily: That was a very important thing for our customers, and I think anyone who's looking to make that transition, it's a really big deal, and Signet has some challenges in terms of working with it in that way. Ignition to PI is another one, so that was a couple of things they wanted on that one. If you're gonna spend a bunch of money on a historian, you want your data to be accurate. But in order for your data to be accurate, you need to make sure that it's actually moving the way that it's supposed to, and you don't have these data gaps. And when you're moving, if you're working with a larger-scale oil and gas company, you're starting to reach the level of data throughput that can start pushing Ignition a little bit past its limits. So our guys actually had to build some special tools to be able to move effectively a limitless amount of data into and out of Ignition. Currently we're seeing about in our testing 10 to 20x the current standard for how people are moving data into and out of Ignition, and that's on a single thread, and our software is multi-threaded. So in theory, if there's you have enough server capacity, we can be moving any amount of data into and out of Ignition. AutoSol to Ignition is another one. That particular was the customer wanted to be able to get trend files out of AutoSol into Ignition.

34:14
Geoff Daily: There's been other customers asking AutoSol for that; they don't currently support it. Our guys are able to build a way to do that so that the customer could now get access to that more granular data, even in a situation where your communications may not be as strong as you want it to be for getting that real-time data. And then there's a bunch of cool custom ETL stuff that we did. I don't wanna talk too much about that 'cause we start getting into proprietary things, and we obviously wanna protect our customers' intellectual property. But there's a lot of interesting things that we can do that may be normally very difficult, but given the tools and the fact that we have a team of integrators, a team of developers, and a team of solution architects specifically focused on this particular issue, this is all they do every day is this particular area. And so that was another kind of category of things. The final thing I was gonna go ahead and talk about on this, 'cause I'm sure some of you all in the room are wondering what the heck is MetaSCADA. The Ignition people were wondering that too when I mentioned it. It is a term that I've coined just in the last month that we are gonna be encouraging the industry to be thinking about. Because what we're really referring to when we talk about MetaSCADA is the layer of people, processes, and technology that connects SCADA to enterprise.

35:22
Geoff Daily: Typically, it's been a thing that has, quite frankly, been kind of forgotten. It's been a lot of DIY-type solutions; take an OPC and custom script something and hope it works. And then you have one guy who's responsible for all of it and quits. And then you're scrambling, figuring out what the heck do I do to replace this guy? You don't want it. And it's also can often be a challenge for the integrators as well. You guys are out there trying to solve really hard challenges that are very difficult to do on a one-off kind of basis, especially in an area as complicated as oil and gas, especially if you're trying to break into oil and gas, because there's a whole other layer of kind of industry knowledge that's required in order to really work with this industry the right kind of way. And so this is a term that we're trying to help encourage the industry to be thinking more intentionally about.

36:05
Geoff Daily: Because this is where effectively I think a lot of value is getting lost in the oil and gas industry. Because there's all this money being spent on devices, all this money being spent on comms, all this money being spent on SCADA, all this money on historians, analytics, AI. But then this piece that connects it all is kind of the forgotten thing, that everyone's just kind of running around doing the best they can on that front. We're really trying to change the standard of what is possible in terms of reliably moving large volumes of data out of your SCADA system and into the rest of your enterprise and back the other direction as well, because we do have write-back capabilities from whatever other sources you're trying to push data into Ignition as well.

36:42
Geoff Daily: So with that, we've reached the end of our presentation. We really think the future of oil and gas is gonna be built by the people in this room who are looking at how they can adopt modern SCADA practices using modern SCADA tools and working with partners who really understand this intersection of oil and gas, SCADA, and technology. So with that, we've got our URLs if you wanna find any additional information. We've also put a couple of both Alainia and I's email address. We've got Big Jim Havner in the back, our account manager. He's one of the best guys in the world, so you'll just wanna be friends with him regardless of anything else. And with that, we've reached the end of our presentation and would love to hear any questions you guys have.

37:18
Audience Member 1: So you're obviously from the Northeast. You talk a little fast.

37:23
Geoff Daily: Minnesota actually, so.

37:26
Audience Member 1: But you mentioned this was a pipeline company that you were doing this stuff for, so...

37:31
Geoff Daily: A midstream company, yeah.

37:32
Audience Member 1: Creations for leak detection hydraulics batch management that type of thing.

37:40
Geoff Daily: You speak to that from a SCADA perspective, or is that?

37:43
Alainia Spencer: Was that for Bifrost specifically?

37:47
Audience Member 1: Yeah.

37:49
Geoff Daily: So for them right now, all we're doing is basically moving their data. So they've got the data into Ignition; they're trying to move it out; we are not currently doing any analytics for them on top of that. There is some stuff in the workings that we're working on. We're just not quite ready to talk about it yet, but afterwards, be happy to.

38:10
Audience Member 2: So, Alainia, we're showing the high-performance HMI standards and everything, so you're quite compliant with that. Are those screens actually responsive? Because, like on smaller screens, those mimic style graphics can be quite difficult, and sort of when I've had to try and do that, I've used sort of a Google Maps style where you can actually have a huge mimic and people can actually zoom in specifically down to the tank they're interested in. I'm just curious if you guys actually built the application to be responsive, and what were your approaches to doing that?

38:49
Alainia Spencer: So unfortunately, based on the requirements for the project, we built something, those screens, in a specific resolution. So they were not responsive. It's not easy to so the pipe tool can only be used in a coordinate container. So there's not much of that nice flex that we can do and opening on a different size laptop or whatever and have that responsiveness. So the answer is no. But we're hoping with the 8.3 release, with the new line tool, we can do some cooler things where we can have that responsiveness. Yeah, so we basically had, so I mentioned earlier, we had four edge gateways. And then we had one central gateway, which consisted of two front-ends. And we had a load balancer, and then we had a back-end gateway. So that was basically the architecture for that particular instance. 30, 40? Yeah. Now we do have a second project that we're working on with exactly a bigger area. And so I believe that implementation, we actually have five back-end gateways, three front-end gateways, maybe two app servers. So that would be a bigger deployment. So we're currently in progress of working on that at this point. So that's a monster. So we haven't done any upgrades or anything like that yet. So we haven't reached that point. Essentially, we have global projects that's shared across all of our resources. We have one project. We use EAM to push things down, things like that. But this is kind of a new deployment, so we haven't really gotten to that realm yet.

40:39
Geoff Daily: No. All right, we'll give you guys an extra couple of minutes.

40:40
Audience Member 3: Oh, yeah. Just in regards to the HMI high-performance handbook, I find that a lot of HMI development kind of stems from the idea of common sense. We are so ingrained with HMIs, just like on our phone and stuff, we get kind of used to the ideas of it. I'm curious if, when you were going through that book if there's anything that kind of stood out to you as something you either didn't expect or went against; maybe what you thought was common sense for designing HIMs efficiently.

41:07
Alainia Spencer: Nothing per se, to be honest with you; I think most of it kind of, it made sense. The objects that were used, the examples that they gave. The colorization, the alarm priorities, using icons as well as a color. I wouldn't say too much. The only kind of pushbacks that we had was basically the customer requirements. So there might have been a couple of times where the color that maybe that showed for bypass was something that was hard to read for the operators. So even though the HPHMI said, "Hey, this is a color you should use we use something else so to fit the customer needs."

41:44
Geoff Daily: When I also just as a quick aside, I realized maybe should mention this earlier part of why you may have noticed that Bifrost we didn't have any screenshots. That's 'cause our HMI strategy is we don't have one; it's intentionally meant to we put all our energy into focusing on the performance of our middleware, and so our interface is a human. You talk to a human, and they solve the problem for you. That's why we didn't have any screenshots for that product.

42:04
Audience Member 4: I was particularly impressed with what you mentioned about your use of document tags for the storage of metadata. Can you give us some more information about the things that you're able to pull off with using those document tags?

42:19
Alainia Spencer: So yeah, it was, we really just use them for our metadata. Kind of like I talked about, it was just easy to store that information, and we use it for our current value information. So I know a lot of people like to use tables, and some of the implementations that I've seen is that people store those current values in like a SQL table, and they refresh it on some time frame. But what happens when you lose that connection to SQL? You don't have anything. So we use it a lot just for the storage, essentially. And then for us to use that so that we can get current value information and store it in other document tags. So that was pretty much the use case throughout the system.

43:02
Geoff Daily: Excellent. Well, thank you all for taking the time to listen to us today. Really appreciate it.

43:06
Alainia Spencer: Yes, thank you guys.