U.S. rival countries have been rapidly modernizing their militaries, with publicized advances that pose credible challenges to U.S. supremacy in all aspects of warfare: air, land, sea, space and cyberspace. On January 19, 2018 Secretary Mattis discussed the National Defense Strategy and emphasized the need to modernize key capabilities to address these threats. He stated: “To keep pace with our times, the department will transition to a culture of performance and affordability that operates at the speed of relevance. Success does not go to the country that develops a new technology first, but rather, to the one that better integrates it and more swiftly adapts its way of fighting. Our current bureaucratic processes are insufficiently responsive to the department's needs for new equipment. We will prioritize speed of delivery, continuous adaptation and frequent modular upgrades.”
Avionic systems are a case in point. They have been on an unaffordable trend due to complexity and cost, particularly in the evolution from hardware-defined systems to modern software-defined systems, where the costs to develop, integrate, and maintain software continues to grow at an unsustainable rate. In response, The Open Group
Future Airborne Capability Environment (FACE) Consortium has established an open procurement environment that facilitates reuse to meet four core goals: improve affordability, speed, agility, and excellence. The FACE™ Consortium is a government and industry partnership dedicated to accomplish this using open industry standards, advanced integration, and maintenance technologies.
Capabilities Behind the FACE Approach
Since its inception in June 2010, the FACE Consortium has been addressing the challenge confronted by next generation Department of Defense (DoD) aircraft or military avionic systems in acquiring advanced capabilities while curbing the cost to procure and maintain the platform over its intended lifecycle.
Therefore, an ecosystem was created where there is an open hardware, open operating system, open middleware, and open applications setting, which could be served by any supplier in the defense industry, large or small. As a result, any FACE software component can be moved or ported from one DoD aircraft platform to any other relevant war-fighting platform with minimal integration complexity, on any desired hardware target, paving the path to a best-fit-for-the-cost solution.
The FACE Consortium membership accomplishes its function through sponsorship and support by all the U.S. armed forces, primes such as Boeing, principal-level members such as Northrop Grumman and over 80 associate-level members such as LDRA. All are working together on the business and technology aspects of the FACE Conformance process. Documents that include the FACE Technical Standard, FACE Business Guide, and FACE Conformance Verification Matrix are just a few artifacts guiding suppliers towards the development, release, and offering of FACE Certified Conformant Products. Members like LDRA are incorporating solutions into its offerings to remove implementation ambiguity and to pave a path forward.
After a software package has been submitted and received passing marks by the Verification Authority and the Conformance Verification Test tool suite, the software package or now unit of conformance (UoC) can be released by the supplier and registered in the FACE Certified Product Registry, available for sale.
The FACE™ Technical Strategy
The FACE Technical Strategy is to provide a software environment that enables moving FACE applications from one DoD aircraft or war-fighting platform to another with minimal software changes to the FACE application. This software environment is referred to as the FACE Reference Architecture, which employs design principles to enhance software portability such as providing a common set of interfaces to the portable FACE application. This is all defined in the FACE Technical Standard Edition 3.0, the most current release available.
The FACE Reference Architecture is comprised of five layered segments where a FACE portable capability or Unit of Portability (UoPs) may reside:
Operating System Segment (OSS)
Portable Components Segment (PCS)
Transport Services Segment (TSS)
Platform-Specific Services Segment (PSSS)
I/O Services Segments (IOSS)
To manage variance and deliver portability, a common set of standardized interfaces providing the connections between the FACE Architectural Segments has been defined.
Operating System Segment
The OSS UoPs provide typical POSIX, ARINC 653, or HMFM APIs as defined by the FACE Technical Standard to allow UoPs to move from one FACE Conformant OS to another FACE Conformant OS.
Portable Components Segment
The PCS is where 80 to 90 percent of the typical software portable capabilities or UoPs exist. UoPs such as tracking and navigation that are not tied to any data transport or operating system implementations live here. Consequently, most portable capabilities between platforms happen here. The UoPs in this segment can utilize two of the well-defined interfaces in the FACE Technical Standard: the OS interface and the Transport Services interface.
Transport Services Segment
The TSS contains UoPs that exist to move data between the portable components that reside in the PCS. This segment removes the concern on how the data is transported, freeing the developer from needing to deal with data conversion or any other transport detail. TSS UoPs are also responsible for data distribution between the PSSS UoPs. The TSS also uses the OS interface.
Platform-Specific Services Segment
The PSSS is comprised of three sub-segments. The UoPs in this segment are typically tied to a particular platform and hence are less portable, such as UoPs that abstract the interface to specific GPUs and other platform-unique interfaces. The PSSS uses the OS interface, the I/O interface, and the TSS interface.
I/O Services Segment
The IOSS lives to communicate with device drivers and provide the PSSS with access to I/O information. The IOSS UoPs form abstractions to specific graphic displays, specific sensors, or transport methodologies, such as CORBA, DDS, UDP, or TCP.
FACE Data Architecture
Because FACE applications need to exchange data, data-centric interfaces and common terminology have also been defined. This allows integrators and subsystem developers to understand the data needs of all their UoPs; to describe the things they want to communicate including the data going into or coming out of a UoP; and to enable the integrator to combine UoPs to provide a larger capability. The FACE Data Model Language was defined to document this data exchange and answer questions about the UoP, its relationships, and the data types.
FACE Data Model Language
The FACE Data Model Language is specified by the open and platform-independent Essential Metadata Object Facility (EMOF) metamodel, raising the level of abstraction to help manage complexity, where these models can be exported from one application, imported into another, transported across a network, stored in a repository, and then retrieved.
EMOF models can also be rendered into different formats such as XML Metadata Interchange (XMITM) and the Unified Modeling Language (UML). Additionally, the Object Constraint Language (OCL) can also be applied to the EMOF model. This makes it more precise by associating assertions or constraints that supply semantic rules to which the data model content must adhere. OCL also provides object query expressions that cannot otherwise be expressed by diagrammatic notation.
The FACE Technical Standard is a robust document containing all requirements needed for a UoP to conform to, in order to be certified. However, the FACE Consortium established a FACE Conformance Program with associated conformance criteria, process, and policy following the process or lifecycle consisting of Verification, Certification and Registration of the UoP. To assist with verification, a Conformance Verification Matrix (CVM) was created. Though the CVM does not replace the FACE Technical Standard, it provides the Product Standard and clarifies the Conformance Requirements that a UoP must meet.
As shown in Figure 4, to expedite delivery of your UoP and enable adoption, LDRA offers an integration package that supports all five segments of the FACE 2.1.1 and version 3.0 reference architecture. Once a software segment is selected, the conformance verification matrix is imported, and LDRA then guides the user through its workflow, consisting of testing activities, artifact placeholders, and template documents.
Conformance Verification Matrix
The CVM has been implemented within a spreadsheet that offers the ability to filter content based on the FACE Architectural Segment the UoP is targeting, including all the requirements to be satisfied. The CVM supports each official edition of the FACE Technical Standard and is used in conjunction with a corresponding version of the FACE Conformance Test Suite, which tests software adherence to the FACE Technical Standard.
FACE Conformance Test Suite
The FACE Conformance Test Suite (CTS) is used to test software and verify adherence to the FACE Technical Standard. Furthermore, the test suite is used by a FACE Verification Authority (VA), which is an entity officially sanctioned by the Steering Committee to conduct or witness For-the-Record verification testing and verify adherence. Nonetheless, the CTS is made available, so that software suppliers who want to conform to the FACE Technical Standard can self-verify to correct any undiscovered errors the tool suite may expose, and obtain peace of mind before submitting the UoP to the VA. The CTS is also hosted on Microsoft Windows, Red Hat Enterprise Linux, and CentOS.
Test summary results besides a pass/fail verdict rendered by the CTS are captured and documented. It will contain a summary of each test case result, test configuration settings, version of the CTS used, date and time of the test run, edition of the FACE Technical Standard applied, and more.
FACE Certification and Registration
Once the Verification Authority completes its verification process and the UoP has received a passing verdict, the software supplier may submit the Verification Results Package to the Certification Authority (CA). The CA then assesses the verification results package, manages legal agreements, and issues a FACE Conformance Certificate.
The final step is registration. The software supplier submits the FACE Conformance Certificate, the UoP description, and metadata to the FACE Library Administrator who reviews and confirms the FACE Conformance Certificate. Certified UoPs will maintain certification as long as the software product remains the same as defined by the Conformance Statement and all legal agreements are met. The Library Administrator then updates the Registry with the UoP description, metadata, and FACE Conformance Certificate ID. Government stakeholders can then search the FACE Library for FACE Certified Products to procure.
Affordability, Speed, Agility and Excellence
The Army FACE Technical Interchange Meeting (TIM) was held on Tuesday, September 18th, 2018 at the Von Braun Center in Huntsville Alabama. Keynote speaker Ms. Philomena Zimmerman, Deputy Director of Engineering Tools and Environments, Office of the Deputy Assistant Secretary of Defense, Systems Engineering addressed the FACE Consortium and Brigadier General Thomas H. Todd III, U.S. Army, Program Executive Officer, Aviation delivered opening remarks.
The Open Group FACE Consortium members demonstrated how scalable multi-domain operations are readily achieved through FACE Conformant applications. In this way, system-of-systems integration is not only possible but can be achieved in a rapid manner with safety and security built in, verifying objectives in affordability, speed, agility and excellence.
This article was written by Ricardo Camacho, Technical Product Marketing Manager, LDRA (Wirral, UK). For more information, visit here .