Interview: The Open Group’s Judy Cerenzia Discusses The Future Airborne Capability Environment

May 30, 2013
Today’s military systems encompass a broad variety of cutting-edge technologies that must somehow operate with each other while meeting demanding safety and security requirements. The Future Airborne Capability Environment (FACE) software framework encompasses operating systems and applications to improve these compatibilities.
Download this article in .PDF format
This file type includes high resolution graphics and schematics.

Today’s military systems encompass a broad variety of cutting-edge technologies that must somehow operate with each other while meeting demanding safety and security requirements. The Future Airborne Capability Environment (FACE) software framework encompasses operating systems and applications to improve these compatibilities (see “The Military FACEs Its High-Tech Future”). Judy Cerenzia, program director of the FACE Consortium for the Open Group, discusses the architecture.

Wong: What is the Future Airborne Capability Environment (FACE)?

Cerenzia: Future Airborne Capability Environment (FACE) is a government-industry software standard that defines a common operating environment supporting portability and reuse of software components across Department of Defense (DoD) aviation systems. [It’s also] a business strategy that promotes acquisition of affordable software systems, innovation, and rapid integration of portable capabilities across global defense programs and higher efficiency to deploy these capabilities.

Wong: How did the FACE initiative come about?

Cerenzia: Current airborne systems are typically developed for a unique set of requirements by a single vendor, causing long lead times for urgent needs, platform-unique designs, limited portability of software components, increased costs, and creating barriers to competition within and across platforms. The aviation community has not created the open standards and open architectures to sufficiently enable portability of software components across DoD aviation systems. Contracts typically do not require conformance to a common set of open standards. Furthermore, program managers are not funded to assume cost or schedule risk of multi-platform requirements.

Related Articles

To address these issues, the FACE Consortium was formed in 2010 as a collaborative approach to develop a common operating environment supporting portability and reuse of software components across DoD aviation systems. The FACE Consortium formed under the auspices of the Open Group and is a “Voluntary Consensus Standards Body,” as defined by the National Technology Transfer Act and OMB Circular A-119.

The FACE Consortium operates as a managed consortium of the Open Group. It is composed of DoD and industry member organizations, their representatives, and advisors, creating an acquisition-neutral setting where industry has direct access to the DoD customer and can work together to produce open standards and to influence procurement and policy. The Open Group’s internationally recognized and proven processes provide the FACE Consortium members with a commercially and legally solid foundation ensuring fairness, market credibility, and the resources to ensure maximum impact.

The FACE initiative provides the open standards and common operating environment that:

  • Reduces life cycle costs
  • Enables, enhances, and accelerates capabilities to the warfighter
  • Provides standardized software interfaces
  • Increases software portability and interoperability across and between platforms
  • Facilitates standard conformance to maximize interoperability between software components within the avionics system
  • Is endorsed by DoD and industry program management
  • Establishes a business model beneficial to both the DoD and industry
  • Fosters innovation and competition

Wong: What does the FACE architecture look like, and what are its major components?

Cerenzia: The FACE Technical Working Group has defined the key vertical and horizontal software interfaces and is developing implementation guidance for using these interfaces. The Technical Standard for FACE Reference Architecture, Edition 1.0 contains a high-level architectural overview and a detailed description of five architectural segments interconnected by three key interfaces. These segments and their interconnections comprise the FACE computing environment. The five segments of the FACE software architecture (see the figure) are:

  1. Operating System Segment
  2. I/O Services Segment
  3. Platform-Specific Services Segment
  4. Transport Services Segment
  5. Portable Component Segment
Figure 1. The FACE Operating System segment comprises the Portable Components, Transport Services, Platform-Specific, and I/O Services segments.

Wong: What are profiles, and how will hardware and software vendors utilize them?

Cerenzia: The FACE Reference Architecture supports general-purpose, safety-critical, or secure avionics capabilities, or any combination of the three capability types through the use of profiles. Profiles affect the interfaces and functionalities available within a FACE implementation. A profile within a standard is a subset of a full standard (e.g., POSIX Real-Time Profiles). This tailored or subset version of a full standard has features removed in order to meet additional implementation requirements for performance, safety, or security, or any combination of the three.

Profiles within software standards describe the included and excluded functionality for a domain within the larger set of functionality in a full standard. Profiles can address functionality, performance attributes, and safety or security concerns within the full standard. Profiles can have a significant impact on the quality attributes of a software standard.

Download this article in .PDF format
This file type includes high resolution graphics and schematics.

Profiles within the FACE Technical Standard are necessary to handle the differing requirements imposed by security and safety domains of avionics. A full standard might not have implementations available that are amenable to generation of appropriate artifacts needed for safety or security evaluations. Likewise, if a full standard did meet safety and security requirements, then the standard might be too stringent and limit the type of applications and services that use the standard. The security domain imposes the most stringent constraints on the FACE Technical Standard. The safety domain imposes somewhat lesser constraints, and the general-purpose domain imposes the fewest constraints.

To develop applications and services, the profiles referenced within this document define the number and set of usable APIs [application programming interfaces]. The most restrictive is the Security Profile, which focuses mainly on multiple classification domains and may also be capable of satisfying the safety requirements. The Safety Profile, which is less restrictive than the Security Profile, focuses on a set of standards and supporting certifications that are sufficient for safety requirements, but are not necessarily sufficient for security requirements. The least restrictive profile is the General-Purpose (GP) Profile, which is a larger set of standards that addresses services and applications that do not require stringent safety or security approvals/certifications.

