FACE in military avionics systems: Now let’s integrate it
StoryDecember 02, 2022
Arun Subbarao
Lynx Software Technologies
It’s hard to escape the headlines around the Modular Open Systems Approach (MOSA), open standards, and individual initiatives such as those from The Open Group FACE Consortium, the creators of the Future Airborne Capability Environment (FACE) Technical Standard. In 2004, the Open Systems Task Force published a Program Manager Guide titled “A Modular Open Systems Approach (MOSA) to Acquisition.” Since then, the industry has seen a progression in policy guidance that raised the profile of MOSA and its applicability within military systems to enable success on the battlefield while lowering acquisition costs and promoting innovation.
The MOSA [Modular Open Systems Approach] strategy made its way into the National Defense Authorization Act language that was first signed into law for fiscal year 2017. In turn, this has flowed into requirements at the program manager level under the now-famous Tri-Services Memo: “MOSA for our Weapon Systems is a Warfighting Imperative,” issued by the U.S. Department of Defense (DoD) in 2019.
The FACE [Future Airborne Capability Environment] Technical Standard – as one of the named open standards endorsed by U.S. policy – was recently described by U.S. Army Brigadier General Rob Barrie as “integral to MOSA success by enabling modularity and promoting software reuse.” Programs such as the U.S. Army’s Future Vertical Lift call out the FACE standard as a requirement.
In today’s digitized avionics, most of the functional capability is implemented in software. Anywhere from 70% to 90% of that functionality depends on the selected equipment and how extensively it relies only on displays for the human-machine interface. The reality is that software development is hard; testing and certifying the safety of that software is hard. The need for greater functionality and adaptation of that software to new situations is constant. The reality is that the old way of getting that software into aircraft fleets – which traditionally took years if not decades – now needs to be completed in weeks or days, sometimes hours.
By codifying a modular architecture, standard interfaces, data models, and conformance criteria into a common operating environment and reusable components, there now exists the means to share capabilities not only across platforms but also across the military services and avionics vendors.
The business benefits: Customers need not redo the development of a capability just to place it on a different aircraft. Components from different programs can be reused, with new components obtained from a wider variety of suppliers. This approach increases competition and the delivery of innovative solutions.
Modularity and interchangeability: the vision of FACE
In short, this standardization of approaches for using open standards within military avionics systems promises to lower implementation costs, accelerate development, ensure robust architecture and consistently high-quality software implementation, and maximize opportunities for reuse. The FACE standard embraces these ideals by providing a modular reference architecture based on segments that can be integrated to meet final system requirements. (Figure 1.)
[Figure 1 | FACE architectural segments are detailed.]
The content of each of those segments can and will vary depending on the preference of the system architect and the demands of the system under development. Despite those variations, modularity is ensured because the FACE standard defines the logical interfaces between the segments.
Each segment consists of one or more components. Each of those components must be shown to be fully conformant to the FACE standard applicable to the segment to which it contributes.
A FACE conformance test suite is used for that purpose, with a certification of conformance awarded following successful reviews by a FACE verification and certification authorities. That successful review is then recorded on the FACE registry with the FACE library administrator.
Any component that has been certified in this way is known as a “Unit of Conformance” (UoC).
FACE operating system segment
The foundational system services reside in the FACE operating system segment (OSS). These services are provided by OSS UoCs and include the control of access to the computing platform, support for the execution of all FACE UoCs, and the hosting of operating systems interfaces. (Figure 2.)
[Figure 2 | Shown: Operating system segment with FACE.]
The OSS is where the foundational element of FACE conformant systems is laid out. The platform software that resides directly on hardware runs here. The benefit of writing this code using FACE APIs is that it becomes far easier to migrate this code between different systems and different hardware. When the FACE standard was being defined, the consortium chose to harness existing standards such as POSIX and ARINC, both of which have withstood the test of time.
From a security perspective, the use of built-in CPU virtualization features to isolate hardware security functions and separate application runtime services from hardware control interfaces goes a long way toward assuring system robustness. Such design techniques eliminate commonly exploited threat vectors that result in security policy bypass, privilege escalation and loss of CPU control altogether.
The ability for software partitions to be fortified and controlled with greater fidelity at the hardware level aligns perfectly with FACE ideals. Figure 3 introduces the notion of a hardware partitioning segment fulfilled by a hypervisor to the FACE reference architecture. The depiction shows a hypervisor isolating two sets of software on two different CPU cores, with each set configured with FACE conformant components. Each set of software is granted greater partitioning properties over a single OS-hosted design in which the device drivers and internal service are separated.
[Figure 3 | Example of FACE configuration with CPU virtualization-assisted hardware partitioning segment.]
Conformance: An example
The fact that the FACE conformance certification process is conducted using an independent assessment is the best way to assure customers that a product conforms to the requirements found within the FACE Technical Standard. The answer to preventing the “what could go wrong” using the FACE standard comes down to assuring 100% conformance to its requirements. Otherwise, the potential strongly exists for reuse to be denied and integration costs to rise because an interface mismatch can occur.
Collins Aerospace is committed to FACE conformance and earned the industry’s first FACE conformance certification in 2016. The company has found that these certificates provide an outstanding marketing vehicle to show proof that it is an open system software provider that adheres to MOSA.
The Tactical Combat Training System (TCTS) Increment II program (Figure 4) is one important example of using open standards to provide multidomain live, virtual and constructive (LVC) training capabilities to modern warfighters. The underlying system – called the Joint Secure ACMI System (JSAS) – uses an open systems architecture leveraging FACE and other industry interface standards to enable interfacing with a variety of monitoring and debriefing systems.
[Figure 4 | Shown: the Collins Aerospace Tactical Combat Training System (TCTS) Increment II aircraft.]
Proof of FACE lies in its ability to win business
Mandatory FACE conformance requirements have flowed down for nearly every applicable military program since the publication of FACE 2.0.
Ultimately, the proof of the principles lies in the ability to win business through their application. That ability is ably demonstrated, in one instance, by the success of Collins Aerospace’s Tactical Combat Training System (TCTS) Increment II program, whose underlying system uses an open systems architecture incorporating FACE and other industry interface standards.
Arun Subbarao is vice president of engineering at Lynx Software Technologies, responsible for the development of products for the internet of things and cybersecurity markets. He has more than 20 years of experience in the software industry working on security, safety, virtualization, operating systems, and networking technologies. In this role, he spearheaded the development of the LynxSecure separation kernel and hypervisor product as well as other software innovations in cybersecurity leading to multiple patents. He is also a panelist and presenter at several industry conferences. He holds a BS in computer science from India, an MS in computer science from SUNY Albany, and an MBA from Santa Clara University.
Lynx Software Technologies https://www.lynx.com/
