Conference PaperPDF Available

An Examination of Open System Architectures for Avionics Systems – An Update

Authors:

Abstract and Figures

Recognizing the need for affordable and effective solutions for the development of avionics systems, the United States (US) Department of Defense (DoD) calls for the use of Open System Architecture (OSA) solutions in Better Buying Power (BBP) 3.0, Department of Defense Instruction 5000.02, and the Defense Acquisition Guidebook. The objectives of this guidance and direction are to avoid vendor lock, enable affordable capability evolution, and promote innovation. Presently, there are several initiatives underway to develop OSA standards for use in military avionics systems. This paper will examine three of these efforts: the Unmanned Systems (UxS) Control Segment (UCS) Architecture, the Open Mission Systems (OMS) initiative, and the Open Group Future Airborne Capability Environment (FACE™) Approach. This paper will start with the specification of the definition of open systems architecture as prescribed by the DoD. Next will be a brief description these three OSA standard activities that are being conducted to address the direction from the DoD. The paper will then present an analysis of these OSAs based on the DoD’s guidelines. Finally, the paper will summarize the state of these OSAs and make recommendations for future work.
Content may be subject to copyright.
An Examination of Open
System Architectures for
Avionics Systems – An
Update
Air Force FACE™ TIM Paper by:
Joyce L. Tokar, PhD
Pyrrhus Software, LLC
March, 2017
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 2
Table of Contents
Executive Summary .................................................................... 3
Introduction ............................................................................... 4
Open System Architecture .......................................................... 5
Definitions .............................................................................................. 5
Quality Attributes .................................................................................... 6
Open System Architectures for Avionics Systems ........................ 8
Unmanned Systems (UxS) Control Segment (UCS) Architecture ................ 8
Open Mission Systems (OMS) Initiative ................................................. 10
The Future Airborne Capability Environment (FACE) Approach .............. 12
Analysis of the OSA Architectures ............................................ 15
Usability of Open System Architectures .................................... 16
Summary, Conclusions, and Future Work ................................ 17
References ................................................................................ 18
About the Author(s).................................................................. 20
About The Open Group FACE™ Consortium .......................... 21
About The Open Group ............................................................ 21
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 3
Executive Summary
Recognizing the need for affordable and effective solutions for the development of
avionics systems, the United States (US) Department of Defense (DoD) calls for the
use of Open System Architecture (OSA) solutions in Better Buying Power (BBP) 3.0,
Department of Defense Instruction 5000.02, and the Defense Acquisition Guidebook.
The objectives of this guidance and direction are to avoid vendor lock, enable
affordable capability evolution, and promote innovation. Presently, there are several
initiatives underway to develop OSA standards for use in military avionics systems.
This paper will examine three of these efforts: the Unmanned Systems (UxS) Control
Segment (UCS) Architecture, the Open Mission Systems (OMS) initiative, and the
Open Group Future Airborne Capability Environment (FACE™) Approach. This
paper will start with the specification of the definition of open systems architecture as
prescribed by the DoD. Next will be a brief description these three OSA standard
activities that are being conducted to address the direction from the DoD. The paper
will then present an analysis of these OSAs based on the DoD’s guidelines. Finally,
the paper will summarize the state of these OSAs and make recommendations for
future work.
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 4
Introduction
Building high-integrity, safety-critical systems are one of the primary activities of the projects within the
United States (US) Department of Defense (DoD). The speed of change in technology has forced the DoD to
look for tools and technologies to accelerate the development and evolution of military systems. To deliver
enhanced, integrated warfighting capability at lower cost, the DoD must more away from stove-pipe solutions
and embrace Open Systems Architecture (OSA) frameworks, which are based on reusable hardware and
software components and services including open interface specifications [1].
Recognizing the need for affordable and effective solutions, the DoD calls for the use of Open System
Architecture (OSA) solutions in Better Buying Power 3.0 [2], Department of Defense Instruction 5000.02
[2], and the Defense Acquisition Guidebook (DAG) [4]. This guidance and direction is intended to avoid
vendor lock, enable affordable capability evolution, and promote innovation.
There are many initiatives underway within the DoD to identify and define open systems architectures to be
used in military systems. Avionics weapons systems are an example of one domain within the military that is
actively pursuing the definition and use of OSAs in the development and evolution of avionics systems.
Some of the avionics weapons systems currently using OSA include: the Common Mission Control Center
which manages command and control of disparate platforms; Global Hawk and MQ-9 Reaper unmanned
vehicles; AH-64 E Apache and HH-60W Black Hawk Rescue Helicopters; U-2 Dragon Lady, F-22, and AV-
8B Harrier Jets. In addition, according to Deborah Lee James, Secretary of the United States Air Force, the
Air Force is looking to incorporate open mission systems architecture in the development of the new Long
Range Strike-Bomber – B-21 [5].
The focus of this paper is on the OSA standards that are currently being developed and used in military
avionics systems. In particular, three efforts will be examined: the Unmanned Systems (UxS) Control
Segment (C2) UCS Architecture, the Open Mission Systems (OMS), and the Future Airborne Capability
Environment (FACE™). Each of these approaches provide a definition of an open systems architecture from
a different perspective and offer some interesting methods to increase opportunities for competition and
improve access to innovation. The paper will concentrate on the technical architectural similarities and
differences. There will be a short discussion of the business models of the three OSA standards. The usability
of the standards will be evaluated in light of avionics systems. Some suggestions will be offered on future
development of these standards.
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 5
Open System Architecture
To get started with the comparison of the Open System Architectures (OSA) of interest, a common
understanding of the basic concepts is necessary. What is meant by systems architecture? an open standard?
an open system architecture? There are numerous definitions of open systems architectures that vary
between domains. The following definitions, provided by the DoD Open Systems Architecture Contract
Guidebook for Program Managers [6], have been selected as the foundation of this analysis:
Definitions
An architecture is the fundamental organization of a system embodied in its components, their relationship to
each other, and to the environment, and the principles and guidelines governing its design and evolution.
An open architecture is a type of architecture whose specifications are made public by its designers which
allows users to make modifications to various components.
An open interface is a public standard for connecting hardware to hardware and software to software. With
regard to hardware, it implies that there is more than one brand of product that can be hooked up to the
device with an open interface. In the case of software, it implies that more than one program exists to
interface with the application that has the open interface or that a program can be readily written to
communicate with it.
An open standard is a low cost, publically available standard, designed and developed by recognized
standards organizations or the marketplace. An open standard supports interoperability, portability, and
scalability.
An open system is a system that employs modular design tenets, uses widely supported and consensus based
standards for its key interfaces, and is subject to validation and verification tests to ensure the openness of its
key interfaces.
An open systems architecture (OSA) is a system that employs modular design, uses widely supported and
consensus based standards for its key interfaces, and had been subjected to successful validation and
verification tests to ensure the openness of its key interfaces. An open architecture is defined as a technical
architecture that adopts open standards supporting modular, loosely coupled and highly cohesive system
structure that includes publishing key interfaces within the system and full design disclosure. The key
enabler for open architecture is the adoption of an open business model which requires doing business
transparently to leverage the collaborative innovation of numerous participants across the enterprise
permitting shared risk, maximized asset reuse, and reduced total ownership costs. The combination of an
open architecture and an open business model permits the acquisition of Open Systems Architectures that
yield modular, interoperable systems allowing components to be added, modified, replaced, removed, and/or
supported by different vendors throughout the life cycle in order to drive opportunities for enhanced
competition and innovation.
An OSA is a contract between several groups of people. Notably, it is an agreement between the
implementer of the standard and the organizations who use the standard, e.g., between the system software
developer and the applications programmers. It is also a contract between the standards developer
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 6
community and the users of the standard, and between the standards developer community and the
acquisition community who specify the use of a set of standards on systems they pay for.
Open Systems Architecture (OSA) integrates business and technical practices to create systems with
interoperable and reusable components.
The essence of Open Systems Architecture (OSA) is organized decomposition, using carefully defined
execution boundaries, layered onto a framework of software and hardware shared services and a vibrant
business model that facilitates competition. OSA is composed of five fundamental principles:
1. Modular designs based on standards, with loose coupling and high cohesion, that allow for
independent acquisition of system components;
2. Continuous design disclosure and appropriate use of data rights allowing greater visibility into an
unfolding design and flexibility in acquisition alternatives;
3. Enterprise investment strategies based on collaboration and trust, that maximize reuse of proven
system designs and reduce the total cost of ownership (TOC);
4. Enhanced transparency of system design through Government, academia, and industry peer
reviews thereby reducing risk;
5. Competition and Collaboration through development of alternative solutions and sources;
6. Component Analysis to determine which components will provide the best return on investment
(ROI) to OSA, i.e., which components will change most often due to technology upgrades or parts
obsolescence and have the highest associated cost over the life cycle.
The effectiveness of OSA is determined by the rules by which the standards work together, and by which
applications are integrated to make operational systems. Can a qualified third party add, modify, replace,
remove, or provide support for a component of a system, based on open standards and published interfaces
for the component of that system?
Quality Attributes
Each OSA is characterized by a set of quality attributes that include reconfigurability, portability,
maintainability, technology insertion, vendor independence, reusability, scalability, interoperability,
upgradeability, and long-term supportability. Below are some examples of the kind of information that is
needed to realize some of these attributes:
Reusability, Maintainability, Interoperability – Is each constituent standard/interface clearly identified (e.g.,
identification including version/release)?
Maintainability, Reconfigurability – Are the standards/interfaces appropriate to the domain of the OSA?
Interoperability -- Does the OSA address the potential interactions of the constituent standards/components,
including optional features and implementation freedoms? (It may be “A Bad Thing” if an option in one
standard in the OSA caused another standard to not work.)
Portability – Are the rules for configuring the OSA infrastructure and for the applications/systems built on the
OSA, clearly specified?
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 7
Maintainability – Does the OSA provide support for testing and debugging systems built on top of it?
Scalability, Long-term Supportability – Does the OSA provide conformance rules for both implementations
of its infrastructure, and for what applications may and must do?
Technology Insertion – Does the OSA provide language for how it is to be included in technical
specifications and procurement documents?
Reconfigurability – Are there multiple implementations of the OSA infrastructure?
Maintainability – Is the entire OSA available from a vendor, or must the system integrator construct and
verify it?
Vendor Independence – If the system integrator assembles the OSA from different vendors, is there a means
for vendors to understand and implement the OSA’s requirements and rules (e.g., a consortium or
implementer’s forum)?
Long-term Supportability – Is the vendor community committed to coordinating constituent updates to ensure
that one vendor’s update doesn’t break the entire OSA infrastructure?
Implementing OSAs will accelerate and simplify the delivery of advanced capability into systems without
replacing entire systems. Incorporating modularity principles should result in systems with highly
cohesive, loosely coupled, and severable modules that can be openly competed.
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 8
Figure 1 Open System Interconnection (OSI) Model; closed architecture and
business models
Open System Architectures for Avionics Systems
Within the DoD avionics community, there are several OSA efforts emerging to address the direction
specified in BBP 3.0 and other government directives. The Unmanned Systems (UxS) Command and Control
(UCS) Architecture is primarily interested in the control segment for unmanned systems. The Open Mission
Systems (OMS) Initiative is focused on both legacy and new airborne platforms. The Future Airborne
Capability Environment (FACE) Approach is defining a Common Operating Environment for airborne
systems.
Unmanned Systems (UxS) Control Segment (UCS) Architecture
The Unmanned Systems (UxS) Control Segment (C2) UCS Architecture was originally designed and
developed by the UCS Working Group (UCS WG) of the Office of the Under Secretary of Defense for
Acquisition, Technology, and Logistics (OUSD (AT&L)) to address the Unmanned Aircraft System (UAS)
domain. This work was transferred to the Society of Automotive Engineers (SAE) Unmanned Systems (AS-
4UCS) Technical Committee in April 2015. With the expanding use of unmanned technology in domains
other than avionics, the UCS Architecture is emerging as the DoD’s information architecture for controlling
Robotics and Autonomous (RAS) in all domains, air, land, and sea [7]. Hence, the name was changed to
Unmanned Systems (UxS) Control Segment (UAS) Architecture.
As with a large part of the
existing military systems, legacy
UAV systems have been
designed and procured as non-
interoperable “stovepipe”
systems. The UCS effort started
off with the recognition for the
need of a common message set to
communicate from the Command
and Control center to the
unmanned air vehicles. Figure 1
demonstrates how the common
open message set helps to unify
the control of unmanned vehicles
across military applications and
services. This work on the common message set led to the adoption of the use of STANAG 4856 [8]. The
objective of STANAG 4856 was to begin to break down the barrier to interoperability by establishing a
standard set of interfaces in the UCS to communicate with different UAVs and their payloads using a
standard message set.
With the adoption of STANAG 4856 and its successful use among our services and allies, the focus of the
UCS WG moved toward developing an architecture that would enable the integration and reuse of services
between programs and Services.
The UCS WG vision was to decrease acquisition and operational costs of unmanned air systems and enable
interoperability by providing a standard message set for machine-to-machine communications, and by
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 9
providing an open standard that defines the interfaces and rules that enable easy integration of new services
and reuse of services between unmanned programs.
During recent years, Unmanned Aircraft Vehicles (UAV) have become a niche in continuous expansion
within the aerospace market. With an investment that has exceeded billions of dollars, it is predictable that the
next generation will possess even more capabilities than today’s. As such, more emphasis has been put on
developing an architecture that will support the development a service oriented architecture for unmanned
aerospace systems command and control and incorporate an Open Business Model (OBM) to address
business goals such as affordability and productivity.
The UCS Architecture is evolving from
an Open System Interconnection (OSI)
model of interoperability to an Open
Architecture (OA) model based on an
Open System Environment (OSE) in
which applications may be acquired
and integrated within a service-oriented
architecture. The UCS Architecture
defines a Service Oriented Architecture
(SOA) and a modeling framework for
the specification, integration,
implementation and deployment of
control station software (Figure 2).
The architecture is centered on a SOA
Platform Independent Model (PIM) and
associated function models. Platform independence (independence of the software operating environment)
allows the UCS Architecture to be implemented on different infrastructures and with different
communications protocols. This supports technology insertion and adoption on multiple UCS systems and
related architectures.
The UCS Architecture is partitioned into Domains based on subject matter expertise to provide easier
navigation and understanding. These include: Primary Mission Control, Mission Planning, Dynamic
Airspace, External Messaging and Communications, Sensor Product Processing, Exploitation, and
Dissemination (PED), and System Support.
The UCS Architecture also includes an open Data Model based on real-world entities (such as air vehicles,
payloads, communications links, etc.) as well as standard units. The data model provides a platform
independent representation of information to be shared between UCS Domains and Actors. This
representation is comprised of a Logical Data Model , which is a self describing model of information
required by all UCS Domains, and a set of Interface Classes, which represents collections of information used
by the Domains in their internal and external interactions.
The system and technology concerns that are peculiar to a particular UCS system or UCS platform are
addressed in a Platform Specific Model (PSM). The PSM adds elements to address system concerns, such as
quality of service, safety, and information assurance. It also addresses deployment and application program
interfaces (APIs).
Figure 2 UCS Architecture Component View
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 10
The UCS Architecture is expressed by a library of SAE publications, of which AS6512[9], UCS Architecture
Description, is the highest in the document tree and is therefore the official designation of the UCS
Architecture. AIR6520 [10] is the Version Description Document which comprises a configuration item
version table, a summary of the configuration item updates, and a list of approved changes. Architecture
Technical Governance, AS6522 [11], defines the set of policies, processes, and standard definitions to
establish consistency and quality in the development of UCS work products and the use of industry standards.
The Conformance Specification, AS6513[12], establishes the conformance requirements for UCS software
components, UCS software configurations, and UCS systems to be conformant to the UCS Architecture.
The UCS Architecture Library also includes four models: the authoritative UCS Architecture Model is
AS6518 [13]; AIR6515 [14] – UCS ICD Model – Enterprise Architect (EA) Version; AIR6516 [15] – UCS
ICD Model – RSA Version; AIR6517 [16] – UCS ICD Model – Rhapsody Version. The Interface Control
Document (ICD), AIR6514[17], is derived from the ICD elements of the authoritative Model. And AIR6521
[18] contains the Data Distribution Services (DDS) derived from the UCS Architecture Model.
The challenge is to develop standards that enhance interoperability of systems, but do not limit beneficial
emergent behavior of UxS developers and operators.
Open Mission Systems (OMS) Initiative
Learning from the work on UCS, the Air Force Rapid Capabilities Office (AFRCO) chartered the Open
Mission Systems (OMS) initiative with industry with the objective of developing a non-proprietary, open
system architecture to drive acquisition and business models away from legacy stove-piped solutions. In
addition, in accordance with BBP 3.0 and other government guidance, the OMS effort is working to influence
and incentivize industry toward a capability based business model which will enhance competition and
encourage rapid innovation. Another objective of OMS is to identify new acquisition and architecture
approaches to reduce development and life-cycle costs, while at the same time providing a viable path to
upgrade and expand system capabilities.
The goal of OMS is to develop industry consensus for a non-proprietary mission system architectural
standard that enables affordable technical refresh and insertion, simplified mission systems integration,
service reuse and interoperability, and competition across the lifecycle.
The objective of OMS, as well as other OSA efforts, is to identify new acquisition and architecture
approaches to reduce development and life-cycle costs, while at the same time providing a viable path to
upgrade and expand system capabilities. The Open Mission Systems (OMS) standard [20] developed by the
US Air Force utilizes commercially developed Service Oriented Architecture (SOA) concepts and
middleware in its definition. The OMS industry partners have developed a mission systems architecture that
is defined by key system interfaces between subsystems (i.e., payloads and sensors) and services connected
through an Avionics Service Bus (ASB). These consensus-defined interfaces use open and standard interface
definitions, and decouple the technical implementations from the interfaces to enable future upgrades and
provide flexibility that allows Platform, Subsystem and Service providers to offer competitive solutions to
future problems. The OMS Standard defines requirements, provides architecture definition, and guidance, and
specifies compliance assessment approaches. The Air Force is looking to extend the capabilities of the OMS
standard to facilitate the rapid evolution of avionics systems.
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org
An Air Force FACE™ TIM Paper
11
The OMS Reference Architecture uses
fundamental service-oriented design patterns
and principles as well as key interfaces and
modules (Figure 3). The functionality of
avionics systems is characterized as a set of
services and a set of clients. In some
instances, a program or system may be both a
client and a service. The OMS standard
defines the basic behavior of clients and
services as well as the Avionics Service Bus
(ASB) protocols for entering and exiting the
system, supporting testing, fault tolerance,
isolation, and authentication.
The OMS effort specifies the test bed
environment required to support the migration and development of OMS compliant systems. The OMS
Standard also defines the compliance methodology and artifacts that are needed to demonstrate that a service
or client is compliant with the standard.
The components that are plugged into the Avionics Service Bus must be self-describing to the rest of the
system, so that other components can “look-up” how to exchange (meta) data with each component as it is
inserted. The Avionics Service Bus is more than a bus – it is middleware that supports the Service Oriented
Architecture. The middleware provide communication capabilities (messaging), provides a registry and/or
broker to allow services to register their interfaces and to allow clients to access the interfaces (which also tell
the clients how to invoke the service.) Common services and client applications can be embedded in the
middleware, thus standardizing common capabilities. The SOA middleware should provide for position
independent services and clients, and also needs to provide low latency, high throughput real-time
communications. A service bridge to the enterprise SOA (e.g. ground stations and other GIG enabled users)
is also needed.
Key architectural elements of OMS include:
Avionics Service Bus (ASB) – Logically, the combination of OMS message exchanges, data transfers, and
special signals over and IP based network.
Critical Abstraction Layer (CAL) – Abstracts OMS-based services from platform specific implementations,
supporting interoperability and portability.
Open Computing Environment (OCE) – The computing environment on which OMS-compatible mission
Services can run to enable portability across Platforms and enable rapid hardware upgrades.
Platform – The host aircraft provides core OMS functionality, including the ASB and CAL implementation,
as well as an OCE for compliant services.
Services – Software based-functionality exposed to the ASB that provide a set of specific mission
capabilities.
Subsystems – The physical hardware, software services, data transfers, and special signals that make up a
complete system capability.
Figure 3 OMS Reference Architecture
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org
An Air Force FACE™ TIM Paper
12
The OMS Standard provides guidance and requirements for OMS Compliance of Service Contracts, Platform
Descriptions and Subsystem Descriptions. The standard also defines OMS Governance for long term
maintenance of the OMS standard.
There is an OMS Reference Architecture that defines the key elements and interfaces. An OMS Message
Model and schema have been derived and extended from the UCS schema.
The Air Force is pursuing the definition of the OMS Standard to improve system (of systems) capabilities in a
cost effective and rapid manner. Open avionics systems are crucial to enabling the competitive, cost
effective, and timely introduction of new war-fighting capabilities in platforms that will persist for decades.
Service oriented concepts judiciously combined with embedded open system techniques will deliver the next
generation of open avionics technologies and architectures. Open architecture test beds based on executable
specifications will accelerate integration and provide the mechanism to compete new avionics technologies.
OMS is a focused effort by the Air Force to improve system (of systems) capabilities in a cost effective and
rapid manner using a layered open systems architecture.
The Future Airborne Capability Environment (FACE) Approach
The Future Airborne Capability Environment (FACE) approach
is to develop a Technical Standard for a software Common
Operating Environment (COE) designed to promote portability
and create software product lines across the military aviation
community. The development of the FACE Technical Standard
was motivated by the advances in mobile devices through the
use of a COE. In the commercial market, the architectural stack
of the mobile device is composed of a collection of applications
that access the operating system through a well defined interface.
And the operating system accesses the hardware through a well
defined interface. The variability in these systems comes in operating systems and the hardware, but the
interfaces between these components does not change significantly (Figure 4).
Presently, the military has considerably more variability in most aspects of the programs and systems. The
objective of FACE consortium is to provide the standards, framework, and interface definitions to enable the
military to migrate to a similar COE structure while maintaining the variability at all levels to support military
Avionics missions (Figure 5). This Avionics COE will reduce life cycle costs as well as the time required to
integrate, test, and field new capabilities. The FACE business
strategy focuses on the conformance to the FACE technical
standard to maximize interoperability between applications
within the avionics systems.
The focus of the FACE consortium is to offer uniform
application of common open standards across DoD aviation to
break “Cylinders of Excellence.”
Figure 4 Mobile Computing COE
Figure 5 Military Avionics COE
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 13
The FACE strategy is to create a software environment on the installed computing hardware that enables
FACE applications to be deployed on different platforms with minimal to no impact to the FACE application.
The FACE architecture is composed of a set of segments where variance many occur. The FACE technical
standard groups interfaces into two primary categories: Vertical Interfaces – those interfaces that support a
software layer; and Horizontal Interfaces – those interfaces that connect applications to other applications, to
data sources, or to data sinks (Figure 6). This
architecture supports the development of portable
applications to improve competition throughout the
supply chain.
The FACE Reference Architecture is comprised of
a set of segments where each segment represents a
place where variance may occur. There are five
segments in the reference architecture: the
Operating System Segment (OSS), the I/O Services
Segment (IOSS), the Platform-Specific Services
Segment (PSSS), the Transport Services
Segment (TSS) and the Portable Components Segment (PCS) (Figure 7). The segmentation of the
architecture eases the impact of change by localizing the level at which change occurs. In addition, this OSA
reduces the integration costs associated with adding new capabilities. Uniform application of common open
standards across DoD aviation will help to
eliminate dependence on proprietary
solutions.
The FACE Data Architecture defines models,
specification, and governance policies to
support interoperability.
To address the differing requirements
imposed by security and safety domains of
avionics, the FACE Operating System
Segment defines a security profile (most
restrictive), a safety profile, and a general
purpose profile (least restrictive). The
profiles specify what resources are available
based on the operational requirements.
The FACE environment is defined by a collection of standards to address business concerns and conformance
concerns in parallel with technical concerns. The FACE Technical Standard [20] is the keystone document
of this environment. The FACE Business Guide [21] describes the business aspects of FACE for
Government and industry; it also highlights the value proposition and business drivers of FACE. The FACE
Conformance Policy, Guidance, and Authorities [22] define the processes and policies that govern the
process for achieving FACE conformance. The FACE Contract Guide [23] serves as a reference for
including FACE specific requirements in a solicitation or proposal. The FACE Reference Implementation
Guide (RIG) [24] provides guidance on combining the software standard profiles with an appropriate
Figure 6 FACE Architecture
Figure 7 FACE Reference Architecture
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 14
architecture. The FACE Library Policy and Infrastructure [25] documents describe how the Library
Infrastructure is implemented, administered, and regulated.
Using the FACE business and technical standards is the smart, intelligent way for government and
industry to provide the most advanced capabilities to Warfighters. Using the FACE approach will optimize
limited resources, enable new business opportunities, and support the United States and its coalition
partners in extending and maintaining a strategic military advantage.
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 15
Analysis of the OSA Architectures
All of the open architectures described in the previous section are collaborative efforts between industry, the
government, and the user community. Yet, the approach of each is slightly different. One question is how do
each of these OSAs satisfy the beneficial characteristics of OSA [26] outlined in the previous section:
1. It is modular, being decomposed into architectural components that are cohesive, loosely coupled
with other components (and external systems), and encapsulate their implementations behind visible
interfaces.
2. Its key interfaces between architectural components conform to open interface standards.
3. Its key interfaces have been verified to conform to the associated open interface standards.
The UxS UCS Architecture represents an evolution from the existing stovepipe systems toward an OSA
targeted to the control segment of unmanned systems . It is a work in progress and is evolving to a standard
systems oriented architecture for UxS Control Segment systems for unmanned vehicles operating in air, land,
and sea environments. It includes the definition of the interfaces, messages, services, and clients that are
applicable to supporting the C2 mission. The Domains in the UCS Architecture address the modularity of the
approach. Key interfaces are a little more difficult to identify in the UCS Architectural materials: there seems
to be an interface between the control device to the unmanned vehicle and at least one between the UCS and
external systems. To satisfy the openness dimension of the UCS Architecture all of the documents in the
UCS Library are available from SAE International for a fee.
The OMS architecture is focused on the use of a bus abstraction to support the integration of modules into a
military system through the use of the Abstract Data Bus and, if necessary, the standardized set of discrete
signals. It also recognizes the need for the integration of legacy components and recommends the use of
wrapper technology to achieve this migration. The standard includes some definition of compliance and
utilizes existing standards such as UCS. It falls short in its openness as it is a somewhat closed environment
when it comes to accessibility from the community at large.
The FACE approach expresses the modularity of systems with segments to capture operational commonality
and functionality. It clearly identifies the interfaces within the architecture, both from between segments of
the application stack and between applications. The openness of the FACE approach is supported by the
availability of all published material through The Open Group
Each of the OSA efforts described addresses the needs of a specific community and all are working to satisfy
the needs of their respective communities with an open systems architecture, conformance, and governance
captured in their respective standards.
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 16
Usability of Open System Architectures
The key concept is 'conformance to the standard,' and the language used in the POSIX standards [27] works
well to capture these concepts. Vendors provide a conforming implementation when they implement all
required parts of the standard. The applications developer produces 'conforming applications' by using only
the features of the standard, and adapting to any customizations permitted by the standard. The UAV
community has had a large degree of success in moving to STANAG 4856. The next phase of the migration
to an OSA is a work in progress. FACE is establishing formal conformance organizations to support their
conformance activities.
Determining a 'conforming implementation', i.e., buying a system that meets the requirements of the standard,
usually requires a combination of testing and of vendor documentation. Determining a 'conforming
application' is a harder task, because testing does not necessarily reveal if the application uses only the
facilities of the standard. An implementation may well provide extensions to the standard, including
behavior within the standard interface that does things not guaranteed by the standard. As part of the
Business Strategy of FACE, the Conformance Subcommittee has developed the FACE Conformance process.
And the FACE Technical Committee has defined a Conformance Verification Matrix (CVM) which
identifies the specific requirements, methods of verification, and associated verification evidence. OMS
defines a Compliance Verification Cross Reference Matrix (VCRM) which contains all of the OMS
requirements and the associated verification requirements and acceptance criteria.
A standard supports its user community when the specification is sufficient to meet the user needs, complete
with respect to all parameter values, behaviors, etc., and has a well-defined conformance approach. For
FACE, the FACE Trademark Licensor issues the FACE Conformance Certification Trademark for Certified
Units of Conformance and Certified Unit of Conformance Packages thus allowing a third party to easily
determine if a component is FACE conformant.
The real test of all of these OSA efforts will occur when multiple suppliers offer similar capabilities and
these modules can be easily integrated into their target systems.
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 17
Summary, Conclusions, and Future Work
OSA systems have a large amount of appeal because of their potential to lower program costs, increase access
to COTS, and ease integration. OSA programs also enable interconnectivity.
From an OSA perspective, the UCS is a success in that there is a large amount of programs that are adopting
the message set and the concept. The effort is aiming to provide a full OSA with rules for interoperability,
standard compliance verification, and openness to the UxS community. Expanding the focus of the UCS
architecture to include unmanned vehicles for land and sea as well as air has created a lot of momentum
behind the UCS Architecture.
OMS is in use primarily in Air Force systems. The Blue Guardian program has developed a platform
architecture using the Air Force's OMS reference architecture and conducted a ground and flight test program
of multiple payload combinations [28].
Currently, FACE has a lot of momentum in the Airborne Systems communities especially within the Navy
and Army. The US Air Force joined the consortium in 2016. More industrial and academic organizations are
joining the consortium as the FACE approach matures. A number of demonstrations of the application of the
FACE approach were presented at FACE Technical Interchange Meeting (TIM) in January 2016 as well as
the TIM in March 2017.
There continues to be more opportunity to expand the use of OSA standards such as FACE and OMS for
system and subsystems, and network platform interfaces. There is a need for more development of the safety
critical and high integrity aspects of these standards. Additionally, efforts are underway within these three
OSA communities to better align the architectures to support interoperability between them.
With the greater connectivity comes the potential for more vulnerability as it may provide greater access for
cyber intruders. This accessibility has prompted concerns that OSA systems are more vulnerable to attack
[29]. More research is needed to demonstrate how open systems can facilitate more secure systems through
the use of strict interface definition and control.
There is significant opportunity for better tool support for component integration and analysis as well as
transitioning the use of the OSA standards into industry.
There is significant opportunity for cost savings and efficient procurement using Open Systems
Architecture. The keys to OSA are strict definition of interfaces and measured compliance to the OSA
standard.
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 18
References
[1] Sledge, Carol, “A Discussion on Open-Systems Architecture,” SEI Blog, November 23, 2015,
https://insights.sei.cmu.edu/sei_blog/2015/11/a-discussion-on-open-systems-architecture.html.
[2] Under Secretary of Defense, Implementation Directive for Better Buying Power 3.0 – Achieving
Dominant Capabilities through Technical Excellence and Innovation, 9 Apr 2015,
http://www.acq.osd.mil/fo/docs/betterBuyingPower3.0(9Apr15).pdf.
[3] Department of Defense, Instruction Number 5000.02, 7 Feb 2017,
http://www.dtic.mil/whs/directives/corres/pdf/500002_dodi_2015.pdf.
[4] Defense Acquisition Guidebook, 2017, https://www.dau.mil/tools/dag.
[5] James, Deborah Lee, “Meet the Air Force’s New Acquisition System,” Defense One, January 13, 2016.
[6] DoD Open Systems Architecture Contract Guidebook for Program Managers, v.1.1, June, 2013, http://
http://www.acqnotes.com/Attachments/Open%20System%20Architecture%20(OSA)%20Contract%20G
uidebook%20for%20Program%20Managers%20June%2013.pdf.
[7] Ernst, Rich, “Unmanned Systems (UxS) Control Segment (UCS) Architecture Overview,” March 2016,
// http://www.dtic.mil/ndia/2016/GRCCE/Ernst.pdf.
[8] STANAG 4856, Standard Interfaces of UAV Control Systems (UCS) for NATO UAV Interoperability,
NATO Standardization Agency, 2012.
[9] SAE International Aerospace Standard AS6512™, Unmanned Systems (UxS) Control Segment (UCS)
Architecture: Architecture Description, Dec 2016.
[10] SAE International Aerospace Standard AIR6520™, Unmanned Systems (UxS) Control Segment (UCS)
Architecture: Version Description Document, Dec 2016.
[11] SAE International Aerospace Standard AS6522™, Unmanned Systems (UxS) Control Segment (UCS)
Architecture: Architecture Technical Governance, Dec 2016.
[12] SAE International Aerospace Standard AS6513™, Unmanned Systems (UxS) Control Segment (UCS)
Architecture: Conformance Specification, Dec 2016.
[13] SAE International Aerospace Standard AS6518™, Unmanned Systems (UxS) Control Segment (UCS)
Architecture: UCS Architecture Model, Dec 2016.
[14] SAE International Aerospace Standard AIR6515™, Unmanned Systems (UxS) Control Segment (UCS)
Architecture: EA Version of ICD Model, Dec 2016.
[15] SAE International Aerospace Standard AIR6516™, Unmanned Systems (UxS) Control Segment (UCS)
Architecture: RSA Version of ICD Model, Dec 2016.
[16] SAE International Aerospace Standard AIR6517™, Unmanned Systems (UxS) Control Segment (UCS)
Architecture: Rhapsody Version of ICD Model, Dec 2016.
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 19
[17] SAE International Aerospace Standard AIR6514™, Unmanned Systems (UxS) Control Segment (UCS)
Architecture: Interface Control Document, Dec 2016.
[18] SAE International Aerospace Standard AIR6521™, Unmanned Systems (UxS) Control Segment (UCS)
Architecture: Data Distribution Service, Dec 2016.
[19] Open Mission Systems (OMS) Standard, version 1.1, December 2015.
[20] Technical Standard for Future Airborne Capability Environment (FACE™), Edition 2.1, 2014,
https://www2.opengroup.org/ogsys/catalog/G162.
[21] FACE™ Business Guide, Version 1.1, December 2011,
https://www2.opengroup.org/ogsys/catalog/g115.
[22] FACE™ Consortium Conformance Publications and Tools,
http://www.opengroup.org/face/conformance.
[23] FACE™ Contract Guide, Version 1.0, December 2014,
https://www2.opengroup.org/ogsys/catalog/G145.
[24] Reference Implementation Guide for FACE™ Technical Standard, Edition 2.1, April 2016,
https://www2.opengroup.org/ogsys/catalog/g162.
[25] FACE Library Infrastructure Documents, http://www.opengroup.org/face/library-infrastructure-docs.
[26] Firesmith, Donald, “Open System Architectures: When and Where to be Closed,” SEI Blog, October
19, 2015, https://insights.sei.cmu.edu/sei_blog/open-systems-architectures/.
[27] POSIX IEEE Standards
[28] Barrett, Donald A, Luke A Borntrager, David M Green, “Blue Guardian: on open architecture for rapid
ISR demonstration,” Proceedings of SPIE 9849, Open Architecture/Open Business Model Net-Centric
Systems and Defense Transformation 2016, May 2016.
[29] Meyer, Bryce L., “Open Systems Architecture and Cyber,” St. Louis UNIX Users Group, Feb 2017.
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 20
About the Author(s)
Dr. Joyce Tokar is President of Pyrrhus Software. For the past 25+ years, she has worked on
mission and safety critical, real-time, embedded, and secure software systems. Most recently,
her focus has been on Open Systems Architectures (OSAs): UCS, OMS, and FACE. As
well as the Army’s Joint Common Architecture (JCA), it’s Common Operating
Environments (COEs). Dr. Tokar has experience with mission and safety critical, real-time, and embedded
software systems, systems interoperability and supportability, software correctness, software vulnerabilities,
high level computing languages, and real-time analysis methodologies. She co-authored the first edition of
Society of Automotive Engineering (SAE) Architecture Analysis and Design Language (AADL) standard
and wrote the SAE AADL Ada and C Programming Language Annexes. Presently, Dr. Tokar is leading the
development of the Ada and SPARK documents to complement the ISO/IEC Technical Report on Software
Vulnerabilities. Dr. Tokar has authored many articles on software and system architecture, software
vulnerabilities, the SPARK and Ada programming languages, and real-time, embedded systems.
An Examination of Open System Architectures for Avionics Systems
www.opengroup.org An Air Force FACE™ TIM Paper 21
About The Open Group FACE™ Consortium
The Open Group Future Airborne Capability Environment (FACE™) Consortium, was formed in 2010 as a
government and industry partnership to define an open avionics environment for all military airborne
platform types. Today, it is an aviation-focused professional group made up of industry suppliers, customers,
academia, and users. The FACE Consortium provides a vendor-neutral forum for industry and government to
work together to develop and consolidate the open standards, best practices, guidance documents, and
business strategy necessary for acquisition of affordable software systems that promote innovation and rapid
integration of portable capabilities across global defense programs.
Further information on FACE Consortium is available at www.opengroup.org/face.
About The Open Group
The Open Group is a global consortium that enables the achievement of business objectives through IT
standards. With more than 500 member organizations, The Open Group has a diverse membership that spans
all sectors of the IT community – customers, systems and solutions suppliers, tool vendors, integrators, and
consultants, as well as academics and researchers – to:
Capture, understand, and address current and emerging requirements, and establish policies and share best
practices
Facilitate interoperability, develop consensus, and evolve and integrate specifications and open source
technologies
Offer a comprehensive set of services to enhance the operational efficiency of consortia
Operate the industry’s premier certification service
Further information on The Open Group is available at www.opengroup.org.
Conference Paper
Throughout the Department of Defense (DoD), acquisition, platform integration, and life cycle costs for weapons systems have continued to rise. Although Open Architecture (OA) interface standards are one of the primary methods being used to reduce these costs, the Air Force Rapid Capabilities Office (AFRCO) has extended the OA concept and chartered the Open Mission System (OMS) initiative with industry to develop and demonstrate a consensus-based, non-proprietary, OA standard for integrating subsystems and services into airborne platforms. The new OMS standard provides the capability to decouple vendor-specific sensors, payloads, and service implementations from platform-specific architectures and is still in the early stages of maturation and demonstration. The Air Force Research Laboratory (AFRL) - Sensors Directorate has developed the Blue Guardian program to demonstrate advanced sensing technology utilizing open architectures in operationally relevant environments. Over the past year, Blue Guardian has developed a platform architecture using the Air Force's OMS reference architecture and conducted a ground and flight test program of multiple payload combinations. Systems tested included a vendor-unique variety of Full Motion Video (FMV) systems, a Wide Area Motion Imagery (WAMI) system, a multi-mode radar system, processing and database functions, multiple decompression algorithms, multiple communications systems, and a suite of software tools. Initial results of the Blue Guardian program show the promise of OA to DoD acquisitions, especially for Intelligence, Surveillance and Reconnaissance (ISR) payload applications. Specifically, the OMS reference architecture was extremely useful in reducing the cost and time required for integrating new systems.
A Discussion on Open-Systems Architecture
  • Carol Sledge
