speaker-0: Hello everyone and welcome back to the OT crowd. This is part three of our What is OPA series? And in this series or in this particular episode, we're gonna talk about architecture. Yeah, all that geeking out stuff. just so if you don't remember, my name's Jarie. That's David. Andrew's not here today. He's off. I don't know where he is. He's probably having fun or something, knowing him. No, I'm kidding, Andrew. We miss you. Come on back. so yeah, so we're gonna talk a little bit about the architecture. and if you're new to this series or you're new to the podcast, this is a part three of our five part like mini series on what is OPA. We figured we'd do that first since some folks don't know what it is. So, David, let's talk a little bit about the architecture of OPA.

speaker-1: Yes. So hopefully everybody's learned to spell OPA. open process automation. it is a a new architecture based on standards. and so when we start thinking about the architecture of an automation system, I I sometimes hear people talk about DCS and PLC like they're some magical device. and As I have gotten deeper into OPA and worked with the standards part of development of OPA and the f and within the OPA forum, we meet other you know vendor representatives and end user representatives and even some academic representatives. you start to really sense that this idea that and automation is special. It's done great things for for industry. But Sometimes people think there's something magical about a PLC or a DCS controller. And and where I would like to start with folks is if you actually open one up, what you're going to find, it's got a computer chip in it. it may even have computer chips you're used to dealing with on your desktop, and and other computers in the business world. the The systems are running 64-bit chips. They might be R ARM. They might be X86. the AMD Intel variants, they may be something else, but they are modern and they are computers. And so that a PLC and a DCS is really a computer. And if we we focus in a little deeper into what's inside the box, it's a computer that has an operating system. It has applications. One of them is the control logic thing that you've picked for it to do. the vendors provide this as sort of a big black box, but in the in inside of it, what you'll find an operating system and applications. It's got network ports. So you know it's got Nix and it's got some capability to communicate protocols. the software uses APIs. The security is built just like the computer system that may sit on your desk or you carry around in your backpack. the comparability to what a IT thinks of as a computer and a computer system and the automation system are very, very similar. Now, let's be clear, there are OT sensitivities. This computer is connected to a machine that's got energy and momentum and chemistry and may be involved in containing materials that are not safe for humans if they were to escape their containment. this is an important piece. This is not a a data system or an email system. so so we've got to treat it slightly differently. Yeah.

speaker-0: Yeah, you just can't reboot it.

speaker-1: No, no. Yeah. Power cycling it does not the chemistry as as I would say sometimes to the the IT folks in our interactions in the Plans like yeah, my my computer cabinet or my my system over there, if I shut the computer off, my system will land four blocks from here. Yes. after maybe experiencing a instantaneous pressure induced dismantling. which were legal words for well you know what that means. Right. you know, fire, release of material, gas, whatever the

speaker-0: Okay.