The prime contractor, system integrator, application developer, and customer specify the requirements for the capability, as well as the corresponding architecture, in order to choose the appropriate profile (or profiles) for developing the capability-driven applications and services. The evaluation takes into account migrating applications and services from one profile to a more stringent profile. The FACE Reference Implementation Guide provides guidance on combining the software standard profiles with an appropriate architecture. The profile affects not only the software architecture, but may also affect the hardware used in the system. All parties involved need to understand the impact that hardware has and adjust the system design accordingly.

Wong: How does the FACE Technical Standard relate to other standards like OMG’s Data Distribution Service (DDS) used in other military projects?

Cerenzia: The FACE approach builds upon the tenets of Open Architecture (OA), Integrated Modular Avionics (IMA), and Modular Open Systems Approach (MOSA) by defining a standardized method of interface between software components and architectural segments. The FACE Technical Standard augments existing DoD and industry standards, like ARINC 653 and POSIX, where applicable.

The Transport Services Segment supports a variety of messaging paradigms (including but not limited to publish/subscribe messaging and request/response messaging) and provides a standardized API for implementation of the communication mechanisms required for these messaging paradigms. These messaging paradigms transport data and support delivery type configuration. There are existing standards that specify these messaging paradigms. These include, but are not limited to, CORBA, DDS, and World Wide Web Consortium (W3C) standards.

Wong: The FACE standard is building on existing standards and does not support subsets. Are there any issues in locking down the specification at this time, and how will it adjust to changes in the underlying standards?

Cerenzia: Conformance of a software component to the FACE standard is governed by the FACE Conformance Program and requires a software component be conformant to all FACE interfaces for the segment the software component resides within. The FACE standard is designed to work in conjunction with many existing open standards. While these standards follow their own governance and conformance/compliance certifications, the FACE standard has been designed to evolve with these standards and support these standards from a FACE interface perspective. As standards evolve, the FACE standard will also need to evolve accordingly. FACE concepts are not new, and the standard and concepts are proven every day in global commercial applications.

Wong: What kind of hardware support is necessary for FACE implementations?

Cerenzia: The FACE architecture is not a hardware solution and has been designed to be hardware agnostic. The FACE approach provides the common operating environment and “build to” guidelines to both platform and mission equipment program management offices.

Wong: What groups will be using The FACE Technical Standard and business strategy?

Cerenzia: Anyone can download the FACE Technical Standard and other published documents at the Open Group Bookstore. The FACE approach will be used primarily by vendors providing military aviation systems and customers wishing to include FACE requirements in solicitations to procure FACE conformant software.

Wong: How does this change the procurement of hardware and software?

Cerenzia: The FACE Consortium is methodically addressing both the business and technical issues that have limited the success of other open architecture initiatives and prevented large-scale software reuse across DoD avionics. The FACE ecosystem expands on the powerful business model of commercial open architecture concepts and creates a marketplace for innovative and reusable FACE conformant software. The FACE Technical Standard defines an open architecture for embedded software systems and the conformance processes to ensure openness at key interfaces. Used correctly, the FACE architecture helps to reduce procurement costs, reduces system integration cost and risk, reduces upgrade and technology refresh costs, and therefore reduces total life cycle costs.

Wong: Where are FACE implementations being used or developed now?

Cerenzia: A Navy C-130T contract was recently awarded that included the requirement for FACE conformance. There are also several RFIs [requests for information] and RFPs [requests for proposals] that have been released that include FACE conformance in the requirements. These include: JPALS [Joint Precision Approach and Landing System], Army Common Operating Environment (COE), the Army Future Vertical Lift (FVL) and Joint Multirole Rotorcraft (JMR), Army Integrated Data Modem (IDM), Universal Ground Control Station (UGCS), and the Required Navigation Performance/Required Navigation (RNP/RNAV) Portable Software Component (PCS) or set of PCS components. The FACE team is in communication with other programs for inclusion of FACE requirements within their contracting language.

Wong: The FACE approach will be employed in many safety-critical and high-availability application environments. Was it designed to be used in conjunction with certifications like DO-178?

Cerenzia: Yes. The FACE Reference Architecture was designed with an understanding of the diversity of requirements across Department of Defense aviation systems, including safety-critical and high-availability requirements. This was one of the driving requirements behind the FACE profiles defined in the FACE Technical Standard. The FACE standard was designed to be used in conjunction with standards (including DO-178) that provide objectives for software development lifecycle processes, the required activities, and design considerations for achieving these objectives, producing the objective evidence indicating the objectives have been satisfied, and supporting airworthiness, system integrity, and system assurance certifications.

Judy Cerenziais currently the Open Group’s program director for the FACE Consortium. She has more than 10 years of senior program management experience leading cross-functional and cross-organizational teams to reach consensus, define, and meet business and technical goals during project lifecycles. She is TOGAF 9 certified and DODAF 2.0 knowledgeable, and she has led a variety of government/industry/academic collaborative activities. As a research engineer for Penn State’s Applied Research Lab, she coordinated multiple large projects for weapon technology development and performance evaluation for the Office of Naval Research (ONR), the Naval Undersea Warfare Center (NUWC), and the Navy’s Torpedo Program Office (PMS 404). She holds a BS in mathematics and an MS in acoustics from Penn State University.

Download this article in .PDF format
This file type includes high resolution graphics and schematics.

Sponsored Recommendations


To join the conversation, and become an exclusive member of Electronic Design, create an account today!