In this episode of Control Amplified, Jim Montague is joined by Dennis Brandl, principal consultant at BRL Consulting Inc., co-chair of the OPAF standards working group and chair of the technical architecture sub-committee. Brandl and Montague discuss the history, goals and news from the Open Process Automation Forum.
Transcript
Jim Montague: 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 topic 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 Brandl, principal consultant at BRL Consulting Inc., and co-chair of the Open Process Automation Forum’s standards working group, and also he’s chair of the technical architecture sub-committee. 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.
Dennis Brandl: Well, I’m glad to be here. I’m glad to talk about this.
JM: OK, first off, a lot of people 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?
DB: Sure, yeah. The nuts and bolts of it, pretty straight forward. The concept here is to talk about opening up, what technically 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 thats catchword, or catch phrase, is basically making standards work. So, they don’t necessarily develop standards, but they take those standards and promote them and push them. So, they 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, and 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.
JM: Right, and back in the 80s, 90s and even today, there’s a tremendous amount of proprietary protocols and technologies and stuff, and their interoperability was not possible. So, OPA and OPAF are trying to get beyond that to, you know I think it’s been described to me as being like your stereo. You know, you could just plug in the speaker cables and that’s what we’re trying to have the process control systems get to, right?
DB: 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.
JM: Alright, so then, just to get a little bit of history, how did this come about? Can you summarize the basic events leading up to what’s going on with ExxonMobil and Lockheed and OPAF’s efforts?
DB: Sure, yeah, yeah. There has been a lot of work over the past decade, essentially, as people were looking at different control system architectures and environments and started thinking, OK, how can we take advantage of some of these?
What happened at Exxon is that they had, 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 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 Ok, 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 ExxonMobil. 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 OK, 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.
Read more: OPAF expands membership, releases O-PAS Version 1.0
Now, simultaneous to that, ExxonMobil 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, OK, these concepts, we know they’re going to work, we’ve 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.
JM: 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’d probably be good to let folks know what they all cover.
DB: 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 see it, 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 tasks, we are simply saying that if you want to have device A 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 newer ones are also based on other standards that are out there.
Part Two of Version One really deals with security, because we recognize that if we don’t design security in 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 as new threats show up.
Part Three of Version One is basically 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 OPAF Communications Framework. And what it defines is the functionality for interoperability. One of the issues about OPC-UA is that it’s 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. It 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 DCNs, 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 selected a standard red fish, which is more on the IT-side of it, that gives you the capability of saying, OK, I need to find out is this device running, what’s some of the statistics or some of the information on it, like is it running hot, is the temperature too high, does it have a fan, is the 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 a red fish and how those would be managed. So, think of a OPAF 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.
