speaker-0: Hello everyone. Welcome back to the OT crowd. My name's Jarie. That's Andrew. That's David. And what we're gonna do today is we're gonna start our little mini-series on OPA. And the first thing I'm gonna ask is Andrew, what what is OPA?

speaker-1: Yeah, so OPA is open process automation. It's the idea of opening up automation to not be quite so proprietary and locked in. and the way that we do that is through standards. now for the most part OPA is not really introducing that many new standards. it's actually a collection of best practices through the industry. a lot of people will call it the standard of standards because if you read through the spec, half of it is just referencing other standards that already exist. there is a little bit of new things that the spec defines, but it's kind of few and far between and what just where where you where you need to specify it so that things can stay consistent. the different systems can work together. So there's some networking profiles to make sure everybody can speak the same protocols and some information model stuff to make sure everything everybody's speaking the same information model when it comes to opc UA. And Yeah, so it's the attempt to make it so that you can easily upgrade and integrate new systems as systems grow and not be fixed into any given hardware system, any given software system, any given network system. so that in the future, when in 30 years when that product doesn't exist anymore and you can't get it. you don't have to rip out your entire system to be able to replace that thing. You can just replace that one component software system, whatever it is that's inside. So that's kind of really the what OPAS is, is is just this mix of standards that we're trying to define what we need to be able to do this interchangeability, exchangeability capability.

speaker-0: And you you mentioned OPAS. So there's OPA, open process automation, OPASS, open process automation standard, right?

speaker-2: Yeah.

speaker-1: Yes. And then there's also OPAF, which is the forum. So

speaker-0: Open process automation forum.

speaker-1: Exactly. So it's run by a a group called the Open Group.

speaker-0: Okay, a lot of open going on.

speaker-1: A lot of openness. but i it gets it gets interchangeably mixed. People say opaf when they mean opass and opass when they mean the forum. I do it myself sometimes by accident, even though since I was co chair I probably shouldn't. but I am guilty of it sometimes. but yeah.

speaker-0: Cool. So yeah, thanks for the overview. David, why don't you dig a little deeper in since you know, you were there at the beginning, the what is it, in the before times and now in the after days. Yeah, why don't you take us through Skunkworks? Yeah, take us through a little bit of what it is.

speaker-2: The early days. The early pre skunk works. I'm I'm gonna just add on to that last point that that open process automation is fully buzzword compliant. We have our full set of acronyms. so we're capable of being in the automation you know discipline. We're we're good.

speaker-0: Bingo card is full.

speaker-2: Right. So open process automation, it basically as Andrew stated, it it's this idea that you know why do we have systems that we don't have interchangeability, interoperability? It's I mean this integration of systems and data has been the lifelong struggle for many of us older engineers. because of the protocols that we had at one point, there were vendors who actually didn't talk certain protocols because they were from another vendor. and that's kind of insane in today's world computing. but the reality is that the the interoperability, interchangeability problem has plagued us since the beginning. And some of that was just the nature of how do we build computerized automation. So but now that we're you know much more mature and wiser, we really need something like open process automation. You know as as a basic definition, you know, open process automation really represents an open, standards based, interoperable, secure automation architecture. A way to build systems where you get more choices in the products and components you use, whether they be software or hardware. the early days we we struggled with well what would that look like? And and we arrived at this this idea of the standard of standards. Why should we create anything new when standards already exist? What we should do is go select, you know, put together an industry consortium to select the standards that sponsor and and allow for this interchangeability, interoperability types of attributes. And if you actually read the OPA standard, the OPASS documents, what you're gonna find is a list of attributes that are things like modularity and portability and interoperability, intersecurity, manageability. and these are all critical aspects. And so OPA really says, all right, so here we are, 2026, and we should be able to use some of the technologies from 2026 or at least more recent than the nineties or the eighties or What at least whatever your technology is actually based on today. Right. Right.

speaker-0: Right.

speaker-2: Let's let's get to modern computing. you know

speaker-0: Let's at least get to twenty ten. I think if we get to twenty

speaker-2: I'm I'm shooting for more like twenty twenty at least because I think you know there are some things that have happened in the last ten years that are actually very powerful and and bring us a lot of value. And and and now you can see them in systems. So open process automation really is this it's a it's the idea that we can have systems that are interoperable, interchangeable by standards instead of by the heavy lifting and engineering and and patching and mapping and all the fun stuff we've done over the years to make this talk to that. and I I I think, you know, those skills were very useful, but I don't want to actually go back to And and now we have open process automation. We have vendors who are embracing the standards, they're realizing how it works. The form has some very interesting the standard is not only a specification of the standard, but it also leads to certification and compliance checking. Right. So the idea that somebody says that they can do something, it's it's not no offense, Jarie, but it's not marketing or advertising. It's it's real, it's been tested. So yeah, I mean it you we all know this with like electrical stuff. You can't buy something that hasn't been certified. Yeah, you

