 Thanks, and good afternoon or good morning or good evening, whatever it is in your neck of the woods. Welcome to the. Business guide version 3.0 understanding the value proposition of the face approach. So, it also gives me pleasure to introduce our 2 panelists. Brendan O'Donnell and Jason, a little bit about Brendan. Brendan served on active duty in the United States Marine Corps as an A H dash 1 W super Cobra attack helicopter pilot and instructor. After leaving active duty, Brendan joined the technology and management consulting firm, who's Alan Hamilton. They implemented new process to improve major systems development and acquisition with the Department of Homeland Security. Brendan has a broad experience helping acquisition and science and technology program managers develop and manage requirements, draft program documentation and interface with prime contractors. He has supported the face consortium business working group since 2012 and is currently the BWG vice chair. Brendan earned a BA in international studies from American University in Washington, DC and MBA from the University of Virginia's garden school of business. He is a Darwin level 3 certified in life cycle logistics and level 2 certified in program management. He holds a top secret slash security clearance. Jason York is a senior software analyst contract of supporting US Army program executive office, PEO aviation matrix from US army combat capabilities development command aviation and missile center. He has been an active participant in face consortium for over 10 years, primarily supporting business working group, steering committee and newer standing committees. Jason is a principal author of the face contract guide, face business guide in open systems management plan data item description. And he is currently supports the PEO AV and modular open system approach, Mosa transformation effort in the office of the secretary of defense contracting for Mosa Tiger team. Jason holds a master of science degree in mathematics computer science from the University of Alabama in Huntsville. So, over to Brendan and Jason. Thank you for the introduction that. You know, you're going to read all of that would have punched it up a little bit, but, but hopefully what you, you all take away from the introduction is that Jason and I have been supporting face for a number of years. Face, if you're not familiar with the overall structure sort of has a couple of different sides to it. 1 is a technical side. Where there are folks working on the technical aspects of the, the face standard and supporting the face approach Jason and I have been supporting the business side. And what we're planning to do here for about the next 40 minutes is go through some slides to talk through. Really, that that subboard there, which is the understanding of the value proposition of the face approach. We have published from the face business working group. Business guide you see there we recently updated that to version 3.0 and for folks who may be new to face. That's a great resource for you to go read to really understand. From a, from a business perspective, what faces is trying to do. So that'll be the topic of the conversation today and, and we, we hope to leave some time about 20 minutes or so at the end to answer any questions that come up and we certainly appreciate everybody's time dialing. So, as I said, as far as agenda for today, we'll talk a little bit about the business guide itself. So folks know the sort of overall contents and where to go to get that information and then we'll cover a lot of the information that is contained in that business guy that really does talk to the value proposition of face. So talk about some of the key goals, the scope of face and the approach and implementing those those goals. A large portion of the discussion today will focus on misconceptions about face. So over time we've as we have supported face and trying to what people know what what face is doing and in the why behind face. We constantly get folks coming to to us with either preconceived notions or misconception about what face is or is not. And so we hope to address some of those and it's a good way to kind of talk about the face approach in a fairly concrete way. So we'll go through some of that. The other emphasis for the discussion today will be on on the face approach and how it supports the do these desire to implement modular open systems architecture principles. So we'll, we'll kind of go through the most of principles and how face supports implementing those. We'll talk a bit about the value of the face approach to both government industry. And it's important to understand that face is a collaborative approach with members from government industry, academia, and all of those folks have interest and and find value in in what the face consortium is doing. And then at the end we'll spend a little time addressing any questions that you might have or throw it up and for discussion. Okay, the business guide 30 for those that are familiar with the the previous two we we wanted to, you know, kind of extend that a little bit and Brennan's already hit some of this what we want to do this. This is a marketing tool targeted for executives to understand the value of the face approach to the government and industry. You know, we did put in a little bit more detail the the face approach the misconceptions talked about when we talk about the scope, you know, a lot of people think, okay, you're targeted toward future platforms that is absolutely true. But we are also targeted toward enduring fleet. We're going to talk a little bit about how the enduring fleet can can leverage and benefit from the face approach. Obviously, very important in in acquisitions is rights and technical data and computer software. So we're going to touch on that a little bit. This guide is publicly available. You know, there there is the link. Next slide please. And from version two to version three. These are really the changes that we that we emphasized. We tried to, you know, capture what is in the face approach. It's been thrown out for a while. So we've got, you know, good graphic or two that details, you know, that we could we could spend, you know, a couple hours just talking about the common misconceptions. What we found that there's a there's a whole lot of misconceptions when you talk about open systems architecture approaches, you know, in the past and they think they bring this forward. We've learned, you know, good bit from the past. So we'll spend some time talking about those common misconceptions. That information is actually in the business guide. What we've seen recently is a lot of DoD and service specific modular open system approach policy and guidance. You know, we're going to, you know, cover that, you know, what came out from the trial services, what came out from each individual services. We'll talk about the NDA and then a little bit lower level. You know, since Brennan and I, you know, both support the Army, what's happening lower level, you know, the service and how PEO aviation, you know, is addressing that. And then we're going to talk, and this is going to be, you know, emphasized here. The face approach addresses all five principles of Mosa and we're going to go over the five principles of Mosa and discuss how the face approach addresses each one of those in detail. Okay. So to step back just a bit and talk about, you know, what is, what is face and why the consortium was put together and why this approach. And why this approach was developed. And you can see there at the end of the day, the bottom line is this is an attempt to get the best avionics software to the war fighters faster. And so the face has developed a technical standard that the face technical standard is an open avionics standard for software. And this is, as I said before, developed by the face consortium, which has members from government. So Army Navy Air Force. A large number of industry participants, both large companies and smaller more focused companies, and then academia. So the face approach has attempted to define a new architectural and business approach to developing and procuring avionics software. So that that approach has technical aspects to it. So how do you how does one technically develop an architecture and develop software. To to this face technical standard. But equally important, I think in the face approach. And as Jason said, from learning from prior open systems. Architecture approaches is that there's been a lot of time and attention paid to the business processes that support. Being able to develop and procure those those software applications that have been developed to the to the face technical standard. The method for managing this process in the consortium. It has been done through under the auspices of the open group. So the open group. Really was the, the Lynch can informing the technical standard. When it got started, bringing together at first the army and the Navy. But the open group provides those sort of those rules for collaboratively developing open, open systems approaches. And because of that everything that that has been developed by the face consortium are publicly available published and available for anybody to go download free of charge. Again, different than other approaches that have been taken in the past, but once things get done and are completed through the internal development process, whether that's something like the business guide or the technical standard. Or a conformance test suite. Those are are made publicly available and anybody, anybody can go download and develop software to the face technical. But again, at the end of the day faces is a. Desire to improve the processes for getting. That avionics software out to the workflow. So, so how did we get here for those that have been around for a while. You know that historically. Do these airborne platforms have been developed for a very unique set of requirements. And usually by a single vendor. And so those. That platform unique design limits reuse of software across the fleet. So, you know, vendor X develops. A platform to a highly unique set of requirements by, let's say, 1 of the services and. To, to develop software across the fleet becomes. Very expensive because we can't. For software each of those vendors have their own proprietary approaches for for developing those platforms. There's there's difficulties. In, like I said, either moving software from 1 platform to the other or developing software. Across platforms so creates high barriers to entry. Lots of lack of competition and what it drives is driven. The services to in the past are having to bundle. New technologies together because the cost of implementing them. Into an existing platform was so high that there had to be sort of a cost benefit. Analysis done to to actually go in and integrate those new software capabilities into existing platforms. This leads to learn long lead times for software development, even for things that are that are critically important. In looking at developing something like space, you know, folks looked and said, hey, the, the, the, the. Another issue is that the, the. Do these current acquisition structure for how we, how we acquire things doesn't sufficiently support we use there. There's not been commonly said adopted set of open standards. For those standards that have been attempted in the past. There was a really no real effective way to enforce conformance to those standards. And on top of that, you know, often the, the way that we. Fund our programs with the doesn't incentivize. Software reuse across the enterprise. So, you know, those multi platform requirements often. They didn't make it into some of the software capability development efforts. So, as a result of that, that current state of play folks got together in BOD. Again, with industry and said, hey, we think we can improve these processes so that this face approach that we're talking about is really a response to come to these problems that were identified. So, what are some of the key goals and what's the scope of face. Obviously, to improve the affordability of capabilities. And as importantly, it's to drive down the time it takes to deliver those new capabilities to the warfighter. So folks got together and said, hey, if we can develop. Some open commonly accepted technical standards define some interfaces that perhaps we can improve both the ability to share software across our, our, our fleets and also reduce the time it takes to integrate that software on onto platforms. And so, you know, so faces is really 1 piece of a larger effort to bring open systems approaches to do the aviation platforms face really is looking at software specifically. There are other open open systems approaches that are looking at things like hardware sensors networks and signal processing those sorts of things, but face really is really all about avionics software. And, and, and so how, how is face sort of operation operational. How is face implementing some of these goals. Well, as I said before, there was a decision made to try to develop some business processes that support. What will be changes to the way we've historically developed and procured. Aviation software and try to incentivize industry to adjust to those changes. Faces to find some technical practices to support development to this open standard. And at the end of the day, really, it's a component based software standard that has been developed. In order to support the development of portable song. So some of the supporting attributes that the consortium has. Identified to support the approach. Number 1 being the desire to accelerate innovation and bring new technology into our platforms. So because of the, the barriers to implementing new capabilities that we discussed a bit earlier. The, the war fighters are not getting the latest and greatest technology on their platforms. So the desire from a, from the face. A consortium perspective is to be able to accelerate how quickly we can get those. Those new platforms are reduced barriers to integrating capabilities and enable the department of defense to pay for new capabilities rather than for costs associated with integrating those capabilities. Another desires to be able to enable cross platform software reuse. So I'm making the software more modular portable. The belief is that we'll be able to support. Reusing software so software that provides a capability. Which is a largely, you know, just, just within the software application. We can take that software and move it from platform to platform in a way that we can't today. Face has currently we'll talk about this in a little bit, but is implemented. A software marketplace where folks can go, whether you were a. Government program manager or your systems integrator, or you're just somebody who wants to know what's out there that has been developed and been through the face. Conformance process. A marketplace where folks can go to discover those things. And then the other thing that faces been very conscious about is aligning with other architecture initiatives. So you'll see that face. Within the face technical standard within the technical approach face leverages existing. Open architecture standards, and then there are other open architecture efforts that are that are leveraging the work that the face consortium has done. And so they've been very conscious about trying to not read that wheels work when necessary and also communicating to others. Some of the benefits and approaches or lessons learned from the work that the consortium is doing. So to support some of those things from a from a business perspective. Face has stood up and has implemented a conformance program. So we'll talk a little bit more about this, but there's a process by which software developer. We'll get their their product verified that it that it meets the face technical standard. And then that that that software application will be certified to to be available for folks and published in the registry of application so anybody can go discover that product that's been developed. The registry is the place that sort of the app store where folks can go look today and see what applications have been developed. And then we've also developed. A series of of guides of publications and put a lot of intellectual energy into helping folks support the business processes that are that are required for this this sort of new approach. So something like the face contract guy that Jason is heavily involved in developing is really aimed at both program managers in a government office if you need to write an RFI or an RFP for an application with with face requirements. We have a sort of a checklist and common language or example language that folks can use. And also for folks who are in industry and need to respond to those RFIs and RFPs, that's a resource that folks can use to to to guide them in those responses. So face for for a few years when Jason and I first started supporting face was very future looking, trying to define processes for how we were going to do this conformance program or what's the registry going to look like. But but face to you know today is operational it's up and running industry is using software product lines to to build applications to the face standards. There's expertise available so if you are, you are new to the face consortium, or you're new to trying to understand what face is all about and you want to develop an application to the face standard. There's lots of folks within the consortium. There's training that's that's coming out certified training that's being worked on right now for folks to be able to develop applications to the technical standards. So the bottom line is there's there's there's lots of expertise out there on how to do this from a technical and you can go in the registry right now. You can see there's units of conformance, which is the face term for for those things that that go through the conformance process that are listed there. There's 14 suppliers that have gone through that process and then have things listed in the registry. The bottom line is faces up and it's ready and it's available. Okay, the common misconceptions, we built this list and kind of revised it, you know, over the last several years, we do a good bit of outreach to platforms, PMs. And I know the other services to and these are these are some of the common or the most common misconceptions that we hear. And so, so we want to just, you know, go through, you know, each one of them will have a slide, you know, for each, but here, like I said, here's the six most common. And then I hand it off to Brendan and we'll just go back and forth going through these. So the first one in that list is that all saw all software on a platform must be face conformance. So this is how a thing that folks come to say, Hey, you know, if I, you know, if I have to build all my my software on my platform to face, either that's going to be prohibitively expensive or it doesn't make any sense because I have a field of platform. But, you know, faces is the intent of faces to promote portability and reuse. There are, there are times where let's just say an upgrade to an existing platform or a development efforts may not make sense to to to be face conformance. So if there's no intent or there's no benefit for a particular software application to be reused or to go into the registry and for other folks to know about it. Then it then your application, you know, doesn't need to be developed to the face standard. It's really a kind of a business case decision for the PM on a case by case basis basis, what what needs to be or what should be potentially reusable software that would be a candidate for going through the face conforming process and what wouldn't make sense to do that. The other the other thing to understand is that that there's no, you know, face. The face conformance programs supports conformance for units, what we call units of conformance, where the interface the interfaces of a software component are analyzed and verified to conform to the technical standard. Face does not there's there's no face sort of system level conformance or face platform conformance. So, so a platform or system can be made up of all software units of conformance that that have been through the face standard. It can it can have software applications that that are that are. Or it can have software applications, some of which are face component, some of which are not. And there's no reason why those 2 things can't exist on the same either subsystem or a profit. So, one of the common misconceptions is that the face approach only applies to future systems. This is absolutely not, you know, true. Obviously, it can it can definitely benefit future platforms because it has the ability to design, you know, from the beginning, so you set up your, you know, face infrastructure computing environment. So, you know, from the, from the very beginning, you know, you can host face component software, the enduring fleet, you know, that they have their up and flying legacy, you know, designs and architectures. There is many integration patterns to set up this infrastructure with, I mean, as a mission processors, you could have spare processing power in your mission processor, or you could have it in your ASC suite, or you, you know, some places have, or some platforms have smart displays, and we're kind of going away from that. So, that may be a resource that we can use to to implement that. There's quite a few integration patterns that the legacy platforms, you know, can realize. And what really helps with the legacy platforms in addition to cost savings, it helps address obsolescence issues. If they have something, you know, go and, you know, obsolete, they can look in the registry. And if it satisfies their need, they can pull, you know, from the registry work with that, you know, software supplier and integrate and avoid that NRE and the time there. So, there is, you know, cost avoidance, government's not in it to save money. We want to cost avoid as much as we can where we can provide more and more capabilities to the war fighters. So, the next common misconception is that that face either, either insures and the face conformance process either can insures or inhibits performance. And like I said before, this is, this is a really a, you know, a conversation about the face, the business approach and the value proposition. So not to get too technically in the weeds, but the face technical standard and the face conformance process doesn't specify or guarantee functionality or performance. So it doesn't relieve that the systems integrator or the project manager from their systems engineering responsibilities to adequately adequately assess how well a software application performs its technical mission. So the face conformance process really is only looking at those technical interfaces and do they align to the requirements developed in the face technical standard. So, if your, you know, your, your calculator software application takes 2 plus 2 and comes up with 5 faces not looking at that performance of that calculator application. It's only looking at whether the software interfaces align to the face technical standard. So another misconception here a lot is that the face approach requires unlimited data rights. That is absolutely not true. In fact, the government can afford all the IP and if the government could afford the IP, what are we going to do with it? Because a lot of times the SMEs reside, you know, in industry. So what we've really focused on is what the other, you know, software acquisition is focused on and that is open interfaces and a modular design, preferably a government prescribed modular design if we can, you know, achieve that. So the face approach really enables the software suppliers to protect their IP, you know, within their applications. We're just interested in keeping the interfaces open to promote competition and innovation. Something else we've heard, you know, particularly early on when face was getting going that there were concerns that face was going to be another layer of requirements levied on a PM or systems integrator and that it was going to be cost and schedule prohibitive. You know, face as we mentioned earlier, that all the products of the face consortium are open, non proprietary, free of charge. So there's no licensing or, you know, any of those sorts of costs that would restrict developers from developing something to the technical standard. There's no royalties or or any kind of restricted covenants when it comes to the actual face technical standard. And what we've, I think, heard from our industry partners is that there are definitely benefits from developing to the face approach that there's there's efficiencies to be gained by using standardized interfaces that support. You know, developing software product lines and being able to scale technologies across platforms. So we'll talk a little bit more about some of the benefits industry, but that that's certainly one of them that ability to to scale technologies across platforms. So in the last one here, I won't spend too much time on it because we've already, well, no, actually this one, this one's different. So the face technical standard does not specify or guarantee compliance with safety certification standards like mill standard 882, you know, or, you know, on the on the civil side FAA deal 178. We have, you know, a recent effort that's being ran in our enterprise architecture group to kind of look at, you know, airworthiness requirements. In the past, we have on the army side, we looked into that and developed a developers requirements guide for airworthy reusable, you know, you will see that that is specific for the army, but it but it is it relates to the face approach that is publicly available. If anybody would like a copy of that, you know, please, you know, contact Reggie contact me and I'm happy to provide email provides you a copy of that. Next slide please. Okay, value to the government and I've got, you know, more slides, you know, coming up, but we have to address policy and mandates as they come out. So we've seen over the years, you know, open interfaces recently a lot of policies on Mosa to use of open standards and, you know, have a way to verify that those approaches. We're looking for, you know, affordability. We're trying to do more with less. We want to extend our money. And in addition to that, we want to provide these capabilities to the warfighter as fast as we can. And then one way to do that is to reuse. So, you know, reusing the capabilities and making, you know, capabilities enabled by software portable to platforms is an excellent way to do more with less and make this available on multiple platforms. Next slide. Okay, I mentioned the recent guidance on Mosa just wanted to recap that a little bit. And just, you know, before I really get into this, I didn't go into detail, didn't, you know, have a slide on the National Defense Authorization Acts. Two very important ones was the one in 17, which really pushed Mosa in the acquisition strategy. And the context in the push was really for major system interfaces and making sure, you know, that those are open and wouldn't be, you know, proprietary. And that kind of, you know, fosters the competition and prevent vendor lock. What we saw with the latest one, the NDA of 21, we saw that go down a level to modular system interfaces. And the drive is really focused on interface and interface delivery. And there's actually language in there. Government's going to make best effort, even if developed at private expense to acquire GPR on those interfaces, just because we're interested in promoting innovation and preventing, you know, vendor lock. So, you know, that being said, those NDAs are out there. So, with the, with the trial services, you know, DOD, you know, we saw a couple years ago a memo come out and it specifically called out the face technical standard. And, you know, a couple of quotes there, continued implementation of these standards is vital to our success. The services, all three of the services followed that up. Secretary of the Navy issued some guidance. The Army Acquisition Executive issued some guidance. And then the Secretary of the Air Force, you know, issued guidance are related to most and how that would be implemented. I can go in just a little bit more detail. I've got, you know, more visibility on the Army side. That Army Acquisition Executive memo empowered ASALT, the Office of the Chief System Engineer specifically, to develop a MOSA implementation plan. That was actually released in June of 2020. And it specified requirements for PEOs and program managers on their recommendations to address MOSA, you know, in their enterprise. PEO Aviation made a significant effort and set up a MOSA transformation organization to address those in several different areas. Provided that and got absolutely outstanding feedback, you know, on the approach for the Army side and it looks like PEO Aviation is kind of leading the way. And we'll be an example for the Army. That was actually a direct quote from the Office of the Chief System Engineer. They were very happy, you know, with that. Next slide, please. So one thing that I failed to mention is in that ASALT MOSA implementation plan, it is aligned to the five principles of MOSA. I've got the principles listed, you know, on the left here in blue and the face approach, you know, was designed to address all five of the principles of MOSA. So the first one is establishing an enabling environment. You know, we've done that. We've got a tech standard. We've got data architecture. We've got tools to support, you know, testing, change requests, problem reports. We've got, you know, guidance on implementations. We've got, you know, it's not doing it credit, but, you know, a face software. Hello, world boss. It's a lot more, you know, detailed than that. There's training available. There is a course accreditation effort to a credit course from third party, you know, suppliers. As Brandon mentioned earlier, capabilities in the registry. We have support on the business side. Honestly, we're covering the business guide today, which is really a marketing tool, why, you know, the face approach benefits government and industry. But we have tableable contract language, you know, in the contract guide, you know, it not only covers RFPs, RFIs, it covers BAAs and OTAs. So I encourage people interested, you know, in that, you know, pull that, you know, modular design, base reference architecture. We define five architectural segments and then also there's a data architecture and it goes into great detail about the shared data model, the single shared data model. The ability to develop domain specific data models to help encapsulate basically it extends the shared data model. It's not required, but a lot of the government efforts we want to develop the shared data model, we can put that on contract and then the USM, the user supplied or ULP supplied model. So we have those, obviously key is designate key interfaces in, you know, the face interfaces are the OSS, the iOS and the TSS. Face is a, it is an open standard, but it is a collection of open standards. We hadn't reinvented the wheel, we use standards that are out there. I just listed a few here, A-Rank 653, 661, OpenGL, POSIX, now it goes on and on. And one of the things that really separates the face consortium and the face approach from other open system architecture initiatives is the conformance program. We have a conformance program that's operational, you know, you go through verification, you go through conformance, you go through registration. If you meet all three of those, all three of those, you get to go in the registry, which is a, you know, card catalog. Brendan discussed that earlier and showed there's actually 25 entries now and we know there's quite a few more, you know, in the pipeline. So that number continues to grow. Next slide. Okay. Yes, we've talked a bit about obviously the benefits from the government side and the desire to be able to get capabilities to the warfighter faster. Which I think everybody who's involved in developing software for DOD aviation systems is interested in elite, you know, particularly folks that are doing that work in industry. And so there's a large number of industry participants. If you go on the face website, you can see who they are. But some of the value that they find in the face approach that number one, they are able to satisfy the customer and the customer's requirements for things like Mosa to support their desire to more rapidly implement capabilities to support the ability to reuse software across the fleet. And so they are addressing the customer's needs. There's also opportunities by aligning to the face approach for industry to increase revenue and market share. So, you know, obviously, there are, if you see things that are coming out, RFIs and RFPs, there are face requirements in them. And so if you are a member of industry and you have some expertise in developing software applications to the face standard, you are going to be ahead of your competitors. By pursuing the face approach, there's also I think a benefit for future platforms, particularly for companies to be able to compete over the lifecycle of those future platforms in a way that if there were not a face approach, they may be locked out. And so by having those open standards, you know, companies may be able to compete in a way they couldn't previously for future efforts. And then, you know, the bottom line for industry, for those publicly, for companies that are publicly traded, particularly is to improve their shareholder value. So, all of those things we've talked about being able to support the customer's requirements, be more competitive than their peers really does support a real return on those investments in supporting the face approach. Again, Jason mentioned earlier that face is not solely focused on the future fleet, but there isn't there's what, and that is definitely true. There's, there's I think a vision to be able to bridge between the future fleet and the current enduring platforms. You know, while that transition in the future fleet is happening so there's work right now going on to bring face to existing platforms. Obviously in the future, all of those things that we've talked about as far as the benefits of the face approach. We certainly envision those coming to fruition for for future platforms for to support new design systems level upgrades. We want to be able to increase the pace at which we're able to feel incremental capability improvements on our future platforms, you know, reduce complexity and be able to port software and again, ensure our war fighters are getting the latest technology without having to pay for those integration costs. So, for the enduring fleet there's investments being made to be able to bring applications built to the face technical standard to the enduring fleet. Jason mentioned some of the benefits around obsolescence. And then also, you know, some of those software development efforts for the current fleet really do have an eye towards, you know, bringing those forward once some of the future looking platforms mature a bit. So, the data rights, we talked about, you know, this earlier and the takeaway here face does not levy additional data rights other than, you know, what's typical in software acquisitions. We encourage the program managers to develop the data right strategies recommend that really focus and identify the most frequently changed pieces. You got to understand the defars and obviously with the recent guidance really need to go after open interfaces and try not to get locked in to one vendor and promote competition and promote innovation. And, you know, a lot of times, you know, we have to look at near term but we also have to look at long term and, you know, extended lifecycle costs. We recognize that industry invest their capital to enhance innovation and to give them a competitive advantage. You know, we are, you know, happy, you know, happy with that we want to be able to protect their IP. We just don't want to get locked in if there is another vendor out there that has, you know, a better product. So, you know, we want to kind of push the envelope as far as vendor independence and keep the, you know, the market, you know, for the best to breed. So, we want to thank everybody for their time today. We've got about, I think, 12 minutes left for questions. If there's anybody who wants to know anything more about the information presented certainly in this brief. You can contact me, Brendan or Jason directly. If you have other questions about face that that may be not particularly business related or more technical nature. And you want us, you know, you need help directing those questions to somebody who might be able to help you out again. Please reach out to Jason or I and we'd be happy to facilitate those conversations. So that being said, I see a couple of questions there. If there's others Simon or Reggie, please let us know, but we're standing by for your questions and thank you again for your time. Okay. One of the questions Jason or Brendan we've got is their face equivalent for the army and naval branches of the forces. Jason, you want to take that. Sure. So, you know, this isn't, you know, specific for the government, specific for a service or, you know, specific for the aviation domain that this is a freely open standard. So it's, it's applicable, you know, across, you know, the board and, and so I mean, any service can use it. Any, you know, industry can use it and we've seen this being used, you know, in other industry, the ore refinery industry, the medical industry. So hopefully that answers your question. I mean, if you find benefit in it, it's freely available to use. Yeah, there's, there is a face technical standard. And there are, there are, there are tools and processes that have been published to support the face technical standard. And it's not an army standard or a navy standard or, you know, UK standard. It is just the face technical standard. Okay. Another question. What are the implications for national security and application security. Jason. Yeah, there is a security group subcommittee, a part of the technical working group that addresses security, you know, issues. I don't really understand about national security, but that there is an effort, you know, in the technical working group to address security. And there's different profiles. There's the general purpose profile. There's the safety profile. And there's the safety extended profile. That's, that's kind of getting them, you know, the technical side and does that, does that answer the question. Yeah, the other thing I would say is, is, is, as, as, as we've stated a couple times today, all of the work products that have been developed by the face consortium are publicly available. Anybody in the world can, can log into the open group of story and download those things. However, the, the members of the face consortium that develop those products are actually US restricted to US persons. And so that, that, I don't know if that addresses your question. So while the, the, the end products are all publicly available, certainly in the development of those products there was attention paid to, I think the concerns that question the question reasons. Is space available for non US forces. Yeah, the technical standards publicly available. They're all of the supporting software development kits and test tools and all of those things that have that are completed development. Within the consortium are publicly available. So anybody can go download them. There's actually some conversations ongoing about lifting that US persons only restriction for members of the face consortium that hasn't happened yet. But, but there's certainly a lot of international interest in this in the face technical standard. Anybody can go get that information. Okay, there's a question here. It looks like within this question is like 3 questions. So I'll address them one at a time. Is there a possibility to use space in. Do dash 178 C D a L a certified software for civil type certified aircraft. In any examples are known projects that are trying to achieve this in any vendors doing stuff there. Any thoughts on applicability for civil stuff. You got all that. Yeah, absolutely. You know, one of the misconceptions and it is, you know, faced is not guarantee or prevent. You know, airworthiness. So what we found, and I can't, I can't give much details about here. We've executed several crates with industry partners to help, you know, mature, you know, the face, you know, technical standard. But, but absolutely. And through the conformance program, a lot of the the industry partners that were under created with they used some of their airworthiness artifacts to satisfy some of the the conformance verification matrix, you know, requirements. If you're asking for a specific example. Where we applied it, I won't name the vendor, but it is a middleware supplier. Was able to achieve, you know, face conformance and their product is a dally certified. Now, I'm just saying you go on the open group, slash face, which is the main face website. You go to the members page. You'll, you'll see lots of companies that support both. You know, avionics systems for for do the commercial industry. Okay. This question, I guess I could answer this one. Can we get the presentation and that will be posted. So, yes, you will be able to get it. Okay, another question. Some industry competitors who currently invested maintaining competency for their vertically integrated system. Their platform, their cockpit may view the deconstruction of their product into separate, several and compatible components as a disincentive to invest in that contents. Where does face stand in maturity in terms of production programs and number of UOC's in production? In other words, how reliably can one predict their return on investment in terms of production revenue stream. It's a big one. So, obviously, you know, one of the things here for the face approach, we are really promoting competition and open interfaces, but it's not just us. The DOD with the most of guidance that came out and, you know, one of the, you know, the key principles is designate key interfaces, have a modular design. So, there, there is a push, you know, for the government to have, you know, the open architectures, you know, the best breed capabilities and it really empowers, you know, the smaller vendors and to be able to play in these markets, which was typically been dominated by a platform prime contractor. You know, one of the things that we saw, and I didn't talk about this, you know, a whole lot, but, you know, the ASALT MOSA implementation plan, it's aligned with the five principles of MOSA and they made it very clear that they expect in acquisition strategies that MOSA is a discriminator. So, if you, if, I mean, that, you know, that's clear and when solicitations, you know, come out, if you offer proprietary interfaces, that is going to be, you know, a negative, you know, based on the guidance, you know, at least, you know, on the army side and I suspect, you know, similar guidance is came out with the other services. Okay, I think we have time for probably a couple more questions. Just on that, I would say, you know, there's lots of companies that have come together in the face consortium to develop the face approach, both the technical pieces of that and the business things that have been done to support the technical approach. But those companies are still competitors. And so, you know, in a lot of ways, they're all doing that return on investment analysis. You know, individually, and for some companies, this, you know, this will be a change to their business model for some, it may be a threat and for some it will open up a great deal of opportunity. Okay, OMS slash UCI and face appear to be competing standards. And is it difficult for industry to support both? Do you see the government heading toward one standard versus the other? So, I think they can coexist. I mean, if you're asking specifically about OMS, there's definitely differences. OMS was developed. Kind of restricted by invitation, you know, only with just a select few companies participating. As far as I know, they do not have a conformance program. You know, similar to face, face is basically a collaboration of the willing. Decision to go through the open group industry comes and participates government comes and participates. What we develop is, it's fairly available and open and we do have a operational conformance program which hits that fifth key principle of Mosa is to certify conformance. One other question. The balsa examine example, does it appear to be publicly available? Can you put the correct link to obtain such information? It is publicly available. Well, it is, it has been approved for public release. And that is being worked. He was actually developed, you know, by the army. We've approved it. We're working out the details, you know, with the open group, you know, with the expectation that that version, I think it's 3.1.13, you know, will be publicly available through the open group website. Okay, those are all the questions for now. I think there's one more that was put in chat. Oh, is there a face Linux version? Thanks. Did you hear me? I did. You know, face really targets, you know, POSIX and a rank 653. Many of the developers will use a Sintos, which I believe Sintos is a real times Linux variant and the technical folks, you know, can correct me here. You know, to that's a lower cost way, you know, to do development and then port to the actual real time operating system. I don't know if I'm specifically answering the question. But there, but you can use a Sintos, you know, for development. Okay, so that there's just one more in there, Reggie. It's right above it. I can. Can you address how face can impact platform other than VPX? Is it worth it? Most of kind of requires VPX. So I'm definitely not a hardware expert. But, you know, face is a face tech standard is a component based standard for software. And we've made it push to be hardware agnostic. So I'm not, I'm not aware maybe open VPX addresses, you know, the definition of Mosa and, you know, the principles. But, but I don't, I don't think you have to be VPX to have a Mosa open system approach. Okay, there is a comment on the chat that VPS is a hardware standard, nothing in face is specific to VPX. And you can use face GPP on any Linux from Mark Snyder. If that's all the questions, we certainly appreciate everybody's time. You know, like I said, if folks have one want to get in more in depth discussions or want to take something offline. Please don't hesitate to reach out to Jason or our contact information will be in the slides at Reggie. Okay. Great job. And the presentation will be available on the website. On the base website. So thank you everybody for joining. Thank you, Simon. Great. Thanks everyone. I'll end today's presentation now. Thanks everyone. Thank you. Thanks.