The Military FACEs Its High-Tech Future

Military hardware and software used to be completely custom in nature. Hardware standards like VME and the newer VPX made COTS practical, but extensive customization was usually required even when building on these standards-based products. This led to vendor lock-in. It also made improvement of existing systems difficult and expensive.

Related Articles

• OpenVPX Helps Military Modules Mesh
• OpenVPX Simplifies Rugged Design Tasks

Part of the problem is that VPX defines too many possibilities. OpenVPX defines subsets that are commonly used (see “OpenVPX Simplifies Rugged Design Tasks” at electronicdesign.com). Often, OpenVPX designs still require a custom backplane, but it’s usually much easier to get OpenVPX boards that work together in the system while minimizing custom configuration work.

Software had a similar problem but with less standardization. Applications were paired with hardware drivers, providing a level of modularity, but movement from one platform to another still was difficult since the driver application programming interfaces (APIs) must be the same. This tends to be easier if the new platform is designed from scratch or the new hardware is like the old.

FACE is built on standards like POSIX. These standards have been employed in the military and avionics space, but they normally have been used or specified in isolation. A component or application would have a bit of portability because it utilized standard interfaces. Mixing in non-standard APIs or a custom mix of standard APIs, though, would limit or eliminate the software’s potential portability or reuse.

Also, FACE brings a wider array of standards into play, allowing developers to create software that would be more portable or reusable on new or different platforms. It should also reduce vendor lock-in since the underlying FACE support will be available from many vendors. FACE isolates the hardware so upward migration to new hardware platforms should be significantly easier as well.

FACE defines vertical and horizontal interfaces. Vertical interfaces support layered software like protocol stacks and are typically found in operating-system frameworks. Horizontal interfaces are found between applications including data source and sink components.

The standard defines what vertical interfaces are permitted and what vertical interfaces aren’t allowed. For example, high-level components cannot interface directly with non-FACE segment interfaces. In general, FACE components and infrastructure can only utilize standard FACE interfaces. Restricting interfaces and defining an overall architecture for applications greatly simplifies subsequent migration since replication of the FACE infrastructure allows migration of FACE components.

While FACE defines the use of a variety of existing interfaces, it does not specify a specific operating system like Linux or Windows. This is important for a number of reasons. First, FACE needs to address existing platforms based on a range of operating systems. Likewise, most high-level operating systems contain too many components while low-level operating systems and real-time operating systems (RTOSs) may have too few features for some applications. The more modular approach allows better matching of software to application requirements.

Another reason for this type of modularity is that many of the platforms where FACE will be used require security or safety certifications. High-level operating systems can rarely, if ever, manage to meet these certifications whereas many of the RTOSs used in these environments can.

On the other hand, high-level operating systems like Linux and Windows can be used for less critical portions of an application such as the user interface. Partitioned hypervisors allow these portions to coexist with certified software and hardware, and FACE takes this into account. Likewise, communication between these two types of software is allowed, and FACE defines the communication protocols.

FACE Profiles

At the top level, FACE defines a set of profiles that target security-critical and safety-critical environments like avionics where DO-178B/C compliance is a requirement. FACE profiles were defined using the tenets of Open Architecture (OA), Integrated Modular Avionics (IMA), and Modular Open Systems Approach (MOSA). The profiles are supersets of each other including:

• Security Profile: uses FACE Security interfaces; time/space partitioning required
• Safety Profile: uses FACE Safety interfaces; time/space partitioning optional
• General Purpose Profile: uses FACE General Purpose interfaces; time/space partitioning optional

The Security Profile is the most restrictive. The Safety Profile is less restrictive but addresses applications requiring a high degree of safety. The end application environment will dictate the type of profile required for the underlying software. The FACE Reference Implementation Guide addresses how to combine these profiles with hardware.

One of the big impacts of FACE is its incorporation of time/space partitioning hypervisors that can allow applications and operating systems based on a mix of profiles to coexist (Fig. 2). Hypervisors have been used in military and avionic applications but to a limited degree. FACE is likely to change this.

The Security Profile specifies support of an appropriately certified Multiple Levels of Security (MLS) separation kernel. The profile supports packet-based, labeled data communication paths. It can address the high-security applications that require certification that meets Common Criteria (ISO/IEC 15408) Evaluation Assurance Level 6 (EAL6) or higher.

FACE Segments

The Operating System segment incorporates a number of layered segments whose APIs map to standard APIs like ARINC 653 and various POSIX API profiles including 51, 52, and 53 (Fig. 1). The segments include:

• Portable Component segment (PCS)
• Transport Services segment (TSS)
• Platform Specific segment (PSS)
• I/O Services segment (ISS)

FACE is designed to isolate applications from the hardware but not from device driver interfaces, leaving this isolation to the underlying operating systems. This makes sense because of the variety of hardware and operating systems that must be supported.

There are standard virtual devices and interfaces for the I/O Services and Platform Specific Services segment. Device support won’t be as standardized as services further up the stack, but access to these services will be.

FACE I/O Services uses a message model that defines a set of payload types including:

• ARINC-429
• MIL-STD-1553
• Synchro
• Discrete
• Serial
• Analog

Note the interfaces like Synchro, ARINC-429, and MIL-STD-1553 that are currently common in military an avionic applications. These are low-level interfaces.

Most applications will utilize the Transport Services segment, which provides more robust protocols:

• Common Object Request Broker Architecture (CORBA)
• Distributed Data Service (DDS)
• ARINC
• POSIX

