Skip to main content

FACE SpecialEdition 2026

Page 1


To subscribe to the Avionics Design e-newsletter and Military Embedded Systems magazine and receive future copies of the FACE Special Edition, CLICK HERE.

To subscribe to The Open Group’s FACE E-newsletter, CLICK HERE.

FACE Consortium interview with Ron Vivacqua (top pic) and Kirk Avery (bottom pic), Lockheed Martin

Navy investing in MOSA strategies

The FACE Technical Standard: Enabling modular, open, and future-proof avionics systems

The UH-60 Black Hawk helicopter uses equipment aligned with the Future Airborne Capbility Environment, or FACE, Technical Standard, which enables a more open and modular enviroment for its digital cockpit.

In this photo, a UH-60R helicopter lands aboard the Arleigh Burke-class guided-missile destroyer USS Higgins (DDG 76). U.S. Navy photo by Mass Communication Specialist 3rd Class Trevor Hale.

Joe Richmond-Knight,
Dan Taylor, Technology Editor p.10

Editor’s Perspective

FACE Special Edition

Welcome to the 2026 FACE Special Edition, which covers the technology and development efforts behind The Open Group Future Airborne Capability Environment, or FACE, Technical Standard. This magazine is the fifth of what is an annual issue, highlighting editorial content on the FACE Technical Standard from the pages and website of Military Embedded Systems magazine, together with the products aligned and certified conformant to the technical standard – all put together exclusively by our staff.

This issue is similar to our SOSA Special Edition, published in May of each year covering the technology and innovation behind The Open Group Sensor Open Systems Architecture, or SOSA, Technical Standard. To read the SOSA Special Edition, visit https://tinyurl.com/2s478wnk.

Both the FACE and SOSA Technical Standards are examples of the modular open system approach (MOSA) strategy, mandated by the U.S. Department of Defense (DoD) for all new program designs and refreshes in a 2019 memo signed by the secretary of each service and reaffirmed at the end of last year by DoD leadership. MOSA is now law, codified in the National Defense Authorization Act for Fiscal Year 2017 (Public Law 114 –328). Section 805 of the Act (“Modular Open System Approach in Development of Major Weapon Systems”).

Momentum within the DoD for enacting acquisition reform and for adopting the MOSA approach will only accelerate adoptions of solutions certified conformant to the FACE Technical Standard.

The architects behind the FACE approach, the FACE Consortium has been around since 2010, making the FACE Technical Standard one of the more mature MOSA initiatives. Its relative longevity means there are many solutions certified conformant with and aligned to the FACE Technical Standard. For a list of these solutions, visit https://www.facesoftware.org/registry.

MOSA initiatives like the FACE approach help bring commercial innovation to the warfighter more quickly and with lower long-term life cycle costs.

“MOSA helps you address readiness,” Jason Thomas, told me in the Q&A on page 16. “It helps you address lethality by inserting technologies, commercial or otherwise, faster at the point of need, when our warfighters need it. It also allows us to then take additional benefits of cost savings and other areas of reuse that we want to proliferate and promulgate elsewhere.”

Thomas also details systems-engineering perspectives on MOSA and how MOSA strategies – with their flexibility and speed – can help the U.S. military win on the battlefield.

“Our ability to adapt quickly is directly tied to what capabilities, or modules, we can reliably field faster,” Thomas says. “Like any competition, the team that makes the right adjustments sooner and faster gives [itself] a better chance of winning. We’re seeing that with what modular open systems approaches can provide.”

One of the factors behind the FACE Technical Standard’s success is that its architects did not try to reinvent the wheel, but rather built the standard by leveraging more than 60 existing standards including ARINC 653, ARINC 661, OpenGL, and POSIX, according to Alicia Taylor, FACE Program Director, The Open Group during her presentation in the MOSA Virtual Summit earlier this year. To watch the sessions, visit militaryembedded.com/ webcasts/event/1321.

Organizations like the FACE and SOSA consortia also provide opportunities for nontraditional defense suppliers to do business with the DoD.

Members of both consortia dedicate many hours of their time to making the business case for MOSA. I recently moderated two webinars on this topic – one from each consortium. Check them out:

