A new ‘FACE’ for aviation acquisition

Using the Future Airborne Capability Environment open system approach to disrupt the current acquisition process.

by Dr. Alicia Taylor

Technology is changing and progressing rapidly. Upgrades to sensors, cameras, communication devices and navigation have improved not only automobile safety, but also our driving experience. When it comes to incorporating new technologies, the automotive industry has an advantage over military platforms because the automotive industry’s business model is entirely different. Whereas most consumers might upgrade a vehicle by buying a new one, the military generally plans on a 30-year life cycle for a vehicle, and upgrades the actual vehicle instead of replacing it. That includes aviation vehicles.

So, while many vehicle components or systems are common across many different models produced by a particular manufacturer in the commercial sector, that is currently not always the case with military aviation platforms.

Military aircraft, whether rotary, fixed-wing or unmanned, have numerous capabilities in common: navigation, communications and situational awareness. Traditionally, these capabilities were developed for each aircraft, effectively making DOD pay for countless reinventions of the wheel. DOD acquisition rules and regulations are numerous and complex. Most are absolute requirements, whereas others are only highly recommended. This complexity and lack of absolute direction is impeding the ability of software engineers to reuse software. That reuse is essential to support rapid, cost-efficient integration of new technologies.

Nevertheless, DOD leadership, members of Congress and other agency personnel are implementing measures designed to improve the acquisition process and strengthen requirements. The National Defense Authorization Act (NDAA) for Fiscal Year 2017 calls for the use of modular open-systems approaches in major system platforms, components and interfaces. More specifically, major defense acquisition programs receiving milestone A or B approval after Jan. 1, 2019, should be designed and developed with a modular open-systems approach to the maximum extent practicable. The Defense Acquisition Workforce Improvement Act requires DOD to provide training and education for the acquisition workforce. Courses, modules and resources are available on open systems. References to the use of open systems can also be found in Defense Acquisition University’s Defense Acquisition Guidebook..

OPEN SYSTEMS 101

What are open systems? What they sound like: systems designed and developed to a consensus-based technical standard that employs a modular design with interfaces. These interfaces enable modules to “talk to” one another with minimal modifications, much in the same way that a home computer can interface with a variety of other systems—printers, scanners, input devices and the like. Open systems are designed to enhance interoperability and reuse. Any software developer has access to the system standards, whereas in closed, proprietary systems, typically it’s only the vendor who has access. Open systems promote competition precisely because they are open and therefore can lead to better access to cutting-edge technology.

The Open Group Future Airborne Capability Environment (FACE) Consortium, a partnership of more than 90 government, academic and defense industry organizations, has defined an open-system avionics architecture for all military airborne platform types. (See related article, “About ‘FACE’,” Army AL&T magazine, April – June 2015.) With more than 1,300 members, the FACE Consortium is a consensus-based organization—that is, all documents and publications are developed through committees, subcommittees, standing committees and working groups, then reviewed by the membership and approved by a steering committee. This ensures that the architectures, technical standards and other documents are developed and agreed to by all of the major stakeholders in airborne systems. Because the development is a bottom-up approach by subject matter experts from both industry and DOD, the documents include well-understood and acceptable tools and procedures.

The FACE Consortium’s approach is designed to advance modularity, portability and interoperability through consistent business processes, technical practices and a software standard. The reuse of software across multiple platforms reduces development costs, integration costs and time to field.

Software suppliers develop capabilities that meet the requirements of the FACE technical standard and allow the exchange of data between FACE components. The FACE technical standard contains requirements for architectural segments and their software components; it defines key interfaces that link the segments together. The FACE conformance program then certifies that the requirements of the FACE technical standard have been met and allows the software vendor to legitimately claim the product to be FACE conformant. This provides prospective customers, including government program managers, with assurance that the software is, in fact, reusable and portable in a FACE environment.

Adopting an open architecture based on a common set of standards promotes development of capabilities that can be reused across multiple platforms. This eliminates or greatly lessens design and development efforts and reduces integration timeline costs. It is also more efficient. If a baseline profile of the specific requirements of these common capabilities is created by analyzing the platform systems and subsystems, then specific software products can be developed to target these common capabilities. Figure 1 illustrates how some of these capabilities (situational awareness, navigation and communications) developed to meet the requirements of one or more of the FACE operating systems segments can be reused across multiple aircraft platforms.

 