speaker-1: The thing it's a bad day. It's a bad day and it becomes very dangerous for the human beings in the in the you know versus the computer room problem. But in the end, the PLC and DCS is a computer system. and it's got all the components of every other computer we work on. that actually simplifies the kind of problems we're trying to solve and moving to standards. another thing about when you look across the system. The difference between a control system and say a a regular IT computer is the life cycle mismatch. we have wires from the field. If you take care of those copper wires, they might last 80 to 100 years. that's that's kind of amazing. the wires themselves could outlive many of the people who work on them. the I.O. and the applications, you know, I/O generally You know, two decades, three decades. At some point you start getting in the new technology. I mean, APL is an excellent example of of a modern technology that's coming. I remember before the four to twenty, you know, when we had four to twenty, they had one to five and zero to ten. And then after four to twenty, we added heart to it. So we know it's always changing. in the middle there, there was some field bus. And and it's very interesting. The goal is to always make it better, but in the end, the IO will last you several decades. Software, somewhere in that 10 to 15 years, you're going to run to the end of its capability. you will either be thinking about new capabilities, the versions themselves, the technology itself is going to change. So here we have something that, you know, somewhere in that, you know, maybe as low as, you know, maybe eight to ten years, but you're gonna be doing upgrades and updates, obviously, more frequently, but at some point. The technology we use today will become the old way of doing it. that is the truth. Don't fall in love with your technology because today's cutting edge stuff is going to be some somebody's junk someday. I actually had the opportunity to work with RS two thirty-two and and some other older technologies, Coax Network Cable, Decanet for those who remember digital equipment. and those were good days. But don't make me go back to that now. and then you get to the computer. And we all know about computers. We all have our our desktops, our portables, our even our cell phones are computers, and our tablets are computers. And we know what a five-year-old cell phone portable, you know, looks like. It's something to be updated. and by the time you hit seven or eight years. You know, somebody's crying about updating it. So here we have a lifecycle mismatch across our system that doesn't seem to make sense. this is how we get into the rip and replace problem. The only answer for changing the computer is you have to change the I/O and the software. So now you're stuck re-engineering your application to do the same thing it did on the old system. Your I.O. talks to the same wires, but They had to be relanded. the good part is maybe the wires get to stay, but there's a lot of activity here. basically because the lifecycle mismatch. Now, what causes that is the fact that everything is tightly coupled. the software goes with the hardware, which goes with the I.O., which goes with the form factor and the size, and the only thing that may be common is the denrail, how you mount it. The 24 volt DC power maybe is common, but a lot of it is so tightly coupled, the only answer is take it all out and start over. It's 2026 as we're recording this. This idea is nuts. loosely coupled is what the software pieces ought to do. Abstraction between the hardware components will make life easier. The idea that you can buy a phone and use the charger you used on the last phone. you can use your mouse and keyboard in the new computer and probably even use the monitor. It's got the same HDMI port on it or or a a modern connector. why don't we have this with the automation world is the big question that we asked when we started all this. We cannot live in this world where things are tightly coupled because it handcuffs us and it costs us a lot of money. we can move to a system that maybe is continuous evolution. And so when we look at what the components are in open process automation architecture, then you start to see where you know loosely coupling things and separating dependency and abstracting away the, you know, connections to interfaces that live beyond the device's lifetime is the way to go. at the heart of an open process automation system is the ability to control the process. And that is done with a controller, if you will. Now, the the terminology we use in open process automation is called a DCN, distributed control node. and I was part of the group that gave that name, and and we can all argue whether we like it, but what we didn't want to call it it was a PLC or a DCS, because it can do either. It is a computer. That runs the control algorithm. And by that, I didn't name the control algorithm. I said a control algorithm. But it is a computer, it has an operating system, it will be network connected, it will have memory, it will maybe have storage, which would be kind of new for a PLC or DCS to have usable storage like a computer. But the DCN is a computer that does the controller function. It is connected to something we call. The network, now in the open process automation terminology, we call it the OCF, which is the open process automation communications framework. it's basically the protocol and the data model and capabilities in the network that are required of an open system. OPA forum in its standard has chosen OPCUA as this as the protocol standard. it is widely known, widely accepted, has a lot of capabilities for cybersecurity, and has a lot of capabilities to solve different kinds of automation problems, whether they be, you know, the client server type or the published subscribe type. they've adopted and and started to do more of the time sensitive networking capability. So we started getting into scheduling and timing of communications because As a system, control is the priority. So that kind of messaging would obviously you'd want it to be first and take priority in the network. Now, in many systems, there is a place where the engineering tools are kept, where the databases are kept, where the app non-control applications might run. As far as engineering tools, obviously control logic configuration, HMI configuration. things like data historians, you might have data brokers that send data to the cloud or wherever other the business system, if you will, wherever they want the data in the form they want it. You may also have other applications for optimization or advanced control. And so that system we call the advanced computing platform or ACP. And think of it as the server world. or server end of an automation system. Most DCS systems have a server or two involved. PLC systems sometimes have that the portable PC that the engineers and techs haul around. That really is your advanced computing platform because it brings your tools and your capability to your system. And with the OPA system you have a choice of how you might implement that ACP. It can still be mobile. But if you're going to do a lot of things on it, sometimes it starts to make sense to actually have it as a central resource and something that's more like the the IT's hyper converged infrastructure models. you can have backup capability and redundancy and all the other things, but it also does a lot of things that let's face it, the IT world does the A C P functionality very, very well. You

speaker-0: Hundred percent, yeah, they're really

speaker-1: know, it might be a bunch of VMs, it you know, you could set VMs up on a on a portable if you really had to. But at some point You have a system and you have this capability. adding to that, obviously, you have the the applications you might use, the HMI, the control, those are the core pieces. Obviously, everybody wants their data. So historian functionality, time series data gathering, you know, other data analytics capabilities. now to tie all that together and make it much easier to use, because one of the things that we've always said. the the end user community, why don't we use some of this great technology advance to make it easier to live with? And so for those of you who have not heard the word orchestration, I'm going to give you the automation definition. It's a process operations for IT people. Orchestration is the automation of the tasks that we have to do. And when I say automation. I'm not talking about simple scripting. I'm talking about intelligent automation, the capability to detect the a situation or a change from normal and repair it a ability to take a data set and build out a system, deploy, detect what's in this environment and bring it safely into the fold of the community. It's everything from basic configuration to cybersecurity setup to the rules and the capabilities that are set for you know role based access control and where the certificates held and and even joining a safe secure network orchestration will give a huge capability. For those of you who have not used it, once you see it, you cannot unlearn or unsee what you've seen. You're not gonna want to do it without role

speaker-0: I mean if you've talked to your IT guys or any of the guys doing like SaaS apps or, you

speaker-1: Right.

speaker-0: know, all that, clo any kind of cloud stuff, I mean this has just been standard practice for

