Standardizing the Unstandardized: Strategies for SCADA Systems

Speakers

Lisa Clark

Manager of Digital Projects

TIGA

SCADA systems can become complex and unwieldy when managed by numerous engineers or when ownership changes through acquisitions. In this  session we will focus on strategies and implementation methods for using Ignition to transform disorganized systems into standardized, efficient operations. This presentation will cover best practices from small, unique projects to large-scale projects with multimillion-tag counts. Highlighting the similarities and differences between these types of projects, this session emphasizes the importance of standards in data modeling and a robust validation and verification process. Implementing these techniques enhances system performance, reduces costs, and increases user confidence — all of which are critical for the successful delivery of projects of any size to clients and stakeholders.

Transcript:

00:00
Ryan Senanse: Welcome everyone. My name is Ryan Senanse. I'm a Sales Engineering Coordinator here at Inductive Automation, and I'm gonna be your moderator for today. And so today's session is going to be "Standardizing The Unstandardized: Strategies For SCADA Systems." And please allow me to introduce our presenter for today. This is Lisa Clark. She serves as a project manager at TIGA, overseeing the development, migration, and support of SCADA projects. She brings five years of aerospace industry experience where she led integration projects between flight controls and avionic software. At TIGA, Lisa's worked as a systems engineer contributing to the development of various large-scale enterprise SCADA platforms for control rooms, desktop users, and mobile platforms. With a robust technical background and experience collaborating with governing bodies and diverse clientele, Lisa transitioned into project management to ensure meticulous validation and verification of project requirements. So at everyone, please give me a hand in welcoming Lisa.

00:57
Lisa Clark: Thank you. Thank you. That's really good introduction and summary of what we're gonna be talking about today. So I'm gonna walk through how my background has kind of led me to this journey of focusing on how to standardize SCADA systems. We've probably all worked in at least one, five, a dozen plus, more SCADA systems, either using Ignition or coming off of other platforms as well. So our main focus today is how can we get an organization or a system to perform well under an increased or expanding workload and how Ignition has helped us get there. As mentioned, I'm Lisa Clark, Manager of Digital Projects at TIGA, The Integration Group of America. We're located in the Woodlands, Houston primarily. And then we also have another big office in Louisiana and then engineers all over America. So a little introduction. So furthermore, his wonderful introduction just a second ago.

01:47
Lisa Clark: My background is in industrial systems engineering from Auburn University. So had a little stint over in the great state of Alabama and then went over to Savannah, Georgia, as a system safety integration engineer. And this is where I kind of had a passion and created that love and endearment for standards. Mainly because when you're flying, as most of us did probably getting here, you really have to ensure that the standards and the requirements were met when flying an aircraft. It's very risky. So the FAA, I worked alongside of them for five years doing a lot of avionics in our world, HMI, right? What the pilot sees or what we would call an operator weather controller sees, and then also flight controls, which in our world is PLCs.

02:34
Lisa Clark: So then I came back home to Houston, left the aerospace industry, and that's where I've been with TIGA, the transition to midstream SCADA controls. So as mentioned, like flight controls, it's now our PLCs. And then avionics had to learn the HMI for operators and controllers in midstream rather than, or pipeline controls for those that are not in oil and gas for the controllers that are operating the pipelines. And then I'm also a committee member for the ISA 112 release that's coming out here soon for the new revision, which is gonna emphasize a lot on validation and verification. So that's kind of what I've been studying and working on this past year.

03:15
Lisa Clark: All right. So who are we? I am an integrator. I'm not a vendor. I'm not here for any software provider, and I'm not a lovely Inductive employee, so I don't know the ins and out of the technology as much as other performers or folks from this week. But we are integrators, and we focus on improving operational efficiency, increased reliability, and safety for industrial markets. And what a better product to do that with than Ignition.

03:42
Lisa Clark: All right. So our end goal normally as integrators coming into a project is we're either migrating, developing, or supporting a SCADA system, whether it's already existing or they're asking us to build one from the ground up. The end goal is normally one of these types of flavors, between one of these four topics. TIGA, please increase our quality and consistency. Please decrease our wasting costs. Please reduce our risk. Increase continuous improvement organically. It's normally one of these flavors that we're being asked to look into. But what do we really hear, or what does the C-suite or the management, or the end client actually hear? They're hearing the only way to increase quality is to spend a ton of money and time on training. The only way to decrease waste and costs is I either have to buy a new platform, I have to buy new servers, I have to hire integrators.