FACE CONSORTIUM APPROACH

Adopting a standards-based open architecture like the FACE approach can reduce nonrecurring engineering costs—those things that are paid for once during product development. Under the current acquisition process, each platform develops separate systems independently despite having the same requirement. That means each pays separately to develop an individual solution at a cost similar to the other platforms. Developing one standard solution to employ across all platforms saves money by eliminating the cost of producing separate, redundant systems. Figure 2 provides three examples of solutions that can be developed once and used across all platforms. This savings could be applied to other unfunded requirements, thus contributing to an overall increase in warfighter capability that otherwise would not occur.

A real-life example that illustrates the principles behind the FACE Consortium’s approach is the Federal Aviation Administration’s requirement that all aircraft, including military and civilian, have Automatic Dependent Surveillance-Broadcast (ADS-B) technology. This new positioning surveillance technology is more advanced, using satellites to identify the position of an aircraft instead of the older radar-based tracking system. ADS-B is composed of two parts: the ADS-B out, which broadcasts aircraft position-related information, and the ADS-B in, which receives information from ground control and other aircraft. (See Figure 3) The position of an aircraft is identified by satellites, then the information is broadcast to ground control and other aircraft via the ADS-B out. Information is then received by the ADS-B in.

Suppose platforms A and B are legacy systems and need to be fitted with an ADS-B out. Platform A has agreed to pay supplier A to develop and install an ADS-B out. Supplier A’s ADS-B out is tightly coupled with proprietary hardware and software on platform A, so it is more difficult and costly to add to other aircraft. Software that is tightly coupled tends to work in one system and usually requires significant reprograming to work in another system, thereby reducing the capacity for integration.

Platform B has contracted with supplier B for the development and installation of a different ADS-B out. Supplier B has aligned the components of ADS-B out with the FACE technical standard, meaning that key interfaces are used to allow information to be passed between existing software and hardware on the platform and the new ADS-B out. Supplier B’s ADS-B out has also been developed and tested, so the costs to fit it to other aircraft and the time to field will be significantly reduced.

If the government controls the avionic interfaces that ADS-B out uses, the cost savings increase exponentially. The FACE architecture, composed of segments and standardized interfaces, allows the components of FACE conformant software to talk to one another. Eliminating duplication of development efforts saves the costs of developing functionality multiple times. If the effort is built to the FACE standard with proper architectures, the government can save on integration cost across multiple platforms. Because any vendor can develop a solution based on the open architecture guidelines, the FACE technical standard increases competition and avoids “vendor lock,” which is generally more expensive and slows a project down.

SHOWING FACE ALIGNMENT

Since 2011, the U.S. Army, Navy and Air Force have awarded more than $1 billion through various proposals and other procurement solicitations aligned to the FACE technical standard. The FACE Consortium also hosts a number of activities to showcase FACE-conformant products and to demonstrate how different software aligned to the FACE standard can be integrated together.

Among these are technical interchange meetings (TIMs), open to the public and hosted by the Air Force, Army or Navy. The February 2016 Army TIM had 31 exhibitors and 11 technical papers presented, and an Air Force TIM held in March had 29 exhibitors and 10 technical paper presentations. The Navy TIM is scheduled for October 17 at the Holiday Inn Solomons – Conference Center and Marina in Solomons, Maryland. It begins at 8 a.m. with a keynote address followed by presentations and exhibits.

Another important activity hosted by the consortium, the Basic Avionics Lightweight Source Archetype (BALSA) Integration and Test Session (BITS), is a technical integration event open to FACE Consortium members only. At the BITS event, software suppliers gain firsthand experience integrating their software products, developed to align with the FACE technical standard, with BALSA software. When two or more software applications are integrated, it means that lines of code or interfaces are added to allow the software products to work together without any issues. At the December 2016 pilot BITS event, six FACE Consortium member organizations demonstrated the ease of integration and shared lessons learned and level of effort needed to perform the integration. One company integrated three components with BALSA to trace a radio-controlled car with GPS and to perform a trip playback that enabled the car to drive itself over its charted path. Another demonstration involved two companies using BALSA to integrate four components and three external devices.

