Primary tabs

U.S. Army - FACE™ and SOSA™ 

Technical Interchange Meeting (TIM)

Tuesday, September 14, 2021

TIP: If viewing on a mobile device, rotate your device sideways to landscape to see all content

Time

South Hall

Activity  
7:00am to 3:00pm South Hall 
Lobby
Registration Check-in and pickup your name badge.
8:00am to 9:30am South Hall 
Ballrooms 1-2
General Session Keynote: BG Robert Barrie, PEO Aviation
9:30am to 4:00pm South Hall Exhibit Hall  Visit 46 Exhibit Booths
       
9:45am to 10:10am  
Ballroom 2
SOSA Overview The Sensor Open System Architecture™ (SOSA) Consortium creates a common framework for transitioning sensor systems to an open systems architecture, based on key interfaces and open standards established by industry-government consensus. The SOSA approach establishes guidelines for Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (C4ISR) systems. The objective is to allow flexibility in the selection and acquisition of sensors and subsystems that provide sensor data collection, processing, exploitation, communication, and related functions over the full life cycle of the C4ISR system. 
10:15am to 10:40am Ballroom 2 FACE Business Working Group 
(BWG) Overview
The FACE Business Working Group (BWG) develops, implements, and communicates Industry-Government business practices and procedures to guide the implementation of FACE contracting, conformance approval practices, and registry and repository processes that incorporate the FACE vision and mission. The FACE Business strategy is described by the business policies and procedures for establishing and maintaining a marketplace of FACE conformant software components that can be integrated into multiple platforms. The BWG defines these business practices to communicate FACE Consortium goals to DoD and industry leaders and promote the use of the FACE approach in avionics developments, procurements, and upgrades.
10:45am to 11:10am Ballroom 2 FACE Techncial Working Group 
(TWG) Overview
The FACE Technical Working Group (TWG) is responsible for all FACE Consortium technical aspects. The charter of the TWG is to identify open standards where such exist, define standards that do not yet exist and provide guidance for using these standards to achieve portability of software-based capabilities across multiple avionics platforms. 
11:15am to 11:40am  
Ballroom 2
FACE Data Interoperability Group 
(DIOG) Overview
The FACE Data Architecture Working Group (DAWG) is responsible for all FACE Data Architecture and Data Model aspects. The charter of the DAWG is to determine the elements of a Data Architecture, define those elements, identify applicable open standards where they exist, define standards where none exist, and provide guidance for using these standards to achieve interoperability at the data level. 
11:45am to 12:10pm
Ballroom 2
FACE Conformance 
(BWG) Overview
The FACE Conformance Subcommittee charter is to: 
1. Define and sustain the FACE Conformance Program to include a set of plans, policies, and procedures, defining the roles and responsibilities of participants, for certifying software products submitted for FACE Conformance Certification. 
2. Provide outreach, education, and guidance regarding the FACE Conformance Program to participants and other interested parties.
 

Time

Room
TIM Papers
Title
 19 TIM paper presentations (25-minutes each) between 10:00 am to 3:55 pm
