 Hi, this is Jim Montague, executive editor of Control Magazine and ControlGlobal.com, and this is the latest in our Control Amplified podcast series. In these recordings we talk with expert sources about process control and automation topics, and just try to get beyond our print and online coverage to really explore some of the underlying issues impacting users, system integrators, suppliers, and other folks and organizations in these industries. For our seventh podcast we're talking to Dennis Brandel, principal consultant at BRNL Consulting Incorporated and co-chair of the Open Process Automation Forum's Standards Working Group, and also he's chair of the Technical Architecture Subcommittee. In these roles he's one of several dozen experts trying to achieve the forum's vision of developing a truly plug-and-play process control system. Likewise, he was also one of many contributors to Control's March cover article updating OPAF's efforts, and that was a tremendous help as well, and so we thought it would be good to get an audio version of this going in addition. Dennis, sorry for the usual preamble, and thanks for joining us today. I'm glad to be here. I'm glad to talk about this. Okay. First off, for a lot of people who are coming at this for the first time, what are the nuts and bolts of the Open Process Automation Initiative, and what is it trying to do? Sure. Yeah. Nuts and bolts of it pretty straightforward. The concept here is to talk about opening up what, classically, has been a relatively closed market, which is the DCS market, and we're doing that through the open group. If you're not familiar with the open group, the open group is an organization that's a password that catchphrase is basically making standards work. So they don't necessarily develop standards, but they take those standards and then promote them and push them. So they've worked on ones that you may know such as POSIX, which is the Interface Standard for Operating Systems, Togaf, which is a standard for enterprise architectures, and FACE, the Future Airborne Capability Environment, which is being used in airplanes around the world, essentially to give you plug-and-play capability there. So what we're trying to do with the Open Process Automation Forum is bring in some plug-and-play openness into the DCS marketplace to basically move it forward from where it was in the 80s, where the architectures were originally developed, to where it can be today with the brand-new capabilities that we have inside electronics, inside software, inside networking. So we're going to make all those available. We're going to make those hopefully creating markets for a lot of different products and a lot of different capabilities. Right. And back in the 80s and 90s and even today, there's just a tremendous amount of proprietary protocols and technologies and stuff, and their interoperability was not possible. And so OPA and OPAF are trying to get beyond that. I think it's been described to me as being like your stereo. You can just plug in the speaker cables and that's what we're trying to have the process control systems get to, right? Yeah, exactly. Traditionally, the DCS systems, the control systems, even some of the PLC systems have been closed. So if you want to have some of them work together, it's an expensive and a time-consuming process and it's really, you end up with fragile systems. They don't work very well together because everything seems to be custom-made. We want to get rid of that, right? We want to make it like your USB that you plug into your computer and everything seems to work together. You don't have to do any software. You don't have to do any configuration. Yeah. All right. So then just to get in a little bit of history, how did this come about? Can you summarize the basic events leading up to what's going on with ExxonMobile and Lockheed and OPAF's efforts? Sure. Yeah. There had been a lot of work over the past decades, essentially, as people were looking at different control system architectures and environments and saying, okay, how can we take advantage of some of these? What happened at Exxon is that they still have a lot of very old DCS systems because it's very expensive to replace a DCS system inside a refinery. So they've got TDC 2000s and TDC 3000s running. The issue you have there is that these things are well past their maintenance time. We had a saying, if you can't buy the spare parts on eBay, then it's definitely obsolete. And I think that's the situation they're in. So they started a project to look at what are they going to do? Several projects, as a matter of fact. One of those projects was a research project to say, okay, if you started from scratch, if you don't look at your history, how would you design a system today? As a result of that effort, there were a couple of white papers that were written by Exxon Mobile. They talked about the requirements for the system and they talked about how you could address it. And then Exxon realized that this was bigger than them, that it was going to take a whole industry to look at some of these solutions. So they went to the open group to start that work to simply say, okay, let's see if we can take these concepts and ideas that came out of this research project and make them real. And that's what the open process automation forum is. Now, simultaneous to that, Exxon Mobile worked with Lockheed Martin to develop a proof of concept to make sure that these concepts would actually work in real life, in real applications. And that's what they did with Lockheed Martin. So we were able to, in the open process automation forum, look at it and say, okay, these concepts, we know they're going to work. We got a lot of work to do to make them work, but we know that it'll work. We know that from an architecture standpoint, things are going to work together and play together and we'll get the interoperability and the portability that we hope we can get. And then just to bring everyone up to the present, the first version of the open process automation standard, which is O-PAS, was just announced this past February with five parts and it would probably be good to let folks know what they all cover. Sure. Yeah. The first release, it's not a real high bar to cross. The whole concept of this was to get interoperability, to make sure that people could build devices that are going to end up being the devices in the DCS that will actually work together. But it's also, as I said, it's to set the foundation for the next level of functionality that we're trying to define. So that foundation includes part one of the standard, which is a technical architecture. Now I want to make it clear, what we're defining is not a system architecture, but what we're actually defining are interfaces. We're not saying how people should accomplish the tasks. We are simply saying that if you want to have device A to talk to device B or software A, talk to software B, these are the interfaces that you will use to do that communication. Now a lot of that is based today on the OPC UA model, but the newer ones are also based on other standards that are out there. Part two of, I mean, yes, part two of version one really deals with security because we recognize that if we don't design security at the beginning, it's impossible to plug it in later. So we're working closely with people who are on the ISA 99 committee and the 64223 IEC standard to define the minimum security requirements that it would take to build a system because we want this thing to be secure out of the box and we want it to be able to be upgraded and as new threats show up. Part three of version one is basically it's a summary of the profiles. The profiles define the functionality that a vendor would provide to you. So for example, we have a profile that talks about how you perform system management and we've got two different options of how you do that. Likewise, we've got a couple options on the OPC work. So part three is kind of a summary. Part four of version one is dealing with the OPC UA or we call it the OPAS communications framework and what it defines is the functionality for interoperability. One of the issues about OPC UA is it is extremely flexible. So sometimes getting these things to work together, particularly when you have to worry about security and security requirements as well as some of the options associated with OPC UA, sometimes it's hard to get those things to work together. So part four defines the profiles that says, if your system supports these features, these functions, then it should play together right away. Part five of version one deals with system management. Now imagine a system that's out there and it's made up of thousands or tens of thousands of very smart, intelligent, little DCMs, distributed control nodes that are all communicating, that are all executing your control functions in a distributed manner. Well, you need to manage those thousands to tens of thousands of devices. So we've selected the standard redfish, which is more on the IT side of it, that gives you the capability of saying, okay, I need to find out is this device running? What's some of the statistics on it, some of the information on it like is it running hot? Is the temperature too high? Does it have a fan? Fan working, those sort of things that you can use to look at all these devices from all these different vendors in one environment. So we have a couple profiles for that as well. Anybody who's familiar with server farms probably has some familiarity with the redfish and how those would be managed. So think of an OPAS system as a server farm with tens of thousands or thousands of very small servers out there distributed out through the field or distributed through your control systems and you need to manage those. So those are the five parts that came out in version one in February. Man, thanks, that's a great summary and that'll really clear things up for people. But getting a good, and I want to get too deep into the weeds and there's lots of weeds, the OPAS architecture is based on a little bit of specialized lingo and new names for things that are pretty familiar. So could you just let folks know what is a distributed control node and the real-time open connectivity network because DCN and OCN get thrown around a lot, but what are they, how do they work and what are some of the examples folks might know of what those are? Sure. DCN, it was the acronym we came up with to talk about the distribution of control into small devices. As we were developing these, I always would hold up a cell phone and I said, DCN, think of it like a cell phone except it probably doesn't have anywhere near as much memory since my cell phone has 34 gigabytes in it and it doesn't have a screen, but it's got the computing power, it's got a multi-core processor, it's got network capabilities, it's got all this. Now what we want to do is take that and sort of concept the electronics and others that it takes to build that thing and marry it with the fact that we need to bring in IO from signals so we need signal processing and we want to run these distributed control algorithms. So if you're familiar with a DCS, DCS is used to start out where you would build a function block diagram and some function blocks would go in one device and some in another device because the devices were old. This was the 80s, this was the 70s. The processors couldn't do much. Today you can run an entire plant on a processor the size of a brick, but you may not want to. So DCN is the idea to go back to some of the distributed capabilities so that if you have failures, the failure is very limited and the key there is that DCN can be upgraded. So if you can pull a DCN out and put it with its next generation, your system over time evolves. You don't have to worry about a big bang update. But I mean a PLC could be a DCN, right? It could be and the primary different from a hardware standpoint it is. From a software standpoint PLCs tend to stand alone. They don't really participate easily in distributed control algorithms. You've got to program a lot of that in. Our concept is that you're not really programming it because it's all running on the OCF, the OPAS communications framework. That's, as I said, that's running OPC UA. Best way to think of that? It's Ethernet through the entire facility. It's the Ethernet that connects the DCNs together. And then we're using the protocols that are in the OPC UA to do that communication and to make it transparent to your program. So I don't have to program in a data transfer from one DCN to another. All I need to do is reference the piece of data and the underlying system will take care of getting it for you. Cool, and the OCN is like a, I wouldn't say a field, but it's like an Ethernet field. Yeah, I think it's an Ethernet. Right, it's an Ethernet communications backbone. It used to be when you built a DCS, your backbone. If you were lucky you had a 10 megabyte backbone playing, communicating between all the pieces, you know, today that's a slow network. So, you know, we have definitely changed our capabilities over the past 15 years, 20 years. To such a point that the concept of networks are slow, just doesn't apply anymore. Networks are fast. Networks are backbones in a lot of systems today. Exactly. So in the three stories I've done about OPA and its developers, you know, Exxon, Mobile, Lockheed and the other forum members, they're always stressed that they don't want to tell suppliers what to put in their components. You know, they just want to define the interfacing between them. And so, you know, how does this provide the interoperability that, you know, OPAF is seeking? You know, and isn't it just to be a little bit of a devil's advocate? Isn't it also kind of an indirect way of saying, hey, we really need you to build this? Actually, it's more like an indirect way of saying, we really hope you're going to build this. Yeah, we are very specifically not talking about functionality as we're defining the OPAF standards. We're really only talking about the interfaces. Now, these can be software interfaces, so we're going to actually have software interfaces that eventually say, okay, you have to accept a file of this format in order to have your configuration. It's also software and communications interface to say you need to support this model of the OPC UA, whether that's the published subscribe or the client server model. And also, we'll have a physical interface standard. And the physical interface standard probably is getting to more where that interoperability piece is. You know, it would be some size of a box or a rectangle of some kind with some connections on it, some standard connections, some standard type of connectors and power going into it. That's probably a little bit further in the future, not necessarily coming out in the next version but the version after that, but that's where we're really going to help try and get this interoperability, interchangeability, and portability, which are really our goals. Cool. Can you also, now we talked a little bit earlier about the kind of parallel effort that Exxon had going before it, the larger, you know, OPAF effort took off. And they're still working on that. Can you discuss the Exxon and Lockheed, the proof of concept, the test bed, and the pilot projects that, you know, that are paralleling OPAF standards effort? Well, I can, yeah. And I can tell you about what they talked about publicly about those sort of things, which is really basically all the information that I've got on it. You know, but publicly what Exxon Mobile did was they contracted with Lockheed Martin and Lockheed Martin then went out to several of the suppliers that are out there that are actually members of OPAF and said, okay, we want to do a proof of concept. We want to use some of the standards that we talked about in there. And you know, some of those standards obviously was the OPCUA standard. Another was an IEC 61499 set of tools, which if you're not familiar with, is a distributed function block standard. So there are a couple of standards out there for function blocks in the IEC world. This just happens to be one of them that handles distribution and it's event-based. So they use that software. They also did some interesting thing with hardware that they talked about. Raspberry Pi is probably the most popular proof of concept and prototyping piece of hardware that's out there if you're not familiar with the Raspberry Pi. It's $30, $40 to deliver to your house and it's got more processing power than we actually use to launch, no, I don't want to say launch to the moon. It's got more processing power than we use to launch the Space Shuttle programs. But they used some of those as some of the hardware Intel had also provided one of their small little computer systems that were integrated in. And then a couple of the other vendors also supplied some hardware to it. So it was to say, take what you've got, see if we can layer the software on top of it and make these things all work together. That's what they did. Primarily to see whether or not the concept that was in IEC 1499 distributed function blocks would actually work. Part to see if you can get the communications throughput across ethernet talking to these devices to actually run control loops. An interesting statement that they made at the ARC conference was, yeah, we were told we had to slow down our control loops from 10 milliseconds to 20. Those subsistence processes have gone like, okay, yeah, that's gonna be fast enough. Yeah, that's more than sufficient for most process applications. Yeah, absolutely. Well, in the pilot projects, these are physical plants that Exxon and Lockheed are operating to test some of these kinds of things. The first one was the test bed. That's a second one that they've talked about a little bit. It actually is a pilot facility that they use to test out processes and verify chemical processes and those sort of things and control strategies. Yeah, so it's actually gonna be running on what we would probably call a real plant. It's not gonna be using, at this point in time, it's not gonna be using certified products because we don't have all the specs out and we don't have the certification things in place, but it'll be running something real. Well, that'll be something else we can cover as we go along. It's just nice to hear about something physical happening as opposed to stuff just happening in the ether, as they say. Yeah, this is not just vaporware and marketware and slideware and other things are actually working. Exactly, although they certainly are taking over in most realms that we cover and it's a little psychologically taxing for let alone covering it, but for the people who are trying to use it, I'm sure. In addition to that, I think there was a non-plugfest event that was scheduled in June at ISA's headquarters in North Carolina and there was like 20 or 30 suppliers that were gonna test products to see if they could comply with OPAS version one. I didn't even follow up, so I just was wondering, did it happen and can you convey any news about it? Yeah, yes, it did happen. We had 15 different companies that were participating and they brought 27 different, I'm not gonna call them products, I'm gonna call them proof of types, prototype sort of things, to see if their systems would match what we wrote in the version one of the standard to make sure that the things would interoperate. So we were checking the system management capabilities of these devices, as well as the OPCUA communications capability of these devices. Several vendors came in with stuff that was almost working, most of them left, I think maybe all of them left with stuff that, yes, it did only operate, it did work. The idea of this was to get the developers together. Not, I don't wanna say we didn't invite managers, but they were kindly discouraged to attend. We wanted to get the real developers in there I walked into the meeting room and all the programmers are over their computers and laptops looking in a very quiet place because that's how they were doing their work. But they all got it working together and the real goal of it was not necessarily to make sure that the products would work, it was to make sure that the spec was right, that we didn't write any holes and we didn't make any mistakes when we wrote the specifications that existed in the OPCUA and in the Redfish implementations or the specs we had for implementations. So as a result of that, they're making a couple changes, we found a couple bugs in a couple places where they just have to do some minor tweaks to the standard itself. But from that standpoint, it was a very successful interoperability vest that we have, sometimes we call them plug fests and their plan is to have another one later once the vendors start developing real products versus their proof of concepts. And that's a standard thing to do in many fields of endeavors to have these kind of events. Although they were talking about this one, it's a non-plugfest plugfest. And I think it had to be called that. Yeah, they had to call it that. When we do a real plugfest, what we'll actually do is we'll open it up to anybody who wants to come in because at that point in time, the first version of the standards will be publicly available and because right now it's the preliminary version, the official version is coming up in a couple months here. So we'll make the plugfest open to everybody, but right now for the interoperability, it was really just the OPAF members because they're really the only ones that can actually look at the documents before they get officially released. Cool. Well, and here's the shortest and final question so far. What's next for OPAF and the standard coming up? Sure, yeah, and I hope I'm not gonna steal anybody's thunder when I say about this, but the next goal, the next thing that we're doing with version two, which is scheduled for early 2020 is to have portable configurations. So you can imagine that you could have a vendor tool that you use to configure the system and configuring the system includes the definitions of your function block diagrams or your IEC 1131 diagrams and the associated, I'm gonna call it code because I was an application programmer for control systems, but that's the configuration that we wanna make portable so what you can use one vendor's tool to create it and download those configurations into different vendors pieces of hardware and or you could take that configuration from one vendor's tool and put it into another vendor's tool, you know, maybe you have one tool that says I'm configuring alarms and another tool that says I'm configuring function blocks and a third tool that says I'm configuring my IO list and they would all share that same information with a common format. So it's portable configurations is what our goal is. What that's gonna give us quite honestly is the capability of taking a system and saying we can actually control a real system with all of these standards and we can do it across different vendors, different vendor hardware and different vendor software. It's a big exciting first step. We had the version one delay the foundation. Now we're layering on top of that and giving us this portable configuration capability. Like putting the icing on the cake, man. Well, I'm gonna call it the second layer. We still have some. Okay, all right, all right. Well, you know, the whipped cream and the strawberries and the second layer. We're not at that point yet, but we'll get there. But there's a really a palpable sense of excitement of like, man, this might really work, you know, and you can sense from the folks involved how the potential advantages are, you know, unbelievably helpful. Yeah, absolutely. And I mean, it changes the market. I think a lot of people recognize that. A lot of the vendors recognize that and others. But we also look at it and we believe that, quite honestly, the concept of open markets and open systems has changed, you know, other markets quite openly. I mean, you can see this in telephones as to what it changed in that market. Sure. You can see it in other industries. And we recognize the fact that's gonna occur in our industry. Now the question is, we can let it happen or we can help it to happen. We can help drive it. Exactly, and that's why people were excited because they're looking at this thing. We got capabilities we'd never even dreamed of. Five years ago, 10 years ago, just never thought we could do it. Now we can do it. It's gonna make a big change, but we know, at this point in time, we know we can do it. And that's the important thing. That's why people are getting excited. Terrific. Well, listen, Dennis, that was a great update on OPA and OPATH and OPATH. And I know a lot of people, myself included, were curious about the forums activities. So thanks for cluing us in today. Yeah, I'm glad to provide some help and tell you all the exciting things that we're doing. All right, we'll check in, probably do another one when there's even more updates to let folks know about. This has been another Control-Amplified podcast. I'm Jim Montague. Thanks for listening. Oh, and please remember, listeners, if you're out there, to Control-Amplified podcasts are available on most podcasting apps, such as the iTunes Store and Google Play, and it's also at Control Magazine's YouTube channel of podcasts. And you can also listen at controlglobal.com, of course, anytime. All right, thanks everybody, and we'll check in later.