speaker-0: Hello everyone and welcome back to the OT crowd. My name is Jarie, and that's David. And this is part two of What is OPA and our little mini-series on OPA. As everyone knows, OPA stands for open process automation. We're big fans. David was on the committee, the whatever.

speaker-1: Massive from the subcommittee.

speaker-0: Everything.

speaker-1: Got to be a a co lead of one of the subcommittees and standards are fun.

speaker-0: Yeah, fun. Fun and air quotes. for those of you just listening. So so part two, we're gonna talk a little bit about get a little bit more in the in the in the nitty-gritty and talk about this idea of you know the vision of it and this idea of standard of standards, which is pretty, pretty powerful. and then yeah, we'll get to it. So David, why don't you take us through this part two?

speaker-1: All right, so so let's start with what open process automation really means. there is a stated vision for what open process automation could be. and I will tell you that its vision is that a standards based, open, secure, and interoperable architecture will allow for bringing business value and technology insertion, which ultimately lowers the lifecycle cost. So the total cost to ownership gets better. in the end, that is the business purpose for OPA. we need systems that are more secure, we need systems that are better at being interoperable, and in our efforts as automation people, it's always guided by what is the business value? how can we apply technology to the problems and issues that we're trying to solve? And make the economics look better for a business. That's why they invest in them. It is a tool. So the open process automation is really has a foundation of a standard and we call it the open process automation standard and opass for short. it is a standard of standards. So the goal behind the forum was to let's not build any standards ourselves if we don't have to. Let's use what's already out there, what already brings interoperability and security and is well accepted and and proven to be useful. as an example, some of the standards we have in for networking, we use OPCUA as a protocol. and a lot of people have used the OPC classic and we know that it was superseded by OPCUA actually many years ago, almost 20 years ago. when UA came out. Its adoption is more recent as people have gotten into using it and and needing the capabilities. for the cybersecurity, of course, there's the IC62443, which everyone is very familiar with. hopefully if you say 62443 in a room, everybody thinks cybersecurity. but this comes from NIST and the the adoption around the world of this is how automation systems should be more cybersecure and that's everything from processes and systems that vendors use to the tools and techniques for implementing the system. Obviously in the control logic world, many people are used to the what's called IEC61131. And it is almost 30 years old. And it's really interesting because I was around when that happened and it it was sort of a standardization of what a lot of the vendors products did. and there is a newer standard called 61499. and it is a function block standard, and I would call it a superset of 1131. And if you ever read it, it's a pretty short standard, but in one place it actually refers you to go look at 1131 languages out of the 61131-3 document. So I that's why I call it a superset. the data model we use in OPCUA is based on PA DIM. So you can kind of see what the forum has done is created a standard of standards. And and the nice thing about that is we don't have to create them, we just get to select them for their interoperability and cybersecurity and their capability to be open. and that's sort of what we do. The standard the standard of standards is a valuable thing. everybody wants standardized capability. And we need to really get away from proprietary or lockdown capabilities because they are holding us back. So the standards are there and the open process automation vision really provide what we call some core priorities. and we in the document and standards document actually read them as attributes and interoperability is the first one. And how many automation vendors have spent what seems like years of their life trying to get A to talk to B. and it seems to be a lot harder than it ought to be. interoperability is is a kind of the the big challenge for an automation engineer to master. interchangeability is another capability and that's the idea if a fuse blows, you know, nobody you know nobody asks whether you're going to use a little fuse or an inner bus fuse. They just work. If you need a half inch bolt, you know, it has to be the right length and has to be the right kind of metal, but a half inch bolt fits where the old half inch bolt came out. and we have a lot of things that have very proprietary connectors. They don't interchange. landing a wire under a screw terminal is about the only interchangeability we get. maybe the RJ forty-five for the for the network. For the network, yeah. Everywhere else is kind of like nope. You gotta have this make and this model. because the form factor and everything else, it's it's kind of crazy. but in the OPA view of the world, things ought to be more interchangeable. that way in the middle of the night, when you don't have one on the warehouse shelf, you can get one that will work. obviously, if you had could get the make and model you're interested in, that's great. But sometimes you have to do with something else. And then you start getting into Adequacy and the rule is equal or better than what you're trying to do with it. And the last core priority is portability. And this comes from the idea, and this is from the end user perspective. You spent time and energy and money engineering a solution, and you make a change. Why can I not just copy this? Why can I not select, cut, and paste or Export and import or something like that that we're all used to with our other technologies, you know. But you have to rewrite it. And sometimes you don't even have to re-engineer it, you just have to get into a new tool and recreate it, which is a waste of time and energy. it also makes it hard to share solutions from system to system because mine was built on system A and you have system B. Sorry, this code is for system A. and that to us did not make a lot of sense. as an end user, I was really loved portability. Actually, I mentioned that I was the co-lead of a a subcommittee in the OPAF forum. and so OPAS part eight is application portability. and that was the group that I was leading at the time. So obviously there's some foundational attributes that we cannot ignore. security, manageability, and reliability. This is an automation system. Those are not negotiable. They are not things that we're going to affect negatively. feel free to make them better is always what we're told. but do not make them worse or impact them in some way that is going to cause a problem for the business. so security and manageability and reliability, and I'd argue in today's age, security is probably The watchword for us. yeah. yeah. Yeah. And that that that's physical and cybersecurity as well. Obviously cybersecurity gets most of the headlines. for sure.