Description
10:00am to 10:25am  
Ballroom 1
RRADE: A Modular TSS Solution The Open Group FACE™ Technical Standard defines the FACE Reference Architecture to promote reuse through portability across platforms. The Transport Services Segment (TSS) abstracts the logic and technologies of data exchange from a Unit of Portability (UoP), facilitating reuse in a broader range of integrated avionics systems.
Reusable, Reconfigurable Avionics Data Exchange (RRADE) includes a modular TSS solution per the FACE Technical Standard, Edition 3.0. Its design and implementation address factors that directly affect the change footprint of a TSS solution over the life span of an avionics system. The allocation of TSS capabilities to the different kinds of TSS Units of Conformance (UoCs) comprising the modular TSS solution may be leveraged to facilitate reduced integration and qualification cost and schedule. RRADE is engineered to support potential qualification to DO-178C Level C, with higher assurance levels possible through additional testing.
10:30am to 10:55am  
Ballroom 1
FACE™ Data Modeling 
for Software Developers
This document discusses challenges found in applying data modeling as defined in the Future Airborne Capability Environment (FACE) Technical Standards, Edition 3.0 to software development.  It discusses the real-world benefits of data modeling to systems and software engineers developing systems aligned with FACE Approach, and compares software related data modeling practices in other industries to data modelling in FACE. Data modeling has broad benefits to system architects and integrators as well as software developers.  This paper highlights data modeling practices that primarily benefit software developers, such as code-first data modeling, enterprise data modelling, Domain Specific Languages, and digitized Interface Control Documents (ICDs), and how FACE data modeling and tooling can take these further.  The paper also presents challenges found in implementing FACE gleaned from experience as a software developer implementing FACE for a number of years, and offers some ideas for effective development of FACE applications based on data models.
11:00am to 11:25pm
Ballroom 1
Halo Effect of FACE™ Technical Standard and Business Approach As the costs of creating advanced avionics software continue to increase and program funding continues to be constrained, a new business and acquisition approach along with a new technology foundation needs to be adopted to maintain competitiveness with near-peer adversaries – everything must change. To meet this challenge, the government and A&D industry have joined forces to create The Open Group Future Airborne Capability Environment (FACE) approach, which redefines the landscape for developing, procuring, integrating, and maintaining next-generation military avionics platforms. This paper will describe the challenges facing these platforms, the forces driving change, and how the FACE™ Technical Standard and Business Approach combats these existential threats to advance global competitiveness in military airborne systems. In addition, the FACE approach delivers additional benefits – sometimes referred to as “halo effects” – that benefit government, industry, and warfighters.
11:30am to 11:55pm
Ballroom 1
FACE 3.0 Conformance of Ansys ARINC 661 Cockpit Display System  Ansys worked closely with the United States Army Verification Authority (VA) to complete the Future Airborne Capability Environment (FACE) Verification process of the Ansys Cockpit Display System (CDS) Server as a Platform-Specific Service (PSS). This paper details the steps Ansys followed to complete the FACETM Verification process and capture valuable lessons learned during this process. The CDS Server is a commercial off-the-shelf (COTS), certifiable, portable, and fully customizable to accommodate different air system platforms for a variety of use cases which include mission systems, glass cockpits and Unmanned Aircraft Vehicles (UAV) operator controls.  Ansys has officially achieved the conformance to the FACE 3.0 Technical Standard in March 2021. The two main topics addressed in this paper are the platform specific layer developed on top of the COTS components to meet the FACE requirements and the different lessons learned from the FACE conformance process.
12:00pm to 12:25pm
Ballroom 1
Strategies for Mixed Criticality 
ARINC661 
As future systems move to helmet displays and large format single systems to present all information to the crew, the separation of criticality will be vital in reducing the full costs of these systems.
The separation of criticality in processing information plays a significant factor in the qualification costs of avionics systems.  A system presenting flight-critical information must be qualified to a higher level, leading to higher qualification costs.
Additional capabilities added to aircraft are rarely at higher qualification levels of the initial system development. The ability to add lower criticality information that can integrate with higher criticality information without modifying the existing higher criticality system reduces efforts of adding new capabilities.
ARINC-661, and the approach taken in its implementation, can greatly reduce the costs of adding capabilities to a platform.
12:30pm - 12:55pm
Ballroom 1
Common Symbology Approach 
Using Configurable Core 
User Applications (UAs)
The use of configurable core components provides advantages in airworthiness qualification and reducing the effort to add additional capabilities into an existing system. Typically, new capabilities added to a system will have user interface impact related to its control and display. 
When it comes to user interface design, it is desirable that the platform has consistent control interfaces and display symbology across all capabilities.  A set of configurable core components, such as a menu system, can provide a common integrated look-and-feel to a user. These common components can be expanded to cover other aspects of the presentation of data from new capabilities.
Increasing the number of configurable core components to include common graphical representations of numeric values distributed in the system can greatly reduce the effort to display data from newly added capabilities to the aircraft.
 
12:30pm to 12:55pm   
Ballroom 2
Increasing Interoperability
for FACE Technical Standard
 
