 I would like to introduce Christopher Crook for the face introduction. Christopher. Good morning, everyone. I hope it's still morning for everyone, unless you're outside the United States. Thank you. Good afternoon. My name is Christopher Crook. I'm the face TWG chair, and I'm just going to do a quick face overview, just to highlight things about the face technical standard, the overall face approach, and, you know, just a little bit about what the face technical standard defines. So, the overall face approach was to develop a technical standard for a software common operating environment designed to promote portability and create software product lines across the military aviation domain. The face approach outlines a software approach that is at the modular level, so it focuses on the software module at the lowest level. The aspects of the face approach are it defines business processes to adjust procurement and incentivize industry, it involves technical practices to promote the development of reusable software components, and a software standard to promote the development of portable components between differing avionics architectures. So, a little bit about the face technical standard, what it provides, first and foremost, the software approach designed to tackle barriers to modularity, portability, and interoperability. It also defines a reference architecture that uses standardized interfaces and provides requirements as well as guidance for developing software components that will reside in different architectural segments based on the capability or service that the software component provides. It defines a face data architecture for describing the data that traverses the different interfaces within the face reference architecture as well as the semantics that define that data. The face technical standard provides the ideal definitions for all the face interfaces that are defined in the standard. It also provides programming languages from IDL to the C, C++, ADA, and Java languages. The face technical standard also defines a set of OS profiles based on different levels of criticality depending on the avionics domain that it is designed for. Those are general purpose, safety, and security. One thing to mention that, whereas airworthiness is a concern for the face technical standard and there are guidance for meeting airworthiness requirements, just implementing the face technical standard does not guarantee airworthiness certification. That is still very much up to the software design, and the face technical standard does not involve a coding standard for software design. I'm moving along. This is a view of the face architectural segments. The face architectural segments form together to create the foundation of the face reference architecture. If you look at this from a kind of a top-down view, at the very top you have what's called the portable components segment. Software components that are going to reside here are ones that are considered the most portable. However, in the face technical standard, portability is not always guaranteed, but software components that are considered to be the most portable are going to be in this segment. The models that will be here are things that rely on nothing more than using the operating system level calls for POSIX and A-ring and moving data around. Going a step down, the transport services segment, software components that are going to be encapsulated within this segment are ones that provide data movement and routing of data and association of data. Anything having to do with actually moving data or manipulating it, all those software capabilities are going to be encapsulated within this segment. One step further down, you have the platform-specific services segment. Here's where you get into your software components that are more ICD-specific and provide either a common service that is going to be portable across different aviation platforms or a graphic service or something that requires data from an external source. How it gets data from an external source is going to be in the next segment, which is the IO services segment. Software components here are going to provide the capability to either get data from or move data to a certain bus, device driver, or external piece of hardware. This is how you get data in and out of your face-referenced architecture. Operating systems service segment is the final segment. It doesn't provide an operating system, but mainly provides the foundation work for how the face-referenced architecture accesses capabilities that were provided via the operating system. This is achieved via APIs. Most notably, the two APIs that are provided by a FACE OSS are POSIX and A-Ring 653. Also here, you're going to have your programming language runtimes that are provided by a specific operating system, like a C++ program language runtime. The Face Technical Center does involve requirements for what features of the programming language runtimes must be provided. I'm getting a message from Sally. Just ignore that. Keep going. Okay. Okay. We'll do. Basically, how you interface the operating system itself is going to be done via the operating system segment. The device drivers, partitioning, time and space partitioning is going to be handled by the software components that are provided by the OSS. Each of the segments is separated by a defined face interface. All these face interfaces are defined within the technical standard and are provided in ideal format. The first interface is between the portable component segment and the platform-specific services segment and how they move data to and from the transport service segment. That is the transport services interface. This is a typed interface, which is message or rather data type specific. It allows the PCS and PTFS components to send messages among each other. It can either be blocking, non-blocking, PubSub, it all really depends on the capabilities provided by the components within the TSS. There is an IO services interface. In the most recent version of the technical standard, that IO service interface is going to be bus-specific pertaining to a variety of different buses, whether it be I2C2. It provides a generic bus, a serial bus. Those are just some examples. Once again, the IO services segment software components are going to be bus or device-specific to provide connection to a certain bus or device. Then the OSS interface. OSS provides the standardized means to use the services that are encapsulated within the OSS, which provides you kind of a gateway to the operating system. The APIs that you're going to be allowed to use are the subset of the POSIX and A-Ring 653 APIs dependent on the OS profile that you are using. Safety being the most restrictive in terms of API calls that your software and Kubona can make. Safety being more aligned to safety-critical applications of being a little bit less restrictive, and then general purpose being the least restrictive in terms of the APIs that you are allowed to use. Just some terms for face software. These are specific to face. Face doesn't like to use the term software component because when it comes to designing software for face, if you have created a piece of software that meets the requirements for a specific segment, you have created what we call a unit of conformance. A face unit of conformance can be referred to that at any point during its lifecycle from design all the way up to conformance. However, it is not considered a conformant unit of conformance until it has gone through the face conformance program, which is the face verification, face certification, and inputting its metadata into the face registry. Units of conformance that communicate with the TSS using the TS interface, as I showed in a previous slide, have to provide what is called a unit of portability supplied model. Into the face data architecture, this is a data model that defines units of conformance, but it doesn't provide design constraints within the model. It merely shows the TSS connections as well as defines and maps data messages that will traverse between that unit of conformance and the TSS. It has details about the connection in it, connection names, what type of connection it is meant to provide, and things like that. You may hear unit of portability tossed around. Unit of portability should only be used in reference to a ULP supplied model. Then a final term that we use is the face computing environment. The face computing environment is what we consider the environment that you have that allows the integration of face units of conformance. What I mean by that is you have all the infrastructure needed to perform that integration. You have all the services and APIs there ready. So if you have a face TSS, a face OSS, a face IOSS, as well as any common services that are required, you have a face computing environment, which is considered an implementation of the face reference architecture. Just in summary, the face technical standard defines the reference architecture designed to eliminate barriers of portability and encourage the development of reusable software. It defines face segments with subtract functionality to promote portability, and it defines a set of best practices for creating face software components. Thank you, Chris. There's one question that we'll ask quickly. If it's a long answer, I'm going to have to ask you to do it via email. The question is, is there any effort to harmonize some components slash interfaces face with requirements from other domain services? There are always ongoing efforts to kind of harmonize face with other software standards. We look at that all the time because we want for face to be interoperable with other standards. As far as domain services or existing products, not so much face tries to be as open as possible without aligning to existing products, but rather existing open standards. Does that answer your question? If not, I can email and provide more clarification. Thank you, yes.