 So Chip, if you're ready, can I ask you to stop today's presentation? Thank you, Simon, and welcome everybody to this morning's presentation on system architectures, MOSA and the FACE technical standard. We'll discuss how this, the FACE approach differs from other standards. I'm joined this morning with Chris Cook, he's the Senior Software Analyst for US Army, PEO Aviation, and also he serves as the Chair of the FACE Technical Working Group. I'm a Senior Market Development Director of Aerospace and Defense at Real-Time Innovations, also known as RTI. I'm also the Chair of the Business Working Group Outreach Committee. So system architecture is a description and representation of a system based on components and subsystems that will work together to achieve mission and operational functionality. A typical breakdown of system architecture for a DOD platform usually consists of the following subsystems. Go ahead and click ahead, Chip. So when we consider a DOD platform, a particular aviation platform, the system architecture is going to be defined in terms of certain subsystems. Now these can either be defined separately or as part of a collective design. Either way, a system is going to consist of hardware, software, network, and in the case of airborne vehicles, a subsystem to define the entities and behavior for radio frequency and signal processing. So this graphic is sort of a continuation of the one shown on the previous slide. And while there are many different architectural modeling languages, tools, designs, and approaches, this is meant to be notional in order to represent an abstract view of the different conceptual subsystems we previously touched on. Here we have shown some examples. Go ahead and click ahead. Some examples of most of the standards that can be used to define the components and behavior for particular subsystems. For defining a network architecture, an example is the victory standard, which defines a networked data bus for use on military vehicles. For hardware, architecture is over on the right. We have OpenVPX as an open standard example, which defines an architecture framework that manages and constrains module and backplane designs. This includes defining pinouts and it also sets interoperability points. Down at the bottom at the RF signal level, Mora extends the victory standard into the radio frequency arena by decomposing radio systems into high-level components that enable sharing of hardware such as amplifiers and antennas. And then finally, at the software subsystem level, and sort of the central viewpoint of this briefing, the face technical standard can be used to realize abstracted software components that are portable between systems. Next. So modular open system approach, also known as most formerly known as open systems architecture, OSA or open systems approach, can be defined as a technical and business strategy for designing an affordable and adaptable system. There's five principles of MOSA. So MOSA is actually defined by 10 U.S. code 2446 alpha, which took effect in January 2017. So the U.S. code defines a set of rules for adherence to the modular open systems approach, which are consolidated into what is known throughout the community as the five principles of MOSA. The first of these is to establish an enabling environment. What that basically means is that the approach should include all of the necessary resources in order to specify, identify, develop, and sustain the approach. This should include things such as the business approaches, contract guidance, technical guidance, training, et cetera. The second is to employ a modular design. Now, for the U.S. code, this is to allow several major system components at the appropriate level to be incrementally added, removed, or replaced throughout the lifecycle of a major system platform. The third is designate key interfaces. The MOSA requirements require that major system components be separated by a defined interface, and that brings us to item four, which is that a MOSA implementation should use open standards, not just in the component design, but in the interface design as well. The last principle is to certify conformance, which is sort of an inherited requirement in order to ensure that correct adherence to the MOSA design and interfaces is guaranteed. Next. So how does the FACE approach apply to this? So if you take a look at the first item established in an enabling environment, the FACE business approach features a business guide, contract guide, software suppliers getting started guide, integrators guide, and many more documents I'll show you later in the presentation. There's also tools currently available to create FACE products. So as far as employing a modular design, the FACE technical standard defines a reference architecture, and it is component-based. These components are abstracted and grouped into logical segments based on the capabilities and services they provide, thus achieving the modular design. Whereas the notion of the FACE segments can sometimes be a little bit confusing, an implementation of the FACE reference architecture is nothing more than a series of components that provide certain capabilities. Some of them have the sole purpose of enabling the capabilities of other components. An example of this would be the components within the transport services segment, which those of you familiar with FACE already will have familiarity with, and the transport services segment and particularly the components within it provide other components the ability to move data. The FACE technical standard also defines a data architecture in order to provide semantic descriptions of data that moves in and out of certain FACE software components, which are known as units of conformance. The third bullet is to designate key interfaces. So each segment that Chris just described is to find the FACE reference architecture and provide these open defining interfaces that can be easily accessed by anybody deploying the FACE standard. These interfaces are just for common services and also provided via the operating system segments. In order to satisfy using open standards, the FACE technical standard uses open, commonly used, consensus-based standards in its requirement for software components, as well as the interfaces. Some examples of these are its use of POSIX, Erring 653, Erring 661, OpenGL, and there's quite a few more. And finally, you need to certify these components to adhere, make sure everybody hears to the standard. So the FACE business approach defines a FACE conformance program that uses third-party entities called verification authorities to certify software components as being fully conformant to the FACE technical standard. There's no compliance or partial conformance. It's all, only 100% conformant is allowed for this FACE approach. Now, there's been plenty of MOSA guidance out there and there's a multitude of documents now declaring that MOSA is the way you should be building next-generation systems. Most likely the most popular ones is TriService's memo from January 2019 that's like FACE, SOSA, OMS, UCI, and Victory. And it's just the use of MOSA is considered a vital to the success of the U.S. DOD. And it should be included in all requirements programming and development activities. Army, Navy, Air Force have also issued separate guidance around the MOSA requirement. Just because you have a MOSA approach doesn't necessarily mean that that approach is open. So there have been certain ventures to establish a MOSA design using an open standard. Now the FACE approach follows this pattern by defining the FACE technical standard, which is an open standard published by the open group. Go ahead and go to the next, Chip. Now as a result, the FACE technical standard as well as all its supporting documents are distribution A and they are publicly available within the supporting ecosystem. That means that all guidance documents, all business documents, contract guides, everything is open to the public. It is an open standard that implements MOSA. Once again, the MOSA is defined by the 10 U.S. Code 2446 alpha. And this slide just kind of shows that FACE does satisfy the requirements in MOSA as defined by DOD. So the first is that it employs a modular design. And yes, FACE does employ a modular design. It focuses at the software component level. It has defined interfaces and as Santa Bonas uses all commonly used open standards. It is subjected to verification to ensure major system interfaces comply with if available and suitable, widely supported and consensus based standards. Once again, yes, FACE does satisfy that. For its OSS level, it is interfaced to the operating system. It uses only open, commonly used APIs, POSIX, AERING 653, to where FACE does not require anything proprietary in order to implement units of conformance, a.k.a. software components using the FACE technical standard. Number three is that it uses a system architecture that allows several major system components at the appropriate level to be incrementally added, removed, replaced throughout the lifecycle of a major system platform to afford opportunities for enhanced competition innovation. And again, yes, FACE does allow for that. It is a component-based system with defined interfaces to allow greater power to the integrator to manage the lifecycle of the entire system. The most approach also integrates technical requirements and contracting mechanisms and legal considerations to support a more rapid evolution of capabilities and technologies throughout the product lifecycle. This is through the use of architecture, modularity, open system standards, and appropriate business practices. These standards are well known. We use a lot of different types of both public standards from other parties and also we've created our own business standards to assist in this approach. So once again, the DOD seeks to yield the following benefits with the most approach. The significant cost savings or avoidance, absolutely. There's essentially a product line mentality that surrounds FACE architecture and FACE procurement because you can now have multiple companies target a class of components that can be distributed to the U.S. government or any other entity for a next generation airborne platform. So yes, FACE does do this. And also the DOD hopes that you can get a rapid schedule reduction and allow for the rapid deployment of new technology as required. And once again, FACE tells us this. The third one is really opportunities for technical upgrades and refresh outside of the older model where we had a very long three to five year possibility and longer refresh cycle with FACE because it's very modular. You can update these components as required in a very rapid fashion without upsetting the entire platform or causing a retest the entire platform. So once again, FACE enables these opportunities for technical upgrades. And then finally, interoperability including system assistance interoperability and mission realization. Once again, FACE does this quite well because it's all based upon standards that are predefined as interoperable and it has been tested to be interoperable across platforms. So as far as how FACE fits within the architecture picture, here we're bringing back a graphic from earlier in the presentation. In this blown-out view, we have a notional environment boundary that would feature safety critical as well as non-safety critical software components as part of a software subsystem solution. Now in this example, we have a common bus separating the two environments where a FACE computing environment is used to house the safety critical software components. As part of a larger notional example, this is meant to convey that FACE is not intended to be the only solution within a software system architecture but is a solution for implementing safety critical software components. Some unique features of the FACE technical standard. For one, it is distro A. It is publicly available. It has no competing abstraction layers. All the software layers are prescriptive. The flexibility allowed below the transport layer, it allows for greater interoperability as far as transport services. It abstracts the protocol and the transport mechanism from the individual component and it allows for different sorts of capabilities to be implemented as far as the transport layer to do things such as message association, transfer between certain protocols and things of that nature. The underlying point is the abstraction of the transport from the individual software component allows for greater scalability and flexibility for the integrator. Governance at the data architecture level. This optimizes opportunities for reuse and interoperability by enforcing a common lexicon for component-to-component interfaces. Also, here recently in FACE technical standard 3.0, added an integration model to facilitate systems integration and kind of make things a little bit more organized in terms of the system integrator. This provides a great way of summarizing all the connections involved in the FACE computing environment that is maintained by the system integrator. Also, we have government industry collaboration on the standard itself and it's supporting ecosystem. The FACE technical standard and all supporting documents are maintained by a standard-based body. Oh, it looks like we've lost Chris off the audio chip. Okay, no problem. I'll take it from here and Chris gets back on. We'll get him on board here. So it's really a key that there's over a hundred government industry collaborators on this standard. It's not a handful of companies or defense contractors or even one service or agency that created this. It's 10 years of collaboration between government industry and academia. So it's something that's well debated and well understood by these companies and I put these published statements, published documents from the faking story and prove that fact. It's really interesting that it's applicable for hard real-time, near real-time, and non-real-time systems. There's different profiles in the operating system that can allow for this and also allows for safety and security capabilities. And then finally, the FACE approach has a domain-specific data modeling mechanism that exercise integration of multiple open standards on the same system so you can actually bring in other standards as required. Okay, I'll do the next few slides here. So how's it different from other most of standards? Well, it's suitable for, as I just mentioned, development of safety-critical software applications. It utilizes third-party component suggestions called verification authorities for the verification of artifacts. So you have an independent agency reviewing submissions for conformance to the FACE technical standard. The FACE technical standard defines requirements for conformance based on three levels of criticality, general purpose, safety, and security. And the FACE units of the conformance have been demonstrated to pass airworthiness certification. There's no blockage impact. In many cases, the FACE standard, the technical standard, tends to enhance and create an ecosystem of people with ready-to-go airworthiness certification evidence, like RTCA, DO170C. And then, as Chris mentioned before, the FACE technical standards are all of distribution A, so they have a supporting ecosystem. Anybody that will come download these at no charge. Now, there's a lot of really interesting use cases for the application of the FACE technical standard. They can be as wide-ranging as flight critical systems with strict airworthiness requirements and hard real-time response. They can be mission systems that need to rapidly integrate the applications from a diverse supply chain, multi-domain operations coming in from different security domains or national domains, and also multi-level security platforms. We actually have today two different companies in the FACE registry with certified conformance capabilities there. So you can actually bring in different agencies, different services, coalition partners, and bring in data from these different capabilities. Also, systems that challenge with lowering the total cost of operations by design phase is very modular and should and has reduced the total cost of operations of many platforms. Also, systems that need to separate and decouple critical software from new software innovations. It's the partition capability of the FACE technical standard allows you to bring in old software, new software, high-criticality, low-criticality software, and run that on the same compete platform. It's also standards-based. It's a standard of standards. So you can bring in multiple industry and industry standards like AIDA, ARIX 553, ARIX 64, C, Java, and others. So it's quite open in that. And E-standards now built into the FACE technical standard, and we try to take advantage of this whenever possible. And then the program is going to be software interoperability pre-qualified through a formal conformance program with proven artifacts. We have that through the FACE certified conformance program. And then, once again, the systems that need to support multiple levels of safety, criticality, or other types of criticality as defined by the entity. So there's use cases for the application of this business approach. One, and probably the best one, platform is a very high cost of change or updates, upgrades. You can actually now use the FACE approach to break apart some of the, I'll say, driveliness of those platforms to insert new technologies as required. There's also programs that say, I like to procure software from an app store with credential entries. It's not quite an app store. We have a FACE registry that actually talks about the capabilities and the credentials behind those capabilities. And then you would go to the software supplier to go procure that application. Platforms that need to include software from many business domains in a diverse, competitive supply chain. If you're trying to create a competitive environment when you go off or bid, FACE is a great way to do that. There's many companies now that have FACE certified conforming products. I think we have now 20 in the FACE registry, and there's a lot more coming. It's a great way to say, here's the set of capabilities I need to please bid on this. Programs that need to reuse software over multiple or similar platforms, and I think this is, especially too, as we get into unmanned platforms where some of the capabilities almost exactly the same, it's perfect for those types of environments. Systems challenge with lowering total cost of operations unless you're poor. And the real goal here is, you know, get the best avionics software to the warfighter faster. FACE is an open standard developed by government industry and academia that enables the most approach for these military avionics systems. It defines an architectural and business approach to developing and procuring avionics software. The development of the FACE Consortium technical standard and business approach is managed independently by the open group. There's no government entity or no set up companies or one company that can control the standard. And all the FACE technical business documents are published as you mentioned before. So, let's go back here. So how do you get started? Well, we have a FACE website. And on this website, there's lots of different options for you to go see. You can see the consortium activities and membership. I encourage everyone to join the FACE Consortium if you have an interest in the standard. There's links to public FACE documents and tools. There's a page on recent procurements and roadmaster FACE acquisitions and there's quite a few of these now. And also information for just navigating the FACE verification and components process. And also a link to the FACE registry that lists out the software platforms that have gone through FACE components. You know, such a ton of support. This is all on the open group.org slash FACE site. We have been very busy over the last 10 years. We've released quite a few FACE documents for both the business and technical side. You can see the different divisions of the FACE technical standard, shared data models, data governance, conformance, getting started guides, verification, business guides, 3.0 is coming out soon. So there's lots of publications. And if you want to learn about FACE, you can download all these publications and begin to read them. I'm sure you'll figure it out in about two years. Or you can just get started. If you're a software supplier, we have listed out, and this is up on the website, documents that you should read to get started to understand what's going on from a software supplier, an integrator, an acquisition, data modeler, or a business perspective. The best thing you can do is get involved. Join the FACE consortium. This is the place where when you go to these face-to-face meetings, if you really gain an understanding, you get to see the presentations and discussions of the different groups inside the FACE consortium, talk about some of the common problems on the both technical and business side, and also just meet some really great people. And I think people have been involved with FACE consortium for some time, but I have developed lasting friendships that will go well beyond our working environment. And once again, you get the network of other FACE members at these meetings, and that's really key. So if you have questions, or essentially ask me anything, send those to ogface-admin at opengroup.us, and they will vector that off to the right party to try to answer your question. Obviously, Chris Crook is part of this team today. He's chair of the FACE technical working group. I'm chair of the business outreach committee on the business side. FACE consortium members, everyone who attends FACE meetings will be happy to or answer any questions that they can. So do we have any questions, Simon? We certainly do, Chip. So first of all, thank you, Chip. Thank you, Chris, for that presentation. Before I go to the questions, we've had a number of inquiries about the slides, and my understanding is the slides will be posted at the opengroup FACE website along with the recording. So you'll be able to download those slides on the opengroup FACE website. So I'm going to work my way through the questions on the Q&A guide. So I'm going to start with Tim, and Tim asks, how do you achieve strong semantic typing in the FACE data architecture? And how does this relate to the open standards used for FACE? So I'll take this one. And my apologies to everyone for my audio dropping. I just continued to talk away before I saw in the chat that my audio had dropped. So I'm sorry for that. And thank you, Chip, for grabbing the ball and running with it. So I appreciate that. So the FACE data architecture in FACE, so whenever you use the transport interface, the transport interface is typed to a specific message. And the FACE data architecture defines all of the semantic representations in a shared data model that data types in FACE can be realized from. So what that means is when you build your data model to describe your data, whether it be, you know, a position message that defines LAT-LONG and altitude, you have to use the observables and measurements defined in the shared data model to realize those types. And the shared data model is managed by the FACE Consortium by a specific subcommittee. You can use the PRCR process to add things to it, but all data models that represent data traversing over a FACE interface must extend from a shared data model, which provides that strong semantic typing in order to describe the data that you are representing at the IDL level, which will be represented at the programming language level once generated off the model. As far as how this relates to open standards used for FACE, it kind of does and it doesn't. This is just one of those things that is used for conformance and to ensure that strong semantic typing in ensuring that whenever an integrator uses a unit of conformance, or a component designed to FACE, there is no question as to the representation of the data that is going to be traversing the interfaces that it is going to be attached to. So that way, if an integrator needs to provide a message transformation or do anything with that message that is traversing that interface, he has the knowledge in order to do that. Great, thank you very much. A question from John asking what are your thoughts of combining all these standards and he says that is Mosa, Mora, Victory Face Sosa into an all-encompassing standard. What do you think of that? That's an interesting request. I don't think that's going to be feasible because the level of technical knowledge required for each of those standards is very high. And I think it's far better to keep them as separate. But do as we did with the Face Sosa, reference these other industry standards in the technical reference guide. And so I think that's key is that you want to leverage these other standards when possible. But I think trying to integrate and then coordinate the development of and the revision of all these standards under one tenement. What would you, Chris, give another idea? Well, for one, it would be a very large standard. Just as Chip said, you would have to have expertise on every single one of these in order to create such a large standard. Now, there have been ventures within the DOD to create what is considered a standard of standards. And what I mean by that is that it applies to the overall system architecture design in that it has requirements like for all hardware you have to use for pin counts, you have to use the open VX standard like that. But it is not like an overall standard. It just provides guidance and requirements for implementing a system architecture based on existing standards. So things like that have been done, but as far as merging all of the standards into one to govern every single aspect of a system architecture that is very hard to achieve, I would imagine, and there haven't been any discussions about doing that unless someone had a good idea on how that would be accomplished. I'm not sure that that is a good idea at this time. But like I said, there have been standard of standards ventures within the DOD to use all of the available standards within an architecture design. And I think to double down on that from this perspective, it would be very hard to fund that unless the DOD has a massive war chest to actually fund all these different organizations. Many of these standards are funded by commercial military or DOD platforms like openGL like POSIX. So I think it would be very difficult to fund and coordinate all these different standards under one umbrella. Okay. Thank you, Chaps. We've got a question here from Todd and we'll take offline, but I'll ask it anyway. So Todd asks what is the cost of third party face conformance verification? So the verification authorities, that the independent agreement between a software supplier and a verification authority, so it is a competitive environment with multiple verification authorities and those will be individually negotiated in most cases with the data and the conformance verification matrix in the test suite all are in good shape. It should be very affordable. If you need help and of course many folks need help especially on their first face conformance activity the VA is there to help and therefore they will charge you more money because they're helping you out to get through the process. But as you get that into the client activity you can actually reduce this cost considerably. Okay, thank you. Boris asks, can you explain the difference between face and IMA? I'll just pronounce EMA or just IMA. So I'll get that correct even though it's a technical problem. So IMA is integrated modular avionics and there's a standard behind that called ERIK 653, managed by ERIK which is a commercial organization that manages avionics standards and aircraft standards. So IMA is a time and space partitioning it breaks platforms into executable partitions executing on a strict time basis. IMA and ERIK 653 is part of the face standard it's actually a fundamental part of our operating system segment in the face technical standard where we look forward to partitioning from both safety and security standpoint, but also legacy and new trusted and untrusted. So partitioning in the face technical standard is a very important activity and IMA and ERIK 653 is a fundamental contributor to that. Okay, thank you. Question from Aaron, it's another difference between asking what is the difference between a key interface and an interface, or he says or what is a key interface and what makes it a key interface? So I would define a key interface as an interface where variance is expected to occur and you want that to be abstracted as much as possible. As far as just an interface, any API can be considered an interface. However, there are only three APIs, the politics APIs, things that are version-specific referenced by a standard. However, things like transport, logging, interfaces where the software developer has a greater array of choices on what can be implemented and where all those choices may be different from another developer. I think that's what separates a key interface from, say, using something provided by POSIX as far as getting your hostname. So places where you see barriers to integration, those are where you're going to see key interfaces and what these defines as key interfaces are one, the transport, the operating system, but it solves the operating system by deferring to commonly used open standards. IO operations as far as device drivers, configuration and I believe that's about it. As far as now, there are other interfaces forthcoming. I know there's a pipeline in the works for a logging API, but that's still in the works. But yeah, basically to encompass the overall point, a key interface is where variance is going to occur from software supplier to software supplier. Okay, thank you. Question from Tony. Is this modular approach extended to the platform for remote and operation activities, for example, mission planning and mission data creation? Who fancies that one? Chris? Chip? I think we're both pondering an answer to that. I think the answer is no. We don't control that aspect of it. We're the architecture of an airborne avionics platform but the system, not the entire avionics platform or airborne platform. We really focus on the compute systems inside in your graph. Yes, I agree. That goes beyond the scope for MOSA and that gets into more platform-specific operations. That could be realized using the MOSA approach but not necessarily governed by MOSA itself. Okay, that's great. Thank you. Question from AV, asking, are face and MOSA new standards that are listed or included under the overall DoD architectural framework documentation versions 1, 2, 3 etc. or are they linked separately to the DoD AF? So the idea of MOSA is relatively new and MOSA itself is not a standard. It's more or less a template for creating a standard. Face has been around since what, chip 2010 and when did 1.0 come out? I think about 2 years later. Okay. So yeah, and since then we've had 2.0, 2.1 and in 2017 3.0. So not so much new but as far as products that are aligned to face, those are still up and coming and you know deployment of face components is still forthcoming. So new in one sense not so much new in another. As far as DoD AF, Chip do you have an answer for that one? I'm sorry I don't. That's great. Todd asks, have the claims related to face presented on slide 13 being substantiated with real world program results? That's interesting. Let's go back to slide 13 real quick. So as far as number one we don't yet have metrics on we don't really yet have metrics on that. That is kind of a long term solution. And that's really only realized when you have a family of software components in a system that you know kind of give you a kind of a base to measure the true cost savings that can be realized using face. So we don't yet have a metrics for number one. Same thing for number two. Don't yet have a metric for that. Three don't really either however the the overall design of components using the face technical standard does allow for this by you know separating capabilities and abstracting certain behavior from the software component level in order to allow for new technologies to be integrated and also forthcoming conditions for the face technical standard also add to new technology in terms of new versions of programming languages and things like that. I know in 3.0 we added support for new versions of C++ as well as data. So and as far as interoperability yes we have shown interoperability as far as interfacing with excuse me legacy components and as far as interoperability with software components that leverage other standards. So three and four yes one and two we don't really yet have metrics on. And I'll step into Chris I think we need to be a little bit more aggressive I appreciate your conservative view on this but as far as number one goes we are bidding separate entities on a platform now where before that is not possible I had to go through a large systems integrator so we are immediately taking costs and avoiding additional costs by based on parts of a platform not the entire platform and modification of the entire aircraft platform certainly schedule reduction we've proven that I don't think we track these metrics well when we do military programs but we certainly have proven that integrating a very complex solution stat with avionics cockpit software transport services systems operating systems graphic subsystems you can now do that quite quickly because we actually have these interfaces with the base technical guide so I think that the two things that we absolutely can say I think the top opportunities also for technical upgrade and refresh are now there's not more aircraft but there's more opportunities for more vendors that you can actually bid on a program where before you might have been walked out and obviously interoperability using this face approach is absolutely proven where you can actually bring in different types of systems and integrate them quite quickly and unpacking weeks versus months or years over also one of our colleagues kind of put in the chat that you know through balsa evidence and showing different demonstrations and integration efforts there have been shown anywhere from 25 to 75% reduction in integration efforts that we've learned through those ventures so thank you Corin for putting that in the chat that's great and I think everyone appreciates your further clarification that's fantastic thank you John asks when you say safety critical is it just software or is it down to the process level as well in terms of face just software excellent that's a quick answer to a short question let me just expand up on that absolutely with regard to face it's just software but if you're going to get airworthiness or get the safety certification with the DL178C for software and DL254 for hardware typically you're going to combine both those standards to achieve the safety certification that's great that was a short question this is a slightly longer question from Vincent he asks does face support data mediation is it our message details change over time and he says for example new fields added etc and we are looking for a capability that will help our publishers and subscribers mediate between different versions of the same message set I would like to pick that one up so that capability can be supplied via a component in the transport services segment the way the transport services segment in face is set up allows for a range of capabilities that are pretty much up to the software supplier as far as how detailed they want to get but say you have a software component that sends data according to an old version of a message and you have a new component that expects it in a newer version which has new fields or a change fields you can implement in the transport supplied by face or not supplied by face you can have a capability in a transport aligned to the face technical standard that allows for message transformations from one version of a message to another so that is certainly possible face is set up to allow for that kind of behavior although it is not defined directly there is nothing prohibiting a transport vendor from implementing that behavior okay thank you question from Tim asks what role have regulators played in developing the face approach how does face change safety audit requirements so this is chip down himself safety is part of face only in respect of that we want to either enable airworthiness faster or make platforms and systems that don't add to a safety burden but we do not have a safety standard within face so that would all be controlled by regulators deploying DO-178C or some other type of safety certification standard that is not something that the face consortium controls it is all we do have DO-178 well personnel with DO-178 knowledge and expertise that assist in publishing airworthiness guidance as far as implementing the face so whereas an implementation of the face requirements does not guarantee a safety certification or safety audit there is guidance available in the face technical standard and in supporting documents to ensure that safety considerations are taken into account when you are designing your face component okay thank you another recently lengthy question read it out as clearly as possible this is from Peter Peter asks may we assume there are face and moza definitions on the data labels etc which come in from 429 for air data and or inertial if so what are those parameters or where is the document that defines it good luck guys that's all that you have Chris thanks Chip I'm just trying to make sure I understand the question let's see do you want me to read it again Chris? no I can see it on the Q&A I'm just I'm parsing the language here if I'm understanding the if I'm understanding the question correctly which I may not be and if I don't if I don't answer this in the way that you put forth the question please feel free to contact me when we can actually have a discussion about this to make sure I'm addressing your question appropriately I don't want to leave you with a lack of information once again my contact info is in these slides as far as the interpretation and data labels for parsing 429 messages this is all going to be modeled in your ULP supplied model as far as providing definitions and the semantic meanings behind the elements of your data message so all that is going to be covered by data architecture which is defined in the face technical standard and once again if I didn't answer your question adequately or you met something else please contact me and we'll discuss this and I can pull the people in the room that have more knowledge than I do on this specific subject area that's great Chris and Peter thank you you've got the guy's thinking there so that's excellent so question here from D'Ralf and I'll pronounce your name correctly what's the latest status of face related tools so there are tool vendors out there that provide products that have the ability to develop and parse and generate code using face data models so those are out there the face consortium website has a third party tools listing that has a few of those out there the face consortium also has plugins available for certain tools and usually those are on the third party tools page as well another good tool to use is the conformance test suite the conformance test suite can be used to generate code and generate dependencies for testing your software that is aligned to the face technical standard but I would advise you to try the third party tools website and see what all is listed there I think there's quite a few vendors out there that don't list their products on that page but if you reach out to some of the open group representatives I'm sure they can point you in the right direction another specific question this is from Mike he says United States Air Force is OMS choose to define interfaces to various devices say for example radar, EL etc but it seems face is not how do you get interoperability if different vendors choose different interfaces so all this is abstracted via an interface in face there's a wide range of different external inputs device drivers and things of that nature there is a certain point that face doesn't dive into as far as certain hardware we abstract that in the IO services segment where you can define particular software components to interface with certain buses drivers or certain pieces of hardware to where the interface that is used by the unique software component to consume or to write to those pieces of hardware device drivers etc the interface is relatively constant and is abstracted in such a way to where if the devices change or new capabilities come about to where that software component that interfaces with that particular bus or device needs to change the software component that consumes the data doesn't need to change so that is how we achieve interoperability as far as devices and hardware OMS just chose a different route it's another solution is wrong it's just a different way of doing it there are certain things that OMS does that face and vice versa so it's just a different approach face chose to standardize an interface that abstracts external interfaces away from the environment so that's how we achieve interoperability in fakes well that's great guys we've come to we're virtually at the end of our hour so I'd like to call it a day here we haven't been able to get we've got loads of questions so first of all to the attendees we share or sorry we leave all your questions and they will be they will be shared with today's speakers also if you have a question that you'd like to ask the team then the email address is ogface dash admin at opengroup.org so that's ogface dash admin at opengroup.org so Chip, Chris before our enders are there any final comments you'd like to make to our attendees today go ahead Chris oh I'm sorry Chip we both kind of jumped in there yeah I would just like to thank everyone for dialing in thank you for your time thank you to you know for listening to what we you know have to say about mosa and the face technical standard I for one hope this has been beneficial to everyone and that we were able to kind of give you a little bit better perspective on how face implements mosa and mosa you know in general so I hope this was beneficial I hope we answered your questions adequately if not please get in touch with us because we would like the opportunity to to answer your questions and make sure that we provide the best knowledge that we can but overall thank you for joining us sorry back to you Chip thanks Chris I think you said everything quite well I just echo Chris's comments thank you once again for attending this webinar I think it was very informative for everyone involved so thanks again take care