04:31
Lisa Clark: I have a lot of upfront costs. How do I reduce risk? Normally the best way is, well, let me trash your system and start all over. Let's redesign and start from the ground up. How do I increase continuous improvement organically? That's the key word there. Continuous improvement, what's really that saying is let's change a lot of things. And there's always gonna be hesitation from either the end user or the person that's gonna be maintaining it moving forward. So today that was kind of the preface, the prologue of where I wanna go, but today I'm gonna talk about how are we gonna standardize and meet those four goals, or at least one of those four goals, using Ignition. In our experience at TIGA, we do a lot of different platforms, and Ignition has really had the best opportunity or the quickest ramp-up time to standardize.

05:21
Lisa Clark: So I'm gonna kinda go through some methodologies and ideas, and examples of how we have gone through that. This bulleted list here, of course, it's not every single way. It's not the only way that you can standardize a SCADA system. I'm highlighting the ones that are the most cost-effective and line up with the Ignition platform that we've seen previously. So control methodology agnostic to protocols, meaning your PLCs, your end devices, they all talk differently. Literally all different protocols; they all react differently. They all can be programmed differently. Whether you're an automation engineer here in this room or an HMI guy, you've seen that, of one way or another. You know, your Allen Bradleys talk differently than your total flows. And I'm gonna go into a few oil and gas ones here just 'cause that's my background, but face plates as well. Controls.

06:09
Lisa Clark: So as your protocols change, your face plates are changing. So we're just continually interjecting a lot of differences when your end customer is asking you for standardization. Alarms, tag names, those are really easy places to where you can see and exploit and ruin a system by having way too many different tag names, way too many different types of alarm templates, et cetera. I've been in systems where a tag name as simple as Flow Rate seems very simple. That's a tag name. I've gone into a system before where there were 22 different ways that they used the word flow rate. Flow, which is FLW. Rate, flow, you know, what have you. So cleaning up tag names and kind of leaning into that Unified Namespace without having to overhaul an entire system can really give you one step closer.

06:58
Lisa Clark: Metadata, that's something that Ignition is really good at. It carries that marriage with SQL, and we'll talk about that here in a minute. Screen layout and navigation go hand in hand. And then the two I'm not gonna talk about today really is the configuration sheets and control narrative. Just because today we're here talking about Ignition, right? Not too much about the PLCs before, and I'll let the automation engineers talk most about that. But those two obviously interject either standards or interject the wild, wild west into your SCADA system.

07:31
Lisa Clark: All right. So I kind of hinted at this a minute ago. As an integrator or if you're implementing your SCADA system, you're the end user; you're the end company result; you need to keep in mind the change process. We're all humans, HMI, human machine interface, no matter how much we engineer, and majority of us are probably engineers or technical in some way or sort; there's always gonna be that human in the loop or human in the process, or just at least a human in the product's use. So I like to keep in mind that no matter what, we always have that change process. There's going to be people's reactions to how we're either implementing a SCADA system or maintaining a SCADA system. So, but what's frustrating is, is I know I'm very black and white; that's probably a negative in my personality at some points. But how can we engineer a solution that doesn't cause even more strain or more hesitation? So luckily, over the years of engineering, there is an engineering practice methodology, V&V. Validation and verification process, that, if you notice, is the exact same path as this change process that our lovely human factors engineers and psychologists have to defined for us. So that's our best tool to combat this issue.

08:48
Lisa Clark: All right. So similar pattern as I was saying. This is kind of our methodology to make sure that we combat, or at least are designing alongside of our end-user's change process. So as they, if I'm gonna go back and forth, and I hope this doesn't become an issue, but they're used to the old status quo, right? They've probably been in a Wonderware system for the past 15 years, or some other type of local HMI for the past some odd years. They're used to that status quo. So let's talk about the discovery and get all the requirements from those end users. And I'm not talking about stakeholders. This is a term that's, you know, I've seen interchanged. They're two totally different groups. We've got our stakeholders; we've got the people paying the invoices, the people paying for the project, but also the end users.

09:36
Lisa Clark: You need to keep both of them in mind. And that's a very delicate balance, which I'm sure all of y'all are aware of. So define the requirements not only with your stakeholders but with your end users. Make sure you capture what that status quo is and then move on into the architecture. Get your senior engineer, get your person that's the most qualified with that Ignition product, and get that architecture and task list drawn out. Now, this is very, very important, and this is where I've been focusing mainly on with ISA 112 committee, is there is this battle. We're not gonna battle it out here today, but, in most electrical systems or controls designs, verification is before validation. Today, I'm just going to talk about validation before verification. That's gonna come into my aerospace background. We would've never been able to allow it to fly a plane, which is verification, without validating the requirements.