Modular open systems are increasing in consideration among program office acquisition strategies. 
Program managers are now trying to understand how to implement and integrate a Modular Open Systems Approach (MOSA) policy into their current system of best practices and reporting.  System and standard integration have moved away from prime vendor ownership and open standards have allowed the program offices to control what capabilities are available for integration which means standards must be mature, thorough and flexible. The Future Airborne Capability Environment (FACE) Technical Standard is one of the most mature open standards available today in the Department of Defense (DoD) due to its complete digital engineering component and verification and validation path, yet it has limited flexibility when it comes to interoperability. The focus of this paper is on improving interoperability to the FACE™ Technical Standard by providing suggestions for effective solutions to increase the interoperability of the standard. 
1:00pm to 1:25pm  
Ballroom 1
Open Systems Management Plan (OSMP) Data Item Description (DID) History, Usage and Path Forward This paper describes the Open Systems Management Plan (OSMP) Data Item Description (DID), covering its history, current usage and planned path forward.  Originating as a one-time DID in support of an Army missile defense program out of PEO Missiles and Space, the OSMP suggested content was adapted to the aviation software domain by the FACE Consortium, exercised by some of the member organizations and refined within the FACE Business Working Group as part of the FACE Contract Guide.  Recognizing the lack of standard open systems approach content guidance and the potential applicability across DoD, FACE Consortium members from the Army proposed a general OSMP DID that was approved for use DoD wide.  With the increased importance of MOSA, utilization of the OSMP DID (DI-MGMT-82099) in solicitations has increased dramatically.  The OSMP DID will soon be revised based on lessons learned, recent MOSA guidance and a formal review via ASSIST. The targeted audience for this paper is broad and includes procurement organizations, responders to solicitations, managers, architects, designers, developers and integrators.
1:00pm to 1:25pm  
Ballroom 2
Applying Security to FACE™ Transport Services Segment (TSS) Almost every day brings news of a security breach or cyber-attack. With the trend of having inter-connected systems and data being shared among such systems, protecting the communication becomes more and more important. In every new system design, security is increasingly a key factor. And following the Executive Order on Improving the Nation’s Cybersecurity, no system can reasonably ignore security and still be competitive. Even when targeting non government applications security is becoming more and more of a discussion item. This paper describes how the FACE™ Technical Standard Transport Services Segment (TSS) communication can be secured using the Data Distribution Service (DDS) standard, and specifically DDS Security. With the DDS Security standard in place, security can be added to any system with just configuration changes. Effectively securing communication channels is a key element of every secure system. 
After an introduction to DDS and DDS Security, this paper describes an example of applying security to Basic Avionics Lightweight Source Archetype (BALSA) reference implementation. BALSA is a working software example of applications aligned to the Future Airborne Capability Environment (FACE) Technical Standard executing in a FACE Reference Architecture.
 
1:30pm to 1:55pm
Ballroom 1
Data Modeling Patterns Data model construction is heavily influenced by the background and practices of the engineers and organizations creating them. There is no formal approach to building a data model guaranteed to result in an unambiguous, reusable, and easy-to-read model. While we are far from presenting such guidance, this paper proposes a series of best practices and patterns which, if adopted, will make models easier to build, reuse, and understand.   
Although this content is most relevant to data modelers and specifically those data modeling to the FACE™ Technical Standard, it will also be useful for anyone thinking about how models can be used on a larger scale. Specifically, how to construct data models not for a system, but for a family of systems and capabilities not necessarily originally intended to be integrated.
 
1:30pm to 1:55pm
Ballroom 2
Addressing the Behavioral Aspects of Integration Beyond Data Modeling A core goal of the FACE™ approach is to promote portable, reusable components. One way the approach accomplishes this goal is by requiring components to clearly document the data syntax and semantics provided or consumed, thus decoupling the business logic that processes data from the infrastructure used to implement data exchange. Unfortunately, the specification largely ignores behavioral properties. Left unaddressed, this will impede integration.
Just as we use data models to unambiguously document semantics, we must add rigor to our definitions of behavior. If we do not, interpreting and implementing behavior will remain a manual task, forcing developers to code around historical design choices, requiring system integrators to know the details of each component. If parameterized, behavior becomes something that can be configured and generated. Then, computers can be used to optimize infrastructure and ensure behavioral requirements are met instead needing manual one-off implementations.
This paper shares ideas for modeling the behavioral interactions between FACE Units of Conformance (UoCs), allowing for further automation of integration. It is intended for those seeking to understand some of the challenges that we still face with integration.
2:00pm to 2:25pm  
Ballroom 1
Porting BALSA to Deos+RTEMS Basic Avionics Lightweight Source Archetype (BALSA) is an example application for The Open Group FACE™ Technical Standard and FACE Reference Architecture. It includes multiple FACE Units of Conformance (UoCs) to compose a FACE Computing Environment and sample application. This application was developed to target the FACE Safety Base OSS Profile but has only been hosted on GNU/Linux. This paper describes the issues and challenges encountered while porting BALSA from GNU/Linux to the embedded real-time operating system (RTOS) RTEMS and then to the time and space partitioned RTOS Deos+RTEMS.
2:00pm to 2:25pm
Ballroom 2

Benefits of Using Common Tools to Achieve FACE™ Conformance and DO-178C Compliance

