 Welcome, everyone. And as you just heard, this session will be recorded. Just want to give everyone advanced notice. The panelists are already aware. The attendees, we will not hear you on audio, but we will have ability to chat with you and also for you to use the Q&A feature to ask questions to the panelists if anything comes up during the presentation. I would like to first introduce myself. My name is Judy Serenzia. I am the Face Consortium Program Director from the Open Group. And I would like to welcome all of you today to the Face Contract Guide webinar. We appreciate your interest in learning more about using the Face Contract Guide. And thank you very much for joining. I am going to run through some of the webinar features quickly. We do have a chat window that some of you have already found and have been using. This you can use to chat amongst yourselves with any of the other participants that are here listed on the attendee list. You have an option to choose all panelists, all participants, or just an individual that you may want to chat back and forth with. There is also a Q&A feature that you can use to type in questions during any particular slide presentation. I will pause after each slide to make sure that if there are any questions in the chat window that we ask the relevant speaker the question so that we can get those questions answered live, not save them for the end of the presentation. And with that, I would like to introduce our panelists. First, we have Gabriel Flores from Northrop Grumman. He is the Face Consortium Business Strategy Subcommittee Lead. And then we also have two co-leads from the Business Strategy Subcommittee, Jason York representing U.S. Army Ammerdeck and Deborah Morady and representing NAVAIR. I'm going to start things off with a quick introduction to the Face Consortium, the FACE Initiative, some of the benefits to government and industry for using the FACE approach. And then we'll turn things over to the panelists to give you more information and education about the FACE contract guide, its intended purpose and how to maximize being able to use it. Okay, so what is the Future Airborne Capability Environment? The Future Airborne Capability Environment is a government industry software standard and business strategy designed to develop to acquire affordable software systems, rapidly integrate affordable capabilities across global defense programs, not just domestic, and attract innovation and deploy it quickly and affordably. The software standard and business strategy are developed through industry and government collaboration via the Open Group Face Consortium. The benefits that we found for government users is that the FACE approach does fit in quite nicely with better buying power. We have a lot of the same tenants including increasing competition, achieving affordability and controlling lifecycle costs of multiple programs. We also look to incentivize productivity and innovation in both industry and government and reduce software development times again to achieve affordability through modularity and portability. We also look at cross-platform decision-making, build it once, use it multiple times, focusing very much on the ability to reuse applications across multiple platforms without having any cross-platform dependencies, eliminating the need to invest multiple times to develop the same capability over and over, and enabling integration of cross-platform requirements. So this all fits right in with better buying power. The cross-platform decision-making is something new for government investment approaches but it's something that can be achieved by using standards such as the FACE technical standard and the business approach we're putting together. We've also put together FACE industry benefits, industry benefits by being able to enable new markets, creating software-centric market opportunities so that there are more market niches that industry can go into with their existing product lines. It also enables penetration of formerly closed platforms where if one prime contractor developed the entire software stack, there wasn't really room for some of the smaller vendors or innovative vendors to access where their areas of expertise happened to be. It provides opportunity for software applicability to multiple aircraft types as well. It also provides a way for industry to lower their cost of doing business. Common standards will lower cost and reduce schedule risks. Standardization of the software interfaces allows for rapid development of capabilities because the interfaces are already well known. And reusing software application does enable integrators to optimize platform performance. Just a little bit about the FACE consortium. We have been very busy developing several work products to date. We have, back in January of 2012, we released edition 1.0 of the FACE technical standard. There were some corrections update enhancements to that that we put together through a technical core agenda, which was rolled out as FACE technical standard edition 1.1. And then FACE technical standard edition 2.0 and 2.1. FACE technical standard edition 1.0 focused more on the technical interfaces. Editions 2.0 and 2.1 introduced the concept of data model and syntactic interfaces. We're evolving edition 3.0 to represent syntactic and semantic interfaces as well. So we're getting more and more detail, more and more ability to share and communicate across different standards, across different communities, as well as within the avionics community. We've also put together reference implementation guides to describe best practices for how to use the technical standard. And then data model, conformance documents, conformance verification matrix as we go through the verification portion of the conformance program. FACE business guide version 1. The FACE contract guide, which you're going to be hearing more about in just a few minutes. And then information on the library infrastructure, where we will store our set of FACE conformant software products in a registry where folks can find what has been through the FACE conformance program, certified as FACE conformant and available to reuse. So we're very excited about the level of effort that we've put in and the fact that we are getting ready for business to enable contracts to be written that have FACE requirements for FACE conformant software and information for vendors to be able to provide how they are going to supply FACE conformant software products as well. You can download any of these documents for free. They're globally and freely available from the opengroup.org slash FACE web page. Just go to opengroup.org slash FACE slash information and you'll find a list of the documents available with links to get each of them individually. Any questions so far? Okay, so with that I'm going to go on mute and hand things over to Gabriel Flores, our first presenter. Okay, hello everybody. As Judy introduced me, I'm Gabriel Flores of Northrop Grumman, FACE Business Strategy Subcommittee Chair. Now the FACE contract guide was published in 2014 and before that, as you saw the number of documents, there were a number of FACE technical documents that were published and made available and we had teams working on the technical aspects of the FACE standard. So what we found what was missing was actually the practical how to get the FACE requirements into solicitation and resulting contracts. And we would often get a lot of questions from both government and industry on how to do this. And as it was a very important part of the consortium to address the business aspects of the FACE standard, it was decided that the FACE contract guide would really solve that part. And so really the FACE contract guide came about out of that and it's really the how to get FACE requirements into solicitation and resulting contracts. And so it provides guidance on the language that you could directly insert into solicitations and contracts. Now none of it is mandatory and is meant to be palerable to the program and the program manager specific needs. It was produced by the consortium with participants that included the U.S. Army, Navy, Air Force, and industry participants. And it will apply to all editions of the FACE technical standard, including 1.0, 2.0, 2.1, and any future editions that will be released in the future. As mentioned, it provides terrible language that you could use for solicitations and it highly leverages the DOD, OSA contract guidebook for program managers. We actually had started looking at that because we didn't want to repeat a lot of the concepts that were in that guidebook, but we just wanted to augment it that was specific for FACE. And it's important to note that this isn't necessarily change any procurement process or requirements. It's just really adding clarity specific for FACE requirements. Okay, next. Do have one question that came in that I'm going to put forth to the panelists before we move on. So what is the real motivation behind FACE? The benefits that have been mentioned are generic benefits which you can achieve by better architecture and design. I'll open that up to our three panelists, and then I can see if I can chime in at the end with some more specific information. I can try to take a hack at that duty. Okay, go ahead, Deb. This is Deb Moradian. I believe one of the primary goals, at least from the NAVAIR standpoint, was there's a lot of guidance as to open architectures, but it was guidance and generalities. And the FACE approach is one implementation of open architecture and one what we would call a technical reference framework, which we thought was needed. Gabriel, Jason, any commentary? John Bowling. Sure, Jeannie. This is Jason. So the FACE approach really promotes portability. And we do that through well-defined open interfaces. So I agree there's other viable approaches out there, but what we're trying to do is standardize across the services and across the industry to have one approach with a layered architecture with well-defined interfaces between the segments. If I may add to that, I would say that we've all recognized that we built a lot of tightly-coupled systems that were necessary to meet performance on the hardware of the era, but hardware is now outpacing the capability of our software writers. So we wanted to come up with an approach that would allow us to pursue abstraction in our software in the avionics arena and elsewhere in order to have an organized approach to it was not one vendor's solution, but to have a vendor independent set of standards such that as we go from tightly-coupled systems to more abstracted systems, we do it in a controlled and shared way so that there's a much better chance for us to do reuse between various vendors and programs. Thank you, everyone. I will move on to the next slide. Okay. So who's the target audience for the contract guide? It's really both for government and industry, right? So any acquisition team that has open system architecture requirements and specifically face requirements that they want to put in their solicitation and contract is really geared toward them. So the team that would include both engineering, logistics, contract spokes, legal, et cetera. And it's also equally useful for industry teams that are responding to such a solicitation so they could understand a lot of the motivation behind the language that would go into such documents. Next chart. The layout of the document is as such. It starts off with an introduction, describing what the document is and its goals. And then it goes into the main section of the recommended tailable language for these specific aspects of a solicitation and contract. It includes specific language for statement of work, technical specification, section L, instructions, conditions, and notices to offers. Section M, where it contains the evaluation factors, and section H, special contract requirements. And then in the appendix, you have an overview of the face conformance program, as well as standard schedules. Some amendments you may want to consider for standard schedules that would include face requirements. And then as well as a template for both OSMP and the software architecture description. And throughout the document, you'll find what we call these commentary boxes that provide additional rationale information and information on various topics throughout the document. So we'll have the tailable language in there, and then we'll have a commentary box to kind of explain our rationale and our thinking behind why you may or may not want to include that language and how you may want to tailor it for your specific needs. Okay, next chart. And for some specific guidance that it provides, some examples here is that it's important to note which face technical standard addition that you'll want to adhere to, whether it's the 1.0, 2.0, or 2.1. You definitely want to put that into your solicitation and your contract. Some additional things to consider is defining what specific capabilities that you're requiring to have face conformance. Another aspect to consider that we mentioned in the contract guide is the deliverables and artifacts. Which deliverables and artifacts do you need to ensure portability and reuse throughout the whole program lifecycle? And what are the appropriate rights that you want to consider to have that? As well as what you'll want in the end is the face conformance certifications. Once they're attained, you'll want that to be delivered for the program. So these are just a couple of examples of some things that the contract guide provides. Next chart. And I think from here, Jason. Yes. All right. Thanks, Gabriel. So what I want to do with this slide is talk about three specific areas that the contract guide doesn't fully address. And the reason the contract guide doesn't fully address these is because the face approach does not fully address all of these three areas, which this has led to some misconceptions that the consortium has battled. So I want to take the opportunity to kind of dispel some of these misperceptions. The first one is in data rights. So you've probably heard, oh, the face approach requires unlimited data rights or minimum GPR. That is absolutely not the case. The rights and technical data and computer software, we are not adding any additional requirements on data rights. In fact, the tech standard doesn't specify any of the data rights in it at all. One thing that we are pushing in the contract guide is to look at your specific solicitation, what you're trying to acquire, talk to your legal counsel, and figure out what rights you do need to make sure that you're successful. When we talk about the face approach, we're talking about well-defined open interfaces between the segments. And we, as a consortium and the face approach, we support software vendors protecting their intellectual property. So that is one of the misconceptions that we wanted to spell here. So we are not increasing the amount of data rights. Actually, we're not changing it at all and we're not trying to get the intellectual property from the vendors. We're allowing them to protect it. We are just really promoting portability. And like I said, we really emphasize in the contract guide to go seek out your legal advice on your specific procurement and figure out exactly what rights you need and what you can afford. The second misconception is about performance. I've heard people say, oh, well, if your face can form it, you're guaranteed performance. Oh, well, on the other hand, if you're following the face approach, you can achieve performance, which is not true at all. Functionality and performance are actually not specified or discussed in the tech standard or the contract guide. It does not guarantee functionality and performance and it does not prohibit functionality and performance. You still have to go through your standard, you know, testing cycle and ensure what you're acquiring does perform as the vendor claims it does. And the last one that's causing this conception, a lot like performance is airworthiness. The face tech standard and the contract guide does not address airworthiness. And I've heard people say, oh, if you're following the face approach, you're guaranteeing airworthiness qualification or oh, if you're following the face approach, you can't qualify, which is not true at all. We decided early on in the consortium not to address airworthiness as a whole. It was kind of a large thing to tackle. So the Army, specifically MRDAC, Software Engineering Directorate, also aligned with our Aviation Engineering Directorate, which is the Army's Airworthiness Certification Authority developed a document, Developer's Requirements Guide for Airworthy Reasonable Face Units of Conformance. That is available based on request. That is actually a Distro A document. So if any of the attendees would like a copy of that, please let me know, and I will make sure that we get you a copy of that. Like I said, that is Distro A. Okay, Jason, before we move to the next slide, we do have a question from one of the attendees that I'll again ask each of the panelists. Does it cost more to do face? And Jason, we'll start with you since you're the current speaker. So if you're talking life cycle costs and you're talking cross-platforms and being able to use this to port it to other platforms, I'm going to say the answer is no. What you need to do is go and look and what you're trying to procure and see if that is a capability that's a good candidate to follow the face approach to be used cross-platform. You know, maybe cross-platform in the services and maybe there could be cost sharing amongst the services, you know, as well. Any time that you can do cost sharing to multiple platforms, it's going to save you in the life cycle cost. On the second hand, if you are, if you're just trying to procure a capability in a stove-pipe manner, it is very likely, it has not been proven, but it is likely it is going to be slightly more expensive to acquire a face-conformant product or a capability enabled by face-conformant software just because you are taking into account kind of a software product line mentality you're trying to prepare, you know, for that portability to be used on other platforms. Deb, Gabriel, John Boling, do you have more to add? Yes, Gabriel. Yeah, I would second to what Jason said. If you're developing a face or a capability with face requirements in a stove-pipe manner, it would probably be the same, if not a little bit more, cost as Jason said. It wouldn't be a whole lot more, but it would certainly be at least the same or a little bit more. And really, again, with face, the cost savings really comes in the ability to reuse these capabilities on multiple platforms. And I would pick you back on to that that like Jason said, if you're doing it, if you're used to doing things in a stove-pipe manner, you don't care whether you're not thinking about that next integration, then face could cost you a little bit more because you do have the element of the conformance testing. But if you're thinking ahead and you're getting that capability with the face common operating environment that's going to make your next integration, you're going to be able to take advantage of a previously developed component. The integration should be easier. So in that way, you're going to save money over the life cycle. As a current software development project using your current methods and now you're implementing the face technical standard, there's going to be a learning curve to do that and it's going to depend on how closely you are currently aligned to the modularization and use of the open interfaces in the face technical standard. This is Gabriel again. I think one important thing that Deb mentioned was the integration aspect. So even if you were to develop a capability in the still-pipe manner, what face will help you, even down the line, if you need to replace that capability with a tech update or improvement to that capability, the integration is a lot easier. So even though your still-pipe just for that single platform, you could save still over the life cycle of that single platform based on the integration aspect of tuck updates. Okay, I have two other questions that came in the chat window. One about whether or not face includes the fully defined data dictionary and associated data library that John Bowling provided information. The face does provide a data model that is compatible with the UCS data model. We're looking at keeping those two efforts aligned. There is a shared data model that's available on the U.S. server that's publicly available. If you go to that www.opengroup.org slash face slash information site, you should be able to find a link there for face shared data model edition 2.0 and edition 2.1 that correspond to the face technical standard. We are working on aligning the data dictionary with those definitions that are in the FAE AS for UCS committee data dictionary that that alignment has not yet been completed. We also have a question and offer to share experience regarding setting up government enterprise bus where different government entities must export some business services. Mohammed, I would like to table that until the end of the presentation. Let folks get through the content and then we'll open that particular question up for discussion. And if we've answered everyone else's questions sufficiently, we'll move on to the next slide. Otherwise, either just put a quick chat in the window or in the QA window and we'll keep the dialogue going until we get folks satisfied that their questions have been addressed. Okay, I'm not seeing any dialogue. So we will move on to the next slide. Okay, Jason, go ahead. Sure. So the path forward hopefully we've kind of picked your interest on the contract guide. Now you need to go get a copy and read it for yourself and see how you can leverage that. As Judy mentioned earlier, that's actually available to download free of charge. There's actually the open group web link so you can go in and log on, register, download that for free. And what we recommend is share the contract guide with your program managers, your contracting specialist, your engineers, and your other procurement support. The contract guide was written for those folks, primarily the acquiring program manager and his staff. As Gabriel mentioned, we actually have a sample language in there that you can reuse and tailor for your specific procurement. This allows you, if you have a procurement with face requirements, it allows you not to start from scratch. You've got some example language to use. And in addition, we have some great commentary boxes that kind of support why the language is what it is that we're recommending. So this is a great asset for an acquiring program manager. And the points of contact, we have Gabriel from industry, Deb from the Navy, and myself from the Army. If you have any questions, if you feel like a deep dive or anything, please reach out and contact us. We've been more than happy to engage with you. Okay, so with that, we've completed the main portion of the webinar. Are there any general questions about what you've heard today or any specific questions you may have having glanced through the contract guide where you may need some more specific information on how to use particular aspects of it, best practices, anything like that. We'll open up the QA panel and the chat panel if you want to type anything in quickly to keep dialogue going. Otherwise, we'll move on to the offer from Muhammad Adlani, I hope I pronounced your name right. He did put it in chat to all participants. Okay, we do have one other question. Are there any non-TOD users of faith? Jason and Deb, I'll lob this over to you first. I know of some who are considering it. I don't know if we could actually call them users, but UN government-to-government conversations may have more information. I've heard of one of our industry representatives who were pitching the idea of using faith for a petroleum application. So, yes, I think there will be non-TOD users. There are certainly applications of faith as an airborne, as an avionics in the commercial aviation industry. Many of the functionalities that commercial aircraft have developed to be faith-conformant and used in our military platform. So we definitely see that market. I kind of focused on one that was not aviation related to start the conversation because we see aspects of that as well. I also know that some in the automotive industry are looking at the software stack, the segment structure, the different APIs that are at each of the segment layers, and particularly the data model concept. Having a set of rules of construction, OCL constraints, and a common data dictionary enables external adjacent markets to build data models and components that need to communicate information from and through those data model interfaces to entities that may or may not be avionics related. So we're looking at the data architecture, the constructs, the data dictionary, rules of constructing actual data model basis elements as a way to expand into adjacent, some DOD, some non-DOD markets, as well as avionics for both military and commercial applications. And if anyone here on the call is interested in learning more how to get involved in the work of the FACE consortium, we do have certain criteria for U.S. persons from U.S. companies just because of the nature of the application that we're working on. But do send an email to ogface-admin at opengroup.org, and I can put that in the chat window at Well to All participants so that if you're interested and want to get more involved, want to learn more, we can give you the information, put you in touch with the appropriate points of contact. Okay, we have another question. How does the commercial avionics market encourage reuse of software? I'm going to go out on a limb, and I know that some of our industry participants do have product line architectures as well that they've put in by design to be able to reuse internally so that they are developing once, being able to reuse, being able to save money on research development, test and evaluation. I don't know how much crosstalk there is within industry organizations on the commercial side versus the government side, but looking at a product line structure in the commercial avionics marketplace might be a good first step toward being able to reuse software. How do you encourage someone to reuse software is basically showing them the benefits of doing it versus the risk and cost of not. And with that, I'll get off the stage and hand the microphone over to those in industry who know more about the concept than I do. Gabriel, I will start with you if you want to address that question. Yes, Deb, can you repeat that question? So how does the commercial avionics market encourage reuse of software? I know that there are internal benefits to reusing software within the company. Like just as Deb or Judy had mentioned, creating software product lines and being able to use a set of software for multiple applications on different platforms. And so there are benefits internally for that. I also received a chat from one of our face industry members pointing out that the commercial avionics industry has created the Erring 653 standard, which is now a standard in almost every new commercial aircraft. The face technical solution has also adopted Erring 653 as part of their solution as well. So there is some cross talk among commercial and military applications. I don't know if developing Erring 653 is a way to encourage reuse of software, but it is an example of where it's been done. Go ahead, John. Well, if I may, once a vendor has an FAA approved, for instance, a DO 178 approved product, they are more than happy to put it on other systems and it reduces their recertification load when they put it on the next system. By also using face, they can reduce their integration workload and benefit even further. And it also allows them to put it into places where they haven't been before by having a vendor neutral environment. So there are a lot of things that the commercial avionics market is seeing as a potential boom for their business. If they produce the best module that does X, they might be able to put it in more places. Yeah, that's a good answer, John. And just to pile on a little bit to that, I want to remind everybody that DO 178C is a civilian guidance. It's out there. And what we've seen is an advisory circular that came out a few years ago, FAA 20-148, which talks about reusable software components. This is hitting on exactly what John was just discussing. It's looking at reusing the software and the artifacts of the software, which can be test reports, any type of documentation. And it established when it goes through a system cert, it establishes a pedigree for that software, meaning that that software has a pedigree, so when it's used in the future, you actually get some airworthiness qualification advantages for that. So the FAA has recognized this and they're promoting the idea with this particular advisory circular. And if I may add back on to that, our airworthiness process also appreciates pedigrees and artifacts in certifying things on a new platform. So it's a win-win if you can simplify your process and take advantage of prior work. Okay, so another chat from a face consortium member. In addition to Air Inc. 653 standard, the face technical standard also includes over 100 commercial avionics standards beyond Air Inc. 653. So it does appear like the commercial avionics market is already reusing software, or at least using and developing standards to encourage developing software that is reusable. This is good information. I appreciate the dialogue in the crosstalk. Okay, so there's one other question that came in for the panelists. Okay, this is a challenging question that this particular person receives from the top manager in the EA world where a lot of other frameworks are released. The question is why use face and not something else? So for avionics applications, we'll narrow it down to that particular technical space. I'll turn things over to Deb, Gabriel, Jason, and John to get US Army Navy Air Force perspective as well as industry perspective on why use face and not something else for the solution. I can give a specific example, Army-related. PEO Aviation a few years ago selected the face approach and the face technical standard as the common operating environment, specifically the real-time safety critical embedded computing environment for aviation. So if you are a software vendor, you're going to develop, you know, software for Army Aviation, if it qualifies to be reused across platforms, you need to follow the face approach to be successful. If I can give an Air Force perspective, if you have good tools in your toolbox, you don't use each one every time you choose the tool that's perfect for your situation. Face provides the opportunity for security profile, safety profile, and general purpose profile. You have to choose what works in your particular system. You may choose face, you may choose something else, but you want to understand what you have and then use the best tool for your problem. Thank you, everyone. You know, I think, you know, this is Gabriel. Another benefit, too, is the fact that the face approach has a really good defined conformance program, right? And really understanding, you know, how you conform to the technical standards is a very important aspect to ensure that you're getting, you're adhering to the standard. Additionally, I think we recognize that there are lots of standards out there and there have been lots of attempts to do it, but one thing that, you know, this consortium made an emphasis was addressing the business aspects as well. And so really having to find, addressing things like the things that are addressed in the contract guide, we have the business guide and we have this conformance program. So not just all the technical aspects, but a lot of the business aspects are defined and addressed within the face approach and that kind of gives a good overall to base going on the standard for both industry and government. Okay, any other comments from our panelists on that particular topic? Okay, so the last question that we received in the chat was an offer to share experience regarding setting up enterprise bus for different government industries must export some business services and wanted to know how face may leverage such an initiative. At this point, I don't know if we can answer this question on the fly. I think we'd want to do some due diligence and some investigating. So I'm going to put my email in the chat if you want to send the information to me at OGFaceAdmin and we can do some investigating and then set up an email dialogue correspondence and take it from there. I don't think this is something that we can do due diligence to and not give a complete and thorough answer if we're just coming up with something in a five-minute time to think about it. Plus, we don't have the opportunity to chat with you. It's the one way you get to hear us. We don't get to hear you back. So it may be something that we can also set up a webinar for future or WebEx with dialogue open to all participants for future discussion once we get more information. Okay, here's another question. Are you planning to address how to contract for conformance testing and how to access the registry repository? So contract for conformance testing, I can't speak to. How to access the registry repository. Accessing the registry repository is a publicly available tool. We have a face conformance workflow tool where the registry of face conformance products will reside. I believe contracting for conformance testing is an individual contract between a software supplier and verification authority that they choose and then the certification authority once they get to the point where they are ready to certify their product, agree to the terms of the trademark license agreement for the certification mark, and then list their certified conformance face software in the face registry. Any repository would be owned by software suppliers. That's not something that would be publicly accessible. But the face registry is a public listing of software units of conformance software products components that are certified as face conformance and available for folks to peruse and reuse, consider putting on various contracts to build their various systems. And Deb, Gabriel, Jason, do you have more to add for that particular question? So I know that the Army has set up a face verification authority. It's one of three verification authorities that set up, you know, right now. That's actually software engineering director at Redstone Arsenal in Huntsville. And our intention in what we've been working with PEO Aviation with is acquiring program managers are encouraged to use the Army face verification authority to qualify and certify or, excuse me, verify face conformance. And on the piece about addressing how to contract for conformance testing, the contract guide includes a brief overview of the conformance verification process that's been set up. It talks about important things to include in the contract guide such as which version of the technical standard are you going to be conformant to, which version of the conformance test suite, and some of those factors will most likely be determined during contract negotiations. I mean, you can send out a baseline in an RFP, but knowing how the government acquisition process can be lengthy, you know, we might have a new version of the technical standard out. We might have a new version of the conformance test suite. So those are some negotiations that will happen, perhaps after contract award. Also, a question that often comes up is, you know, can I bid on a project if I'm not yet conformant? And yes, we do address that in the contract guide where, you know, you would put in gateways basically where you would want to be monitoring the conformance of the developed software, and of course the final delivery would have to be conformant. I hope that answers the question there. As far as the actual, the conformance verification testing, which you would be doing with the VA, and then the final step is going through a CA, that is a different contractual process. It's going to be between the software developer, the software supplier, and the VA, and then of course between the software supplier and the CA. So that is not in the contract guide. The process is mentioned, but not that contracting process. Yes, this is Gabriel. I second what Judy said. In the contract guide, we do address the conformance testing in the sense of the process and what you want to include in your software development plan and how you want to address the verification process. And so in that sense that the conformance would be part of that verification process. And as far as accessing the registry and repository, we do address that, you know, if there are capabilities that may be available within, or if there are space units of conformance that may be available for your specific program or that you may want, that you could potentially look at the registry or have a vendor offer something that's within the registry and see what's available to offer for that program. So we do address it in the sense that the registry is available to see what capabilities are available for the program. Okay, any other comments from the panelists on that particular topic? Okay, so we have one low-hanging fruit question that I will address. Just a reminder that this presentation is being recorded. It will be available for download in the next day or two. And for all of you who have registered here, we do have your email address is available. We can send you the location of the link when it's available. And then one other question here. Are newer versions of the FACE standard backward compatible to older versions? I'm going to start off by saying yes and no and then turn this over to other panelists for more embellishment if needed. Addition 3.0 is currently being worked right now. And we have nine technical subcommittees working various aspects, various portions of that version of the FACE technical standard. Each one of those subcommittees has a backward compatibility matrix that they are working on to ensure that their portions of the technical standard for Addition 3.0 will be backward compatible with Additions 2.1, 2.0, and 1.1. As far as 2.0 being backward compatible with 1.0 and 1.1, there is some backward compatibility, but it is not complete. The technical working group has realized that that could be an issue moving forward, especially if a software supplier is building software to become certified FACE conformant to one addition. They don't want to undo that conformance by making their software product combat compatible to a later addition. So the technical working group is working hard on making sure that the current addition, under development, Addition 3.0, will be backward compatible with the ones that have already been published. And then we will move forward with keeping future versions of the FACE technical standard backward compatible from that point on. And I skipped a question about from DCS. Has anyone looked at two-face implementations and the resulting inconsistencies and conflicts? And what, if anything, has been done to correct those disconnects? So we have about six minutes left in our webinar. I'm looking for Jason, John, Gabriel, if you want to take a stab at answering that question. If you know of any FACE implementations that have been looked at and if there are inconsistencies among them. Sure, Judy. This is Jason. For a little bit over the last five years on our MRNEC Aviation Science and Technology efforts, we've been doing exactly this. We've actually built a system called ARIES, Avionics Reference Embedded System, that actually contains four different FACE environments. It spans VxWorks 653, LinkSauce 178, and Integrity 178. We also have different chip sets, different board support packages, different TSSs. And we have gone and taken software and ported them to the others. We've documented lessons learned. Probably some people on some of the attendees are familiar with the Joint Common Architecture effort. We actually supported one of the efforts. We helped with a model-based acquisition to get data correlation fusion managers from two of our industry partners took those, integrated them in, and then did a port to the others and documented any integration challenges, any integration problems that we had, any data model problems we had. And since we're active in the consortium, we actually fed that back through the Data Model Configuration Control Board and also through the subcommittees. So, yes, that effort has been done. It continues to be done, and we're actually expanding from four face approach implementations to more, where we can gather more information. Okay, Deb, John, Gabriel, would you like to add more to that discussion? Okay, just one quick comment then. If you are familiar with face implementations resulting in consistencies, conflicts, and need help figuring out how to correct disconnects, you're always welcome to use the PRCR problem report and change request tool that we have to give feedback on your own implementations if there's an issue with any of the documentation that you're using that is not clear for how to do that. We would encourage you to report any issues that you're having with the documentation that's preventing you from successfully building your own face implementation as well. And with that, we're coming up on top of the hour unless we have parting words, closing thoughts from each of the panelists. I would like to take this opportunity to thank Gabriel Flores from Northrop Garmin, Jason York representing U.S. Army Ammerdeck, Deborah Moradian representing Navarre, and John Boling from Air Force Lifecycle Management Center for speaking with us today. I'd like to thank all of you who joined as participants. We appreciate your interest as well as your questions and comments. I would encourage you to please download the Face Contract Guide, read through it, start using it, get familiar with it. Again, it's available at www.opengroup.org slash face slash information, and let us know if we can be of any further resistance to you as you're looking through the contract guide or looking at any of the other face documentation. We're happy to help and we're here to support. With that, Gabriel, Jason, Deb, any final words before we depart? No, nothing for me. Just thank you for listening in and definitely go download, check out the contract guide and we're available for any further questions or answers that you may have as you explore that document. Okay, thank you everyone. Have a good afternoon. And as soon as the link with the webinar recording is available, we will send that out to all participants. Take care. Bye-bye.