10:29
Lisa Clark: So going into midstream, which is pipeline control, similar level of safety, maybe not the same as flying 300 people in an aircraft, but still a level of safety, and critical systems, a lot of logic goes into play. So I like to really enforce that validation first. And Ignition, I'll kind of walk through a lot of, Ignition tools that have helped us do validation before we go into project execution. So what do I mean by validation? Is this the correct product? It's completely different than did we build the product correctly. So let's first confirm we have the correct product. Go into execution, and this is where I'm gonna bop back; give you a little whiplash there. So at the bottom of our V&V process, when we're doing execution, you're rocking and rolling, and your team is excited. You've got your core data, you're working on your UDTs, and you've got your instances and your HMI.

11:24
Lisa Clark: This is either where you're gonna have your end users in complete chaos or they're gonna be riding along that train with you. So I like to keep that in mind with my team members. I'll just be like, "Hey, they're disgruntled right now 'cause they're falling down the cliff." You feel like you're going up a mountain; you're climbing Mount Everest. They feel like they're falling down a cliff right now. They're seeing a lot of differences, chaos, changes. Oh my goodness. So with that, you wanna climb back up the mountain with them. I know it's an inverted mountain. You're climbing back up into verification with them alongside of them. And I wrote on here, point-to-point, dual polling. Everybody has their own different flavor, line checkouts. However you're commissioning your system, do that alongside of your end users. Let them climb up that process with you, so that you can have a successful cutover and a successful hypercare.

12:18
Lisa Clark: All right. So I went over methodology of how we've seen it successful. Now the real guts of this presentation is how does Ignition help us do that? Going back to the slide with the multiple bullets, I'm just gonna go through a lot of tools, or, maybe not tools, but components, Perspective, components, modules, what have you, how can you leverage Ignition? As mentioned, we are a systems integration firm. We do lots of different platforms, and we've done migrations and developments on multiple ones. And I could say that Ignition is probably the easiest one with the ramp-up time and cost effective, which is always important for all stakeholders. So we'll start with HMI graphics. In my personal opinion, as mentioned, this is not the Bible. This is all methods and opinions and our best practices learned as a firm since 2017.

13:12
Lisa Clark: HMI graphics is such a clean and simple way to get your end users on board. I'm using a very simple one that we've used a few times, or at least a rendition, a flavor of this per se. And most of you are like, "Oh yeah, this is just high-performance HMI, Lisa; you're not explaining anything new or novel. We've seen this a hundred times," which is hilarious because, yes, we've all seen it a hundred times. I've also gone into a hundred other systems that have never seen this before. So, sometimes just explaining to them, "Hey, let's embrace just a teeny bit of high-performance HMI. Okay, you're not on the HPMI train. We can either do a different flavor of this style guide," but just implementing a style guide in general, some consistency, will help those folks that are used to the status quo, maybe not fall on that cliff so hard, and just kind of babystep them into the standards.

14:06
Lisa Clark: So we've done this; I'm trying to think, I think we call it the SCADA master plan. A few folks have called it or some type of journey created with your end users. Sometimes this is just the first step, and it gets them really on board. What's the easiest way to see it, to believe it? And a lot of times you can implement this without dramatically changing your core data. You can add in the HMI level on top of it without having to go gut all UDTs; go gut 20 different edge deployments you have in order to standardize. Maybe that's step two, three, or four down the road. So yeah, nothing too new or novel here, but I just kind of wanted to emphasize, get your graphic designers out, get your main Perspective developers at the beginning, workshopping on how to standardize the visuals while you're kind of winning over or working on it. It could be you have this sitting on top of a very messy core data design, and while you're spending the next few months or however large the system is working on UDTs, your HMI doesn't change dramatically.

15:14
Lisa Clark: All right. I titled this slide Leveraging SQL. Probably should have labeled it Leveraging Metadata because there's so many different ways that you can import metadata into your Ignition system, and that in itself is a pro. This is an example of sometimes you come into a system where you have... I mentioned edge deployments. I have one system with over 400 edge deployments. Luckily, you know, we were able to go in and start standardizing all of them before it turned into 500, 600, 700 edges. But let's say back; give me roll back a year and a half ago. The first 100 or so were all completely different. All their tag names were different. All their metadata was different. These two edge boxes put the metadata in parameters. These two put them in... Where else? We've done them in parameters; I've seen them in SQL. I've seen them nonexistent at all.