speaker-0: Yeah.

speaker-2: Exactly. These days a lot of systems are gonna have you know gonna need components and capabilities that are certified anyway. If you buy a safety system, it's been certified. pretty soon cybersecurity is likely to fall into that bucket.

speaker-0: For sure.

speaker-2: already is the standards. That's right. The the governments and regulators around the world are starting to say you can't just do what you want. You gotta do best practices and saying that you are ready and not really being ready is no longer adequate. It's not safe to the businesses. It's not safe to the end users. and that's really, you know, cybersecurity is actually sort of a safety topic in many ways. And and these are what hopefully the open process automation set of standards, the concepts, the ideas and the products will bring to our marketplace. No. You know, and no offense to the the vendors for what they've done for us for forty, fifty years. But it's a different time period now and we've we've really got to make some changes.

speaker-0: Yeah, the times they are a change in. I think Andrew put it, or maybe you put it. this is the USB for OT, or I'm probably we probably stole that from someone else. But right, I mean, makes sense because I USB, you know, when I did that back in the day, we had plug fests, we had compliance, you gotta be certified, you stamped it. And right that nice thing about that is okay, now go build your system. Go, go do things that might like the value add is in solving the problem, not My proprietary, you know.

speaker-2: So I'm gonna date myself. I actually was around when the TCP IP standard was gosh

speaker-0: rat of gosh. Really?

speaker-2: Yes. Wow. So I was talking to these network guys because I was gonna build one of the first networks in the company I was working for. And I and it's like, do you know, do you do you know TCP IP? yeah, we're gonna do TCP IP. So I start down the list. Do you do Telnet? no, we don't do Telnet. Well, you just told me you're TCP compliant.

speaker-0: Yeah.

speaker-2: They're like, Yeah, but we haven't got tel networking yet. I'm not sure you Yeah,

speaker-0: Can say that.

speaker-2: yeah. I and and and then the next vendor showed up and do you do telnet? yeah, we do telnet. Do you do FTP? No. Wait, so so that as actually the the new world is we've got to, you know, end users. have to know that when you plug this together, if you go to Best Buy and buy that mouse or keyboard, it plugs into the USB port and it works. Now you can buy the one you want, you know, the ergonomic one, the cheap one, the the fancy one with lights, whatever you want. But they plug in and they work. And and that is the kind of world that we want, both from a physical connector as well as software connectors. And we know in the software world the APIs are are king and The IT world has mastered them and the OT world is still trying to figure out how to make them work some days. and and that's that's kind of what we want to change.

speaker-0: Interesting. Yeah. It's I mean

speaker-2: Let's make it easy to build systems and get back to making processes run better, more efficiently, more profitably for the the companies that are using these systems.

speaker-0: Yeah. Yeah. I know Andrew had talked about we were talking about Apple. I I couldn't figure out if it was like the thunder cable, the fire wire c or whatever. I I don't know, whatever, but like like your point was like yeah. Lightning. There you go. Lightning. Yeah. Yep. It

speaker-1: Yeah, so Europe Europe recently made it illegal to put anything but USB C. there I think it's a few caveats, but anything but USB C on any device.

speaker-2: Imagine that common charger cable.

speaker-0: I have a there

speaker-2: the

speaker-0: filled with I don't how many of these silly cables it like which one?

speaker-2: Yeah. Yeah.

speaker-1: It's good for the consumer, it's good for everybody, it's good for the environment at the end of the day. to have one standard cable.

speaker-2: It's it's all over the world. Yeah. You think it's

speaker-1: Cheers.

speaker-0: Pretty.

speaker-2: yeah. These these this kind of standardized existence is what you know. We have batteries that are standard. Yes. Or you know, we have connectors. We have the the audio connectors are pretty standard. It it the the video connectors are pretty standard in in the other technology worlds. Why doesn't automation have some of this? And the screw terminal for landing a wire is your your basic adequacy there, but yeah.

speaker-0: I mean it's time. I mean, I can't I mean, I don't know this for a fact, but I mean, this is one of the only industries that doesn't have

speaker-2: It is one of the last ones that has such high content in non-standardized proprietary models. and it's funny because in the automation world, we're working in plants and sites that have a lot of other areas. And you know, in the early days, one of the conversations we had is well, why is it the guys with the pumps and the motors just specify a a horsepower and a frame or a you know a footprint? The valves fit within this this size. And for us the answer is yeah, just take everything out of that room, gut it, yeah, and start over because now it's some new stuff and yeah. This idea of standardization is it's due.

speaker-0: Yeah, just imagine if we had to like screws or bolts weren't standardized. I I mean it used

speaker-2: Exactly.

speaker-0: to be. I know. Well the other thing

speaker-1: Hand done.

speaker-2: Machine.