speaker-1: It's a it's an amazing we we I yeah I I before you know in the past I I worked on a R and D project and we actually could take we could literally cut the tape on the box, pull the computer out, the the I P C we were gonna use for our DCN, mount it on a den rail, power it up, apply all the software. secure on board it into the network so it was an equal member and partner in the network. It had all of its certificates and had all of its cybersecurity set. It knew how to talk on the network and it could talk to the IO in eighteen minutes. From the minute I open the box to running and talking to IO eighteen minutes. Try that with a PLC or DCS system.

speaker-0: won't work. Yeah. I mean that's the promise, right? And

speaker-1: Right, right. Depending on the you know, in the replacement scenario you can do it fairly quickly, but even then eighteen minutes is pretty fast. you know, if it's a greenfield installation, this may be days or weeks worth of work setting up stuff. And the idea that orchestration can configure the proper addresses and the proper VLAN and the proper certificates and the proper you know, connecting to the the the the DNS and the domain controller for all the security and the the groups and the OUs and the all that.

speaker-0: All that stuff that IT does.

speaker-1: The stuff that takes, you know, at a command line or in a in a nice tool, it is clicking forever and the system just does it for you. This is the winner. orchestration is one of those tools that we need a lot more of an automation. and this is all based on You know, the separation of the components, loosely coupling the software, using APIs, using standards, not proprietary you know, inventions or whatever. This is, you know, OPC UA. It's really interesting. The controller and the IO don't need to know who each other are. Correct. Because in the end, it's just an OPCU UA server or client for data. Now, you've got to know how, you know, when you when you send it something for card seven channel nine, you need to know there is a card seven channel nine. And and that all still exists in the engineering. But the but the reality is by separating these things and and and you'll notice that we've sort of separated I.O. from the the controller as a a paradigm. There's nothing wrong with having IO connected to a controller, very typical classic. PLC DCS model. But in the end, if you lose your computer, you can't talk to the I.O. And if you have redundant communications on your I.O., if one computer can't talk, another one can. And so this abstraction of I.O. from compute is just a a natural evolution for higher resiliency and reliability. doesn't mean you have to live in that world, but you'll keep paying the price for the the tightly coupled IO and compute basically if your card gets zapped by lightning or something else happens to it, you gotta go get the same make and model. Right, right. And and this this this creates other issues, but so that that's I think the you know the idea is that the a PLC in a DCS is not a unicorn, it's a computer. It's a specialized computer. I would argue, why does it just have to be a toaster or just a blender? the IPC has capability. many of them have multi-cores. You run your control logic, but on the side you can run your optimization, you can run your loop tuning, you can run your advanced control maybe. you might run some local data logger instead of if you lose your network connection, you're not actually losing your data.

speaker-0: Right, right. I mean, I think it's the the the flexibility and I I do like the whole idea of you know we're separating out core components that have one different life cycles and two may have different demands put upon them. And it's almost it it and maybe you know, in my opinion, making those redundant or having it ways that you can you know, if if something goes wrong. Right. You're not y you don't have a single point of failure, I think is the way maybe the way

speaker-1: And and that's really the way to think about it is don't tightly couple things together so one little problem takes the world down. Right. Right. we all know that, you know, in the o the automation system we don't want to lose control. Correct. And we don't really like losing a visibility. Right. you know, we know the controller is running even when you go get the coffee or heat your lunch up, but the the reality is we like to see it happening. And I'd argue that we need a third piece of that, which is we don't want to lose our data anymore. Right. So if you're upgrading your historian software or you're you've got something else going on on the server that it sits on, why is it I I lose the data? and so I think in today's technology and loosely coupling the applications and separating the dependencies and separating the life cycles will allow you to evolve and change and modify as you need. And this goes back to that idea of You know, you choose when you're gonna do this. The system is for the end user. it should grow and evolve and change as the needs change, as the demands change. you know, I've I've often said, you know, in many times you're looking at a controller provided by a vendor and they don't make a bigger one. And so if you found a or they don't or

speaker-0: Make it anymore.

speaker-1: or yeah. But the the idea of the if you If an engineer came up and said, I really need to have that digital twin thing running right here, I can go get a bigger computer. Right. right. I can upgrade networking as time goes on. I can upgrade and add IO as necessary and not worry about the limits of the the bus locally coupled I/O, you know, only so many cards. I don't have that problem with remote I/O. Right. you definitely gain Some efficiencies and some capabilities. In the end, it will lower the total cost of ownership. It'll give you some choice. it will allow you to say yes every time your your plant manager or your boss comes in with some some idea, something article they just read, some book they just saw, some some news feed they got, this latest, greatest thing that's gonna make the company millions or billions of dollars. And you can say, Yes, boss, I can do that. Yes, boss. Well that's awesome. That's the that's technology.

speaker-0: Perfect place to end it. Like, yes, boss, right? So thanks, David, for the overview of the architecture. this is part three of our five-part series on what is OPA. if you're new to the OT crowd, please give us a rating and review if you like what we're doing. We're just here to help out. and until next time, thanks for listening, and we will see you later.

speaker-1: Thank you.