16:05
Lisa Clark: Array tags. I've seen people use array tags to throw that into the enterprise SQL. Anyways, Ignition provides such a good marriage with SQL that can be leveraged throughout your whole Ignition system. So here's an example of, you know, maybe you have a vague tag name like analog value, or you have, like I talked about flow rate or just flow in general or volume. Sometimes you don't have a very descriptive tag name. So how do you combat undescriptive tag names or undescriptive instance names? Because later, when your end user is trying to use the Power Chart or use all the amazing tools that Ignition gives you, the drag-and-drop alarm journal, that table where you can just drag and drop and you have alarms. If none of your instances make sense or none of your tag names make sense, those tools become almost useless.

16:54
Lisa Clark: So like I said, leveraging SQL, that merriment between Ignition and SQL can do wonders for you. This is a perfect example where we went through everything... You can go through any system and go through and redefine and give all those parameters a lovely home so that you can leverage that throughout your system. That is another way that you can standardize your SCADA system and telling your end users, I haven't touched your UDTs. All we did is went in and scrubbed it. We can add the SQL table on top, or I didn't touch your UDTs, but we went in and added a lot of parameters, which then let us, gave us the opportunity to edit your instances and give you a little bit more detail. And then maybe you can use that as your Bible for phase two of the project to go later update your UDTs and instances, because that's important for.

17:48
Lisa Clark: This is an example of those type of tools that I was telling you the Perspective components. I'm sure everyone in this room has used a Power Chart. If you're familiar with the Perspective tools that Ignition has, something as simple as a templated Power Chart would only be successful unless you have that standard core data. So on that example before, where we had an unstandardized core data system, you're not able to use a Power Chart, but we're giving that customer or that end user the baby steps of, okay, well, we're gonna use, we're gonna add this SQL table on top of it to give you all that information, that metadata, that goodness for you to understand your SCADA system. But we have to use an XY chart or, you know, some other solution while we're working on the backend to standardize the rest of your core data. So that hopefully at the end goal is that you're tag naming, that UNS that Unified Namespace that you're working towards can then create templated Power Charts or a templated alarm dashboard, what have you. So that's kind of like the next step. All right. So I talked mainly about data. I'm gonna transition over to the next few bullets and what we like to standardize. And my favorite is screen navigation. Just 'cause my background was avionics, so not gonna lie there. That's why.

19:08
Lisa Clark: The dock philosophy. The very first thing that you see whenever you go into an Ignition designer, Ignition throws it in your face. There's nothing you can do about it is the framework at the very beginning, where it shows you the top of your screen, the bottom, and your left and right docks, whether you configure them or not. Like I said, as soon as you log in, it's the first thing is shoving at your face. Configure your docks. When we're doing our HMI workshops at the beginning of a project, that is one thing we see a lot. Every screen has its own header, has its own footer, has its own right dock, left dock. Some people slide it in, some people cover the simplest things of going through and say, Okay, well, how are we gonna use the dock for your system?

19:48
Lisa Clark: Do we wanna do navigation on the left? Okay, then if that's the case, I'm gonna lock it in and make it a global dock for your whole system. Here is an example of two different systems that chose doing all trending being a bottom dock. And you can see how that is consistent. We're gonna keep that trend no matter where you click, you right click, left click, what have you, from here on out, anytime you wanna trend, it's gonna come from your bottom dock or from your right or pop up, a modal pop up, what have you. I'm not saying this is the best way to see trends. I'm saying at the beginning of your standardization workshop, a lot of people wanna go straight into screens, or how do I do my valve control? Or how do I do my pump control? Sometimes it's nice to look at the bird's eye view and say, "Let's start literally at the very beginning of what is our dock philosophy? How are we gonna do the top, bottom, left, and right?" and then stay consistent throughout your entire system.

20:43
Lisa Clark: And then here, normally that starts the conversation so organically into, okay, well, now that we've designed your docks, what's your navigation philosophy gonna do? The docks is not the only way to navigate. Here's a good example of two different screens. And these are mockups. As you can see, they're not perfect Ignition screens. These were mockups that started that HMI workshop. The left screen, the right screen, I probably had like eight or 10 different iterations, but it started that conversation during that validation step where I gave them tons of mockups and was like, guys, once we pick one, we're gonna stick to it. So across the top, this is actually using a top dock, the header, and it's in place. It's staying on every screen, no matter what screen they went to. And then you can leverage Ignition session parameters however you see fit or however you pass in your variables to stay consistent throughout the system.

