Authors:

• Chris Crook
• Steve Fulmer
• Joel Sherrill, Ph.D.
• OAR Corporation

The Open Group Future Airborne Capability Environment™ Consortium (the FACE™ Consortium) Technical Standard defines the FACE Reference Architecture to promote reuse through portability across platforms. The Transport Services Segment (TSS) abstracts the logic and communication 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.1 [FACE3.1]. 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 Design Assurance Level (DAL) Level C, with higher assurance levels possible through additional testing.

This paper describes the design decisions and refactoring employed to add support for the Aeronautical Radio, Incorporated (ARINC) 653 Safety Base Operating System (OS) Profile to RRADE to complement the existing support for the Portable Operating System Interface (POSIX) Safety Base OS Profile. Topics of interest to Software Suppliers include OS abstraction interfaces, C++03 Capability Set differences, and refactoring rationale. System Integrators who deploy and maintain the TSS solution within one or more FACE Computing Environments within an avionics system may be interested in the new Transport Protocol Modules (TPMs) for Application Executive (APEX) sampling and queueing ports.

Authors:

• Gary Gilliland Technical Marketing Manager, DDC-I

The Open Group Future Airborne Capability Environment™ Consortium (the FACE™ Consortium) has developed a Reference Architecture and Standard for real-time embedded avionics systems. The FACE Technical Standard defines required capabilities for real-time operating systems (RTOS), portable components, and data architecture to facilitate information exchange between components. The FACE Approach allows software-based "capabilities" to be developed as reusable components utilizing industry standard API's.

The Deos SafeMC™ multi-core operating system is designed to enable application software component portability, where binary (not just source code) reuse is the ultimate form of portability. This binary portability capability improves upon the objectives of the FACE Consortium, such that not only are applications portable but the DO-178 development artifacts for the avionics application are reusable across product lines within multi-core environments. Deos has achieved operating system segment (OSS) conformance to the FACE Technical Standard 3.1 Edition for Safety Base and Safety Extended profiles.

Authors:

• Ryan Paetzell, Pr. Systems Engineer, Collins Aerospace

This document discusses the successes and lessons learned from integrating the Mission Flight Management Software application (MFMS-1000) Portable Component Segment (PCS) Unit of Conformance (UoC) onto several platforms. Conforming the MFMS-1000 with edition 2.1.1 of the The Open Group Future Airborne Capability Environment™ Consortium (the FACE™ Consortium) Technical Standard has facilitated rapid deployment of the MFMS-1000 between disparate platforms despite limitations with the Portable Operating System Interface (POSIX) capabilities offered. Insights will be given in several areas related to integrating the MFMS-1000 into multiple platforms including:

• Benefits of immediate testing
• Common recompile changes identified
• Challenges in deploying a combined Ada and C language PCS UoC
• Board Support Package (BSP) limitations and integration workarounds
• Challenges associated with Radio Technical Commission for Aeronautics (RTCA) DO-178C verification and certification

The material covered in this document provides a perspective on both the successes and challenges encountered from deploying the first FACE Certified Conformant Flight Management Software PCS UoC.

Authors:

• Christopher Noll, Sr Technical Fellow, Flight Control Systems and Software, Collins Aerospace
• Harold Tiedeman Jr, Sr Technical Fellow, Avionics systems and FVL Chief Engineer, Collins Aerospace
• Steven Avritch, Principal Technical Fellow, Flight Controls, Collins Aerospace

Leveraging a Modular Open Systems Approach (MOSA) on closed-loop fly-by-wire (FBW) flight control systems is a challenging task. Hardware size, weight, and power have traditionally been prioritized over open solutions. Hard real-time requirements associated with FBW systems have resulted in the use of very lightweight software stacks that are optimized for low-latency, deterministic performance, and simplicity of certification.

Today with available modern multicore processors and safety-critical Type 1 bare-metal hypervisors, it is now technically feasible to create MOSA solutions in the flight control domain.

This paper will discuss the origin of MOSA requirements for airborne weapon system computing environments, will describe the complexities associated with fly-by-wire flight control computing, and define optional multicore architectures. Among these architectures is a mixed MOSA concurrently supporting FBW applications and lower bandwidth capabilities, applying virtual machines (VMs) as a level of modularity.

The mixed modularity approach outlined in this paper is well aligned with the Open Group Vision of Boundaryless Information Flow™ (Ref [6]), in that the approach supports the free flow of information throughout the computing system while at the same time supporting the unique and differing real-time needs of flight control applications simultaneously with low-bandwidth general purpose applications.

Authors:

• Ehsan Salehi, Field Application Engineer, LDRA
• Stephen Di Camillo, Technical Marketing and Business Development Manager, LDRA