Sledge, Carol, "A Discussion on Open-Systems Architecture," SEI Blog, November 23, 2015, https://insights.sei.cmu.edu/sei_blog/2015/11/a-discussion-on-open-systems-architecture.html.
Meet the Air Force's New Acquisition System
  • Deborah James
  • Lee
James, Deborah Lee, "Meet the Air Force's New Acquisition System," Defense One, January 13, 2016.
Unmanned Systems (UxS) Control Segment (UCS) Architecture Overview
  • Rich Ernst
Ernst, Rich, "Unmanned Systems (UxS) Control Segment (UCS) Architecture Overview," March 2016, // http://www.dtic.mil/ndia/2016/GRCCE/Ernst.pdf.
Open System Architectures: When and Where to be Closed
  • Donald Firesmith
Firesmith, Donald, "Open System Architectures: When and Where to be Closed," SEI Blog, October 19, 2015, https://insights.sei.cmu.edu/sei_blog/open-systems-architectures/.
Blue Guardian: on open architecture for rapid ISR demonstration Open Architecture/Open Business Model Net-Centric Systems and Defense Transformation
  • Donald A Barrett
  • A Luke
  • Borntrager
  • M David
  • Green
Barrett, Donald A, Luke A Borntrager, David M Green, " Blue Guardian: on open architecture for rapid ISR demonstration, " Proceedings of SPIE 9849, Open Architecture/Open Business Model Net-Centric Systems and Defense Transformation 2016, May 2016.
Instruction Number 5000
  • Department Of Defense
Department of Defense, Instruction Number 5000.02, 7 Feb 2017, http://www.dtic.mil/whs/directives/corres/pdf/500002_dodi_2015.pdf.
Standard Interfaces of UAV Control Systems (UCS) for NATO UAV Interoperability
STANAG 4856, Standard Interfaces of UAV Control Systems (UCS) for NATO UAV Interoperability, NATO Standardization Agency, 2012.