21:39
Lisa Clark: So as you are navigating across the top, this is a very typical example. That's why I wanted to bring it up. Y'all probably implemented this already or have seen it across multiple SCADA systems, but something as simple as our navigation for this system is going to be dropdowns across the top. I've also seen where they choose to do their navigation, everything on left or right dock or not to do dropdowns at all. You can see how this stays consistent, whether they're going into the map feature or over here is a site overview screen. But as soon as they start typing in site A on the right, it's gonna keep them on site A on all their other screens. And that kind of just helps create that organic navigation. Really, you didn't have to do anything other than make five screen... Five dropdowns. How many did I do here? Five dropdowns, five session parameters, and create consistency. We've done before where we started at just navigation and docks and kind of left the original screens alone. And even that itself kind of starts that standardization and HMI experience for your end users, kind of getting them on board. And Ignition does a really good job of kind of letting you doing all those parameters session parameters throughout your entire system.

22:56
Lisa Clark: All right. Gonna bop back a little bit to core data because a lot of those things only work, especially when you're doing screen. I talked about the templated Power Charts. Templates, templates, templates. UDTs were built to be templatized. That's the entire idea, right? It was to enforce and maintain requirements at a tag level; you build your UDTs, then you use them to create your instances. I've come into systems, or we've come into systems, where they started off really, really well. They have one I'm gonna pick on tanks. I don't remember what I, oh, this is a pumping wellhead, but I'll try and do something less oil and gassy. I'll do a tank. They had one UDT for tanks. They were rock solid, and then they grew, they acquired, they added more tanks. Maybe they hired a new automation team.

23:48
Lisa Clark: So they configured their tanks completely different. And it's four or five, six years down the road. Now they have 12 different UDTs for tanks. And then they're coming back and saying, "TIGA, help us standardize. We've gone all wild west on our UDTs; now none of our screens work. Our face plates don't work anymore." We've seen that a lot. And as y'all know, as end users, I'm kind of trying to show the little green dot right on instances. Once you start overriding, it almost becomes a trickle effect. You're getting further and further and further away from your standardization. Your big project you had five years ago of standardizing all your UDTs. This is just one example. I'm not saying it's the only way to combat that. Obviously processes and change management and keeping your automation that we talked about earlier, keeping your control narrative, keeping your config sheets in line is obviously the best way to stay standardized in your automation and your implementation.

24:45
Lisa Clark: But another way that we've seen it is, okay, managing instances instant overrides becomes a headache. And like I said, that kind of goes against the goal of what UDTs were developed for. And we wanna make sure that we're staying on track. So for large projects where we've seen that something that is helpful, then what's another way that we can keep your tags in check? I'm sure y'all have seen this, but using parameters, parameters have seemed to be like the little secret that just kind of sits there and people use them as variables throughout their OPC item pads or throughout their register pads. But you can delineate that from your UDT instance override. And so we have seen a lot of good projects. I've seen them throughout a lot of implementations of Ignition of putting your registers in the parameters.

25:35
Lisa Clark: So then you can still change your tag name in the UDT or change an alarm in the UDT or change a setting in the UDT, and it still propagates down to all your instances because the parameters don't overwrite that. And that's another fun feature of something of using Ignition's tools so that you can maintain that strength and that standardization of a UDT. The last example I'm gonna go with is going back to the PLCs a little bit talked about how they literally talk in different languages. The protocol of whatever end device you're using. Allen-Bradley's, Emerson rocks, what have you. It's a perfect world. Whenever I've seen a SCADA system where they're like, "We use solely one protocol," that's amazing, that's awesome. It's just not what we see typically. So the kind of marrying the tags, the core data that we talked about a minute ago, and marrying the HMI, this is gonna be the most challenging, but is also the biggest bang for your buck. I guess for your operators, your controllers, your training, and your maintenance throughout the system or throughout the system's lifecycle is trying to keep all your control screens, your face plates, and everything protocol-agnostic.

26:49
Lisa Clark: This is normally like the utopian; the end goal of a standardization project is: How can you do that? And I purposely chose this crazy, chaotic one as an example rather than just like a simple valve control or whatnot because this one took a lot of time. I was talking about at the beginning where Ignition has a lot of those examples with the least amount of time or the most cost-effective if you're truly trying to solve a large project. This would be the most time-intensive out of all the examples I'm walking through today. Because this control screen let me look at it real quick. This is for those that are in oil and gas; this is a Totalflow. I can tell you that this is a Totalflow one based off of the tags like we talked about, they talk differently, but we worked with the customer in creating one control screen that would be used across all their protocols.