Title 10 U.S.C. 2446a.(b), Sec 805 states all major defense acquisition programs are to be designed and developed using a Modular Open Systems Approach (MOSA). The goals of MOSA include reducing the cost and time to deploy new technology, improving the ability to deliver technical upgrades, and improving interoperability among systems. While not explicitly stated in MOSA guidance, there is an implicit requirement that MOSA aligned systems must be safe and secure. Considering the rapid pace of technological innovation and understanding that most of this innovation is realized through software, it's imperative that MOSA aligned standards for software development and verification support compliance with safety and security best practices.

The Future Airborne Capability Environment™ Technical Standard (FACE™ Technical Standard) is one of the foremost MOSA aligned standards designed to promote portability and create software product lines across the military aviation domain. This paper will present several ways the FACE Technical Standard and technical practices, together with complementary software security standards and best practices, support the development of secure software.

Authors:

• Richard Jaenicke
• Green Hills Software

Advanced air combat training now relies heavily on digital technologies, with the ultimate goal of blending live, virtual, and constructive elements to provide the highest fidelity training. Some of the biggest challenges in advanced simulation and training include platform interoperability, timely upgrades to threat models, and the security of data and tactics used during training. A Modular Open System Approach (MOSA) can help with each of these.

• MOSA's objectives of rapidly deploying new technology and enabling interoperability of systems and mission integration directly address training challenges of interoperability and timely updates through standard application programming interfaces (APIs) applied at appropriate modular layers.
• Other standards such as the Common Criteria and Raise the Bar address security functionality and assurance, and can be used in combination with open API standards to field reusable components that meet common functional requirements.
• The Tactical Combat Training System Increment II (TCTS II) program is a prime example of an air combat training system that employs both MOSA oriented API standards, including the FACE™ Technical Standard, and security functional and assurance standards, including Raise the Bar.

Authors:

• Shaun Foley, Skayl, LLC.

Transport Protocol Modules (TPMs) are optional components within the Transport Services Segment (TSS) that handle lower-level interactions with the "outside world". This powerful abstraction has many uses but understanding it is confusing since different use cases have different expectations and implications for both the TPMs and their users. This paper describes two primary use cases for TPM uses: interoperating with another Transport Service implementation and integrating external components that are not FACE™ Units of Conformance (UoC).

The main architectural role played by TPMs is to isolate the mechanics of using a particular protocol from the Transport Service (TS) as a whole. TPMs allow the TS to adapt to unknown future protocols and to interoperate with other Transport Services. However, if a TPM supports Serialization Injection and modularizes its own low-level data access, then it can be easily extended to incorporate data from new external components without needing to modify portable UoCs.

This architectural segregation has a big impact on how and more importantly 'when' integration occurs. A TPM abstracts the protocol and data payload of a connected device or system. It also separates when the semantics of the data payload can be defined. It isn't until devices are integrated that one actually understands the semantics of the data the TPM is passing to the TS. By data modeling the data at the TPM interface, at the time of integration, the integrator can utilize TPMs to connect to devices and assign the semantics of the structured data the TPM produces. This separation of concerns is a key enabler of MOSA.

Authors:

• Daniel Finnegan, Technical Solutions Manager - TTTech North America
• Mirko Jakovljevic, Customer Solutions Architect – TTTech Auto AG
• Wolfram Zischka, Aerospace Product Manager - TTTech Computertechnik A

MOSA in its current form does an excellent job identifying the modular software and hardware frameworks required to establish an open architecture for embedded systems. However, it does not cover physical aircraft integration methodology or other constituent elements essential for the design of robust embedded systems. Open Ethernet interfaces are core system integration technologies that must be integrated and configured with other software/hardware framework elements to enable real-time application hosting. However, the system modularity and scalability required for incremental upgradeability can be impaired if the design, configuration, & integration methodology do not prevent unintended cross-functional interferences among SW functions. The ability to incrementally modernize and upgrade the system can be further impaired if care is not taken to ensure that the open standards being used truly ensure the interoperability of all hardware and software within the system.

This paper outlines relevant system integration topics that could impair "Boundaryless Information Flow" in an otherwise MOSA-conformant system. It reflects on system integration decisions which may limit the ability of the Government, OEMs, or Tier 1s to fully meet MOSA's objectives.

Authors:

• Chen Li, Technical Director, MQ-1C Ground Modernization, GA-ASI
• David Brown, Associate Director, Avionics, Collins Aerospace
• Jonathan Demildt, Associate Director, Avionics, Collins Aerospace
• Mike Hubler, Co-Founder and Chief Experience Officer, Tektonux