speaker-0: For sure. There's been a lot of that lately. I mean, we're recording this

speaker-1: yeah.

speaker-0: in in September of 2026, and I can't tell you how often I'm stuff's popping up that, this got breached and that got breached and this got breached. And

speaker-1: Right. I I just as a public service, if you're listening to this, please, if you have your system connected to the internet without cybersecurity and firewalls and other protections in front of it, please do something about that. Yeah.

speaker-0: Yeah, for sure.

speaker-1: You know, it's it's too easy for the folks who want to do ill to to our systems to get to.

speaker-0: Yeah, I mean, especially in the age of AI. we haven't we haven't talked about AI yet. We will on further or future episodes, sorry, but it is accelerating how quickly vulnerabilities can be you know, like literally like it's your own agent army in the

speaker-1: Zero days becoming zero second. Yeah.

speaker-0: Yeah, exactly.

speaker-1: And that's you know, it I it just does not make me feel good to think about that. what that means is we've got to get smarter and better and we've got to build systems that are based on standards and that are well implemented. and that is how this will get better. Yeah. So so I guess to summarize, you know, the idea behind open process automation. is to define what what all these capabilities and attributes and cores and the vision for it is the goal. but in in the end, open automation really equals, you know, you're free to choose. It's yours to own. And it ought to be open to growth and and improvement over time because the world does not sit still.

speaker-0: That is that is 100% true. I mean, we, you know, we were just at the Ignition community conference this week and surprising. I mean, of course, those folks are open by nature because they're using Ignition and that's inductive automation for those of you that don't know. And yeah, I mean, what we've been hearing more and more is that folks do want to be able to build on an open platform and By definition, a platform is something you can build on. and so I would say, you know, it it was very fascinating to see. And it was a great conference. They really do a great job. I think it's their 14th year. It's an insane amount of like a couple of thousand people, I think. and yeah, the theme was how how to build on top of open platforms. And and I'm just curious, like, could you summarize in like one sentence? So you're a plant manager, you're a control engineer and an end user and you wanna use open process automation, like what's the one sentence you're gonna tell your boss about this? Like, is there like ki I mean, obviously we can try to capture it in one sentence, but what what do you think as an end user

speaker-1: kind of hard. Yeah it is. Yeah that that's you can do it. Yeah yeah.

speaker-0: Dave.

speaker-1: so for the the practitioners, the the engineers and technicians who use it and live with it and take care of it, support it, what I would say is open process automation brings all the tools and capabilities that you've been asked to implement, that you've wanted to implement That you've dreamed that someday it will be better. and having an architecture built on the open standards is really going to give that to you. It gives you choice and better tools and and capabilities that are well thought out and and standardized. if you're a plant manager, the number of times the automation people have had to tell you no. when you ask them to implement some business capability, some use of data, some new advanced technology that will you know, drive profitability up and you know, cost down. And and these are regular demands, by the way. Any all the practitioners are gonna recognize this. and some of them you they're they're you know, they read the latest stories in the in the magazines and the books and the And they say, okay, how can I do this in my business? And for the plant manager, if your environment adopts open process automation, the answer never has to be no anymore. There's not a limitation to what is possible with that infrastructure that's based on open standards. there's no proprietary lockout, lock-in, lockdown, whatever words you want to use. the prison

speaker-0: Sentin'.

speaker-1: yeah, you can't get that here. You can't put that here. Right, right. and you don't and in and there's a couple other business aspects that are implied by open process automation as well. In many systems, when you start talking about advanced control and some other things that the system vendor did not provide, their first rule is don't put it inside our system. So what you're done what you're stuck with is putting it next door. It's in another network, it's it's on the other side of a firewall or a router of some type, separ segregation, separation. Open process automation says, well, bring it in the house. Put it in the kitchen, put it in a living room, put it in the basement, stick it in somebody's bedroom. It doesn't have to be outside the house. you get all the functionality and features, but you don't have to keep it out of the house because it might somehow. affect the proprietary system. It's an open system. It doesn't have those problems. so for somebody who's leading the business, you get choices and you never have to hear the word no. This kit won't do that. and for the the practitioners, you never have to say no to management. You start saying yes. nobody likes to say no and and after a while they get tired of hearing no and

speaker-0: They do.

speaker-1: they do The more you can say yes, and you get to do some cool stuff. You finally get to implement some new new technology, new capability, go solve, go be the hero. Yeah. good

speaker-0: Yeah.

speaker-1: stuff. Make it make it easier for your your operators to be successful today, running that line during their shift. I personally took that as my view. my job was to make them successful for their shift. Yeah. Come in, be safe. Do the best they could for the company, do their job without the hassles, and then go home safe and with a good feeling. They got things accomplished, they met the goals, they met the you know, what was expected, and they didn't have hassle and pain and you know, go home with a headache kind of thing. It's you know, the stress of it is some days. And and that's really it. It's OPA is is here to make things a better. A better model for an architecture, the one we really want.

speaker-0: Awesome. Awesome. Well, hey, David, thank you so much for that. That was part two of what is OPA. in part three, we're gonna dive a little bit more into the architecture of what it is, what the components are, et cetera. Right. And you'll you'll notice that Andrew's not here today. He's he's on break, so we miss him. You know, come back soon, Andrew. but yeah, we'll we will see you next time. Thanks again for listening.

speaker-1: Thank you.