27:43
Lisa Clark: And the only thing that is changing is the behind-the-scenes of the timestamps. Because some end devices are gonna use hours, minute, seconds. Some of them do it all in one tag. Modbus will do it individually as well. So this is where you just use your HMI standardization to keep it all looking the same, whether the behind the scenes is or not. So sometimes if you're using a different protocol, you may have, whenever you hit the submit button or the send the actual control we'll send the end device differently. And this is a huge helper for whenever you are working in a large system that this customer or this project probably has around multiple hundreds of operators in the fields. These were all moving and acquiring, and the oil and gas... Sorry, I'm trying to make this not industry-specific, but it really doesn't help with this example.

28:41
Lisa Clark: They're acquiring and selling wells a lot, meaning that operators are moving between customers or companies. So they are either learning how to do a plunger control on a Totalflow, and then they have to then learn how to do a plunger control on a SCADApack, and then a plunger control on another product. So a lot of training time goes into play with the end operators, and going back to our change process, those are the folks that are gonna be our end users. That's who we are working and creating products for. So we wanna make sure that they're not hesitating or frustrated. And so this is gives them one clear control panel no matter what protocol they're working on. So I'm almost to the end; I know I'm checking too, so I just wanted to end with nothing is more important, more permanent than a temporary solution.

29:35
Lisa Clark: I've heard this so many times. Whenever I'm in a HMI workshop, "Well, Lisa, let's just do this, and then we'll come back to it in a month, and then we'll standardize, I promise." So I always like to end a meeting or interject this in whenever somebody's trying to combat a roadmap and be like, "Guys, as soon as we do something, as a temporary solution, I can promise you we're gonna see that in five years." So goes without saying on standardization projects. All the temporary solutions are permanent. So yeah, that's it. I think we have some time.

30:14
Ryan Senanse: Awesome. Thank you, Lisa, for that amazing presentation. And now we get to turn the tables over to all of you. So we're gonna have a Q&A session. Lisa can answer some questions that you have. We have our wonderful mic runners in the back. So if anybody has a question, please raise your hand and we'll send a mic over. And I know we also have some questions from the livestream.

30:36
Lisa Clark: Okay.

30:36
Audience Member 1: So on standards, if you have, if you're looking to standardize something and you have disagreements within your group, because you know both ways are good, you don't wanna really raise a support ticket to IA, where would we, you know, what's the best way of going about that, getting solutions?

31:02
Lisa Clark: So remediating between two stakeholders, like whose opinion matters?

31:04
Audience Member 1: So for an example, say you have two machines. One is they're almost identical; one's just slightly different. And you're creating UDTs. And one solution is to just like not have a module in it. And the other one is to just slap and use some inheritance, right? And the other one is just include it all-in-one and have that module disabled. What's the better solution? What's the trade-off? That kind of thing.

31:36
Lisa Clark: So in my line of work, where everything is changing nonstop, assets in the field are changing, my always go-to whether the solution or the technical solution is better, cleaner, more expensive, more time-sensitive. I always land on what's the easiest to maintain. What solution is the easiest to maintain is normally going to be, in the long run, your most cost-effective. Even if it takes an engineer, says this solution is the best solution, but it's gonna take me three weeks to develop it. It may not be what the end customer wants to hear, be like, I want solutions today, tomorrow. But that's normally how I pivot the conversation. Like, well, let's take a step back. If we spend three weeks now, is that gonna be the easiest for you to maintain moving forward? That normally wins the argument.

32:24
Audience Member 1: Okay.

32:26
Ryan Senanse: And then, so one question that we had like submitted was, do you have any recommendations for getting buy-in for standardization initiatives?

32:36
Lisa Clark: Yeah, so that's, okay, good. That was goes back to that question is maintenance. So normally maintenance is the number one key or training, training your actual operators. I am gonna go back to, in my experience, 'cause that's the only thing I can present upon is going to be majoratively assets that get acquired or migrated, developed upon. They're moving hands all the time. So getting that buy-in is, you gotta read the room. Is that end customer or that end user here to stay? Is this their baby for a long time, or are they prepping their SCADA system to sell? Are they prepping their SCADA system to acquire more? Maybe they wanna make sure this could be their SCADA system. They have 10 edge devices, one enterprise gateway, a redundant gateway, and a dev gateway, and that's their Ignition platform for the next five years.

33:27
Lisa Clark: They would have a different methodology of how to standardize than a company that has 600 edge gateways and three different front ends with load balancers, and all of them have a redundant system, etcetera. Their buy-in to standardize is going to be for scalability and performance. So that would be my number one suggestion is if you're getting a buy-in for standardization, read the room, understand what their SCADA system is intended to do five, 10 years down the road, because that's really what standardization is meant to do.