› Making the Business Case for the SOSA Approach (https://tinyurl.com/mry8w9jf)

› The FACE Approach: Cost Reduction through Portability and Interoperability (https://tinyurl.com/tp7fw9ey)

We will continue to cover MOSA and the FACE approach like we’ve covered open standards for more than four decades at OpenSystems Media, dating back to our first publication –VMEBus Magazine, still published today as VITA Technologies.

Helping bring this issue together were Alicia Taylor, Loren Baynes, Reggie Hammond, and their colleagues at The Open Group. A big thank you as well to Sally Bixby of SG2 and Rich Jaenicke of Green Hills Software, who helped in their roles with the FACE Outreach Subcommittee.

To be part of future FACE and SOSA Special Editions or to contribute content to Military Embedded Systems magazine, reach out to me (john.mchale@opensysmedia.com) and assistant managing editor Lisa Daigle (lisa.daigle@opensysmedia.com). Thanks for joining us.

Advertiser Index

5 DDC-I – Executive Speakout

5 Wolf Advanced Technology –Executive Speakout

12 Wolf Advanced Technology –Engineered for intelligence at the edge

15 LCR Embedded Systems –All systems go

19 DDC-I – Deos: Proven performance flying in tens of thousands of aircraft

24 The Open Group –The FACE Approach

Profile Index

ADVERTISER PG

Operating System Segment (OSS) DDC-I, Inc. 22

I/O Services Segment (IOSS)

Wolf Advanced Technology 23

About the FACE ® Consortium

GROUP EDITORIAL DIRECTOR John McHale john.mchale@opensysmedia.com

ASSISTANT MANAGING EDITOR Lisa Daigle lisa.daigle@opensysmedia.com

TECHNOLOGY EDITOR – WASHINGTON BUREAU Dan Taylor dan.taylor@opensysmedia.com

CREATIVE DIRECTOR Stephanie Sweet stephanie.sweet@opensysmedia.com

WEB DEVELOPER Paul Nelson paul.nelson@opensysmedia.com

EMAIL MARKETING SPECIALIST Drew Kaufman drew.kaufman@opensysmedia.com

WEBCAST MANAGER Marvin Augustyn marvin.augustyn@opensysmedia.com

VITA EDITORIAL DIRECTOR Jerry Gipper jerry.gipper@opensysmedia.com

SALES/MARKETING

DIRECTOR OF SALES Tom Varcie tom.varcie@opensysmedia.com (734) 748-9660

STRATEGIC ACCOUNT MANAGER Bill Barron bill.barron@opensysmedia.com (516) 376-9838

EAST COAST SALES MANAGER Bill Baumann bill.baumann@opensysmedia.com (609) 610-5400

SOUTHERN CAL REGIONAL SALES MANAGER Len Pettek len.pettek@opensysmedia.com (805) 231-9582

DIRECTOR OF SALES ENABLEMENT Barbara Quinlan barbara.quinlan@opensysmedia.com AND PRODUCT MARKETING (480) 236-8818

STRATEGIC ACCOUNT MANAGER Jill Thibert jill.thibert@opensysmedia.com

EUROPEAN ACCOUNT MANAGER Michael O’Kane michael.okane@opensysmedia.com

View the Consortium member list at https://www.opengroup.org/ content/future-airborne-capabilityenvironment-face/member-list. www.opengroup.org/face

The Future Airborne Capability Environment®, or FACE®, Technical Standard is a widely accepted, consensus-based open standard designed to promote interoperability and portability of software in avionics and other electronic systems. (https://www.opengroup.org/face)

www.opensysmedia.com

CO-PRESIDENT Patrick Hopper patrick.hopper@opensysmedia.com

CO-PRESIDENT John McHale john.mchale@opensysmedia.com

DIRECTOR OF OPERATIONS AND CUSTOMER SUCCESS Gina Peter gina.peter@opensysmedia.com

GRAPHIC DESIGNER Kaitlyn Bellerson kaitlyn.bellerson@opensysmedia.com

FINANCIAL ASSISTANT Emily Verhoeks emily.verhoeks@opensysmedia.com SUBSCRIPTION MANAGER subscriptions@opensysmedia.com

Modular by Design: Deos™ RTOS Enables Rapid Updates to the Warfighter through FACE® Conformance

Modular Open Systems Approach (MOSA) is a general directive for system design architectures whereas the Future Airborne Capability Environment®, or FACE®, Technical Standard takes this general approach and makes a specific blueprint to implement modularity for avionics. By following the FACE Standard, system designers can meet the MOSA requirement for DoD programs.

Key benefits of a modular approach and the FACE Standard are:

• The use of standards such as ARINC 653 and POSIX® enables functional partitions to be interchanged within a fielded system to upgrade existing functionality or add new functionality without redesigning the system. This design allows new capabilities to get to the warfighter faster.

• Increased system agility due to a vendor agnostic approach –you can incrementally update hardware and software from a variety of suppliers

• Interoperability between platforms due to a data-centric environment to connect communication nodes, sensors, displays and more

Advancing Open Architecture for Mission-Critical Systems

DDC-I’s Deos™ real-time operating system (RTOS) features a modular component-based architecture. This modularity extends to the file system and data distribution service components as well. This enables reuse of interface drivers, user applications and FACE UoCs across different field systems.

Deos supports independent upgrading of individual modules such as a new sensor interface, application upgrade or completely new capability without affecting the other components of the system. This architecture allows you to leverage the latest technical advances in hardware and software.

Reach out to talk with one of our experts!

www.ddci.com/FACE

The international expansion of the Future Airborne Capability Environment®, or FACE®, Consortium has significantly strengthened our ability to develop and deploy mission-critical applications across a broader range of platforms and programs. As adoption of the FACE Technical Standard has grown globally, we have seen greater alignment around open architectures and interoperability, enabling us to deliver solutions that integrate more efficiently across diverse operational environments.

From a mission-critical applications perspective, broader international participation has accelerated collaboration among airframers, platform providers, government agencies, and suppliers. This diversity of expertise helps ensure that the FACE Technical Standard continues to evolve in ways that address real-world operational requirements across multiple regions and defense programs. As a result, we can develop products with greater confidence that they will integrate seamlessly into multinational platforms and coalition environments.

The expanding global membership has also strengthened the business case for investing in FACE Technical Standard conformant solutions. Customers increasingly recognize the value of portability, reuse, and

reduced integration risk, and the growing international ecosystem provides a larger market for certified products and services. This enables us to leverage common architectures across programs while reducing development costs and shortening deployment timelines.

Most importantly, the Consortium’s international growth reinforces the long-term viability of the FACE approach. A larger, more diverse membership base drives innovation, encourages standardization, and fosters collaboration across the aerospace and defense community. That momentum ultimately benefits both suppliers and end users by delivering more capable, interoperable, and sustainable mission-critical systems.

FACE Consortium interview with Lockheed Martin leaders

Kirk

Senior Fellow, Airborne Mission Systems and Autonomous Technologies

Chief Architect, Lockheed Martin

Rotary and Mission Systems; Steering Chair of the FACE Consortium

The Open Group Future Airborne Capability Environment, or FACE, Consortium conducted an interview with Ron Vivacqua, Director, Integrated Engineering, Integrated Warfare Systems & Sensors, Lockheed Martin; and Kirk Avery, Lockheed Martin Senior Fellow, Airborne Mission Systems and Autonomous Technologies Chief Architect, Lockheed Martin Rotary and Mission Systems. (Avery is also Steering Chair of the FACE Consortium.)

Q: We understand Lockheed Martin has had significant contributions in these key tri-service programs: U.S. Army FLRAA [Future Long-Range Assault Aircraft], U.S. Army Sentinel A4, U.S. Air Force ARTS-V3, and NAVSEA [Naval Sea Systems Command] Crane EXBAR.

With the U.S. defense acquisition undergoing shifts per the DoW [U.S. Department of War] and driven by urgency to deliver new tech updates much, much faster to the warfighter, would you touch upon how or if Lockheed Martin is accelerating or altering your way of doing business that involves open standards?

VIVACQUA: Lockheed Martin is leaning hard into the DoW’s desire to go fast. Recently, Stephanie Hill, our SVP for Rotary and Mission Systems, had an interview with Politico, where she discussed examples of where we are generating proven capability at speed that is reliable, operationally ready, and mission-relevant. A key to this is active participation in the development, analysis, and alignment of open standards to ensure we’re producing reusable, portable, adaptable, and interoperable capabilities. A great example of this is the work happening with Golden Dome for America, where multiple OEMs are bringing capabilities together and rapidly integrating those capabilities at speed to create a unified defense system for the protection of our nation.

Q: Does Lockheed Martin have the FACE Technical Standard or the Open Universal Domain Description Language (Open UDDL) included in your strategic plan

in the next three to five years? Do you anticipate an upward trend using the FACE Technical Standard or Open UDDL [at] Lockheed Martin?

KIRK: Lockheed Martin products have been following open systems principles and open standards. Our product lines embrace design patterns required for component integration into a multitude of reference architectures and support alignment between disparate open standards, including alignment with versions within a given open standard. The FACE Technical Standard is one of the key open standards driving our software product lines. The Open UDDL standard is also driving our product lines but is more broadly applied across our platforms, including governing the key interfaces and data exchanges between modular hardware and software components of the holistic platform ecosystem. As part of the FLRAA program we are working collaboratively with our partners to utilize UDDL within the program model to fully define the cockpit and mission systems’ data exchanges. This provides consistent use of the domain-specific data model across the program enterprise to support the Army’s Enterprise Architecture Framework (EAF). This facilitates timely and affordable integration of future capabilities following defined open systems use cases and concepts such as the Digital Backbone Concept.

We do anticipate an upward trend in use of both the FACE Technical Standard and the Open UDDL standard as open standards mature across the DoW, commercial, and international customers. One of the key reasons for anticipating that growth

is the internal growth we have realized across the Lockheed Martin enterprise from the evolution, use, and deployment of open systems product-line components across our solutions using these and other open standards.

Q: The FACE Consortium has been strongly supported by Lockheed Martin since its inception in 2010. With your 30-plus years of increasingly impactful roles at Lockheed Martin, at what point (in what role) did you first become involved in influencing or advocating [that] the FACE Technical Standard be part of proposals and winning defense bids?

KIRK: The interesting thing is that we have been using open standards going back to the late 1980s. Certainly open systems approaches and open standards have evolved over time. Originally, we were focused on reuse and developing internally focused product-line engineering approaches. Over time our approaches and product lines evolved to support our evolving needs, but also followed new standards being released and embraced by our customers. Around 2010 the world of open standards was evolving, and our customers were driving focus on the holistic benefits of reuse. That drove industry to evolve our approaches and product lines to support those new external objectives. The FACE Technical Standard, along with other standards like OMS [Open Mission Systems], were critical to evolving MOSA to what it is today.

Lockheed Martin was part of the team that started the FACE Consortium as we had a vision of what we believed the future of the consortium could bring. Our involvement was primarily driven by aligned objectives. What we were doing internally, aligned to FACE Consortium objectives, and more importantly aligned to our customers objectives. As we actively participated in leadership and development of FACE Consortium artifacts –including the FACE Technical Standard – we saw the value it was having for our business and how it was affecting and meeting our customers’ needs. This drove the advocacy. The release of FACE Technical Standard Edition 1.0 and successful captures of programs requiring the FACE Technical Standard enhanced that advocacy.

Q: Do you envision a notable upward trend in defense or other market segments of open standards products in the next 12 to 24 months?

VIVACQUA: Absolutely. The threat landscape is changing more rapidly than ever, and our customers are looking for architectures that are relevant for the next 20 to 40 years. This requires hardware and software architectures that are flexible and sustainable, with upgrade paths that don’t require reliance on OEMs. Our business is committed to partnering with customers to bring these platforms to light.

Q: Please share what or how the FACE Consortium overall can expand or adjust its current work projects that may help increase acquisition and adoption. Is anything missing?

KIRK: My [position] is that adoption comes from belief. Belief in the standard and the associated ecosystem meeting the

objectives it was designed to provide. I also believe there are multiple areas of evolution that can support increased adoption.

The first area is international expansion. Expanding internationally will increase the providers developing solutions and increase the consumers of the solutions. Having more products meeting objectives and more consumers realizing those objectives will drive adoption and drive maturity.

The second area is standards alignment. There is and always will be a multitude of standards, and standards will continue to be developed. We need to embrace that fact and work to collaborate and transparently align with other standards. No one standard will ever drive a complete platform solution. Having the design patterns identified, described, and proven will drive adoption. Increasing our standards-alignment participants and increasing standards-alignment participation is a great first step.

The third area is conformance. The conformance program is too complex and too costly. The key red flag to all of us is that customers are not requiring conformance and the number of products in the FACE Registry is not at level showing use. We know that is not true, as so many across industry have products and product lines aligned to the FACE Technical Standard. Judging adoption by the number of items that have completed the certification process or the number of items in the registry is incorrect. We really need to focus on levels of conformance. Some products may lend themselves to the full certification process, others may not. Following a trust but verify approach allows consumers of the products to ensure they understand product alignment and maturity based on conformance artifacts – specifically requirements-verification matrices and conformance test suite execution. We need to let the market drive the conformance approach. Lastly, the conformance test suite deployment, use, and evolution needs refinement. This is a critical task of the newly formed Conformation Test Suite Working Group within the Consortium. Active participation in that group will be critical to success.

There are many other areas the FACE Consortium Steering Committee is currently discussing to help increase acquisition and adoption. Those require engagement of the members of the consortium and will really drive us to meeting expansion and adoption metrics and measures.

Q: Is there an avenue or mechanism [by] which other FACE Consortium members can connect with Lockheed Martin to inform (you) of their products or to open an initial discussion on specific opportunities to work together?

VIVACQUA: Lockheed Martin is always open to engaging and partnering on products that will assist in developing solutions to better serve our warfighter. As an integrator across four business areas (Aeronautics, Missiles & Fire Control, Space, and Rotary and Mission Systems), our number one job is to provide strong teams to develop and support platforms for the protection of our nation and our allies. This is only possible if we truly lean into a one-team mentality, not only internal to the company, but with our customers and our industry partners. ■

From legacy to leading edge: FACE and MOSA transform technology integration in defense avionics

As defense programs demand greater agility and cost-effectiveness, the Future Airborne Capability Environment, or FACE, Technical Standard and the modular open systems approach (MOSA) are providing program managers, systems integrators, and avionics architects with the architectural foundation for flexible, risk-reduced technology upgrades in military avionics.

The ongoing evolution of military aviation demands faster technology integration, greater cost control, enhanced security, and long-term adaptability. The Future Airborne Capability Environment, or FACE, Technical Standard and the modular open systems approach (MOSA) are at the heart of this transformation, providing the technical and conceptual foundation for modular, interoperable, and future-proof avionics. The FACE approach and MOSA enable risk-reduced integration, lower life cycle costs, and support secure and agile upgrades.

Investment for long-term advantage

The shift toward modular, open architectures is more than just a technical evolution. It is also a strategic investment with major implications for cost, risk, and operational flexibility for defense programs.

Implementing open standards like FACE and MOSA requires an initial investment in technical and organizational change. However, long-term savings and operational flexibility are substantial.

By decoupling platform architecture from functional logic, system providers can reuse certified modules across multiple projects, reducing vendor-lock-in and minimizing costly reintegration. The FACE Registry,

a publicly accessible marketplace for certified software modules, further amplifies these benefits by increasing visibility, accelerating procurement and fostering a competitive environment where both large and small vendors can participate equally.

These advantages extend well beyond the initial development stage. The clear separation of system modules facilitates easy replacement or upgrade of individual components. It enables parallel modernization and targeted integration of new technologies with minimal disruption. This approach streamlines maintenance, addresses hardware obsolescence, and keeps testing efforts and costs predictable. Thus, modernization becomes scalable and auditable, delivering tangible cost savings and operational readiness throughout the system’s life cycle.

Security architecture and multilevel security (MLS): Building trust into the system

As avionics systems become more interconnected and software-defined, security becomes mission-critical. Adopting a FACE approach addresses this challenge with a robust security architecture developed by the Security Subcommittee of the FACE Technical Working Group. The standard enables the integration of components with different security requirements and supports physical and logical separation via partitioning technologies such as ARINC 653.

A key focus is multilevel security (MLS), which allows modules with different classification levels, such as open navigation systems and classified mission algorithms, to coexist securely on shared hardware. The system’s resilience is further strengthened by secure communication interfaces in the transport services segment (TSS) and the ability to define dedicated policies for security-relevant data paths. Domain-specific security mechanisms, including data encryption and access control, can be implemented without compromising interoperability. This architecture, combined with standardized data models, meets stringent military requirements and is equally applicable to both critical infrastructure and civilian aviation.

Stock image.

Data exchange and compatibility:

The role of the TSS

One major advantage of the FACE standard is the flexibility of the TSS, which acts as a mediation layer between software components. The TSS can host middleware functionalities that go beyond basic data transport, including versioning, semantic data conversion, validation, and integration of messaging protocols.

This flexibility is particularly valuable for platforms with mixed-generation systems. For example, a modernized targeting system can access data from an older navigation module without requiring direct interface modifications. The middleware then acts as an adaptive layer that supports MOSA’s central objective of enabling technology updates independently of platform structure. This approach preserves architectural integrity and accelerates the pace of modernization.

The

FACE Registry:

Certification and marketplace

Building upon its role in terms of cost and innovation, the FACE Registry also reduces integration risk and sustains competitiveness through its rigorous certification process.

The FACE Registry is more than just a directory. It serves as a central hub where program managers, system integrators, and developers can discover, compare, and source certified Units of Conformance (UoC) with confidence. Each component listed in the registry undergoes a formal conformance process to ensure interoperability within the FACE architecture. This process provides assurance that only rigorously tested, standard-compliant modules are available for integration. Procurement and integration are streamlined, and trust is built across the defense avionics ecosystem.

The path to FACE conformance involves three stages:

1. Conformance Test Suite (CTS): Automated testing by the developer

2. Verification Authority (VA): Independent validation by authorized bodies

3. Conformance Authority (CA): Final certification and entry into the registry

By leveraging the registry, organizations can reduce integration risk, accelerate modernization, and maintain a competitive edge in a rapidly evolving market.

Common misconceptions about FACE approach

Despite its widespread adoption, there are still several misconceptions about the FACE Technical Standard. One common belief is that all software on a platform must be FACE aligned or certified conformant. In reality, the standard is primarily designed for interchangeable or reusable modules, not for every line of code. Another misconception is that the FACE approach guarantees performance. In fact, the standard defines interfaces to ensure interoperability, but it does not dictate the software’s functionality or speed.

Concerns about intellectual property are also often misplaced. Although the FACE standard promotes open interfaces, developers are not required to relinquish ownership of their proprietary technology. Intellectual property remains firmly with the creator. Additionally, some believe that the FACE standard is only relevant for new systems when, in fact, retrofitting existing platforms is a central goal of the standard. Finally, although initial implementation costs may be higher, the long-term benefits of module reuse and increased competition can result in significant cost savings over a program’s life cycle.

Empowering developers and architects

The successful implementation of the FACE approach and MOSA is supported by a wide range of tools and training resources. The BALSA reference project [The Open Group-supported Basic Avionics Light-weight Source Archetype environment], for example, provides a minimal, functional example environment that demonstrates how to build a simple but complete FACE compliant application. This is complemented by detailed documentation, guidelines for software vendors, integrators, and project managers, as well as regularly updated training programs. These resources are critical for steering projects in the right direction from the start and avoiding costly missteps.

Harmonizing standards for operational capability

Modern defense systems rarely operate in isolation. The continued advancement of open systems approaches requires the integration of various architectural standards into one overarching system. While the FACE approach modularizes and standardizes platform software, other standards like the Sensor Open Systems Architecture, or SOSA, Technical Standard and the Air Force Research Lab’s Weapon Open Systems Architecture, or WOSA, address specific domains such as sensors and weapons.

Successfully integrating the FACE approach, the SOSA Technical Standard, and WOSA requires harmonized data models and interface definitions. For example, integration enables a SOSA compliant infrared (IR) seeker to be leveraged as part of a WOSA missile system; the system then communicates with the mission computer of the carrier aircraft through FACE compliant middleware. Such end-to-end architecture supports modular upgrades, mission-wide interoperability, and multinational deployment scenarios, all of which are key factors for future-proof defense structures.

Going forward

In combination with MOSA, the FACE approach establishes a conceptual and technical basis for a new generation of open, maintainable, cost-effective, and secure avionics systems. These standards enable modularity, interoperability, and streamlined certification, thereby empowering defense programs to transition from legacy architectures to leading-edge capabilities. ■

Joe Richmond-Knight is regional sales manager at SYSGO and supports customers in the adoption of safety- and security-critical software architectures for embedded and avionics systems.

SYSGO https://www.sysgo.com/

Taking flight: A new era for rotary-wing avionics

Across the U.S. military and allied forces, rotary-wing avionics are being rebuilt from the inside out: new architectures, smarter sensors, and software-defined systems designed to keep pace with threats that evolve faster than hardware-refresh cycles can keep up with.

The helicopter cockpit has always been a crowded, demanding place – a collection of gauges, switches, and toggles that pilots spent years learning to read in seconds. That era is ending. Decades-old platforms like the Black Hawk and Apache are being asked to survive in environments their original avionics were never designed for – GPScontested, communications-degraded, and saturated with threats that can detect and engage a helicopter before its crew knows they’re being tracked. At the same time, a new generation of platforms is being designed from scratch around open architectures and softwaredefined systems.

The questions facing the defense industry on helicopter avionics are as much about process as technology: How do you modernize a cockpit that has to stay mission-ready while it’s being upgraded? How do you build security into hardware that will still be in service thirty years from now? And how do you

make open architecture a real, auditable engineering reality rather than a marketing claim?

Open architecture: from policy to program reality

A spokesperson with RTX (Arlington, Virginia) says investment in upgrades has been consistent and is accelerating across U.S. and allied platforms, and open architecture is a big part of that push.

“The primary drivers are addressing system obsolescence, accelerating adoption of modular open systems architectures, and enabling faster integration of new mission capabilities that improve situational awareness, interoperability, and overall mission effectiveness,” the spokesperson says.

The modular open systems approach (MOSA) began years ago as congressional direction, but today it has become the organizing principle for virtually every major U.S. military aviation program. For example, the Army’s Program Executive Office (PEO) Aviation has made MOSA the framework for affordability, readiness, and capability growth across its entire aviation portfolio, with FACE, or Future Airborne Capability Environment, Technical Standard and HOST [Hardware Open System Technologies] identified as foundational standards.

That policy language is translating into actual program decisions. The selection of RTX subsidiary Collins Aerospace (Charlotte, North Carolina) on the U.S. Army’s UH-60 avionics modernization effort is one example. The RTX spokesperson points to this pick as evidence of “growing customer demand for MOSA aligned solutions that can accelerate capability upgrades while reducing integration risk.” (Figure 1.)

U.S. Marine Corps photo of of V-22 Osprey tiltrotor aircraft by Lance Cpl. Nicole Stuart.

Boeing describes the AH-64E v6.5 upgrade path as the Army’s first MOSA compliant enduring aircraft, built around a more capable mission-system backbone for communications, navigation, sensor fusion, and future technology insertion. Bell, for its part, is making the same architectural argument for its MV-75 FLRAA tiltrotor, describing the platform as “built with MOSA” from the ground up.

Not every program is starting from scratch. The V-22 Osprey’s avionics story is the legacy-fleet version of the same challenge: The VeCToR cockpitmodernization program and flightcontrol computer redesign are framed primarily as obsolescence mitigation with a path toward more affordable future modifications rather than as a ground-up reinvention. The practical difference between a clean-sheet MOSA design and a retrofit MOSA compliance effort is sizable, but the defense industry is working hard to close that gap.

The challenge of integration

Talk to engineers working on helicopter avionics upgrades and you might be surprised by what they say keeps them up at night. The usual suspects – fitting new gear into tight spaces, sourcing parts, getting

hardware certified – are not actually the biggest obstacles, says Bill Dillard, senior business development manager for aerospace and defense at Microchip Technology (Chandler, Arizona).

“Modern avionics platforms offer significant size, weight, and power (SWaP) advantages and are supported by mature, dependable supply chains,” he says. “Certification is a well-understood and manageable level of effort.”

The real headaches, Dillard says, lie in getting power where it needs to go and making old and new systems talk to each other. Older helicopters were built around data formats and proprietary communication protocols that have no straightforward connection to modern digital systems.

“While converter solutions exist, they are typically suboptimal in terms of performance, complexity, and long-term maintainability,” he says. (Figure 2.)

The RTX spokesperson says that the core challenge is updating cockpits that were built as one-of-a-kind systems, without taking the aircraft out of service to do it. Open architecture, the spokesperson asserts, is how the industry is beginning to solve that problem.

Seeing through the fog

Solving the integration problem is only the starting point. Once new systems are on board, the question becomes what they enable – and right now, the capability the military wants most is the ability to keep flying and fighting when conditions turn against it. Dust storms, fog, smoke, darkness: the environments where helicopters have always been most vulnerable, and where the next generation of cockpit technology is most focused.

The Army’s Degraded Visual Environment Mitigation program and its follow-on effort are the most visible examples of this effort, combining infrared sensors, radar, and LiDAR to build real-time 3D terrain maps that pilots can use when their eyes can’t be trusted, according to an Army fact sheet.

The RTX spokesperson states that sensor fusion – combining data from multiple sources into a single picture for the pilot – is the technology closest to being widely adopted across the fleet. “It delivers immediate operational benefits without requiring a full platform redesign,” the spokesperson notes.

FIGURE 1 | Collins Aerospace’s Mosarc avionics architecture is a family of modular open systems products built around MOSA compliant computing, networking, displays, and software that is designed to enable rapid capability integration across military rotorcraft. Image via Collins Aerospace.

• 2070 FP4 TFLOPs AI Compute

• Embedded Blackwell GPU, with 2560 CUDA cores and 96 Gen 5 Tensor cores

• Multi-Instance GPU (MIG) support, two instances.

• 14-core Arm® Neoverse®-V3AE CPU, 2.6GHz

The new IGX Thor product line is engineered for high-performance edge computing in the most demanding environments. Built on NVIDIA’s IGX™ platform, Thor delivers powerful AI processing, real-time data handling, and rugged reliability, making it ideal for mission-critical applications.

WOLF’s boards—16T9, 16T5, 16T1, 16T0, and 16TZ—bring this performance to life, providing a robust and adaptable hardware foundation for advanced AI and autonomous systems.

The goal is not to have more screens but to present fewer decisions, a situation that gives pilots a cleaner, faster read on what’s happening around them.

Helmet-mounted displays are part of that sensor integration as well. Collins Aerospace’s Zero-G helmet is designed to put critical flight and mission data in front of a pilot’s eyes without adding to the physical strain of a high-workload mission. On the Apache, Boeing has been developing haptic controls and automated hold modes that reduce the mental and physical effort of flying in degraded conditions, according to Boeing documentation.

Across every program, the pattern is the same: the avionics takes on more of the burden so the pilot can focus on the mission.

Cybersecurity: built in, not bolted on

Open architectures create a cybersecurity challenge, however: The more interfaces a cockpit has, the more entry points exist for an adversary to exploit. Dillard says that Microchip’s answer to that problem starts at the chip level, before software ever enters the picture. “Hardware-rooted security is increasingly recognized as essential to avionics system integrity, with formal requirements now flowing into design and certification processes through DO-326A and DO-356A.”

Military helicopters can stay in service for 30 years or more, which makes the security situation more complex than it may initially look. A system that is secure today may not be secure against the threats of 2040. Quantum computing alone could eventually break encryption methods that currently seem impenetrable. Dillard’s solution is to build security into the silicon itself – a foundation that can be updated over time without replacing the underlying hardware.

“A strong, silicon-embedded security enclave establishes a durable root of trust and can be progressively strengthened through software and cryptographic upgrades as threat models evolve,” he says.

The Army’s own guidance on MOSA treats cybersecurity the same way – not as a feature to be added at the end, but as something that has to be designed in from the start, using established controls, according to an Army release. After all, an open architecture

FIGURE 2 | Microchip Technology’s PolarFire FPGAs [field-programmable gate arrays] and SoCs [systems on chip] provide security for avionics applications, combining supply-chain assurance, tamper resistance, secure boot, and cryptographic engines to protect hardware and data. Image via Microchip Technology.

that can be upgraded quickly is only an advantage if it cannot also be compromised quickly.

Cockpits as network nodes

The communications picture is changing fast as well. Helicopters are no longer just voice platforms, but are becoming data nodes in a broader tactical network as they share targeting information, sensor feeds, and situational-awareness data with ground forces and other aircraft in near-real-time. Marine Corps H-1 helicopters have already demonstrated the ability to operate on a mixed Link 16 and

CERTIFY IN THE LAB, THEN FLY

Getting new avionics onto a military helicopter is not just an engineering problem – it is a paperwork problem, but this paperwork exists for good reason. Flight-critical software has to be verified to standards that don’t move as fast as commercial technology does, and that tension between upgrade speed and testing rigor is one the industry has been working to resolve.

The answer, increasingly, is to do as much of the hard work as possible before an aircraft ever leaves the ground. According to Bell Helicopter its Weapons Systems Integration Lab brings together fly-by-wire controls, avionics, electrical systems, hydraulics, and mission systems under one roof for end-toend testing. Naval Air Systems Command (NAVAIR) engineers are working on the Common Systems Integration Lab, which does the same for cockpit upgrades, thoroughly verifying that new equipment works properly alongside the legacy systems it has to coexist with, according to a NAVAIR release.

Additionally, when Army, Bell, and NASA teams collaborated to evaluate the MV-75’s flight-control laws, they used a fullmotion simulator to work through handling qualities and control-law refinements before the aircraft flew a single hour.

The standards that govern this work – DO-178C for software, DO-330 for tool qualification, DO-297 for integrated modular avionics – are not obsolete. What is changing is how efficiently the industry can meet them.

The hybrid model that’s emerging from these trials uses commercial off-the-shelf (COTS) technology wherever the certification burden allows it, and keeps purpose-built, fully qualified designs where safety or mission requirements demand them.

The ultimate goal of all this: To speed up development without resorting to possibly unsafe shortcuts.

ANW2 network alongside ground stations, and the Navy’s CMV-22B added a high-frequency radio capable of communicating beyond line-of-sight without relying on satellite links, according to information from the Navy.

The RTX spokesperson frames this connectivity work as central to what customers actually want when they specify open, standards-based interfaces: The ability to plug into whatever network the joint force is running, now and in the future.

What’s coming next

The roadmap for the next several years is getting clearer. Bell’s MV-75 – the Army’s next-generation tiltrotor assault aircraft –reached a major development milestone when the Army accepted its first virtual prototype in June 2025, with first flight planned for 2026, low-rate initial production in 2028, and initial fielding in 2030, according to the Army. The MV-75 is the clearest statement yet of where U.S. assault aviation avionics are headed: open architecture, digital backbone, and a design built to accept new capabilities as they become available.

On the legacy or upgrade side, progress is also ongoing. In March 2026, the U.S. Army took delivery of the H-60Mx, a Black Hawk modified to fly with or without a pilot at the controls, integrated with Sikorsky’s MATRIX autonomy system, according to the U.S. Defense Advanced Research Projects Agency (DARPA).

The delivery is part of DARPA’s Aircrew Labor In-Cockpit Automation System (ALIAS) program, which looked “to create a highly automated system that could be integrated into existing aircraft to enhance mission flexibility and safety, particularly in complex and contested environments,” according to DARPA. Fully autonomous combat operations are not imminent, but the arrival of the H-60Mx shows that optional piloting has moved from a research concept to hardware the Army is actually testing.

fleets without taking aircraft offline for long periods. MOSA is what makes that possible: when systems are built around open, modular interfaces, a new radio or sensor can be swapped in without disturbing everything around it.

Dillard sees the same logic applying to security. Getting the architecture right from the start – open interfaces, modular software, hardware-embedded security – is what enables a helicopter’s avionics system to be relevant and protected across a service life that may span multiple decades and as-yet-unpredicted threat environments.

The cockpit of the future will not look like the one it replaced. It will be quieter, cleaner, and far more capable – and the work being done right now, on chips and data buses and software-partitioning schemes that most people will never see, is what will make that possible. ■

The spokesperson for RTX says the broader industry trend is toward upgrades that are smaller, faster, and lower-risk –changes that extend the life of existing

VPX, CMOSS, AND SOSA ARCHITECTURES IN ACCORDANCE WITH MOSA DIRECTIVES

U.S. Navy investing in MOSA strategies

Jason Thomas

Systems Engineering Lead for the Department of the Navy in the Office of the Assistant Secretary of the Navy for Research, Development, Test and Engineering

The modular open systems approach (MOSA) mandated by the U.S. Department of Defense (DoD) in 2019 for all new programs and upgrades has been embraced by all the services, including the U.S. Navy, which produced a MOSA Guidebook on how and why to implement MOSA. In this interview I conducted with Jason Thomas, Systems Engineering Lead for the Department of the Navy in the Office of the Assistant Secretary of the Navy for Research, Development, Test and Engineering, at the September 2025 MOSA Industry & Government Summit, we discussed the guidebook, the current momentum of MOSA strategies, and the benefits of MOSA from a systems-engineering perspective. We also explored common misconceptions regarding MOSA, metrics for measuring MOSA success, and what Thomas would like to from industry regarding MOSA. Edited excerpts follow.

MCHALE: Can you please share your experience in the defense industry and your role and responsibilities for the Navy?

THOMAS: I’m responsible for the posture of systems engineering for all naval systems. [When] I say Navy, that’s Navy and Marine Corps, naval. The naval portfolio really looks at air, surface, subsurface, C4I [command, control, communications, computers, and intelligence] systems, land, tactical communications system. System engineering [in the Navy] encompasses MOSA [modular open systems approach] architectures and digital engineering work, and I’m responsible for ensuring our policies, procedures, and guidance are aligned and supported across all those domains.

MCHALE: We are here at the MOSA Industry and Government Summit. So, let’s chat about MOSA. Why does MOSA have so much momentum in the defense community right now? How does it benefit the warfighter and how does it fit in with DoD leadership plans for acquisition reform?

THOMAS: I can’t mention or a comment in terms of policy or acquisition reform right now. I can speak to my observations and experience on this momentum shift. We’re seeing a big focus on warfighter response to rapidly evolving operational environments. Our ability to adapt quickly is directly tied to what capabilities, or modules, we can reliably field faster. Like any competition,

the team that makes the right adjustments sooner and faster gives [itself] a better chance of winning. We’re seeing that with what modular open systems approaches can provide. We’re also seeing a lot of guidance from SECNAV [Secretary of the Navy], from CNO [Chief of Naval Operations], and others on this impetus and this drive for fielding capabilities faster, leveraging commercial technologies, and broadening the industrial base to leverage big primes, traditional vendors, and nontraditional vendors to really deliver what our warfighters need.

MCHALE: I’ve heard discussions about a product your team is involved with in the Navy MOSA guidebook. What is the goal of the guidebook, and what are your plans for the next edition?

THOMAS: The goal of the guidebook is to really provide information to programs and some guidance where we saw a gap between what higher-level policy and intent [is], and at the execution level, “How do I do MOSA? What does that mean to me, and what do I need to consider?” Iteration 1 of the guidebook was released in January of 2025. [The guidebook was] necessary to really provide guidance to programs, PEOs, the workforce, and industry on how the DoN [Department of the Navy] is approaching MOSA implementation. The need was immediate; and our team did an incredible job coming together and delivering Version 1.

Version 2, which is set to release in early 2026, builds upon that effort and delivers more content and guidance to help programs, implement MOSA strategies, and realize what this type of approach can yield in terms of value for the warfighter and for the taxpayer.

Version 2 of the guidebook is going to include more guidance on contract language, specific information for program managers, details on the system-engineering technical reviews, acquisition gate reviews, different acquisition pathways, and [information] across the life cycle with all disciplines and domains represented to ensure that everybody can see themselves in MOSA. It’s not just for new programs or for mission systems – it shows a broad applicability and strategic approach to deliver lethal, ready warfighting capabilities.

MCHALE: I’m a publisher, so I want to know: What’s your distribution [strategy] on that? Do you send it to everybody when it’s done?

THOMAS: We send to Distribution A, which is for full public distribution.

MCHALE: MOSA is often talked about from a long-term, life cycle cost perspective, as it will enable more commercial innovation to leverage more quickly, thus reducing down times and upgrade costs. But what is your view of MOSA from a system-engineering perspective?

THOMAS: From my perspective, it’s really all about system engineering, and system engineering is really all about total life cycle performance and support. System engineering hits on architectures, requirements, and mission needs when and where we need them. How do we define and decompose our systems into modules or components? How do we select products or solutions that fulfill needs? How do we verify and field those functions and capabilities?

Additionally, how do we insert new technologies, and how do we do all that with a bounded trade space of cost, schedule, performance (i.e. delivery need dates)? We also have to consider those elements for today as well as the evolving threat environment that we’re dealt.

So really, MOSA helps you address readiness. It helps you address lethality by inserting technologies, commercial or otherwise, faster at the point of need, when our warfighters need it. It also allows us to then take additional benefits of cost savings and other areas of reuse that we want to proliferate and promulgate elsewhere.

So again, MOSA is an approach that ties in the technical and the business aspects. What’s important for planning MOSA, or planning a MOSA strategy, is understanding your current

LIKE ANY COMPETITION, THE TEAM THAT MAKES THE RIGHT ADJUSTMENTS SOONER AND FASTER GIVES [ITSELF] A BETTER CHANCE OF WINNING. WE’RE SEEING THAT WITH WHAT MODULAR OPEN SYSTEMS APPROACHES (MOSA) CAN PROVIDE.

needs of today, what may occur tomorrow, or what you’re looking at tomorrow, and what potentially may happen in the future so you can make the best decisions you can earlier, be more adjustable and adaptable.

MCHALE: What are some of the common misconceptions of MOSA that you come across?

THOMAS: From my experience, it’s approach versus architecture. Architecture is a fundamental and important part of your MOSA. Your architecture helps you define the system that you’re building, the capability that you can deliver.

The approach is really everything within data rights, tech data packages, contracting strategies, and much more. What work is organic? What work [needs to] leverage commercial bestof-breed technologies? What are my refresh rates, my update rates? How do I orchestrate a strategy that fuses the business and technical pieces together to deliver an effect?

Then leveraging various standards that are out there, some that are called out explicitly, like the FACE [Future Airborne Capability Environment] and SOSA [Sensor Open Systems Architecture] Technical Standards. Those standards help us with quality. Having good standards helps you define what quality you expect of those capabilities that are being fielded. I also don’t see enough conversations integrating our procurement

About the FACE ® Consortium

www.opengroup.org/face

The Future Airborne Capability Environment®, or FACE®, Technical Standard is a widely accepted, consensus-based open standard designed to promote interoperability and portability of software in avionics and other electronic systems. (https://www.opengroup.org/face)

View the Consortium member list at https://www.opengroup.org/content/futureairborne-capability-environment-face/member-list

brethren, our sustainment brethren, into those conversations. We really have to facilitate the value and the importance and stake they have in that. It’s not solely driven by architecture or standards, or, frankly, from engineering. And I say that as an engineer. It’s truly a team effort.

MCHALE: Some DoD leaders have called for more metrics on most of success to combat the naysayers. How would you describe or measure the success of a MOSA initiative?

THOMAS: Anything we do should provide value that helps the DoN advance in delivering for our sailors and Marines. One of the things I’ve noticed in conversations is the focus on cost. I’ve also heard some people talk about speed. I would suggest we focus the conversation on business value. This way it gives programs more flexibility to establish the MOSA strategy that best fits their needs, while our guidebook offers a multitude of things to consider to realize that vision.

[It starts with] understanding your value proposition for your weapon system or your system that you’re providing to the Joint Force with the DoN. Some things are legacy [and will need] to be sunset. So, it’s not smart or wise to adopt a MOSA strategy at that point. But you could still do rapid prototyping and rapid experimentation, and take advantage of those opportunities where it makes sense through those programs. They now become players that contribute at the strategic level instead of being neglected or minimized.

On the other side, if you’re a brand-new weapon system that’s being conceptualized or developed, that’s not your final state. It may be your final state when you deliver an IOC [initial operating capability], but it surely won’t be your final state. The first day after IOC, a program may start a modernization effort based on what’s been discussed or learned. You’ll have evolving threats, supply-chain issues that may arise, new technologies [that] will mature and present new opportunities, new algorithms that you want to take advantage of, and more. The program will have to pivot or adjust to meet new or evolving needs; some things were planned for while others were unforeseen. Systems engineers must consider these things for any system they support.

All that work, all that activity to produce a product and value still requires time and investment of resources to deliver. Having MOSA up front and early allows you to shorten those later evolutions and later activities. [Let’s say] your development for your acquisition program from conceptual to IOC is 10 years. Then you have an engineering exchange proposal, a modernization effort that’s going to be five years from the time that you define it and release a contract or RFI to when it’s fielded. That’s [now] 15 years from the start. If your MOSA is baked in early, potentially your modernization is going to be fielded at year 12 or year 13, or earlier if you can pivot before IOC. So, how we look at time has to be really well-understood in its totality. Same thing with budgets, cost, personnel, and skill sets.

Once we understand really the full life cycle and the full totality of what we’re talking about in terms of a MOSA, then you can start looking at those modules of activity, modules of work, modules of progress, modules of capability differently, and start decomposing and saying, where do I really get efficiencies? And that’s for a single program. When you start looking at portfolios and larger strategic efforts, you can get significant return in terms of data, sharing, testing, a myriad of other benefits on development, fielding, potentially again, defense industrial base, with other sources of repair, other sources of material that you don’t necessarily focus on or think about as a single program manager for a single program.

MCHALE: How do you look to further industry engagement and feedback for what you do at the Navy?

THOMAS: How do we become better partners in a multitude of areas: For example, in IP, data rights, technical data packages, different options for only releasing an RFI or an RFP. We (the government) may have something in our mind, predisposed to belief, structure, or approach that worked in the past, or didn’t work in the past. We may just not know any better that’s where we want to have better engagements and learn.

If there’s better approaches that are out there that we can take advantage of, different designs, different architectures, different technology, different business strategies, incentive structures,

that may appear we’re not in alignment with industry, but it’s only because we’re not informed. Help us understand better what we can do on that front. That’s just my personal opinion.

MCHALE: Looking forward, how do you see MOSA impacting DoD procurement five years from now, or even longer? Predict the future.

THOMAS: I think, between the high-level defense guidance that we’re all seeing, the priorities that are out there, the evolving threat environment, the economic landscape, all things that are happening globally, I think MOSA is going to be a key enabler to help address what the warfighter response is, as well as humanitarian responses to those activities that may occur.

But if we all look at it and say, I want a new app on my phone, okay, here you go. Now, I have different options for weather apps or finding a parking spot, or whatever it is, I have different opportunities. Why? Because of the standards that help you build to a particular capability or expectation, set of expectations, that you’re looking for. It’s the business and technical sides coming together seamlessly.

I think MOSA is a foundation of building blocks for all that we want to do going forward to be adaptable, responsive, lethal, and that strengthen the industrial base. It truly is a strategic imperative. ■

The FACE Technical Standard: Enabling modular, open, and futureproof avionics systems

In recent years, the accelerating pace of technological advancement in both military and civilian aviation has revolutionized avionics systems development. At the heart of this revolution is the standard known as the Future Airborne Capability Environment, or FACE, Technical Standard. In tandem with the modular open systems approach (MOSA), the FACE standard is laying the foundation for modern, open software architectures for airborne platforms. The FACE Technical Standard is not just another industry standard –instead, it represents a major departure away from monolithic, proprietary systems toward more open, modular, and reusable software components.

The Future Airborne Capability Environment, or FACE, Technical Standard was developed to help overcome ongoing challenges in integrating vendorspecific avionics systems that are difficult to maintain, resulting in high operating costs and making interoperability between systems difficult to achieve. Since 2019, U.S. law requires all major defense acquisition programs (MDAPs) to adhere to modular open systems approach (MOSA) principles and while there is no equivalent legal requirement in Europe, embedding modular procurement logic into tenders is increasingly becoming a requirement for national procurement agencies in Germany, France, and Italy. Many NATO countries are currently investigating how their own national projects can align with the FACE Technical Standard. Taken together, it is clear that MOSA has laid the strategic groundwork for open, networked, and future-proof international systems while FACE alignment will provide the concrete, verifiable software architecture implementations for technical airborne systems.

Alongside the FACE Technical Standard, the Open Mission Systems (OMS) framework and the Universal Command and Control Interface (UCI) have become established in military software architectures, while also becoming increasingly important in civilian aviation. There is no content overlap between the three standards, meaning they have the capacity to complement, rather than compete, with each other. In practice, an airborne platform can be built to be aligned with the FACE Technical Standard while also still using OMS architectures and UCI data interfaces.

Technical architecture of the FACE approach

The technical architecture of the FACE Technical Standard organizes software into five distinct segments:

› Operating System Segment (OSS)

› Transport Services Segment (TSS)

› I/O Services Segment (IOS)

› Portable Components Segment (PCS)

› Platform-Specific Services Segment (PSS)

Each component connects to the overall system through defined interfaces. For instance, OSS is a component within the FACE Technical Standard that Sysgo PikeOS can implement and ELinOS (a guest OS) can run within a FACE-compliant system.

The FACE Technical Standard defines three OSS profiles that customize operating system APIs, programming languages and features, runtimes, frameworks, and graphics capabilities to support software components with various levels of priority:

› Security: Limits OS APIs to a minimal yet functional set, enabling assessment of high-assurance security functions that run as a single process.

The General Atomics MQ-1C Gray Eagle Extended Range (GE-ER) is an uncrewed aerial system (UAS) designed for surveillance and weapons delivery. GA-ASI photo.

› Safety: Less restrictive than Security, it allows only OS APIs with a proven safety-certification pedigree.

› General Purpose: The least restrictive, supporting OS APIs for both real-time deterministic and non-real-time, nondeterministic requirements, depending on the system or subsystem operation.

The Shared Data Model also plays a central role, as it serves as the semantic foundation for all messages.

The FACE Technical Standard also uses a variety of established standards, including:

› ARINC 653 (partitioning for safety)

› ARINC 661 (cockpit displays)

› POSIX APIs (portability)

› OpenGL (graphics interfaces)

› Ada, C++, Java (programming languages)

By integrating these standards, the FACE approach becomes an interoperable platform that offers high flexibility for system integration developers. This model strongly supports typed data structures and ensures that position data, sensor readings, or status information are interpreted consistently throughout the avionics system.

Implementing the FACE approach opens up new opportunities

Implementing the FACE Technical Standard is an investment that delivers lasting value. While it requires initial technical effort, the payoff can be substantial – especially for system providers working across multiple platforms or planning long-term software product strategies. By separating platform architecture from functional logic, FACE alignment unlocks true reuse and modularity, enabling proven modules to be deployed across diverse projects without costly redevelopment. Standardized interfaces streamline collaboration with partners and subcontractors, accelerating integration and reducing risk. Perhaps most importantly, FACE conformance boosts market visibility, thereby positioning manufacturers to win more business by tapping into the public registry of certified modules and responding quickly to new tender opportunities.

The program provided developers with insights into how Army aviators plan and execute tactical missions using cutting-edge technology.

Aviation.

Alignment with the FACE Technical Standard also creates new opportunities for smaller and specialized software providers that were once shut out of large systemintegration projects and unable to compete with established prime contractors. Traditionally, the complexity of integrating proprietary systems acted as a barrier, but FACE alignment removes this obstacle. By clearly separating modules from overall system responsibilities, smaller companies can concentrate on delivering well-defined software functions, have them certified, and market them independently through the FACE Registry. This approach expands market access, lowers business risk, and fosters a more competitive environment – one where quality, innovation, and interface compliance matter more than entrenched customer relationships. These dynamics are especially promising in rapidly evolving fields such as artificial intelligence (AI), sensor fusion, and real-time systems.

The FACE Registry is the gateway to visibility, credibility, and new business opportunities. Acting as a publicly accessible “app store” for military software components, it enables program managers, system integrators, and developers to quickly find and compare certified Units of Conformance (UoCs). Every component listed has passed a rigorous certification process, guaranteeing seamless interoperability within the FACE architecture. For manufacturers, the Registry is more than a directory – it’s a direct channel to market. Certified UoCs and UoC packages can be showcased to the entire defense ecosystem, opening doors to new programs, platform integrations, and partnerships. With its standardized registration process, the FACE Registry turns certification into competitive advantage, making it easier than ever for high-quality solutions to stand out and win.

Making FACE aligned offerings safe and secure

Modern avionics systems are becoming increasingly interconnected, and the shift toward software-defined platforms has made security a critical priority. While the FACE Technical Standard is not itself a security-certification authority, it incorporated mechanisms early on to address security-critical requirements. The FACE Technical Working Group’s Security Subcommittee plays a central role in this effort, developing recommendations, security profiles, and integration patterns that enable components with differing security needs to function together within a FACE compliant system.

A key focus is multilevel security (MLS), which ensures physical or logical separation of modules with different classification levels when integrated on a shared computing platform. The FACE approach also supports the integration of domain-specific

FIGURE 1 | Representatives from multiple Army directorates participated in the simulated environment during the Special User Evaluation for the Future Long-Range Assault Aircraft (FLRAA) program, held during spring 2025.
Photo: Morgan Pattillo, Program Executive Office,

security measures, such as data encryption and access control, without compromising overall system interoperability. When combined with standardized data models, these measures deliver security that meets the highest military standards, making the FACE Technical Standard equally applicable to critical infrastructure and civilian aviation systems. From a safety perspective, the FACE approach does not replace existing standards, but rather complements them. Developers of FACE aligned safety-critical software can benefit from the use of modular architectures, isolated testing techniques, and automated verification. (Figure 1.)

Developers and architects adopting the FACE Technical Standard have access to more than just specifications and testing procedures; they benefit from a broad set of open tools, documentation, and training resources. A key resource is The Open Group-supported BALSA reference project, a minimal yet functional example environment that demonstrates how to create a simple, fully FACE confromant application. BALSA can serve as an ideal starting point for custom development, backed by comprehensive guidelines for software vendors, integrators, and project managers, along with regularly updated training programs. Delivered by the consortium or accredited partners, these courses serve both technical teams and decision-makers, covering topics from architecture modeling and data description to transport service integration and middleware. This knowledge base helps projects start on the right track and avoid costly missteps.

Going forward

Conformance to the FACE Technical Standard, together with MOSA, is paving the way for a new generation of open, maintainable, cost-effective, and secure avionics systems.

Deos™ Embedded Real-Time Operating System

Deos™ is a MOSA-aligned, time and space partitioned Real-Time Operating System (RTOS) which has been certified to DO-178 Design Assurance Level A (DAL A) since 1998. Developed from day one using DAL A plans and procedures, Deos features hard real-time response, industry standard ARINC-653 and Future Airborne Capability Environment, or FACE® , Technical Standard 3.1 Safety Extended/Safety Base Profiles, and shared resource partitioning to deliver the highest CPU utilization and performance in the industry.

Initially rooted in avionics, Deos use cases extend to ground vehicles, autonomous and crewed systems, weaponry and more. Unlike legacy RTOS solutions, Deos offers a modular approach, uniquely at the object code level, which isolates deterministic applications from changes when other modules are added, removed, or modified. This maximizes application and system component reuse resulting in reduced cost of change for system updates.

www.ddci.com/FACE/ DDC-I, Inc. www.ddci.com

sales@ddci.com

By aligning closely with laws, technical standards, and formal certification processes, it fosters a growing ecosystem that blends innovation with robust security. For stakeholders across both military and civilian aviation, the FACE approach represents a new paradigm in system development – modular, open, and built to stand the test of time. ■

Joe RichmondKnight joined Sysgo in 2022 as an FAE/ Solutions Architect. He is a member of the IET [the U.K.’s Institution of Engineering and Technology] and has a strong background in the use of embedded systems for the Internet of Things (IoT), as well as the design and implementation of complex data-acquisition systems.

Sysgo • https://www.sysgo.com/

Operating System Segment (OSS)

FEATURES

Ą MOSA, FACE Technical Standard, GCIA, and PYRAMID aligned

Ą Modularity & abstraction – enabling rapid upgrades

Ą Certified and flying in over 10,000 aircraft –ranging from control node to IMA

Ą Ultra-fast boot times

Ą Safety & Security – protected memory & cache, secure boot & networking, encryption, minimal attack surfaces, more

https://www.linkedin.com/company/ddc-i/

The WOLF-3184 DAL-C is a rugged FPGA-based video capture and transmission module designed for safety-critical aerospace and defense applications. Built around WOLF’s second-generation Frame Grabber eXtreme (FGX2) technology and the AMD/Xilinx Kintex UltraScale+ FPGA family, it delivers high-performance video processing, conversion, and transport with low latency, low power consumption, and deterministic operation. Developed in compliance with RTCA DO-254 Design Assurance Level (DAL) C requirements, the module is ideal for avionics, machine vision, sensor processing, and mission systems where reliability is critical.

The module supports multiple video interfaces, including up to four HD/3G-SDI inputs and outputs, two DisplayPort inputs with HBR2 and Multi-Stream Transport (MST) support, and a STANAG-3350C compliant RGsB input. FGX2 technology enables direct DisplayPortto-SDI conversion within the FPGA, eliminating unnecessary host processing and reducing system latency. Supported formats include 720p60, 1080p30, 1080p60, and 1080i60, enabling integration with a wide range of displays and sensors.

For embedded computing environments, the WOLF-3184 DAL-C provides a PCIe Gen3 x4 interface and aligns with ANSI/VITA 46.9 I/O mapping standards for both 3U and 6U VPX platforms. The module can also be paired with NVIDIA GPU-based solutions to enable ultra-low-latency peer-to-peer data transfers, reducing host CPU overhead and accelerating real-time processing workloads.

Designed for harsh environments, the module features rugged conduction-cooled construction, operates from -40°C to +70°C as standard, and supports extended operation up to +85°C. It meets demanding shock and vibration requirements while maintaining power consumption below 15 watts. Linux drivers are supported, with optional Windows, VxWorks, and Green Hills INTEGRITY-178 support available. Manufactured under AS9100D and ISO 9001:2015 quality systems, the WOLF-3184 DAL-C delivers a reliable, long-life video I/O solution for mission-critical airborne and defense platforms.

FEATURES

Ą DO-254 DAL-C Certified for safety-critical aerospace and defense applications.

Ą WOLF Frame Grabber eXtreme 2 (FGX2) architecture for high-performance video capture, processing, and transmission.

Ą AMD/Xilinx Kintex UltraScale+ FPGA delivers deterministic, low-latency video processing and conversion.

Ą Up to four HD/3G-SDI inputs and outputs for flexible multi-channel video integration.

Ą Dual DisplayPort inputs supporting HBR2 and Multi-Stream Transport (MST), with up to two streams per input.

Ą Direct DisplayPort-to-SDI conversion performed entirely in hardware, eliminating host CPU involvement and reducing latency.

Ą STANAG-3350C compliant RGsB input enables support for legacy and military video sources.

Ą PCIe Gen3 x4 interface provides high-bandwidth data transfer to embedded processing systems.

Ą ANSI/VITA 46.9 compliant I/O mapping for seamless integration into 3U and 6U VPX architectures.

Ą Rugged conduction-cooled design with operation from -40°C to +70°C standard (up to +85°C), plus high shock and vibration tolerance.

Ą Low SWaP profile with power consumption under 15W and support for Linux, Windows, VxWorks, and Green Hills INTEGRITY-178 operating environments.

https://wolfadvancedtechnology.com/products/xmc-fgx2-vio-do254wolf-3184-dal-c/

Turn static files into dynamic content formats.

Create a flipbook
FACE SpecialEdition 2026 by OpenSystems Media - Issuu