The Future Airborne Capability Environment (FACE) Technical Standard and DO-178C, Software Considerations in Airborne Systems and Equipment Certification,  are two essential software standards in the avionics world. Conforming to both standards can be confusing because they use the same terminology in different ways. It is important to understand the focuses of the two standards, each with different goals, and imposing different constraints on the software development lifecycle (SDLC). From an engineer's point of view, the verification and validation requirements in both standards have similarities, including how they impact the SDLC. To minimize the cost and effort of complying with both standards, it is important to take both standards into consideration during validation and verification. The cost and effort can be further reduced by using testing tools that incorporate FACE Conformance requirements into the validation and verification steps required by DO-178C.
2:30pm to 2:55pm
Ballroom 1
Achieving Multicore Certification 
to DO-178C DAL A Using a
FACE™ Operating System
In March 2021, CMC Electronics received the first regulatory approval for a multicore avionics system certified to DO-178C and the CAST-32A multicore objectives. That Technical Standard Order (TSO) was followed by three more TSO approvals in April 2021, all to the highest design assurance level (DAL A). The systems that received TSO authorization utilize the INTEGRITY®-178 tuMP™ multicore RTOS, which is certified as conforming to the Future Airborne Capability Environment (FACE) Technical Standard, Edition 3.0. This paper describes the high-level architecture of those systems, the considerations taken to achieve the first approvals for a multicore avionics system, and the benefits of using an operating system conformant to the FACE Technical Standard.
2:30pm to 2:55pm
Ballroom 2
Multiple Transport Implementations Reuse of software is a business objective for the Department of Defense (DoD) as a mechanism to reduce costs for software related expenses. The effort to reuse software is directly related to the design of that software and the target platform. Through common use of the FACE™ Technical Standard, software architectures would be aligned, reducing the impact of porting capability software from one platform to another.
The system integrator is responsible for much of the porting and reusing as directed by the platform. The variability in the development approach of software conformant to the FACE Technical Standard can impact the effort a system integrator has to incorporate that UoC into an existing system.
Several methods to approaching the integration of Transport Services Segment (TSS) interfaces to Units of Conformance (UoCs) that use those services are presented here. The results of this examination and recommendations are presented in this paper.
3:00pm to 3:25pm  
Ballroom 1
FVL Digital Backbone

The request for Modular Open System Architecture (MOSA) solutions has been a practice to address several key tenets that the US Army Future Vertical Lift (FVL) weapon system needs to maintain asymmetric advantage. The US Army FVL programs have required a digital backbone to address integration issues and ensure that they maintain asymmetric advantage. This paper introduces the envisioned digital backbone for US Army, Future Vertical Lift aircraft. This paper provides context for how the Future Airborne Capability Environment (FACE) Technical Standard supports enablement of the digital backbone, core air vehicle, and mission system architecture framework. This paper focuses primarily on data distribution and cyber security aspects of the digital backbone, looking both at accommodating legacy systems and systems designed specifically for interoperability with the digital backbone.

3:00pm to 3:25 pm
Ballroom 2
FACE Approach Supports FVL: A MOSA implementation of avionics software for prototype FLRAA and FARA Developments The Open Group FACE™ Consortium has an Approach and an Open Standard that aligns with the five principles of the Modular Open Systems Approach (MOSA). The U.S. Army Program Executive Office (PEO) Aviation MOSA Transformation Office is positioned to support next-generation aircraft designs for the Air Vehicle (AV) and Mission Systems Architecture (MSA) hosting military aircraft avionics. The Future Vertical Lift (FVL) Family of Systems (FOS) includes two next-generation aircraft, Future Long Range Assault Aircraft (FLRAA) and Future Attack Recon Aircraft (FARA). 
The aircraft avionics products for these future aircraft will include embedded software hosted on architectural software aligned to the FACE Technical Standard to align with the MOSA. The U.S. Army’s PEO Aviation FVL Project Offices stated Place of Interest for future investment includes: Aircraft Survivability Equipment (ASE), Degrade Visual Environment (DVE), Future Engine Capability, Communications, and Air Launched Effects (ALE).
This paper describes the efforts of six of these FACE member organizations who formed a prototype FVL FACE Integration Team to develop and integrate prototype products that meet capabilities identified within U.S. Army’s stated Place of Interest. All products are intentionally aligned to the FACE Technical Standard.
 
3:30pm to 3:55pm
Ballroom 2
Automated FACE Model Transformation with Ansys SCADE and RTI Connext DDS This paper describes the tooling and process enhancement on the ANSYS® SCADE® and RTI Connext tools for developing UoCs for the Portable Components Segment (PCS), the Platform-Specific Services Segment (PSSS), and the Transport Services Segment (TSS).
FACE™ is a living standard; several versions of the Future Airborne Capability Environment (FACE) Technical Standard have been released; this paper focuses on the way users develop components and reuse them for the different versions of the FACE Technical Standard at low effort thanks to automated model transformation. The tool chain presented in this paper has successfully been applied for FACE 2.1, 3.0 and 3.1 releases allowing users to develop both their FACE data model and their software application component only once, still passing the FACE Conformance Test Suite for these three FACE versions.