 Thank you Steve. All right. Thank you very much. Thank you Well, it's a pleasure to be here today and this is a very exciting time It's very exciting because we are in a convergence of technologies and business practices and needs on the part of the industry the the industrial automation industry and What's what's really exciting about this is the the confluence of Both hardware technology software technology and Standardization are all coming to play to create a new value proposition In industrial automation as it has in the DoD market space Couple of terms before I get started just I want to just get some definitions out of the way You'll hear the term face Face is future airborne capability environment. It was a standardization process. It still exists today It's in process started back in 2010 and the purpose was to bring capability to the warfighter In a much more rapid and economical sense than was previously able to be achieved that's been running for six years and As of this date, it's very successful and Went through a lot of birthing But the point we're at right now is it is open for business Software is being created under an open architecture construct certification is in process And a market space is opening up open process automation is taking advantage Reuse of a lot of those fundamental concepts and so what we're going to talk about here today is What that influence is on industrial automation another definition as you'll hear the term continuous process flow and batch process flow continuous process flow is an operation like in a refinery where you have feedstocks coming in Operations are done on those feedstocks and product is created in a continuous never-stopping process okay Batch processing would perhaps be the food or pharmaceutical where you create a batch of material you process it You package it and then you clean up and start over again. Okay, so it's in batch This system or these concepts are applicable to both so the industrial motivation what what brought this about is in Exxon for example and other industries as I've learned through my discussions with different companies These companies are facing considerable replacement of legacy projects that have been in place for a long time And they're trying to figure out how to replace those systems that are going obsolete and Do it in an economical way so that capital expenditure and operational expenditures are optimized they looked at state-of-the-arts existing proprietary systems and There were several factors that said maybe there's a better way of doing it They were concerned about the high cost of technology refresh the Expense or inability to integrate third-party Products into those existing systems So for example one of the stories that was related to me was I've got PhDs Working in the back lab that are able to create optimization algorithms for creating product But I can't get those optimization algorithms into the control systems because There was proprietary barriers or inability of standardization So that's one one area that they want to address Market liquidity for sophisticated development tools because a lot of these systems similar to the DoD market space are closed there wasn't a Ready market of Applications and software and tools that were generally applicable across these systems So they said that's another itch. We want to scratch can't get them on the existing systems Does not allow the independent acquisition of system components Where his face was focused on Software Industrial automation is focused on hardware as well and the ability to bring third-party Hardware and software into these systems is extremely limited and they wanted to break that paradigm and Then finally the security model Was considered to be bolted on not intrinsic And here's where the emergence of technology comes into play is the ability to integrate Embedded integrated Security technology is upon us today And I think a lot of that's been brought about by the industrial Internet of Things Where there's a ready market for industrial security for or security for the Internet of Things That same technology is now applicable and available for use and control systems whereas before it was aftermarket bolt-out To the first order so where his face started in 2010 Back in 2013 The open group had a conference in Washington. I was giving a presentation and Exxon mobile happened to be in the audience and At the at the lunch luncheon table with Don Bartusiak and Steve Batar were sitting there and Couple of the folks and this was a DOD spot or DOD Market space conference. We said, you know, what do you guys what your interests here? And you know why why are you here and what we found out is their concerns their needs were identical Almost one-to-one mapping with the concerns we had in the DOD and why face was stood up And so they were interested from that point on in 2013 Defense avionics industries have transitioned from a proprietary stovepipe approach to more of an open architecture The face construct is aiding that so applications in the avionics market space For subsystems are now reaching the point where the software that enables those can be transferred from platform to platform Assuming that those platforms have a face operating environment on them and that's a big assumption But that's the market that we're the space we're moving into That analogy is going to exist for industrial automation as well in the DOD motivation Again, what drove us with face was the long lead times even for urgent needs to bring new capability to the warfighter Platform unique designs limited the reuse of software and increased cost So that created barriers the competition within and across platforms That was the primary driver for the face consortium standing up back in 2010 and As I said this analogy with industrial automation is almost identical in the same principles and practices that we used in Face we're now using in open-process automation form or OPA So what's driving all this? This is a curve that was I believe published by GE Aviation looking at the complexity of software as a function of time and what's driving it So this curve and by the way This curve is interesting because I've seen in several Studies by DARPA and and IBM and a couple of others that this is almost a universal curve of complexity For for software-enabled systems. So this curve shows the growth of complexity in avionics systems Starting back I'd say in the 60s moving up that where that dotted line is Into the 80s early 90s and then where we are today In the key driver for this if it's hard probably to read in the back of the room But hardware dominant versus software integration dominant What we mean by that is these systems back then These are avionics systems But again, this if you think about it for a second this really applies to medical systems to industrial systems Back in the hardware dominance area functionality was was done in an electro hydrodynamic manner gears analog digital or analog dials and and data Differential equations modeled by inductors and capacitors That all rapidly transitioned into software enablement where it touch screens Data fusion functions so on and so forth where the complexity of the software Naturally grew and so the concern in face was we were reaching an unaffordable point for the next military vehicle So when face was stood up we looked not to start over again and and and and You know build something that someone else built but let's take advantage of what's out there already and that's a recurring theme That we're that we're using is reuse of existing standards So in the commercial market space commercial avionics were facing the same concern the growth of avionics complexity driven by the movement from analog systems the digital systems was on an exponential curve where the a38 or the beat the 7.7 87 was reaching a point where it was potentially going to be very expensive through the incorporation of an integrated modular architecture Standardization they were able to drive the cost and complexity down to affordable levels And so we said to ourselves in the in the face consortium back in 2010. There's hope for us There's things that we can do with regard to standardization that will make this Possible to drive costs down and we're seeing that today. We're seeing cost reductions Now on the industrial side, I'm giving credit to Exxon for this slide They used it in an industry day that we held Going back in the in the 20s. It was very simple analog systems pneumatic controllers Then in 1959 60 it moved to the first central computer And I think this was done by an avionics company by the way or a defense contractor Who came up with this and then moving on into time in 1975 to 78 Again, think that curve that I just had up there the increase in complexity With regards to digitization started taking hold Moving forward into more complexity doing more functions and software growing it further and At the same time the cost and complexity and obsolescent issues We're growing with this So today where we're had headed is what can we do to reduce that through standardization? And so what we're looking at is a virtualized system Using a high availability of real-time processors similar to like a mission processor that we use in the avionics world tying it with a high-speed bus and then having end Channels single-channel modular Distributed edge devices and that allow direct access to these sensors and actuators and so this this this complex system Digitized system a lot of proprietary interfaces is now being The vision is to drive that down to a much simpler system through the use of modern-day technology And standardization So what are those factors to achieve this breakthrough system? And that is what ExxonMobil by the way is charged to do and put Lockheed Martin under contract to create for them leverage consortium hardware and software standards development And when we talk about hardware and software standards We're not just talking about a set of standards for the sake of technical standards what Steve mentioned Earlier was the coupling of business practices And I'm gonna go back again to the face consortium. We looked at what caused other open architecture Standards to fail in the past because there's been a lot of open architecture Standards as I'm all sure of you in the room know that have not been successful And the key factor behind that was the business side of it the business practices Creating a market space certification. So for example in face We don't allow waivers we don't allow deviations you're either 100% Conformant to the face standard or you're you're not registered in you're not able to brand your product as face conformant If you take that two steps down the road what that means to the program manager that's that's gonna utilize that face product in his or her system Means that they don't have to risk up if they have that assurance that that product will work and It's 100% conformant and it went through a certification process and it is in a library or a registry for discovery That reduces risk tremendously on the part of the program manager and therefore he or she does not have to risk up the price of Acquisition to cover that risk for mitigation second factor is the power of emerging multi-core processing It's incredible. What can be done in a microprocessor today and the emergence of multi multiple cores in those processors and the The ability of localized memory and what you can do in those coupled with software Operating systems to enable it just it's it's mind-boggling. What can be done? In in a system on a chip today that wasn't available five or ten years ago availability of high capacity networking 10 gigabit and And higher so that your aggregate bandwidth of all these systems or sensors and actuators that are tied to the network can be managed and Controlled and sensed And that that network is also intrinsically secure Whole new technology that's emerging that's available to us today. That wasn't available 1020 or five years ago intrinsic security the ability to sense Problems that that may be attacking the system are now coming online in the commercial world and And is available to be taken advantage of and the utilization of a lead system integrator somebody to tie it all together and Lockheed Martin for example, we get the contract from Exxon mobile to do the requirements analysis, you know The system engineering v diagram starting with user needs and requirements derived requirements and Then all the way up through integration and test That's a very disciplined approach to creating a complex system and so plans processes and procedures are very important because all those interfaces have to be documented all the requirements have to be documented and the Derived requirements have to be levied on to the subcontractors Vendor neutral technology Okay, we look at the supply base in a vendor neutral fashion when we do a selection We do a trade analysis. It's vendor neutral It's based on all the factors that are associated with a trade study to select the very best vendor to do the product a deep technical depth of field Bringing together the experts both chemical engineering controls engineering systems engineering to build the product and then as you get up going up the other side of the v-chain logistics planning Experience in the Open software and hardware standards and that we are a founding member of the future airborne capability consortium technical standards and business Practices were one of the factors of why Exxon selected us And then from a risk reduction point of view programmatic expertise subcontract management configuration management logistics So today what we're doing is And where we are in the program is We've done the requirements analysis We've levied those requirements onto this onto sub derived requirements for the subcontractors and we've sent out RFPs to subcontractors for a prototype system And we're waiting for those replies to come back in and Then we will be awarding contracts to subcontractors to build a prototype system to test these concepts Okay, this is a journey. We're on and this is a prototype phase that we're in right now So a lot of people ask me wow you guys are opening up all these standards and you know How am I gonna make some you know, how am I gonna make any money on this or what are you doing to me? and so The whole key of this is standardization All right, and so I use this chart. I've used it many times is what's standard on all these devices The interfaces Okay So if you had a house that was built in 1940 or earlier even and it was wired For an incandescent bulb on the far left That same Infrastructure can be used today all the way on the right for an LED Now from a value proposition point of view, what have I said to you? Hey, I'm gonna sell you these LED light bulbs but Get a change your house to 12 volts DC Now you got to go to two pin prongs call electrician in what do you think the market? Successive that would be probably zero to none, right? But by standardizing on that interface the base we're able to Have a hundred year evolution of technology in the same infrastructure It's a very simplistic analogy, but that's what we're trying to do here standardize the interfaces Certify those interfaces. So, you know that circular Screwbase is the same as that one over there. So when you buy it, it will fit. All right, that's a hundred percent certification And what but what's competitive about these is the application design? So think about that for a second. All right, the interfaces are standardized But the design the business logic as we move into software Can be proprietary and licenseable and so on so forth. All right, he is what this is all about is interfaces and standardization What's different? in the face initiative we We're analyzing the business aspects in parallel with the development of the technical standards So in face we split a technical working group. That's strictly worried about date architectures Segmentation of the of the software operating systems And then the business side which is primarily interested in contracting. How are we going to do contracting in this new environment? What's the certification processes? We're going to use and what's the way that you the user or the? Seller can discover or publish What you've created. Okay, and then third fourth is outreach. How do you advertise this? We meet under the a voluntary consensus standards as a voluntary consensus standards body And there's two two rules that are two laws that we regulations that we Stick to and one is the circular one a 1 1 9 Which allows government participation in a voluntary consensus? Creation body and the National Cooperative Research Protection Act which has very strict rules about these companies getting together And not creating an antitrust situation Okay, so there's very strict things about what we can talk about and what we cannot talk about So for example contracting Your contracts that are about to be let so on so forth are forbidden to be discussed in these in the consortiums We analyze previous away open architecture efforts and We conducted a quality attributes workshop engage both the buyer and the seller and then there was a great aggressive Outreach by the industry and government the sum of that is that both the buyer and the seller sat across the table from each other And they're doing that today in the open process automation. What's beautiful about that is the sellers Really get a chance to to Understand the issues that the buyers have and vice versa in a very non Confrontational environment to sit across and understand why I need this on the other hand why I have to sell it for this price Though that interaction occurs during these meetings So the common software baseline framework that came out of face was two things a common framework oops go back a common framework and Then shared software components That sit on that framework and the best example I can use for that is a very another simple example is You go, you know tax season is coming and you go to Best Buy or whatever and you or go online And you get turbo tax or one of the other tax preparation forms and it doesn't matter Whether you have an HP computer Lenova whatever type computer at home hardware as long as it has the same operating system on it You have that that that Transparency of hardware and that's what we're trying to achieve in face and also in OPA So that software as long as you have a common framework what we call an operating environment sitting on the hardware and It can be multiple different vendors of hardware And then you have shared software components. We call them unit support ability UOPs in the face consortium You'll hear that quite a bit and in OPA that'll start to emerge and then variable operating system components of various certified Operating system Providers in face. We broke that into an architecture broke it down into the architecture into segments And a top-level description would be this column here is the operating system segment Okay, and that contains contains the OS and then we have another segment We called IO services, which is where you could say the drivers reside and then we have platform specific Services segment which you could consider that to be a translator So if you have a legacy equipment that you're trying to communicate with that has data models that are associated With that legacy equipment you need a translator and so that would sit up in the platform specific services segment And then up in portable components is where you would have your actual application sitting And then transport services segment or on the right-hand side is basically the switchboard all the messaging and Data passes through that that transport services segment that routes it to all of the various other Segments now the beauty of it is and I know it's hard to see in the back of the room But these green lines Represent the interfaces go back to the light bulb, right? those interfaces in face are all standardized and tested and Certified with software tools that the consortium presents and also other elements of a verification matrix So as we now move into transition to industrial automation We have a similar Existing layered architecture, which is the from the Purdue model the the four layer five layer Model for industrial automation L4 being business planning and logistics and L1 through 3 is the computing platform and basic control and human machine interface and then down L level zero is the sensors and actuators and then we have a safety critical system, which is a third Backup system that is independent of The level zero through level four Now when you see this tie-in here, this is not a tie-in from the point of view of control Where the level zero through level four controls this the the safety critical system But the safety critical system may be monitoring Like think of a diode connection of the various sensors and so therefore this was the model that they work with You saw in that previous picture for many years. Well, what we want to do is Is break that down into basically three layers Which is the L1 through L3 function? We call it on the the OT data center okay, and think of this as a Real-time advanced computing platform think back to those microchips that I was talking about those multi-core processor chips that do a Tremendous amount of have a tremendous amount of processing power And the applications will sit up on that operations platform Go back to the architecture that I showed you for face the segmentation. So those software chunks That's a technical term those software chunks that sit up in that architecture our unit support ability that means that Steve could build a unit of portability to the standard and it will work on Dennis's system and vice versa Okay, it really doesn't exist today. That's the vision of where we're headed in the doD world We're proving it out today Okay, there's there's contracts let already that's doing it. So this isn't pie in the sky stuff This is real stuff. It's just moving it into a new market space the real-time service bus is That network as I said earlier that has the aggregate bandwidth capability to handle a large array of devices on the south end of it and So that aggregate bandwidth again open open standards not proprietary so that a you as a supplier can create subsystems that can tie into that real-time service bus so things like the data models and Network speeds and protocols so on so forth will be defined and again credit stacks on mobile We use this charted in industry day earlier So I want to make sure they get credit for that another key point is the DCN distributed control node the key of the distributed control node is It'd be a good example say you got a fuse box in your house you got 20 breakers in it 20 circuit breakers right and they're all filled You want to add two more circuits to your house? All right, what do you got to do? The box is filled you got to add another box and so now you're carrying that whole complexity of the box and The infrastructure to support that the idea here and this is this is another breakthrough idea is can we go down to a Singular one-to-one relationship between the distributed control node that controller that's monitoring a sensor or Driving an actuator can we go to a one-to-one relationship with standardized hardware interfaces? standardized software unit support ability on it so that when we have Upgradability or a need for upgrading a need for expansion. We can add in DCNs on a one-to-one basis So got a couple more functions. I want to bring in a couple more sensors add a couple more DCNs Into a standardized backplane not a proprietary backplane a standardized backplane So that's the concept we're playing with right now with regards to the DCNs in in addition with the DCNs think about regulatory control and This is another key function is if we have fundamental regulatory control Let's say of a furnace Okay There's n number of functions that have to be monitored on that furnace and number and n and m number of actuators to control fuel and And air or oxygen into it What if we group those together in a regulatory fashion so that should we have a failure in the real-time service bus? that these n num n and m number of DCNs maintain regulatory control of that furnace without having to rely on upper-level controls and So those are some of the concepts that we will be testing in the prototype as well In addition you see the traditional DCS distributed control system these this is what exists today Analyzers these are devices that are like gas chromatographs that are online that are measuring the output of product Machinery monitoring safety systems wireless gateway and programmable logic controllers What we will be doing is putting in Rappers software wrappers above these so that if you go back to that model where I said in the Platform-specific services segment we do data translation So in this case we would build data translators for existing legacy equipment To map into the new system this allows us to enter into brownfields and us I mean the industry to enter into brownfields We have existing equipment already and it'd be prohibitively expensive to rip all that equipment out and put in something for the sake of open Architecture you want to be able to walk into that system Piece by piece and we studied this in the face consortium We came up with five scenarios of how to do that including adjunct processing so on so forth And so the wrapper concept allows you to use existing systems translate the data And get it into the new system So key operation open architecture characteristics are Provide standardization of the key interfaces. That's number one. That's very important Support the layered architecture principles. That's those five layers. I was talking about So you don't mix Application software with data translation where they're now tightly coupled. And so if you have to replace that you got a headache It's gonna be very expensive. Let's break that up into two different components Standardize the interfaces and then be able to procure those from different sources if that makes economic sense to do that Or you can buy it from the same firm Facilitates abstraction. That's key abstraction of hardware for example because hardware is what goes obsolete and that's what we're fighting constantly is the obsolescence of microprocessors and FPGAs and so on and so forth and so by abstracting that hardware through these standards and certification we're able to greatly mitigate Reduce the cost of obsolescence life cycle management. So key attributes adaptability Configurability to meet different needs you have a system. It is now modularized So now you can take that system Put it in this plant Take the same components reconfigure them put it in this other plant Or different subsystem or move it to a different move it from continuous process to batch process So you're covering multiple market spaces Talked about modularity and portability already scalability. I've talked about that with the DCMs and interoperability Another key focus is data modeling both the data architectures and the models that are used to represent Information in the face consortium. We didn't we didn't start from scratch and and come up with a new data model We utilized data models that were from other organizations We also applied a certification process to it so that again you have that risk reduction On behalf of the the costs of the system Other key system attributes required in an open architecture environment are of course security safety and reliability and Each of those systems has analogies to the DOD space that we did in face airworthiness system safety for example So opa open process automation. I would say has very similar objectives to face future airborne capability environment Establish a standard common operating environment Okay, that's it's the TurboTax example I used okay No matter what system you have at home as long as it's got that operating system on it You can you can doesn't matter what the hardware is Create a strict set of open standards for that environment in opa it extends into hardware So and there's there's precedence for that already There's open VPX for example is a is another standards body that does connectors Before so many jumps up and says wait a minute that that could drive costs pretty high I'm just using that as an example of hardware standardization opa is going to be looking at what makes sense from From a hardware point of view Establish portability based applications as I said earlier with all those attributes From a business point of view create a conformance program. That's number almost number one on the business side Create a registry of portable software Question I often get on this this one is wait a minute. I spent all this money to create IP in my software I got put it in a registry and Expose it and the answer is absolutely not What's in that registry is metadata that describes your software application and it's open and it's published and It does not contain proprietary information. It's just a set of metadata that represents. What is your software? the Repository where that software resides remains 100% under your control in your company That's not touched at all by these standards the registry. However is is is an open Database that people can go and look at for reusability purposes Create contract guidance It's nice to have an open standard. It's nice to have this technical standard, but how do you buy it? How do you buy products to it? How do you sell products? What do you put in the RFP? How do you respond to the RFP? So part of the work of the consortium the business side of the consortium is to provide guidance a document That would go to your procurement folks or your contract folks and it gives them guidance on how to write an RFP How to respond to a an RFP with a proposal? and then obtain Industry and DOD program management endorsement and these are again. These are objectives. So what we mean by that is Outreach we held an Executive forum where we invited Executives in the in the DOD industry and I expect we're going to do the same in OPA where they come in and And and see demonstrations get presentations get an understanding of what these concepts are all about And how they can impact in a positive sense their business. So that's that's what the business working group focuses on creating documented Processes and procedures for each one of those elements and the open group on their part is The carrier of the message and also the publisher of the message. So we create this information Open group then takes it and through their process and publishes it to the world and And helps out tremendously in those areas So the OPA the benefits of face and OPA we believe absolutely it establishes new markets and new suppliers Creates both software centric and for OPA. It's going to create hardware centric market opportunities It's going to allow the introduction of third-party capability. You're going to have companies That now will emerge that Have created products both software and hardware That are going to add such value To the down to the to to the end users process that Here to four were unable to be put into the system and provides the opportunity for rapid insertion of an innovative concepts the ability to Understand those interfaces have your own PhDs for example in your back labs Being able to test those optimization algorithms quickly in the system and then put them into the system So they may generate something in MATLAB Today it's very difficult to get that MATLAB product into the end of the system Tomorrow should be relatively straightforward lowers the cost of doing business common standards lower cost and schedule risks As I think I've talked about this already pretty much with regards to risk management of known standards using systems that are built to known standards and And life cycle cost reduction Through obsolescence management standardization of that software hardware enables the rapid insertion of new capabilities reuse of software components and hardware elements Allows industry to economically reuse even within their own facilities and Reduces long-term obsolescence impacts so with that There's any questions. I'll be happy to answer one question I do get asked quite often is You know what what's the impact? To the to the integrators or the existing industry base and we got that a lot of that on the DoD side In the aerospace business and I firmly believe that these open standards through the certification process is an enabler It's an enabler of existing Companies to do even more and to penetrate even more markets and it also allows new entries So I think it's a win-win situation for both new entrants and existing Players in the industry with that any questions That's a technical term I Do and the crossover I think is it I think the crossover is in the area of Data as a service and so now that you in you know, if we look at the enablement of information flow through IOT And the ability now perhaps to create new markets where you're you're offering a service based on that data And there's some examples that exist about exist already for example with Major capital equipment Being remotely monitored Bering gets hot in a locomotive and information has gone goes to a central Database and monitored and And Information is provided to the user based on that but you need to do maintenance pretty quick So I see yeah, I definitely see a crossover between the two the other side of the coin is security is in my opinion security is very important and It's one thing to Have this ubiquitous data. It's another thing To absolutely ensure security in that environment. So that's that's the key Enabler and key enabler to that my opinion Using the vendor neutrality So if I understood the question correctly I would I would answer it this way you start with a set of requirements derived from user needs you take those requirements and you Build a set of derived requirements For each subsystem whether it be a software element or hardware element, right? So you have these these derived requirements Then you go out to the supply base and You evaluate what the supply base can offer in a vendor neutral fashion And then come up with based on the the trade space that's created the best value to the customer Imagine changing the face name It's a great awesome standard that sounds a bit like a weapon system Well, yeah, that's it. Yeah Brand identity is is something that's that's very important. Of course for the industrial automation Market space we have OPA open process automation. So Face is not really utilized in that space the name face. It's used as an example in the same vein of Not wanting to reinvent but to reuse so the principles and practices derived from the face consortium are now being used in the OPA open process automation consortium But the branding is is OPA With Yes The key factors are the business practices Associated and the technical openness and the certification Those factors are almost universal no matter what market space you're in we happen to pioneer them in face But they're those same concepts are applicable Just about to any market in my opinion about this forum one way of describing is the face standard is change is changing continues to change the way that Product is bought in that maybe it looks industry and this is likely to do the same across multiple industries As you say, it's it really doesn't depend on the industry. It's that those components mean that this is Pretty wise Could we have the person that asked the question clarify it and we'll be happy to the goal is to get these objects and their attributes collected in a Sort of authoritative way so that you can essentially go to a singularity of repositories now We do have another standard ODEF that can help in that But I'm curious if there's been any active interest and entertainment of trying to cluster a brain together these various industry repositories well the key repository That we've set up in the in the future of born capability environment is The is the registry not repository registry For the units of portability that fall into those segments that I showed in the presentation And those units of portability the definition of the interfaces and the data model for those are carried out in the technical working group that define The key attributes of those interfaces the apis for example that are allowed to be used in Each of those five segments and they're a restricted set of apis and they get More restricted as a function of safety profile a general purpose profile safety profile and security profile with respect to that specific Term that you have there. I'm not aware of the utilization of that in the face consortium But I would refer that question to the architects in the consortium Question We're so you're you're getting a snapshot in time on the open process automation and also face face Just talk about that for a second face has now delivered Technical standard. I think we're up to we're just about to deliver a 3.0 And we have a verification matrix delivered Certification processes all all the elements needed delivered with respect to OPA. We're meeting we literally kicked off OPA in late December early November and It's it's it's still in the the the formative stages. We've stood up a business working group We've stood up the technical working group. There's progress being made and next week at the automation research council forum the ARC forum We will be coming together for a face-to-face meeting to map out additional roadmaps and deliverable items Because we are now including things like hardware and hardware interfaces. It adds a little bit of complexity But but I'm but also we're drawing an awful lot from face with regards to Some of the technical standards and things like that and also existing industry standards for Interfaces a whole set of industrial standards again in OPA. We're not and this is very important We're not reinventing the wheel. We're not creating a new standard for the sake of a standard I call it a standard of standards. We're looking at what's in the automation industry today That's standardized. We're picking the best of those and that's what we did in face And once we pick the best of those then we're going to put a certification program in place So we will be mapping that out At our face-to-face. We've already we already have some some straw man Roadmaps, but we'll be that's that's our work product for next week