Implementing FACE-conformant avionics systems
StorySeptember 23, 2016
Wayne McGee
Mercury Systems
Stephen Simi
Tucson Embedded Systems
The Future Airborne Capability Environment (FACE) is a government/industry/academia initiative started by U.S. Naval Air Systems Command (NAVAIR) and the U.S. Army Aviation and Missile Research, Development, and Engineering Center (AMRDEC) in 2010 to create a standard for avionics application development. The goal of FACE is to lower the cost and amount of time necessary to create open systems applications and promote reusable applications across multiple platforms. To facilitate collaboration with industry and academia, The Open Group created the FACE Consortium for the purpose of developing, publishing, and administering conformance to the specification. Besides NAVAIR and Army, to date more than 90 companies and over 1,175 members involved in the avionics sector have joined the FACE Consortium. Most recently, in 2016, the Air Force Research Lab (AFRL) officially joined FACE, rounding out the participation of the entire US military services. Today each military branch has and continues to require FACE in their proposals for any future capabilities.
The first release of the FACE specification was made in January of 2012. Subsequent work has resolved a hosting library for FACE-conformant applications, proper use of the FACE logo to protect branding, requirements for an application to be labeled conformant, and standard data models to allow applications to share data in a common format. Since the initial release, the original specification has evolved, as attempts to implement the specification required further clarification. Where other open systems initiatives have failed, FACE’s attention to both technical and business processes have proved successful.
The first demonstrations of candidate applications for conformance branding occurred at the Face-to-Face Technical Information Meeting (TIM), held by NAVAIR in 2012 in Solomons Island, Maryland; the latest and largest U.S. Army-hosted TIM was held in February 2016 in Huntsville, Alabama. The first two FACE applications that have successfully completed the FACE verification process were announced publicly in July 2016, with additional promises of many other verified products and capabilities to follow soon. During a May 2016 panel on the future direction of unmanned aircraft systems (UASs) in the Army, Col. Paul Cravey, capability manager for UAS at the Training and Doctrine Command (TCM-UAS) asserted that those companies that want to do business in tomorrow’s environment, must know FACE.
Finding a home for a reusable FACE architecture
While the intent is to create hardware-agnostic FACE application software, at some point the software must find a home, a host, and target platform to fly within. Today’s battle space is not unified, but is instead made up of dissimilar aircraft platforms using various configurations of architectures and operating systems. Unfortunately, porting hardware-agnostic software to a host architecture with a hosting operating system is not a trivial task.
Once a suite of aircraft is capable of hosting FACE open systems architectures, then FACE applications can plug right in. Once plugged in, those application capabilities can interoperate across a network-centric battlespace, thereby increasing the situational awareness across what was once a raft of dissimilar aircraft.
Discussion of FACE architecture
Figure 1 illustrates the system software segmentation of the FACE architecture on one of the first FACE verified applications – Reusable Radio Control Component (R2C2) – developed by AMRDEC and hosted on an open systems FACE archi- tecture. The segments of the FACE architecture include the operating system, I/O services, platform-specific services, transport services, and portable components.
Figure 1: Architecture diagram of a FACE-verified application operating on a FACE application-ready host platform.
|
|
One prototype mission-computer hardware system that can host the FACE architecture and applications is pictured below the line in the boundary diagram, where other externally connected hardware devices reside.
The first two segments that enable the architecture are the operating system segment (OSS) and the platform-specific services segment (PSSS). The OSS includes a FACE-conformant operating system with run-time support, necessary frameworks, and generic health-monitoring services. The PSSS provides the specific device drivers necessary for the OSS to function on the computer and provides low-level health-monitoring functions to insure proper operation. The I/O services segment (IOSS) provides additional functionality beyond the low-level device drivers. For its part, the transport services segment (TSS) provides the architecture with common data types and formats, configuration, quality of service, and the ability to transform data from one format to another.
The R2C2 FACE application resides within the PSSS. The green lines in the diagram depict the FACE architecture interface between the segments. These interfaces are key to open systems architectures and are well-defined in the FACE technical standard.
As simple as it sounds, plug-and-play is aligned to a plug (i.e., application) and its receiving socket outlet (i.e., architecture); the two ends must interface via well-defined standards such as FACE. The FACE application’s interface must align with the FACE architecture of the hosting hardware processing platform. The interface software libraries must both compile and have variable names and data types known on both sides. If the software applications and architecture line up, all is well – it is lights on. Next step: port the software to another FACE-aligned architecture – lights on there as well. One day soon, reusable FACE capabilities will be integrated across a battle space of dissimilar aircraft and vehicles, etc., all able to host a FACE architecture and FACE applications and ready to assist with enhanced capabilities where they are most needed.
Implementation example
Avionics plug-and-play can be achieved by combining open systems applications with open systems architectures. For example, the U.S. Army’s AMRDEC-SED [Software Engineering Directorate] developed, successfully verified, and integrated the R2C2, a FACE Platform-Specific Service (PSS) software component. The R2C2 is a reusable platform-portable software component that will facilitate the integration of (legacy and next-generation) military radio systems onto Army aviation platforms. It was demonstrated during previous FACE TIM events; the Army’s FACE Verification Authority verified the R2C2 in July 2016. In a parallel effort, Boeing-Philadelphia successfully integrated R2C2 in July on a target platform designed to represent platforms on the Future Vertical Lift (FVL) platforms.
R2C2 is integrated into each aviation platform’s operational flight program (OFP), which provides the interface between the platform’s computing and radio equipment. The first increment of the R2C2 software provides control interfaces to the AN/ARC-231 and AN/ARC-201D radios. Follow-on software increments are underway, adding in the control interfaces to future airborne networking and satellite communications radio equipment. While initially focused on reuse among Army aviation platforms, adding in Link-16 capabilities opens up software reuse on NAVAIR platforms across military branches. (Figure 2.)
Figure 2: TESseract mission computer from TES-SAVi with AN/ARC-231 and AN/ARC-201D radios.
|
|
The R2C2 software implements a communications control application programming interface (API) that provides access to the capabilities of the radio devices. The API is a set of software methods that standardize control of the radios from the host platform and replaces the platform-specific protocols of individual radios with a single abstracted software interface mechanism.
Next up
Open systems applications and architectures show great promise in lowering the cost and time necessary to create new applications and promote reusable applications across multiple dissimilar platforms and, eventually, across military branches. Operating system and portable component applications-conformance testing is now underway, which will lead to filling the FACE Registry with reusable software capabilities. Government, industry, and academia will continue to support the Open Group’s FACE Consortium and forge new business strategies for future capabilities for designers and users.
Wayne McGee is the vice president of sales and general manager for North American Operations for Creative Electronic Systems, a member of the FACE Consortium. Wayne has served in various senior management positions in his career and has more than 30 years of experience in the VME, CompactPCI, ATCA, and VPX markets. Wayne is also the chairperson for the VNX VITA-74 Marketing Alliance. In the past, Wayne has worked for such corporations as Motorola Computer Group, VMIC, SBS Technologies, and GEIP. He holds a BSEE from the University of South Carolina.
Stephen Simi is the vice president and program manager of Military Aviation Programs for Tucson Embedded Systems, also a member of the FACE Consortium, and serves as vice president of product and services for TES-SAVi. Stephen is chairperson of the FACE Integration Workshop committee. Stephen has more than 30 years of experience in design, reusable open systems software development, embedded systems integration, and product and business development in the software engineering, optical engineering, and military aviation spaces. Stephen has also held positions with Boeing-Space Station, MITRE, the U.S. Army, and Breault Research Organization. He earned a Master of Science in Engineering from the University of Maryland.
Creative Electronic Systems www.ces-swap.com
Tucson Embedded Systems www.tes-savi.com
