Jarie Bolander: Hello everyone and welcome back to the OT crowd. My name is Jarie. That's David. Unfortunately, our colleague Andrew couldn't make it today. We're trying to figure out the best way for schedules. Unfortunately, since he's in Germany and we're in the US, it's a whole thing. But we're gonna figure it out. In fact, I think we're we have it figured out. So you will see David DeBari: Yeah. Jarie Bolander: his handsome face soon. so we David DeBari: Yes. We need a smiling face present. Jarie Bolander: need your smiley face. Exactly. So This is part four of our five-part series on what is OPA. And what we're gonna talk about today in this episode is kind of the parts of it, a little bit more of the structure and the mechanics, you know, like what is this all about? How does it get checked? And then we'll talk a little bit about some field proof. But I'm gonna sit here and let David explain it because he's the one that's the The out of all of us the expert. David DeBari: I lived through some of it. Yes. All right. Jarie Bolander: Take it away, David. David DeBari: So so let's talk about how open process automation is actually defined. there's the open process automation forum, which is a a group that's put together it's a consortium of industry participants, it's vendors, end users, academics, some other interested parties, and The purpose of the forum is actually to create what's called an OPA specification. And we call it the OPASS, but the specification is broken into parts and it's sort of a functionality part-by-part section. We call it a standard of standards because the idea is that we don't create any new standards that don't need to be created. We just adopt standards that are accessible and adequate for the requirements as specified. you know, we want manageability and cybersecurity and interoperability and interchangeability and portability and there's a there's like 27 attributes but you can imagine that trying to trying to do all this but so right now the opass is actually nine parts nine defined parts in the very first version since the the opath group the forum started in 2016 they created a version one and version one is parts one through five parts one through five are talking about the basic architecture, the technology expectations, the attribute list, if you will. But it also defines what are the cybersecurity requirements, which are very important. What are the manageability requirements, which are also very important if you have a system. And then the third part was that that really rang through on the first set was what we call the OPA. communications framework. And what that really translates to is what is the network protocol and topology expectations. So in the cybersecurity part, what we defined was that IEC 62443, the NIST based and IEC adopted protocol set for how would you define cybersecurity for an automation system. Very important there. there's a lot of minimum requirements. if you know sixty four four three very well, they have security level requirements, one, two, three, and four. and in the forums OPAS document, the minimum level that components are to have is called SL two. SL two is a dedicated adversary. SL three is where you get into government sponsored and SL4 is actually nation state type actors, but SL2 is the minimum requirement. and so this everybody should be familiar with 62443. If somebody says it, you know that's cybersecurity in today's world. And it defines things from everything from you know you have to have role based access control, you have to have authentication, you have to and and some parts of it actually say when you build code, You should follow certain procedures which allow for you to build safe code. the second part is the manageability. And with manageability, obviously, you have this how do you know things are well and and things are good in your system? And and you can get diagnostics. So one key piece of that is redfish. And people say redfish, what is redfish? Well, in the IT world, redfish is a name for what is actually the grandchild. of SMP simple network management protocol. so if you've ever tried to connect to a switch or a computer and ask, you know, what's going on, how much disk space, what how's port 17 doing? that's the tool. Well in the entering, you know, in the years since SMP, there was a an ICMP and now Redfish. So Redfish is the grandchild of that that capability. You can use SNMP as well. And and there's some other tools that people use for management. But the idea being that you ought to be able to know what is in your system and its status, that it's running and it's version it's running version 17.2 of some software, that it's got this much memory and it's using this much memory kind of thing. what we normally do for diagnostics for systems, and these are system level diagnostics. There are diagnostics for I.O. and things like that, but they tend to be more related to the proprietary tools at this time. the third piece is the OCF, which is the network. And in the standard, OPCUA is called out as the standard. And it can be client server, there's also pub sub. And with the new advent of OPCUA FX, we're going to get some of the capabilities to universally access things like IO and channel and and set you know parameters and configurations for those and diagnose and see how happy the card is and the port is and the you know all that stuff. but this is really why the standardization is very important. Doesn't matter what system you have, if you use the standards and everybody is using the standards, then you don't have any interoperability integration issues. how do I collect all the data? How do I create? How do I diagnose a problem? Is it I/O? Is it the card? Is it a power supply? Is it a controller? Is it a piece of software? Is it a computer with memory errors, whatever disk errors, whatever there may be, network issues? and the idea is that the standard does that. So in version two, we we took and added a data information model to be used. For the OCF. So OPCUA, we use a structured model, which is not just a simple value. It is the value, a timestamp, and a quality bit. And with that, you know exactly w when the timestamp on the data was. And and the quality bit, of course, is whether you should trust it or not. We're all used to that in systems today. So it's not just the data. And then we added three other pieces, which are very interesting. And then most of this comes out of the PA DEM standard as well. And those are the the high and low engineering range and the engineering unit. So if you think about it, it's a structure of you know of VTQ value timestam quality plus high and low range and engineering units for the value. In this case, you don't ever have to worry about, gee, is that up? 100 and zero to a hundred C, or is that a zero and a hundred and fifty C? It comes with the data. and that is very valuable. Jarie Bolander: Okay. David DeBari: And and in the automation world, this has been a decades-long battle about scaling Jarie Bolander: Really? David DeBari: because remember, we do like 24 volt four to 20 milliamp. Well, four to twenty milliamp is zero to one hundred percent. So what is the engineering assigned unit assigned to zero? And what is the engineering unit signed to 100%? And that's where we run into these, you know, problems where you get into troubleshooting and you realize it's supposed to be zero to a hundred degrees C, and somebody somewhere made it zero to a hundred and twenty degrees C. And so, yeah. Exactly. Jarie Bolander: Yeah. Well it's like units for you hear all the like d you know decimal to or I'm sorry, standard to metric like, you know David DeBari: Right. Feet versus meters, you know. You don't wanna know how to crash a a spacecraft into Mars? Mess that up. Yeah. Same thing happens for our processes. You gotta get it right. Yeah. Jarie Bolander: Or yeah, or not have a not have a a mirror. It's crazy. Yeah, and it it does seem well mean what's interesting about that in in which I mean seems obvious, but again, what do I know? that you're David DeBari: Well yeah. Jarie Bolander: like debugging something in the middle of the night. You're like, okay, what word is this? David DeBari: Well, we realize it's it's the problem we've lived with for so long. You know, Jarie Bolander: Right. David DeBari: some physical sensation, pressure, you know, and a lot of things it's not really pressure, it's it's stress or strain gauge type stuff. It's converted to milliamps, and then milliamps is converted to a digital value. And so what's the value supposed to be? there's a whole lot of mathematical conversion going there. And we're humans, we mess it up. And so the second part of the version two standard. that came about was we defined that you could use IC six eleven thirty one as the programming language as the first one. And that is what we're all familiar with. You know, it's been 30 years since the PLC and DCS vendors agreed to the eleven thirty one standard and they you know they've added the six along the way here. It used to be just called eleven thirty one, but six eleven thirty one and we're all familiar with the six eleven thirty one dash three language components, ladder logic. function blocks, sequential function charts. there is instruction lists and and structured text. now the instruction list piece has kind of been deprecated. It still exists in some places, but in other places they've gotten rid of it. But structured text people are very familiar with. Ladder logic's very pop popular. Function block is also, you know, a more object oriented modern programming method. And then, of course, for sequences, the SFCs. That's the standard. there is a second part of the standard, which is six six fourteen ninety nine, which is a function block standard, which is event driven. it was actually created by the the folks who were the leaders of the 61131 group, realized they had missed some parts, and so they went back and IEC gave them the 61499 designation, and they did this. it's really great for state-based control. it has been used in the field as well, and it's just not widely available or adopted in industry. the 61131 is what everyone has used used for the last 30 years. and the the last part was there was a physical standard, which is basically says. Hey, your computer has to have network ports. And it and it ought to use the RJ forty five and it ought to Jarie Bolander: Ha ha. David DeBari: be able to talk gigabit networking and that kind of thing. it's kind Jarie Bolander: Right, right. That's pretty funny, yeah. David DeBari: of interesting. We didn't wanna define what products look like. We just said that need to have these kind of features. Jarie Bolander: W well, I mean it's like anything. Like this is the spec of the thing, like, you David DeBari: Right. Jarie Bolander: know, a mouse or a pump or whatever. It's like common connector like, you know, XYZ, which which makes sense. David DeBari: Common connectors, common plugs. Yeah. Yeah. Yeah. Jarie Bolander: I mean that's what standards are for. So you can interconnect things. That's the whole point. David DeBari: Well, we wanted to get away from proprietary connectors if possible. And and Jarie Bolander: yeah, that's yeah, it's horrible. David DeBari: devices not having enough network ports. it's hard to do redundancy when you have one network port. Jarie Bolander: Right. David DeBari: and so these are the things that we've decided if we're gonna build a modern system, we're gonna design and and call out the standards, we might as well call out what's what physically's gotta exist. Jarie Bolander: Yeah, I mean and I think what's interesting about all of this is that, you know, in the IT space, electronics, you know, David DeBari: Yeah. Jarie Bolander: all of these are standards like Ethernet or whatever. Exactly. I mean just imagine if they were random, right? Which Yeah. David DeBari: Wait, they all have to be 19 inch rack mountable? Yeah. yeah. and and that is the automation world. I mean the DIN rail is is pretty standard, but there's a whole lot of backplanes that are not standard. And Jarie Bolander: Right. David DeBari: and they're just, you know, product size. And Jarie Bolander: Yeah. David DeBari: and you say, well, okay. Now we did not specify size, weight, power, those kinds of things. We did say is it ought to be twenty-four volt DC because that's pretty industry standard. Jarie Bolander: Yeah. David DeBari: you know, when you Jarie Bolander: Yeah. David DeBari: get into the the IoT world, you get into the 3.3 volt and some other weird voltages, but because we use 24 volt Jarie Bolander: Yep. Yep. That's just chip voltage, yeah. David DeBari: DC, let's just make it that. and so that was sort of the you know, the there's always the 120 you know, there's the the AC power capability, but in in our world it's really the DC world. so you know, we don't try and narrow it too down. We don't wanna stop innovation and ability to for people to create their own products and have their own values for customers to want to buy but we said it ought to at least have these features. and so that that's yeah, it really and actually it is. We do not want to over specify. And that is Jarie Bolander: Well it's like the minimum set, right? Like here is the minimum capability to to talk to each other. Yeah. Right. David DeBari: a an argument we have regularly in the forum because some people want to specify everything. And it's like if you do that, then it's like describing the same thing. And now it's not a product with IP and innovation. It's a commodity and it's something that no one even thinks of I mean, what shape is a ball, right? I mean okay, football. A American football is is oblong and you know, maybe a rugby ball is you know, it's it's oblong. But but most people when they think ball, they think baseball, basketball, soccer ball, you know, name it, volleyball. It's round, it's a sphere. Jarie Bolander: Yeah. Yeah. Right. David DeBari: and and so that idea of not over specifying comes up regularly. We don't want to inn we don't want to limit innovation. And then there's actually a a further end that we're doing it used to be called version three, but it's now gonna be probably a version two point something. And that's where we add application portability and orchestration. So now we're getting into the more complex areas of a system that actually touch many of the other parts. For example, the the last part, part nine, is the orchestration section. And it's and if you ever try orchestration, you can't go back. You don't want to go back. You can't unlearn what you now know. but exactly. It's t yeah, that's right. Right. It in in twenty twenty Jarie Bolander: Well, I mean it's like in the IT world, you know, co kuber kubernetics and spinning up servers and virtual machines and like you're duh, we've been doing this for fifteen, twenty years, yeah. David DeBari: six it's table stakes for being in the game, right? If you can't do orchestration, it's like, why would Jarie Bolander: You can't compete, yeah. Yeah. David DeBari: I use your product? Jarie Bolander: Yeah. David DeBari: Well, in automation, we've been doing things manually for so long. Why? And and so and but orchestration has to use cybersecurity because you don't want things to happen that aren't authorized. it's got to use the diagnostic tools to do detection of a situation that's not normal or or actually, you know, ad adverse to the system's health. And these are the big pieces. So in all these parts, the interesting part about the open group is that the standard has to be tested for conformance. and it's really interesting. You can't self-certify. in my own experience, very early days, the TCP IP standard was coming out, and the actually the fiber F O I R L standard was coming out. And I was talking to these switch vendors and I'd ask them, and they were all TCP IP compliant. And then I'd ask one of them, do you do Telnet? And they said, no, not yet. But you said you're c fully compliant with TCPIP. And they said, We are. It's like, but you just told me you're not doing Telnet. Okay, fine. The next vendor I talked to, Telnet, yes. How about file transfer protocol, FTP? No. Wait, you told me you're fully compliant. And so this idea as an end user, this is frustrating to no end. so what the Forum has done is decide we have to have these all third party validated and checked and tested and certified for conformance to the standard. If the standard says X, they can do X. If the standard says not Y, then they don't do Y. This is, you know, and these standards are standards from the OPC Foundation, the 6443, the Redfish. So the standards are, you know, the features are defined in the standard. And we just say, well, prove it. If you want to claim it, Jarie Bolander: Yeah. David DeBari: prove it. Jarie Bolander: Yeah, I mean sam similar with USB, similar with Bluetooth, similar with Wi Fi, similar with pretty much any like IEEE standard, you know, even UL conformance and compliance or whatever. Yeah. I mean of course, right? Like safety is always about that. David DeBari: Right. Exactly. And we're very used to that idea, like UL and other safety stuff. But when yeah, when you're using a protocol and they call it open and then you realize it's open as long as it only talks to the devices from the same company. That means it's Jarie Bolander: Ain't open. Yeah, in the same stack. David DeBari: open with like a membership card. yes, Jarie Bolander: Or worse, you know. It's particular reversion too, that used to be a problem, right? David DeBari: So we had that in some OP early OPCUA R and D that I was involved in. And one vendor did not support a very common data type. unsigned 16 bit integer. And it was like, What? Well, we never use it. It it gets used everywhere by other people. Well, we don't need it. Yeah, but if you're gonna be interoperable, you do need it. Jarie Bolander: What do you mean? I mean, gosh, that's yeah. David DeBari: So the conformance checks are done. We've the forum has identified labs and sources for conformance. cybersecurity, NIST has a you know, ISCI has agreed to perform the set of certification steps because it the the forum calls out the important parts for the automation system, but not everything. Because it is not, it's component certification, it is not system certification. 6433 has a system capability and it has some vendor things which are a little out of bounds. I think that vendors need to do that, but for the standard we're looking at, it was a subset. So ISCI was gonna do that. The OPC foundation has testing capabilities, companies that do OPC UA testing. So you can get your OPCUA tested through them. there are some labs that have been set up to test the redfish. you know the the first one was the the Eardy lab doing over in an Australian at a university doing this testing. So this basically says your redfish will interoperate with anybody else's redfish if you use it. Your OPCUA will interoperate With anybody else's OPCUA if you're certified. The cybersecurity capability means you are actually doing all the things that are being asked of the SL2 level as a minimum. So that is the conformance checks. And what happens is the the forum actually reviews the certification information and allows a vendor to claim adherence, compliance with the standard, Jarie Bolander: Yep. David DeBari: and then they can. use a actually they get a symbol like a UL symbol or a T U V symbol or whatever. There is a forum, OPA forum symbol, and they have the legal right to claim it. and Jarie Bolander: Cool. David DeBari: the the forum keeps a registry of those companies and products that have been certified. and all of this yields exactly. Yeah, no it Jarie Bolander: Yeah. No, I mean that's pretty cool. Yeah. I mean it's has has to be able to do that. Yeah, you have to be able do that. David DeBari: it's it's a it and having never been involved in compliance processes myself when we went through this as the forum one, there's a lot to it and there's a lot to doing it right. and and so Jarie Bolander: yeah. Hundred percent. Hundred percent. No, there's there's so much. Yeah, I mean and you know, I'm glad you laid it all out. I mean, obviously that's a lot to to to to to capture and to think through. but we wanted David DeBari: It it really is. It really is. Jarie Bolander: but we wanted to kind of lay it out and have you kind of go through go David DeBari: Uh-huh. Jarie Bolander: through that just because, you know, a lot of folks, you know, you may or may not have to go through it or if you're just curious, but yeah, I mean I think I think what you know in the next part, part five, David DeBari: Foundational. Jarie Bolander: we'll talk a little bit more about what this all means and we know where it's been deployed deployed in in the field, but it is David DeBari: Okay. Right. It Yeah. Jarie Bolander: pretty it's c it's it's complicated yet not complicated, I think is the way I like to put it. it's really right, right. Right, correct, right. David DeBari: It's trying to make it very unc uncomplicated, easy to use, and the foundation is for the open process automation, the foundation is the standard and compliance to the standard. Because Jarie Bolander: Right. David DeBari: we know if the standards work and people follow it gets Jarie Bolander: Right. David DeBari: easier. Jarie Bolander: Right. One hundred percent. One hundred percent. Well, thanks David for taking us through that that David DeBari: Yeah. Jarie Bolander: I know a little bit tricky sometimes and maybe a little bit more detailed than most people want, but you know David DeBari: Well, if you wanna cure insomnia, I'm gonna tell ya, reading standards documents, wow. It it's interesting. It's a it's I I have a lot of respect for these people who have done it for for decades. And I've worked with some of and it's just like, You've been doing this wow, this is hard. It it's almost Jarie Bolander: Pretty pretty pretty much, right? So yeah, we have to write this stuff. I know. It's crazy, yeah. It's it's insane. It's insane. David DeBari: as hard as firefighting problems in the plant. It's a different kind, but it it's important piece though. Jarie Bolander: Yeah, exactly. Exactly. A hundred percent. So thanks again for for joining us. this is part four of our five part series on what is OPA. Next up is part five. So I hope you'll listen to that. And thanks again for listening. If you like the show, rating and review wherever you like it, wherever you get your pods, and we'll see you next time.