34:00
Audience Member 2: Any recommendations for changes after the PO was placed, for example.

34:06
Lisa Clark: Oh, okay. Sorry. Yeah, there we go.

34:09
Audience Member 2: Yeah. When the buyer or does not specify details for standardization and the supplier had something in mind when they quoted and we do try to integrate with the current solution that does not match.

34:21
Lisa Clark: So your question is, at the beginning, you're doing the project; they didn't mention or have requirements on standardization. You're mid-project, and it's becoming an issue.

34:31
Audience Member 2: Yeah.

34:31
Lisa Clark: Change order. I'm just kidding.

34:33
Ryan Senanse: Yeah.

34:35
Lisa Clark: No, I'm just kidding. That's where it comes in. If you're an integrator or the one implementing, you're gonna bring that level of expertise to the table, whether they asked you or not. And that's what they're hiring you for. I've heard that as well is, "Hey, you know, you are the SME; you're the subject matter expert. You should be telling me how to standardize," and they're almost right. So with your experience, I would say definitely keep learning and keep implementing new systems; try new tactics. Like I was talking about the parameters on the instances. I'm not saying I've done that on every single system. I've probably done that on a handful of them; keep learning and bringing those best practices to the table. But yeah, legally or commercially, you gotta do a change order.

35:18
Lisa Clark: But as engineers, as we all are growing with the Ignition platform, things are gonna change with 8.3. There goes that change process. I know it's gonna take me a while to learn it with whatever those changes. So you're gonna have to just continually perfect your implementations and keep changing, and they'll understand 'cause it's the technology is ever-evolving. That's probably why they're going to Ignition because they're noticing that it's the SCADA systems in general are evolving, and they're wanting to go down that path either with you or bring it with them.

35:51
Audience Member 3: In your talk, you mentioned UDTs, which has been around in control space for a while, but there are a couple other topics that you mentioned: Unified Namespace and also metadata. How do you implement those in a meaningful way so they're actually bringing value to the projects above and beyond what a UDT would normally bring?

36:11
Lisa Clark: Yeah. So I've seen that challenge in general for going across industries. Unified Namespace was not meant for an asset that is moving. I work mainly in assets that move. So it's very hard when a customer says we want a Unified Namespace. We want the cell; we want the assembly line methodology where they came from manufacturing and they're now in SCADA or the other way around. Scenes where the, you know, an oil and gas person such as myself going into a manufacturing space, you have to learn the industry. It's all different. So that's one thing that I normally bring up whenever a customer says we want that buzzword UNS; we want Unified Namespace, which was like the buzzword a few years ago now the buzzwords AI. But we wanna Unified Namespace. I normally say, "Hey, let's take a step back.

37:03
Lisa Clark: Let's read why the UNS was developed and how that's best for you." And normally the answer is marry it with metadata. When I say things are moving perfect example is operations. Physically, our operators are moving, driving from site to site or remote and into site to site. It's not like they go up to a manufacturing facility and the cell, once you build it, is built. The compressors are getting moved from East Texas to West Texas, but we wanna follow that compressor. Well then none of the metadata with that compressor follows because all of it with, it was about the lat and longitude was in East Texas and the company who maintained it was in East Texas. What have you? So that's kind of where I kind of take a step back and say, "What do you want out of the UNS?

37:53
Lisa Clark: Okay, what you want?" You just want your tag names to all look the same. That's not the exact tag path where a true traditional UNS system is where your tag path is perfect needed for MQTT, where you have to have that structure as well. We normally say, "Is MQTT ever in your lifespan? Is that in your five years from now? Is that in your 10-year plan from now?" Let's go ahead and plan for that as well. Going back to your question about maintenance, maintaining a system down the road that is intended to or hopefully maybe they're doing a cell modem project to get off serial to go to cell modem so that two years from now they can go MQTT, go ahead and plan your tag paths, your instances, what have you, as best as you can so that that transition down the road becomes the best and most fruitful scenario for you.

38:45
Lisa Clark: But going back to your original question about UNS, I would suggest that is where your merriment of metadata is gonna be the most leveraged because normally just pull out and ask them what they truly want. That's the hardest question, 'cause sometimes they don't know what they truly want. And that's where it goes back to your question about being the SME is sometimes you have to say, "Hey, your peers, what we've seen, our best practices you hired us for this, is we've seen a lot of Ignition systems that implement it this way, or we see a lot of SCADA systems that implement it this way," and go through the pros and cons with them. Yeah.