These protocols address a range of communication mechanisms. For example, DDS supports publish/subscribe semantics. CORBA supports the Internet InterORB Protocol (IIOP). The initial set of FACE I/O and Transport Services is just a starting point. The standard is designed to be extensible and flexible to handle future hardware and transport mechanism.

Related Articles

• What’s The Difference Between DDS And AMQP?
• DDS Sweep Function Generators Improve Interface
• Data Distribution Service Scales From Embedded To The Enterprise

The TSS components can utilize the PSS and ISS services. Communication between partitions will be through the TSS, down through the PSS, across the hardware interface, and up through a matching stack at the other end in a typical stack-oriented communication protocol.

The PSS components typically match the underlying hardware. The interfaces are encapsulated in the matching Interface Control Documents (ICDs). ICDs are already available in most of the environments where FACE will be used.

Deliverable components that utilize lower-level FACE APIs reside in the Portable Component segment (PCS). Components do not use the FACE I/O interface directly.

FACE segments include a range of definitions, partially to address the FACE profiles. TSS components that can work in the Security profile while there is another for the Safety profile then can be definied.

FACE also includes Units of Portability (UoPs). These components utilize PCS, TSS, and PSS, so they should be portable across systems that support these requirements. A component could be moved from one aircraft to another or it could be replaced by a compatible component. Keep in mind that there is not a single FACE configuration. Still, given a FACE configuration, suitable software interchange is possible and practical.

Non-standard frameworks or runtimes can be used, but they must be constrained within a UoP. The FACE standard enumerates a range of UoP configurations and exceptions. UoP boundaries must exist within a segment and a partition. UoP-to-UoP communication must go through TSS. These restrictions make certification easier. UoP use is designed to maximize portability and interchange while providing a wider selection of modular solutions. 

Face Data

The FACE Data Model (FDM) defines the data exchange methodology between FACE components (Fig. 3). It is needed so UoPs can communicate with each other with data that each can understand. FDM utilizes strong typing. TSS support also defines formal units and unit conversion, which prevents using meters per second or furlongs per fortnight to define acceleration. FDM defines three layers of abstraction:

• Conceptual Data Model (CDM): conceptual views
• Logical Data Model (LDM): logical views
• Platform Data Model (PDM): platform views

These layers are based on the Object Management Group’s (OMG) Model Drive Architecture (MDA). The Unit of Portability Model (UM) is below the PDM. UM also maps to the underlying code support from languages like C and Ada as well as data definitions such as IDL and XML.

The CDM defines concepts while the LDM adds details like units, value domains like real numbers, constraints, and measurement precision. LDM also addresses conversions between values.  The PDM maps LDM entities to physical data types. For example, long and double precision floating point would be PDM realizations of a real number.

Programmers may find these multiple models to be overkill, but they are necessary because certifications require detailed definitions of the entire system. Interoperability will also need to address a range of platforms. Not all applications will be written in a single language even though C is very popular. Concise definitions are needed to handle this wide range of platforms and requirements.

Facing The Hardware

Hardware typically comes with software in terms of a board support package (BSP). Software such as operating systems may be approved or bundled with the hardware as well. FACE improves this state of affairs because the software now will deliver well defined FACE APIs that will make it easier to incorporate and verify higher-level FACE APIs and software on the hardware.

Integrators or some vendors may eventually have a complete, off-the-shelf FACE configuration for some hardware. For now, a FACE implementation will incorporate software solutions from a range of vendors.

FACE is not a standard starting from scratch that will require new software. In general, existing operating systems and tools will require only minor tweaking to support it. POSIX and ARINC 653 are commonly available features on most RTOS products already used in this market.

Also, FACE is a software framework that can address a range of hardware configurations. It can apply to a single OpenVPX box with multiple boards connected via InfiniBand or VME. FACE is equally applicable to distributed systems with nodes connected via an Ethernet network. 

Certification plays a part in adopting FACE. Most of the initial application areas have safety and/or security certification requirements such as DO-178B/C for avionic solutions. FACE components will be designed to streamline the certification process. Some operating systems already address this issue, and the FACE framework shows the relationship between components.

The Changing Face

FACE is an approach that helps unify the underlying software including operating-system and communication support. It started as a U.S. Navy program at the U.S. Naval Air Systems Command (NAVAIR). It has since been adopted by more U.S. military organizations. It will make joint projects easier and allow for more component reuse.

FACE may also move outside this arena if developers are smart. Organizations like the Eclipse Foundation have made major strides in improving development tools because of the cooperation such an approach fosters.

There are winners and losers with FACE. Integrators and prime contractors benefit because they will have more standard components to choose from. Companies that can create partnerships will have an edge in this type of procurement environment.

In general, FACE will allow developers to concentrate less on integration and more on their own secret sauce. It will also increase overall understanding and use of common technologies that many are not aware of or using now because of the integration costs when dealing with a custom configuration.

For example, DDS inherently brings publish/subscribe semantics to the table. As one of the components within the FACE Transport segment, it will be an option that will be supported by a number of operating systems. There may even be multiple DDS implementations available, providing a wide range of choices for building a system.

FACE is still evolving and its use is in the preliminary stages. FACE Version 2 will enhance the health monitoring and fault management requirements. Specific FACE profiles and requirements eventually will become part of a system requirements document enumerating the software configuration in the same level of detail as an OpenVPX system on the hardware side. In fact, FACE conformance was part of a recent Navy C-130T contract.