Army Aviation and the FACE™ Consortium are at the forefront of defining ready and actionable technical standards to support Modular Open Systems Approach (MOSA) efforts. MOSA done right means more capability and faster fielding at scale to maintain capability overmatch. As such, vendors are incentivized to be forward looking and collaborate to showcase reuse, portability, and rapid integration. GA-ASI, Collins Aerospace, and Tektonux demonstrated the power of open systems through rapid integration of Gray Eagle 25M Advanced Teaming capability into a Future Vertical Lift (FVL) representative environment as part of an overarching open systems demonstration supported by other partners as well. By building on top of a robust toolchain, reuse of FACE™ Units of Portability (UoPs), and maintaining a user-centered design approach, the team members quickly updated and integrated disparate FACE Aligned software components into a demonstrable advanced teaming system. This demonstration of open systems integration at scale and across partner vendors presented unique challenges and lessons learned beneficial to product managers, technical leads, and platform integrators. Additionally, model-based systems engineering and adherence to FACE principles supercharges teaming and interoperability between different FACE platforms, enabling boundaryless information flow. Standardization and portability of models defining key public interfaces revolutionizes interoperable capability development, integration, and fielding.

Authors:

• Dave Walsh, Vice President, Parry Labs
• Tony Adams, Solutions Architect, Parry Labs
• Mark Brown, Associate Director, Collins Aerospace
• Will Keegan, Chief Technology Officer, Lynx
• Chip Downing, Senior Director, RTI
• Scott Dennis, Chief Architect, U.S. Army Aviation & Missile Center
• Glenn Carter, Branch Chief, U.S. Army Aviation & Missile Center
• Alan Hammond, Steering Committee Chair, FACE™ Consortium

The US Army Aviation Enterprise is executing a transformation in how complex weapons systems are built collaboratively using a prescribed Modular Open System Approach (MOSA). To satisfy the Office of the Secretary Defense (OSD) guidance to use an Enterprise Architecture (EA), the Program Executive Office (PEO) Aviation is actively developing an Enterprise Architecture EA which provides common definitions, interfaces, and requirements for capability across the entire fleet of aircraft in the form of Major System Components (MSCs) and Modular System Interfaces (MSIs) contained within an Enterprise Product Architecture (EPA). The Program Executive Office (PEO) Aviation (AVN) Enterprise has identified an MSC titled, "Aviation Mission Computing Environment" (AMCE) and is developing its Component Specification Model (CSM). The AMCE CSM consists of configurable processing, Software Operating Environment (SOE), and software loading requirements. The PEO AVN Enterprise has determined that the resulting MSC developed by a supplier meeting the AMCE CSM shall "facilitate incremental deployment of capabilities".

This paper intends to draw attention to specific MOSA related benefits to be achieved in our industry. We propose definitions of software modules, operating system properties and key interface standards, with assumed use of the Future Airborne Capability Environment™ Technical Standard (FACE™ Technical Standard), for two distinct SOEs for the AMCE CSM: a mission system SOE, and a safety critical SOE.

Authors:

• Jonathan Craig Adams, AFLCMC, MDA/MBSE/DE Expert

The Department of Defense outlines its strategy for advancing Digital Engineering (DE) through a hand full of goals [D200]. Goal Five describes the necessity of transforming both culture and workforce – to address perhaps the greatest DE challenge the Air Force Lifecycle Management Center (AFLMC) undertook a pilot effort to model the SOSA™ Technical Standard Edition 1 [D201]. The pilot effort observes and suggests that transformation begins with understanding our current body of knowledge, current thinking and then applying innovative new practice(s) in order to realize DE goals. This paper describes how an innovative DE practice shifts thinking from communicating through requirements-based, document-based and/or current Model Based Systems Engineering (MBSE) approaches to an innovative approach, where architecture shapes requirements. Existing engineering practice most often approaches from requirements-based and document-based thinking, where requirements specify architecture. The innovative DE practice shifts thinking from communicating through requirements to communicating through architecture then requirements DE Goal One speaks of model formalization, integration and use. Another innovative practice, where architecture verifies and validates, focuses on The Open Group SOSA Sensor Reference Architecture (RA) model use, then its integration that builds upon architecture shaping requirements. Together, these two innovative practices, among others, ease integration from multiple vendors to meet the goals of nascent DE efforts within the DoD. The RA model integrates the Consortia Data Model, in order to type the structural model elements of the SOSA Sensor architecture that express its behavior and specifies its requirements. Integration and use of these models' better address the interoperability barriers to realizing continuous end-to-end representation of every SOSA Sensor acquisition across their lifecycle.

Authors:

• Benjamin Korzekwa, Moore Integrity Engineering
• Brandon Meiners, Moore Integrity Engineering
• Niraj Srivastava, Ph.D., Pacific Defense
• Michael Scott Moore, Ph.D., Moore Integrity Engineering

