 A warm welcome, please, for Breadhub. Thanks so much, Steve. OK, one thing I've learned is I think I'm the only person that read the instructions that said, you need a dark background. So hopefully the blue shows up OK. Steve, thanks so much for the invitation, the opportunity to represent ExxonMobil, and also talk about our collaboration with the open process automation forum. As Steve mentioned, since October last year, I've been the program manager for our internal R&D program. Really excited to see the work we're doing to move from our closed proprietary systems to open systems. I think if we're successful, we'll unlock tremendous value. So in the next 40 minutes, what do I want to cover? I want to cover the motivation, how we got started in this, why we're doing it. I'll share our vision. It's an ExxonMobil vision, but I think it's an industry vision. We'll talk about the two key approaches we've got in progress. One is with the open process automation forum, which is under the direction of the open group, and then our internal R&D program. I'll share a couple of slides on the results of some of the work we've done, and I'll close with a couple of slides looking at the future, how I think things will play out over the next couple of years. And if I'm on time, we'll have about five minutes left for questions at the end. OK? So ExxonMobil has a problem. A couple of years ago, we looked at where our distributed control systems are. A large percentage of those are reaching into life over the next couple of years, primarily those in our chemical plants and our refineries. ExxonMobil made a decision that we wanted to explore doing something different. What were we looking at when we wanted something different? Well, we wanted more marketplace competition. We wanted lower barriers to innovation. We wanted to lower the lifecycle costs. And ultimately, we want to generate greater value. A common theme you'll hear this morning is that ExxonMobil believes there's tremendous value that can be unlocked by moving to an open, interoperable, standard-based system that provides greater computing capability and increased rates of refresh compared to our systems today. This is not just about lowering the cost. It's about having greater capabilities and using those capabilities to capture value. OK? So what's in scope? Well, if you're familiar with the Purdue model, the levels 1, 2, 3, and 4, the scope of the open process automation activities are outlined in yellow. At least they were yellow on my slide. So at level 1, we're including basic control and the PLC. We would call these edge devices. So what I've learned over the last year is edge device means a lot of different things to a lot of different people. But within the open process control form, it's things that are connected to valves, sensors, analyzers, things that actually touch the process. We explicitly exclude safety systems. So within ExxonMobil, safety systems have a much different governance structure. They share common technology. But for our first effort to change an industry, we made a conscious decision to exclude safety systems. So at level 1, we've got basic control and PLCs. We've got all level 2 and all level 3. On the side, you've heard a lot already about IT and OT and the convergence of those. So we're showing that open process automation certainly involves all the OT layer, but certainly some of the IT layer. And some of the opportunities we'll talk about this morning is how we combine those and actually choose the best of OT and IT to generate an open, interoperable, secure process control architecture. So what's the ExxonMobil motivation? Well, we have discussed that we had DCSs that are approaching end of life. And some people say, well, why didn't you just go out and buy a new DCS? Well, we've done that in the past. And we think there's some challenges as that. Specifically, if you replace with in kind, from existing DCS to new DCS, as they are today, you end up with a system that requires a lot of resources, a lot of cost to increase computing power. We all know that computing power continues to increase month or year after year. Our systems are not really designed to take advantage of that. The other issue we have with existing systems is it's very difficult and can be expensive to integrate third-party components. So you buy a DCS from a supplier. If you want to add components that they provide, it's great. If you want to add components from somebody else, it can be a challenge. And that also plays into our third item, which is systems typically are bundled versus best in class. So somebody in the industry innovates, comes out with a new component, either hardware or software that provides additional capability. If it's not from your DCS supplier, you may or may not be able to integrate that into your DCS system. And next to last up here is the DCS systems actually have a very significant footprint. So that works fine at our largest sites. You look at a very large complex refining in petrochemical facilities, that's great. But we also have a number of smaller standalone facilities. And there may be some opportunities to put some advanced applications in there, some additional automation. But you can't incrementally start low and build. You need to bring in a whole DCS. So lack of scaling. And then security. We've talked some about security this week. I think there's a separate session on security later on this week. It's a big issue. Historically, distributed control systems or industrial control systems have dependent upon air gaps. And we all know that's not adequate. So as a result, many of our DCSs have built on security items. And we think that's a challenge. So we've got to address that. When you look at the overall industry, the challenges we have are both technical and commercial. Existing suppliers. I see a number of them out there, so don't throw stones at me, OK, please. They basically sell tightly integrated hardware and software, proprietary components. They sell it to you. You buy it. And then you're locked into a long-term service agreement. What we hear back is that many of the suppliers actually make most of their money on a long-term service agreement, OK? That means if you want to change the industry, you've got to adjust that business model. So we're accounting both commercial issues and technical challenges to change, to go to an open, interoperable, and secure process control architecture. So that's kind of our motivation. Let's switch gears and talk about what has changed. People have talked about open process control systems over the years. Never been able to deliver on it. And we've been asked, well, what has changed now? Why do we think we can be successful now? And there's a number of key enablers that have occurred over the last several years. The first is, other industries have demonstrated the ability to move from closed, proprietary, tightly integrated hardware and software to open systems utilizing commodity hardware and software that is interoperable across the available hardware. So in the avionics area, that's happened. Many of you may be aware of the face standard that's out there. The US Department of Defense has pushed that. We've seen a number of papers reporting benefits from where the avionics industry has moved to open systems. And then the telecom industry. Telecom networking industry historically was based upon closed, proprietary, integrated hardware, software applications, or appliances. They've now gone to much more open commodity hardware with virtualization of the software. We think that's a good model for what we can achieve in the process of control area. So we have two other industries that have moved in this direction. Computing power continues to expand. We think an additional computing power will be critical to moving to an open system. We see more and more integration of IT and OT. Historically, these were two great divides and often with fights going on between them. I think we've now realized that they must work together, and it's not one or the other. It's the best of both in how you choose to work together as a key enabler for moving to a new system. Cyber security, common theme. We talk about innovations. Unfortunately, the innovations come in both the defensive side and the risk side. So as the attacks become more advanced, the role becomes a more dangerous place to live in, more and more people are looking at where the risk associated with our operating facilities. The need for greater cybersecurity increases. Unfortunately, there's also a number of advances in how you can defend yourself. We think that's critical to make our new platforms capable of incorporating those new cybersecurity features. And there's a host of other items, industrial under things, wireless, cloud. Those are all changed expectations from end users on what they might be able to have when it comes to advanced process control systems. So what's X on mobile vision for our next generation industrial control system? And this is a theme you'll hear. Standards-based, open, secure, interoperable. Those are the key quality characteristics. Let's talk about what that means. First, in order to have a standard-based system, you must have standards. And you'll see that it's so important where the open process automation form comes in. We cannot have a standards-based system if we don't have standard. So we'll talk a lot about what the form's doing and how those standards are being developed. Commercially available. So we want multiple suppliers, multiple system integrators, and multiple end users. If this activity ends up in a custom built X on mobile architecture, it will fail. It will not survive in the marketplace. It will not be cost competitive. So we've got to engage the industry in a significant portion of the industry, both from the supply side and the demand side. We want to have a system that allows us to integrate best and class components. We want security design and built-in, OK? We operate our plants not from components, but from an integrated system. So we must have the capability to take compliant components as certified by the form or certified by the certification agency and create an integrated system that works. So that's a key part for us. We've talked about fit for purpose or end user needs. We want to be able to upgrade our components as justified and as required. We want to avoid the big bang where it's roll out the old and bring in the new. When you look across the components inside a distributed control system, there's many different components there. We want to avoid having them all tightly coupled. You have to replace them all. We want to be able to replace as justified and as needed. That applies to both our software components and our hardware components. So one area that we've had some confusion on relates to protecting our supplier's intellectual property. When we talk about open, that's scared some people. Let me emphasize what we're looking for is open interfaces that allow interoperability between components. We are not looking for suppliers to open source their systems. We're not looking for people to donate IP. We expect to have a system that supports protection of IP from the suppliers. That's a really, really important outcome. So open from an interface standpoint, from a connectivity standpoint, but yet protection of the component IP. ExxonMobil invests a tremendous amount of manpower every year developing applications or software. Today, if we do a DCS upgrade, almost all of that software needs to be thrown out and we start over again. Sometimes even within a particular DCS supplier as they move up in platforms, a change will require throwing out and starting over. We want to be able to have application code and software code or application depending on what term you like to use that we can port from one hardware platform to the other hardware platform. One of the key things we're striving for is the flexibility to respond to need. The need to change the wiring in your system is going to be different than the need to change your software. It may be different than the need to upgrade your chips from a computing power basis. We've got to have that flexibility to pick and choose upgrade when we want. They all lead to simplified replacements. We believe that we were successful delivering this vision. The market's probably expanded for our suppliers and ultimately we'll have a platform that will support innovation and value capture. So that's our vision. So based upon that vision, we've developed a reference architect. There's a lot of information on here. I won't go over this in detail. I just want to highlight a few things. The first thing I hope you notice is it's a much flatter platform than the Purdue model. We have the ability to collapse functionality. What I will also highlight is the new activities. So we have our edge devices. We have our real-time bus and we have our advanced computing platform. We've introduced the term distributed control node and let me note also that this is an exon mobile vision. This is exon mobile terms. The form has actually made some slight revisions. So if you go back and forth, you'll see some changes there. But for exon mobile, DCNs or edge devices, what do I mean by edge devices? They provide at a minimum IO processing, but you can also embed computing power down here depending upon what your need is. The computing power may change. You may have some very simple computing power that allows you to do some regulatory control, but you may also embed some advanced computing power that allows you to do advanced applications. The data comes in, initial process here. You go up to a flat bus, a very flat system. And then we go up to our real-time advanced computing platform. We see more advanced computing applications going on up here. And then the other thing we see that's critical to the success, particularly as you look at additional analytics in advanced applications in the data centers, today's platform and the classic Purdue model, you do level one, then the level two, then level three, and then everything in level three goes up to level four, and then level four is you do your IT stuff and potentially move that over to the cloud. We see with the advent of advanced sensors, low-cost sensors, additional data coming in that we want to do advanced analytics on, not required for real-time control, but required for profitable applications. We envision a path that allows us to go either to our internal or locally hosted IT center or externally up to the cloud directly from the real-time bus without the need to go to a level three, okay? What that means is I can unload this pipe here and I can have this machine focused on what it needs to do without a bunch of a pass-through traffic going on. So that's a key difference we see in open architecture, okay? So let's talk about the approaches we've got, and it's really important to understand there's two parallel activities and I've tried to lay out the presentation so you understand what I'm talking about one versus the other. I will say they're tightly connected, very supportive of one another, but they are distinct and different. So the first one is the open process automation form. Part of the open group, okay? Like the other forms in the open group, it's an industry consortium focused on the development and use of standards to improve industry performance. Our form is made up of about 80 members. We've got about 20 end users, a broad range of suppliers and a number of system integrators and I'll show you the members in the next slide. But it's really important to understand it's a broad industry operation. What is the consortium done or what is the form done? The first thing it did was issue a business guide so that Harrington will be talking more about the business guide this afternoon. There is a open meeting of the open process automation form this afternoon. I'll put a plug in two o'clock, two to 3.30. If you wanna know more about what's going on in the form come to that meeting, okay? Ed will give you an update on the business guide, which is really defining the ecosystem, how we expect everybody to make money in this new world. And then the other thing the form is doing is working on the standards. And Dave Emerson will be talking something about the standards and what's going in on that. So the initial focus will be on interoperability, but we'll have future releases and I'll show you a timeline a little bit. So open process automation form. So there's the members, okay? I won't go over the members in detail, but I do wanna highlight the breadth of participation and users, existing suppliers from DCS vendors, hardware and software suppliers, system integrators, and then we've got some other companies over here also. So really happy to see the broad membership. If you're here today and you're involved in process control and you're not on this list, I encourage you to join, okay? So the other thing I wanna show is what's, there we go, what's the structure look like? So I don't know how this compares, I assume this is fairly normal for the open group. Structure, we have a form leadership, okay? Trevor will be leading discussion this afternoon a brief highlight of what's going on in the form. We've got a number of working groups. The two on the side really do most of the heavy lifting, the business group is looking at issuing the business guide, they've got a couple other activities going on. The technology group, you can see the cross, a broad participation, suppliers and users and others, and then on the bottom side are the subcommittees and that's really where the majority of the work gets done, okay? You've got a particular interest in a certain area, we've got a subcommittee you can join, okay? So that's the open process automation form train. The complementary part of that is the ExxonMobil funded R&D program. So being a structured company, we use a gated R&D process, multi-year, been going on for a number of years, went through a big gate earlier this year to support funding for the ongoing activities. Why are we doing this? We believe that by spending our own money, we can lead the industry and demonstrate what's possible, okay? We don't wanna go to the loan, but we do believe doing our proof of concept and our prototype systems, we provide data that we feed into the form and we can use to demonstrate capabilities. Ultimately, what do we wanna do? We wanna execute one or more field trials. Field trials required for commercial readiness, commercial readiness, support, global deployment. As part of our work, we're utilizing a system integrator and we'll continue to do that. It's important to understand ExxonMobil is not getting in the DCS business. We have no intention of developing DCSs. We wanna continue to use suppliers and system integrators, okay, but we are heavily involved in what we're doing in the R&D activities. And then, most importantly, to be totally successful, we've introduced the concept of collaboration partners. So we announced in January or February this year that we had three companies that had signed a letter on tent. We're currently in discussion or developing final agreements with a half dozen or so companies to join us in our OPA activities, developing systems, testing systems, and ultimately looking for those collaboration partners to do their own independent field trials, okay? So ExxonMobil, our suppliers, our system integrators and our collaboration partners, all critical to moving forward. So this is our one-page overview. Does this show up good back there? I wasn't sure if the gray would show. And these slides will be made available, okay? So I appreciate you guys taking pictures, but you also get a PDF file this after the meeting. So what do we have here? We've got our focus areas, our participants, and our timeline. So the proof of concept was, excuse me, the proof of concept was the early thing we did. I will include three pages of results from the proof of concept when we get to the real section. That was really to address some key technical feasibility issues. We were trying to do things that maybe hadn't been done in our area in the past. People were concerned that we were trying to do them possible. So we wanted to make sure early on that we had something that might work. Involved in that was ExxonMobil, Lockheed Martin functioning as our system integrator and a number of suppliers, 10 suppliers to be exact. We wrapped that up in April this year, moved on to a prototype phase. Prototype is expanding the concept of the proof of concept into a system that we can actually move to a pilot unit, replace the existing DCS with an OPA system and run that pilot plant with an OPA system. So this is our next stage, moving towards commercial readiness. In addition to Lockheed Martin, we also brought in wood as a field system integrator. So this will be a system that actually goes in the field in a lab environment, in a research environment, but it'll be operating a pilot plant, it'll be connected to real flow meters, real instruments, it'll be used by an operator. So that's a key next step. We then move into this year, early next year, we'll be looking at developing a test bed. So where the prototype is a very static system that we're trying to demonstrate key capabilities, the test bed will be our experimental unit as suppliers continue to provide new components as the form-issued standards will evaluate those on the test bed. Ultimately, coming out of the test bed will be designed for our field trials and our field trials being executed. I showed the collaboration partners being coming in as part of the test bed, observing and participating on the test bed activities, and then moving into their own field trials, okay? Now, all this is underpinned by the form. Form kickoff was in 16, the business guide issued early 18. First standards will come out by January 19 followed by additional standards, and we hope by 2021, we'll have a first complete set of standards, okay? So that's the timeline. Those are the activities we're progressing if we move towards technical readiness for an open process control architecture. So 15 minutes to wrap up on results and what's next. So three slides on our prototype, or assuming our approval concept. So starting in 2016 and wrapping up in April of this year, we worked with Lockheed Martin and our suppliers to create a prototype of what an OPA system would look like. Hopefully this resembles the reference architecture, our edgy devices down here, our real-time bus, our advanced computing platform. We show the suppliers components we used. So two, just on IO, three distributed control nodes, our bus. We actually did two tests on our bus, one with DDS provided by RTI and one with a flavor OPC UA. And then we had our advanced computing box up here. ABB was kind enough to provide their controller in a software version only, extracted from their hardware. We ran that up here. So that's our system. Happy to say it worked and it provided the basis for our prototype. Now let me show you a couple of things that we actually accomplished. So the first key thing was interoperability. And when I talk about interoperability, we define that as the ability to, for two components to exchange meaningful information. Why is that important? Well, we want to allow integration best in class components. We want to foster competition. We don't want to enable customization. Lower the cost of integration and eliminate the need for a single supplier to provide all system components. So this is a blow up of our part of, excuse me, blow up a part of our prototype or proof of concept. We had an edge device from Stahl doing basic IO. We had a DCN from NXT control doing control down here. The control of these components were executed on the soft controller from ABB running on our R-Tax system. We had an HMI that pulled it all together. So HMI was from inductive automation, pulling in data from the ABB component, from the Stahl and from the NXT component. So four different suppliers there, running on a fourth suppliers platform, all working together, okay? Two years ago, some people told ExxonMobil this wasn't possible, okay? It is possible, okay? Is it easy? It's not easy and we're not finished, but we're moving in the right direction. So the second thing I wanna talk about is a little more challenging, which is application portability. We define application portability as the ability of software program to be run on multiple platforms without major modifications, okay? Why is that important? It allows us to take our application code we talked about and extend that from one platform to another so we can update our platforms and maintain our applications. So this is my little bit of automation in my slides here. We started with a piece of control software from NXT running on a Raspberry Pi. Yes, Raspberry Pi is a non-industrial application, okay? But this was a lab experiment. This is a proof of concept, so please be patient with me on the Raspberry Pis. We had a box from Intel and with a click of the switch, we moved that software from one box to the other with no minor or no modifications, okay? Able to re-host that software. Now, a number of IT folks might say, well, we do that all the time. Well, that's great because we need to learn how you do it and we need to be able to do that down in the OT world because today that doesn't happen very often, okay? So that's kind of the results. A couple of minutes to talk about what I think will happen in the future. So key is what happens with a form. I remind you, we cannot have an open standards-based control system without standards. So the form is working on OPAS standard. It will be a standard of standards. We're still working through how much white space is there. We hope we were able to utilize a number of existing standards. The technical working group is working on this. Version one will come out in January. It'll be focused on interoperability. Version two will be configuration portability and version three will be application portability, okay? All things we've demonstrated today on our proof of concept. This is an outline of what will be in the technical specification. Eight parts, you can see when each part will come out and what subcommittee is responsible for that, okay? So a lot of work going on to get this ready. So what's next? Is there some mobile activities? So we're currently on our prototype. Oh man, have that finger here, okay? So we see this as a standard technology development from proof of concept, the prototype, test bed, the field trials, and ultimately commercial deployment. Each stage moving us higher up the technical readiness ladder, okay? On the prototype specifically, what are we going to do in addition to some key technical capabilities? I mentioned we're actually going to migrate an existing DCS off, put an OPA system on. So this will be a miniature DCS upgrade project, okay? We're also bringing in the system integrator, expanding the system integrator role. So our initial focus on the proof of concept was all about complex system integration, getting systems to work together. We're now bringing in a classical system integrator to do the field integration work, okay? And on the prototype, we're also bringing in additional suppliers from our hardware and software standpoint. So that's our plan, that's progressing. I mentioned our collaboration partners, so we're working on that. I expect that in early 2019, we'll have an announcement about who those collaboration partners are and what we're doing. The 2019 and 2020 activities will be focused on the test bed. ExxonMobil will see the test bed, set it up and continue to use it, but also make it available to our collaboration partners. You show collaboration partners here. That test bed will be done with the ExxonMobil selected system integrator. And then as we move out to 2021 plus, we hope that our collaboration partners and ExxonMobil will do parallel field trials. The collaboration partners will also be in a position to bring in their own system integrators, okay? So we will use the standards as they're available. If you go back and think about the timeline, some of this is progressing in advance of the standards. So how we actually line up what we field trial versus what's been released of the standard still to be determined. Within the collaboration group, we will share non-competitive learnings, okay? We are outlining a system of standard test related to performance of the components and conformance of the integrated system, okay? And then we'll kick off hopefully early 2019. So I did wanna spend a minute on our ecosystem. This is a simplified slide from the business guide, but this is really highlights how things changed in an open world. We expect we'll split out the hardware suppliers, software suppliers, subsystem integrators, potentially our system integrators, and our service providers. This separation is all enabled by the use of standards, okay? Today, certainly the subsystem integrator, hardware supplier, and software supplier are all our existing DCS suppliers, okay? So this is a major change. It opens up the capability of the system integrator role. Our existing some DCS suppliers, we hope, will elect to become system integrators. What we want is the competition on this side so that everybody can bring the component that they provide the most value in, okay? If we're all generating commodity hardware, let's not fight and drive the cost of that so that nobody makes any money, okay? Let's move on and use our resources on where we add value, whether that be on the software or on the integration side, or on the service provider role, okay? So if you want more on this slide, there's a whole section in the business guide that describes this in more detail and provides additional information about each of the roles going forward, okay? What I'd like to do is my next to last slide, just talk a little bit about the benefits. You guys can read this. I won't go over every one of them, but when we are successful developing and having available open-processed real systems, we believe there's a wide range of benefits. For ExxonMobil, we want to focus on value capture, but there's other ones here. Safety is certainly, security is a key one, but we think there's benefits on the supplier side too, okay? This will allow you to remain relevant to your customers and allow you to focus on where you make your money and eliminate non-differentiated products. So I wanted to close with the Bradhound view of the future, which is always dangerous, but as they say, that's why we're up here. So ExxonMobil has completed the proof of concept. We demonstrated interoperability. We demonstrated portability among applications and configuration that work was done earlier this year. Our development of our prototype system is underway. That will go live in our pilot unit in 2019. So we will have an OPA system running a hydrocarbon unit, granted one very small, but it will be at temperature and at pressure. The form is actively selecting the standards. Version one will come out in January of 2019. We're engaging our collaboration partners. We expect to have those announced early next year and begin engaging them on the testbed activities. We believe we're creating the demand for additional system integrators. So you'll see not only what ExxonMobil is doing, but what our collaboration partners are doing. Four key things we see as key success factors. One is critical mass of end users. If this is an ExxonMobil system, we will not succeed. So we're really happy that we've got 20 end user companies engaged in the form. We need to continue to get them engaged. We're also actively recruiting, part of why I'm here today. So if you're an end user, not involved, we'd love to talk to you. Suppliers have to come along. And we hope if we have a demonstrated sufficient number of end users, the demand will be clear. Suppliers will come and provide the components. And then we need our system integrators to integrate the components. And ultimately, we need to be able to demonstrate that an open, secure, standard-based, interoperable system provides value relative to our closed proprietary system. Because that's what's gonna drive its use. That's what's gonna drive the growth of the system. So with that, I'll open it up with questions. Please take a seat. Well, you've generated a ton of questions. We may not get through all of them, unfortunately, but for me, for me it's great hearing this stuff because one of the things we say we do at the open group is we help our customers solve business problems through standards. And this is a great example of that. As you said several times, you can't do this without the standards. So I'll run straight through these questions. There are quite a few, I think you kind of answered this, but you wanted commercial availability. Did you consider building yourself because internally developed could build interoperability? We considered it for maybe five seconds. Okay, we think that's a recipe for disaster. We are not in the DCS business. We find oil, produce oil and gas, refine it, make chemicals, that's our core business. We want to stay in our core business. We think that the way you drive improvement is to spread the engagement across the industry and demonstrate a demand from a number of customers. Okay, how open do you expect the component interfaces to be? Is it limited to the software interface or does it extend to the hardware interfaces too? So hardware interface is a very interesting dimension and depends on whether you're talking about the edge or above the, on the bus. So I think above the edge, the hardware interfaces are driven by the IT infrastructure. Okay, so we're not looking to do anything different there. On the edge, we would like to move to a standard physical platform so that we can land the wires one time and then we can upgrade our components without having to move the wires. That's part of the vision. What we found through the form is that's more challenging, I think, than the software interfaces. So we're proceeding with the software interfaces. In fact, the timeline I showed was for the software interfaces. The form has pulled out the physical platform as on its own timeline and I think it's still under development. So we would like to see a physical standard on the edge. Whether it happens or not is to be determined. Two that I can combine. Basically, is there a plan, what is the plan to certify and onboard suppliers on the standards? So a big part of what the form is doing is providing and creating a certification process. If you look at the subcommittees in the business group, one of those is on compliance. So the certification will be controlled managed by the form and suppliers will be able to go through the process and get their components certified. I've actually sat in one of those meetings a couple of weeks ago. The one in Sunnyvale? Yeah, the one in Sunnyvale. They're making great progress there in the business work group. Are all the, let me see how you can answer this one, are all the collaboration partners from the same industry? Or can you not say at this point? I know you said they weren't announced until next year. No, they're not. I mean, they're from the process industry. Right, but not from oil and gas necessarily. Not necessarily from oil and gas. Okay. Okay. How will the standard differ from or relate to existing standards from, for example, ISA field bus or other standards organizations? So early on, the decision was made, the best way to success and the most expedient way to success is to leverage existing standards where possible. And I think we've been true to that over the last couple of years. So we are looking at leveraging existing standards from ISA, IEC, a number of organization foundation field bus. And if you take a look at the snapshot that's out there, you'll see some of that. And certainly when the standards, first standards come out next January, you will see that we are leveraging existing industry standards to create interoperability. Is it really about commoditization or interoperability? Certainly some components will be commodity, but really what you want is interoperability and innovation, is it not? Can you read that again? Yeah, I'll read it slowly. Is it really about commoditization or interoperability? Yeah, I mean, so we're not trying to commoditize every component, okay? What we are trying to do is commoditize the sum of the infrastructure that allows us to add value and interoperability with software, okay? So we're not asking for commodity software, okay? We want custom built software that adds value that has unique IP embedded in it, okay? But we want to break the tight coupling that we have today of hardware and software. Does that answer? It does for me, not my question, but certainly that's... If I didn't answer your question, find me at the break and then we'll talk. Today's upgrade is driven by Microsoft. Will it not be helpful to go for an operating system supported for more years? Yes, so anybody from Microsoft here? Okay, maybe, maybe not, okay? So I'm not here to make a statement on Microsoft versus other operating systems, but certainly if you look at the direction the form's going, we want the ability to pick and choose. And I think if you go back many years, I mean, we as in-operating users kind of drove the transition from proprietary OSs to Microsoft, and I don't think we really understood what we were asking for when we asked for that. And we've kind of been put on the treadmill and now I think there's some serious thought about is it time to get off the treadmill, okay? Consistent in what I've heard before, so. Final question, we heard you say that the first version of the standard will be available early next year. Which is relatively quick. You also referred to, where was the precise question? You referred to previous efforts at open standards in process control. What's been the difference? Well, I think the difference is that page of enablement activities, okay? We're leveraging what other industries have done, okay? If you go talk to people in the avionics area, you talk to people in the telecommunication and networking area, you're like, sure, there's no reason you can't do this in the process control area, okay? So, we're not blazing the trail, we're not gonna be first, but I think we're able to now leverage what has been demonstrated, and we will change our industry. I sat in one or two of the industry day events where people were saying, oh, this has been tried, you'll never succeed, and so it's good to see it happening. Well, and that's why we did the proof of concept. Okay, and if we wouldn't have been successful, we would have disappeared and never seen us again, but we're here, so. We're glad you're here, Brad. Thank you very much. Okay, thank you. Thank you.