 Well, welcome. So why am I here? We could have kept the secret. We didn't have to tell you anything, but we need your help. So I'm here to tell you more about what we're doing, how you can play a part if you choose to, and also get ready because it's coming. We heard it this morning. It's not if. It's when it's inevitable. So as Harry said, I'm David DeBarre. I work for Exxomo Research and Engineering Company. About seven years ago, I met two guys, came to my site. Steve Bitar and Don Bertuzzi-Tak, we've heard them speak before about OPA and our ideas, and they started speaking to me and I thought, this is crazy, but I am in. I want to do this. I had just done a migration project to the latest and greatest of a particular vendor, and I did not like the process. I had spent a good six and a half months of 12-hour days trying to make it work and telling my managers and all that it will work, trust me. And so when we started talking about what this program was all about and it was about many things initially, this was one that definitely hit it for me. So I'm here to tell you a little bit about where we've been and where we're headed and why. That's not good. We'll do one at a time. How about that? Okay, so ExxonMobil many years ago, seven or more actually, recognized the business problem, that we had a lot of obsolete equipment because think about it, we all put in our control systems in the 80s and we promised our managers, they're going to last 30 years. So 30 years from 1980 is 2010. Uh-oh. Maybe we didn't think we'd be around when this day happened. So the project itself, we decided to focus only on the DCS and the PLC parts of the system. We have specifically decided not to address safety systems. We do know that some of the technologies that we propose and ideas that we have might extend to the safety system, but we also know safety systems generally have a higher bar to clear and it's very important that the vendors who produce those systems do things that are prudent. But we have this problem with the DCS and the PLC systems that we really needed to solve. So think about it. They talk about digitization is happening. We started 35 years ago and we put in all kinds of computers. The problem is we didn't need cybersecurity because it wasn't connected to anything and that technology we implemented was going to be there for 30 years. Well, over the last 30 years, we have wished for better technology and now, of course, we're needing to do something about the old technology. So, you know, many of you will recognize some of these pain points. We want more innovation. We want to lower the life cycle cost. We want to get more benefit. This sounds very familiar to just about every business conversation. In the last two days, I've heard it repeated and repeated and this is very important to us. We also recognize that some of the problem is commercial. Some of it is technical. And so what we propose is maybe we just make a step change here and do things a little differently because if we start replicating the behaviors of the past 30 years from now, some young engineer we're going to hire next year is going to be at the end of their career asking, why did they not solve this problem? So that's our why. So I like that I have seen this picture like four times in the last two days. Some of the speakers have sort of scrubbed the words off of it, but I can see it. You can see the gold color is the new stuff in our opinion. A revision to what we might call the Purdue model or the ISA model, pick your choice. And we use the ISA model for our references, but the DCN, of course, is a small device. We consider it a small device. I have no problem with somebody wanting a DCN as a thousand channels, but I want one that's somewhere around a dozen because I think of it in terms of scope of failure. And if I can reduce the scope of failure and I don't have a control that fails a thousand loops, my process might keep running. The operators usually can deal with small scopes of failure. We also said the DCN ought to be able to do more than just basic regulatory control. The applications that we think about trying to run extend from fast historians. We have people talking about data analytics, Azure at the edge I see in the press. So everybody's thinking about what they can do with an edge device. Well, it's got to be more than just a single purpose appliance. Of course, at the top, we need server class equipment. A lot of us run our innovations there now. We call it the layer three in the model. That's where all the innovation happens, generally a Windows server type environment, but not necessarily. And there again, we say, well, why couldn't we run some control there as well and just talk to some I.O. somewhere in the field? And of course, the tide altogether is a real-time bus. And I made this point last year. If you look at it, we've represented all the equipment we use today as participants in this world. But we've also taken them out from underneath the DCS. They are peers on a network. The data is democratized. I say we put the distributed back into distributed control. Some of these systems need to talk to systems that aren't an operator's problem, which is the process control system. They're going to talk to equipment health or some other business system. And so this model fits that. The data can talk to a control system and operator, or it can go around them and go to the cloud or go to the business system or wherever it might be needed. It's not hindered. I call the DCS sometimes as a pinch point for data. So this is the overall architecture that we envision. Now, this is a concept. It's not how to build it. I think we talk about the Purdue model, and a lot of people went and built systems based on the framework. This is not a absolutely an architecture that we say, go build it like this. We don't want that. We want people to figure out what standards play, how we can achieve the results we're after in a flatter model. Okay. So we did our proof of concept, and I was here last year, and I got to tell everybody how that went, and it was a success. We took 10 different vendors, and we mixed the pieces parts together. We even used some of our DCN concept stuff to form the simulation layer to feed. We actually used physical wires just to prove there wasn't smoke and mirrors. We simulated, so it was all in a lab. We did really use real devices, but they were not as industrial as probably we would all like. But we did do a fired heater process, and we were able to simulate it. We did some advanced controls. We tested out a couple HMI's. We did some simple historian work, and we were demonstrating some capabilities with the system, particularly some attributes we were interested in. So in this, as you can see, we used three different DCNs. We actually used about 50 devices, so it was a big pile of them. I did have a picture last year. If you look it up, you'll see it sort of on the wall. We did use open standards communications of OPC UA and DDS, and we interchanged them just to see how well that worked. And of course, the 10 different vendors, and we do thank them for their participation in that successful proof of concept. So why did we do a proof of concept? Well, we've been told some things were impossible or very hard to do, and so we decided to test it ourselves. Specifically, we were interested in things like interoperability, because integration is expensive. And if I don't have to work so hard at integration, I can make it easier. So if I use standards, maybe interoperability is really easy to do. Sometimes integration is painful as well, as some of us who've worked in the industry know. Some days it doesn't work so well. So interchangeability was another idea we had, because these devices have a different lifetime. We have measured some of our instrument, where it'll probably last 80 or 100 years, but we know the processors are not going to, and the applications are somewhere in the middle. So I am either stuck on the same platform without taking advantage of things like Moore's Law, or I can change the platform and keep my software. So interchangeability is a pretty powerful thing. And we know companies go out of business, companies change names, companies get bought, new competitors come in. Why can't we use them? Interchangeability will give us that. Another attribute that we did was some portability things. So we did configuration and application portability. And so there's a subtle difference there. Configuration portability allows us to keep our engineering and all the money we've spent developing applications. If we could just transfer them from one system to another in some standard form, we wouldn't have to re-engineer. To some extent, you could argue this is the challenge we face when we upgrade our equipment. If we could just simply do some sort of export and import, some minor translation maybe, it should work. In the application world, we would like to have a common environment. So if I could run my application on different platforms, then I get a common environment. And the nice thing is that helps with interchangeability as well. Because if someday device A dies and I have none in the warehouse, but I have a device B and it is adequate to the task, then portability will allow me to install my application on device B, get back up and running, start making money again because that's what the companies and business do. Make the products, stay online, keep making money. We also did some tests of the network throughput. We did some comparison. It was a very simple comparison, so I don't want to make too strong a case here. But the one thing we will say is that there's no one size fits all solution. Everything has its own niche. It was designed to solve a certain problem. So in some cases, we would like to use different methods for communication. But we do want them to be standards-based, not proprietary. Another thing we did was some advanced control. And we were able to demonstrate some control algorithms that we could run at one second or better. And today, those things tend to run in the 15 to 30 second range. So sitting on the same network, talking the same communications protocol, using these very powerful edge devices actually, we were able to show some real benefit possibility there. And so this is some of the why we started this whole thing. We did a proof of concept to show that one, it can be done. Two, that we see benefit potential. Can we realize it? And we've shown that. And so last year, we came and told you about the success that we had with Lockheed Martin in this process. It was very good. And we're very happy with that. So let's talk about the timeline of our project, our program actually. So we started with the proof of concept and that's done now. The prototype has started and that's where we take what we learned in the proof of concept and we apply it to a pilot unit. It is a process, a small one. It has real hydrocarbons. It has real pressures and temperatures of a process nature. It's not simulated. It's the real thing. It has a safety system. So our goal is to push the envelope a little bit, put this in front of an operator, which is a real test. If anybody can find the flaws or the mistakes we've made, it will be an operator for sure. So we're going to move on past prototype and do a test bed. And for the test bed, we're going to, we have recruited some collaboration partners. And the goal behind this is to push the R&D forward, learn more about how to develop a system using a heterogeneous set of components, how to implement a standards-based open, secure, interoperable system and process control system as we've described it. And then we want our collaboration partners along with what we'll do. We're going to go all separate and do our own industrial field trials. And the industrial field trial idea is basically, let's get this stuff, we call it technically ready. Can we use it in our processes? Can we use this on our projects? Is this a choice we have? And so that's the process that we're commencing at this point. As you can see to the left, we've had various partners in the process. The proof of concept, it was Lockheed Martin Next, I'm mobile in the 10 suppliers. For the prototype, we have Lockheed Martin. We recruited Wood as a more field-oriented system integrator and also to sort of cold eyes review, we call it. We'll get a feedback from what they think about this system. And of course, we have a new set of suppliers. I'll show you in a few minutes who they are. For the test bed, we're looking at system integrators more suppliers because we're going to need more suppliers. And of course the collaboration partners. When we go to the field trials, obviously everybody's going to need some system integration. We're going to need some products and we'll go do our own thing. We did agree that we're going to share the information so that everybody benefits from the usage of an OPA type system. Obviously what people do with their system is their own business. So underneath all of this you'll see that the OPA forum is developing standards along the way. And we feel that since we never wanted this to be an ExxonMobil only system, it has to be driven by standards and has to be agreed upon. It needs to be a commercial available system pretty much to everybody. Therefore, the forum was started with the founders and we were one of them. And a lot of people have joined since we're up above 80 now. A bunch of end users, suppliers, vendors, academics, other interested parties, all trying to make a standard of standards that we can have a system built from. So the business guide was released early last year and that sort of describes the roles in the marketplace and people can figure out which roles they might want to play and how the interrelationship between them might work. And that's very important because we need the marketplace. We need our vendors to stay in business. We need them to stay profitable and everybody needs to know what role they might play. Just last week we announced the release of the version one standard from OPA. So we're dealing a lot with interoperability there. And later this year we're looking at the version two and following that with the version three, they will build upon each other and continue to expand the focus of what OPA thinks the system might be. And we feel that once it's version three is tested, then that will be sort of the minimum set of standards necessary to build an OPA conformance system. We have conformance processes that are being developed, some procurement items that are being discussed in terms of how this will work or how it should work. Version three is not the last version because it's designed to be evergreen therefore as technologies change or as other things need to be addressed, there will be a version four, a version five, version six. Maybe there ought to be a dot dot dot down at the bottom. So that's sort of it. We have our program. We are tying ourselves to the forums standards, standard of standards for the OPA system. And we're creating a plan that we can get to what we call technical readiness, which means it's an option for our business to use for projects. So it went too far. Again, this thing's got a hair trigger. So these are our collaboration partners. These folks have signed up to work with us and help us push the R&D forward. And someday do a field trial of some kind. They may be ahead of us. They may be behind us. It doesn't matter. They'll be ready when they're ready. Obviously, the field trials will need system integrators. We probably can't all use the same ones. So there's a marketplace there. We're obviously going to need products to use as well. Software and hardware. And so we will commence this process somewhat in parallel with the prototype. But the prototype will, it's pretty much a static design right now. So it's not going to evolve. It's not pushing the R&D too far forward right now. This is where we're going to push the R&D for with our new friends. By the way, this is not a complete list. We are still considering additions to our collaboration agreements. We would like to prioritize on broadening industry participation and maybe geography. But if you have an interest, you need to speak up because it can't stay open forever. All right. So this is our prototype system architecture. And you might recognize it looks a lot like the POCR architecture. But I'll say it was simplified. This is a real instantiation, so it's not test a lot of things. It pretty much is, let's find something that will work. Find some vendors who are more in the marketplace today versus some of the things that we hand built for the lab environment of the POC. And so I'll go ahead and show you who those vendors are. So our pilot system is a small system. And I'll just give you a scale of it. It's around 140 IO. That's the hard IO. It's obviously got a lot of intermediate signals as most control systems have. It's around 30 loops. So it's not big. There is some cascade. It's not really I'll call it high-end advanced control type stuff. It is real hydrocarbons at elevated temperatures and pressures of the nature of the pilot runs. And this one, of course, is the ExxonMobil working with Lockheed Martin and Wood to make it real. The vendors have provided some components and we are in the process of integrating them right now. We hope to have this in front of an operator running the pilot unit in maybe the third quarter of this year. So that's our plan. We'll see. I'm still looking for Murphy in the org chart. So what do we change? Well, like I said, it's a little constrained over what the POC was because POC was R&D. We were just blue sky trying to figure out how things could work. And now we need to make a system that an operator will like and enjoy and not be mad at us for making them suffer through a shift. And so we've gone to more commercially available products from companies in our world. Tried to stay away from lab equipment, if you will. I maintain there's nothing wrong with a Raspberry Pi, but it's the generic one the kids use in middle school for robot camp. They're not made for industrial use. Very powerful, though. In the communications world, we have moved to using Modbus TCP. And it has to do with being compliant with our existing systems. Because although we're taking out a DCS system, we are replacing an existing DCS system with this. It does have some interfaces in Modbus is a standard use. So we converted over to using Modbus for that. And of course, we did simplify by just going with a OPC UA as well. In the software side, we had used some utilities, some freeware, some open source stuff and the proof of concept. And we decided to go test software development kits that are available as well. So these are more commercial products. I'll say they're probably a little more robust, but they do cost money. In the historian world, we had substituted for just simple data recording. We're going to use the OSI Pi. We're going to integrate that with our HMI and other things that are going on. We added alarms and messaging. So in the POC, there were no alarms, which was kind of fun. I will tell you, since it was simulated, we did blow up the fired heater several times. We had to tune everything. What was really good about the simulator is it said explosion at one point. But if you really tried hard, it said big explosion. We got the tuning down. It works pretty good when you tune it. The cybersecurity is an area that we are pushing the envelope because we really didn't test much of that in the proof of concept either. And so we're talking about things like device authentication, route of trust, certificates and role-based security and for software and implementing an honest zones and conduits, NIST framework style network. It adds a lot of interesting network equipment to your world to do this, but we decided it's a perfect time to give it a shot because this world is coming to us. Any of you have been to the cybersecurity presentations, it's coming. Just get used to it. So we figured we'd give it a try. It was a little too much for the POC. We had to prove that just the basics would work. Our crazy ideas were actually capable of doing. I guess, and lastly, in the ARTAC world, this system is going to be online for a fairly short period of time, measured in months. It's not years. It's not going to sit around a long time. And so we made an economic choice and I don't mean that in a negative way. It's simpler to just do a simple VMware based system. So we ended up with just a Dell server and we didn't use the Wind River stuff that we'd used in the POC. In the test bed, we think we're going back to that world to test out their high availability ideas. So those are the kind of things that we'll look at. But for the prototype, it's to be run by an operator reliably, perform the functions of a control system, and show that it can be done. So this is my last slide. So basically, the why we're doing this, we could wait for vendors. We could wait for the world to change. We want to answer our business problem and we need to make a bigger change. We think that our progressing the R&D helps people see that it's possible. We can demonstrate to ourselves that we can actually generate the benefit we think is available. The OPA form, of course, is tasked with the idea of creating a system, a standard of standards that define what an OPA system would be and is capable of. That's very important. And to make that successful, we really need more participants. We need end users to decide they want to participate. We need suppliers and vendors and other interested parties to help us. We have to identify standards. We have to figure out if they're good enough. We have to figure out how to test them for conformance. We have to make sure that it's something that can be built. It has to work for all the various industries that it might serve. I can speak for the oil and gas chemical world, but I don't speak for pharmaceuticals, metals and mining, food, other people who might use this. We need the assistance from everybody, actually. We obviously need vendors to provide software and hardware components for usage in the system as well. We hope that vendors are, even if they're not telling us about it, out there trying it in their own labs. And if you want to talk to us about it, we're open to have that conversation. And if you're interested in helping the open forum, we do have the open group booth outside. They tell me it's the last one. And Mike Hickey will help you out if your organization is interested in joining up with this and coming to our meetings and helping us get there. It's important stuff. With that, I thank you for your time and attention.