"Primary goals of The Open Group Sensor Open System Architecture™ (SOSA) Consortium include significantly shortening the time to field new sensor capabilities and reducing development and integration costs. To achieve these goals, the SOSA Consortium is developing the SOSA Reference Architecture and Technical Standard, which defines modular elements with open interfaces for integrating hardware and software components from different sources. Except for the SOSA Data Model, which is based on the Future Airborne Capability Environment™ Data Model Architecture (FACE™ Data Model), the SOSA Consortium has thus far defined and managed the SOSA Reference Architecture and Technical Standard using office documents and tools. With a large Technical Standard like SOSA, this is cumbersome and difficult to manage. The SOSA Technical Standard is transitioning to Model-Based Systems Engineering (MBSE) techniques for defining and managing the Reference Architecture and Technical Standard, but this transition will take time. To improve efficiency in the interim and to provide a proof-of-concept example SOSA System Management Subcommittee (SMSC) members have worked together to develop an initial cut at an MBSE-enabled process, models, and tools to realize the process. This realization will be used by the SMSC In-Band System Management team for defining and managing the system management related interfaces to SOSA Sensor Components (modules and infrastructure elements) until the SOSA architecture modeling approach and supporting tools have been completed. It is provided to the SOSA community to be used or adapted as needed."

Authors:

• Arlissa Vaughn, CEO, Aegis Power Systems Inc.
• Matt Van Steen, Senior Design Engineer, Aegis Power Systems Inc.
• Mark Peastrel, Senior Design Engineer, Aegis Power Systems Inc.
• Kyle Lamothe, Mechanical Engineer, Aegis Power Systems Inc.

Power supply module (PSM) testing backplanes are an efficient way to verify alignment with the Sensor Open System Architecture™ (SOSA) Technical Standard. The need for these tools increases as conformance requirements begin to emerge. In the pages that follow we will introduce the SOSA Technical Standard, its impact on PSMs, and focus on a commercially available testing backplane's ability to accelerate PSM integration. System developers, verification authorities, and component manufacturers leveraging the SOSA Technical Standard who seek to accelerate their integration timelines benefit from incorporating this tool into their process. Shortened development timelines, an agnostic vendor supply chain, automated in- process testing, and expedited mean-time-to-repair (MTTR) in the field are all benefits gained from the use of a backplane tailored to the SOSA Technical Standard. Because the tool assures a consistent data format, crucial PSM data from any vendor is made available to mission users for the life of the product.

Authors:

• Rafael J. García, Georgia Tech Research Institiute, ELSYS-AES, Open Systems Development Branch

The Open System Development Branch in the Electronic Systems Lab of Georgia Tech Research Institute (GTRI) has been working to produce a VITA 90 VNX+ Small Form Factor prototype in order to test the current progress of the standard and design methodology for Air Force Life Cycle Management Center (AFLCMC) and other government stakeholders. The prototype is built from an unfinalized version of VITA 90 and incorporates design suggestions from these stakeholders to drive design decisions. The main areas of investigation for this program are commercial-off-the-shelf (COTS) components integration, electrical design, mechanical/thermal considerations and front panel connectors. This document aims to inform stakeholders of the current integration hurdles and potential directions suggested to investigate or further develop in the standard

Authors:

• Patrick Rogers, AdaCore Inc.

This paper presents the use of static analysis as a means of automating the verification of source code conformance to FACE™ programming language capability sets. A specific static analysis technology for Ada is described. We then show how it can be used to automate the inspection activity, including especially those capability set restrictions that cannot be verified by a link-time test. The paper will be of interest to those concerned with conformance verification. Although the specific technology described is unique to Ada, the same principle of static analysis applies to the other programming languages supported by the FACE Technical Standard.

The material covered by this paper supports the OpenGroup vision of Boundaryless Information Flow™ by advancing the best practice for conformance verification.

Authors:

• Andre Odermatt, Principal Application Engineer, Real-Time Innovations (RTI

Redundancy is essential for ensuring safety, preventing catastrophic failures, and maintaining continuous operations. Mission-critical systems require high levels of redundancy to ensure operation in hostile environments or during emergencies. This paper explores redundancy of communication between different Portable Components Segment (PCS) and Platform-Specific Services Segment (PSSS) instances. Communication between the PCS and PSSS is handled by the Transport Services Segment (TSS). Redundancy is generally not formally addressed by the FACE™ Technical Standard. However, there are different ways redundancy can be achieved by choosing the right technology for the TSS – redundancy can then be handled by the integration software and the TSS, independent of the PCS and PSSS. Therefore, generic Units of Conformance (UoCs) can be used that do not need to be aware of redundancy and can handle messages from different sources.