speaker-0: Yeah, back back in the before times. I mean, even something as simple as the connection to a fire hydrant was not standardized. really. yeah, yeah. There were six hundred different vendors for the connection to a fire plug. Because in the US. And the reason is in the US back then, this was in the nineteen hundreds or roughly, fire departments were private. You you had to pay each fire department or a fire department to come save your house. It was not a community thing. so you they so what would happen is there was they put a little plaque on your house. The fire department would roll up, they'd look at the plaque, like, well, if there's no plaque, we're not gonna do anything. So then they're like, you know, probably be a good idea.

speaker-2: Yeah. I worked outside of New Orleans and I had a peer who actually helped with the canal system in New Orleans. And they had these old pumps that had they were just odd frequencies and voltages. Yep. Because they were hand built back in the day before we agreed to, you know, in the US sixty hertz and you know, the the iterations of the hundred and twenty volt AC stuff, you know. Yeah. It was just odd.

speaker-0: It is, right? And the tragedy of these, I was just doing some research on this, but the tragedy of having all of these different connectors for fire hydrants, again, silly, right? There was proprietary for each community. They'd have their own. People would obviously made their own. and then there was a I think it was Baltimore. There was a fire in Baltimore, and it was like a big, nasty fire, like it's consuming

speaker-2: What's it coming in?

speaker-0: like an entire block, blocks and blocks. They called for what's called mutual aid. This was in like 1907, 1908 or something. They called for mutual aid. All these fire departments came with their equipment and they're like, we can't connect to the fire agent. They just let the whole thing burn. Now they actually built a standard. I think they call it the Baltimore standard to be like, we're gonna standardize so everyone in the US has got the same connector. So you fast forward like eighty some odd years, and in my neck of the woods, I'm in San Francisco, California. There was the Oakland Hills fire. I'm sure you've heard of that in eighty nine, ninety.

speaker-2: Yeah.

speaker-0: Called for mutual aid, all the way from Nevada. Called for mutual aid. Got there. They couldn't connect because Oakland didn't upgrade their fire hydrants for the common connector. So no. I don't know if you

speaker-2: And nobody brought a bag of adapters, right? 'Cause that's

speaker-0: They didn't have that

speaker-2: the world the automation people lived in and you had a you had a bag of adapters because you never knew what you would run into. But can you can imagine?

speaker-0: Well, okay. I mean, if you saw the pictures and and maybe I'm I'm probably gonna write an article about this because I'm I'm trying to do this narrative of like why standards matter. But I remember like I was in the Bay Air at the time and I was a private pilot. So I get my pilot's license. And so after the, you know, the fire and everything, I actually flew to that out of St. Carlos airport down in the peninsula. I flew and I flew over the ridge. Literally one side completely gone, the other side there, right? But you just you realize you're like that entire hill, and then like I don't know, 20 people died or something. Like, and it was reminiscent of the firestorms in LA. Like the wind picked up, took the whole side, right? And again, mutual aid in a crisis, they show up and they can't connect to the water.

speaker-2: That's gotta be just right.

speaker-0: Right. Now, not saying that that happens in obviously in O T, but the analogy is so I'm sure, right? You know, and

speaker-2: It has in the past. I guarantee you I have gone to respond to something and realize I don't have the right connector. It's in my desk. Or somebody else has one and I gotta go find them. Right. It this is that this is why standards do matter. And and it's standardization has been a very great tool. Mm-hmm. You can overstandardize if you're not careful. Right. you don't want to inhibit innovation. Right. But you and you know, and the constant march of technology, but You know, agreeing to doing things the same way is a very common thing in our world and yeah, it needs to come to automation. Right.

speaker-0: And it's all about like I'm connecting to other things, right? Like so at the interfaces, right? Anyway.

speaker-2: So it's not as bad as a fire, but I guarantee you the the days in the past where you could not get one system to talk to another because the protocols didn't work, the cabling wasn't the same. god. That I mean, and nobody made a translator or any kind of adapter. It it was kind of crazy. And in and you give in today's world of technology, computing, data flows, it doesn't make any sense anymore. The competitiveness of a a vendor is not based on their their USB C connector. it it just doesn't make any, you know, it doesn't make any sense. That's that's not a I'll call it a reasonable barrier to entry to to keep doing. You there's other IP and other reasons that you can make yourself valuable and and wanted by customers. This kind of thing is just not it. Especially with the other things that do have to be standardized in terms of safety and cybersecurity and and and allowing businesses to use these tools to their benefit.

speaker-0: Right. Well, thanks guys. That was for everyone listening. This is part one of our series. I think it's gonna be four or five parts. I'm not sure. We're just gonna wing it on what OPA is and how you can think about it.

speaker-2: We're gonna keep going.

speaker-0: Keep going. Yeah. So until next time, this is the OT crowd. Thanks for listening or watching. And if you are on a platform and you like what we're doing, rating, review, like. Subscribe, all that funny stuff, whatever y'all like to do. But we're gonna keep on going and thanks again for listening.