39:23
Audience Member 4: I have a question. So and in all many executive top management, people, they have this idea that they want to have one system used everywhere by everyone, right? So, and to me, it's a little delusional because, in reality and there is such a thing as a over standardization, and if you do too much of it, it just hinders innovation, right? And so my question is, do you see that, and how do you balance that between standardization and innovation? Because if you go one way, obviously it's not good the other way. Also, it's not good. So how do you handle this balance between standardization and innovation or recommendation for like uniqueness in a different areas?

40:12
Lisa Clark: Yeah, so I'm gonna answer that two different ways. Two different ways that I see it happen is I kind of hinted at the, on the protocol-agnostic slide. It's amazing whenever a customer says, "Hey, we have 500 wells and they're all controlled the exact same," it's like, "Wow, that makes the integrators life super easy." That is utopian, but there's no way that every single well acts the same just as if you're in manufacturing. Not every single building acts the same. Not every single process is the exact same. So you do have to kind of take a step back and say, "I'm not gonna solve this at the UDT level, or I'm not gonna solve this at the PLC level. I'm gonna solve this at the HMI level," so that you can be fruitful or change how you operate the site itself physically.

40:56
Lisa Clark: You can't handcuff them down to this is the only way you can operate this site. So I agree with that. So that's kind of that's how I would take a step back and say, "Well then let's just standardize how you control or react." 'Cause reaction time in a safety-critical world is very important. So I would just focus on standardizing that if it's more important for you to be innovative and fruitful and ever changing at the field. The second way I am gonna answer that is that's normally why a lot of our customers are going to Ignition is because it's ever changing. There's other SCADA platforms out there that have not changed. And that could be why that's their SCADA master plan, is that we're moving to Ignition because we want to be able to attach our ticketing system to it. We wanna at easily attach our production accounting system to it. We want to easily attach snowflake to it or something of that nature. They're normally going down that Ignition path already because of its innovation, and ever life-changing, and the ease of adding in external interfaces.

41:57
Audience Member 5: So as a system integrator, one of the challenges that we face is with how fast this industry is evolving and we're always creating a new standard, right? So from your experience, how do you manage within a system integrator company communicating those updates to the standard? Say like you change the way you present a certain graphic and you want all of your systems to have that. So you make one change, and then all of a sudden you have 50 systems that are out of date. How have you managed that or seen that accomplished in a meaningful way?

42:34
Lisa Clark: So you're seeing communicating within your own company, like, "Hey guys, this is the new way we're gonna do valve."

42:40
Audience Member 5: Within your development team. Yeah.

42:43
Lisa Clark: Okay. So we have a very tight development team. Luckily, a lot of comradery and team members and associates talking. So hopefully we're normally innovating. We are actually changing all the time. I wouldn't say we've probably kept a standard between two to three projects with the intent of continually learning more and pushing for changes, right? What have you seen on this project? What have you seen on that project? Let's powwow together and see pros and cons; what have you? But process-wise, what we've done to make sure that everybody is understanding because we do have our Ignition team is probably 60, 80 engineers in total of our SCADA team. So there's no way we're all gonna know what we're doing on a day-to-day basis. So that is a struggle in itself. But we do have some processes in place.

43:39
Lisa Clark: A lot of things of like any time a project is closed or at a milestone, 'cause some projects never close. If it hits a milestone, we do a lot of lessons learned, which has a very derogatory, like, everyone's like, "Oh, you must have messed up. You had a lessons learned meeting." We try and bring it as, no, we're always learning. We are engineers. We're developers. What lessons can you learn? And then we broadcast that out to the team, and that normally starts the development track of, "Oh, I heard so and so had that hiccup on another project." So we're just trying to continually add processes to make sure our developers all hear one another are doing because we are all over the United States.

44:17
Lisa Clark: We have two main brick and mortars, but we have remote workers up to Pennsylvania, to Florida, to Denver, to California. So it's not as easy as, "Hey, everybody, get in the conference room; we're gonna talk about this." So that would be is try to implement some type of process to where you have communication throughout your development team and not keeping your developers in bubbles. I've seen that as some, actually at my previous employer, like we stayed together as developers and we were together for 5, 6, 10 years. We like to try and move people around for that reason.

44:54
Audience Member 5: Thank you.

44:54
Lisa Clark: Yeah.

44:56
Ryan Senanse: Awesome. And so unfortunately, we are out of time today. Big thank you to Lisa for giving us the presentation.