Feedback from the participants was very positive. All participants stated that the BITS event was a valuable integration experience. “The BITS event served as an opportunity for software suppliers to get their feet wet using the FACE approach for designing software,” said Chris Crook, systems software analyst with Intrepid Inc., a small business provider of services and technologies in the federal marketplace. “The occasion gave vendors the chance to see a working example of a FACE reference architecture, BALSA; dive into it to see and understand how the pieces work together; then learn how to use those pieces in unison with their own software and share what they learned.” Immediately after the BITS event, three software companies spent four hours working together to integrate six components and four external devices with BALSA.

Four teams representing 10 FACE Consortium member organizations participated in the June 2017 FACE Consortium BITS event. One team, composed of three recent college graduates, integrated a commercial off-the-shelf GPS with BALSA on a Raspberry Pi. The Raspberry Pi, developed by the U.K.-based Raspberry Pi Foundation, is a small, affordable, programmable, powerful computer found around the world that uses an open-source operating system and was designed to encourage users to learn programming by tinkering. Feedback from a second team underscored the ease of replacing one of the components in BALSA with that same component from their software. “With the FACE approach as a common, well-understood framework, it is easy to dive into BALSA and replace its transport services segment with our implementation in a matter of days,” said Henry Liao and Shaun Daimonji, software engineers in the Autonomous System Division of Northrop Grumman Aerospace Systems. (The transport services segment allows data to pass between software located in other segments.) “We got a taste of what it would be like to integrate our component into another FACE system, and it’s really not too bad. The clearly defined segment boundaries and data paths make the task straightforward.” A third team integrated multiple software products with the messages tied together by a shared data model. Some of the products from this team have been certified through the FACE conformance program. The final team built on their integration activity from the pilot BITS event by controlling a fixed-wing aircraft instead of a radio-controlled car.

The encouraging results from the BITS events and the TIMs suggest that software suppliers are developing software products aligned to the FACE technical standard and companies are integrating those products. The number of solicitations and proposals aligned to the FACE technical standard that have been awarded since 2011 is also encouraging. The next steps are to identify common capabilities across military aircraft, use modular open-systems approaches in major system platforms, components and interfaces, and eliminate DOD acquisition rules and regulations that inhibit the reuse of software.

CONCLUSION

“The FACE Consortium members have reached the mountaintop in developing an implementable standard that enables vendors to develop capabilities that meet the government’s need for an open architecture-based solution for avionics software. I am pleased with the progress that we are making in populating our repository with FACE-conformant products and with the participation in our integration workshop activities,” said Dr. Terance Carlson, chief information officer/G-6 for the Program Executive Office (PEO) for Aviation and FACE Consortium chairman. “Our next steps include expanding awareness of the FACE standard and its value through training, and increasing the adoption of the FACE technical standard across the aviation program offices in each of the DOD services.”

The implementation of the FACE technical standard aids in meeting some of DOD initiatives and requirements, such as DODI 5000.02, and the FY17 NDAA. Enforcing open-system architectures and effectively managing technical data rights aid in cost control by promoting effective competition for the life cycle systems. The FACE approach is the chosen open software standard for PEO Aviation to be applied to existing and future platforms.

For more information, contact the author at [email protected].

DR. ALICIA TAYLOR, a contractor with QuantiTech Inc., is an information technology project and planning analyst supporting PEO Aviation chief information officer/G-6. She provides technical expertise in the development, implementation, integration and testing of the FACE technical standard and other FACE Consortium documents. She is active in the FACE Consortium and chairs several subcommittees and working groups. She holds a doctorate of education in educational leadership from Northcentral University and an M.A. and B.S., both in mathematics education and both from the University of Alabama. She has also completed several Defense Acquisition University courses, including Fundamentals of Systems Acquisition Management, DOD Open Systems Architecture, Modular Open Systems Approach to DOD Acquisition, and Software Reuse.