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.
Gray Eagle 25M’s open architecture allows easy implementation of [the]
[Technical Standard] across control interfaces, avionics, and datalinks, and provides the ability to integrate a customizable suite of multi-INT sensors providing the stand-off survivability with stand-in capability required for multi-domain operations. Photo courtesy of General AtomicsAeronautical Systems, Inc. (GA-ASI).
Gold Sponsor
7 TES-i/Tucson Embedded Systems –Executive Speakout
13 TES-i/Tucson Embedded Systems–Helping You Realize the Promise of MOSA Through the FACE Approach
7 Abaco Systems –Discover Abaco. SBC3513L. TSN Capabilities
9 LCR Embedded Systems –Mission possible: VPX And SOSA aligned solutions for any mission
12 RTI – RTI Connext TSS
3 The Open Group –The FACE Approach
WEBCAST
MOSA Virtual Summit 2024: Applying open architectures in avionics, radar, EW, and C5ISR systems
Watch keynote address and separate sessions: https://tinyurl.com/2dbn4jcc (This is an archived event.)
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
By John McHale, Editorial Director John.McHale@opensysmedia.com
Welcome to the 2024 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 third 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 each year covering the technology and innovation behind The Open Group Sensor Open Systems Architecture – SOSA –Technical Standard.
Many industry and government organizations are members of both the FACE and SOSA consortia. While the FACE Technical Standard is the more mature of the two standards, they are both successful examples of a 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.
Since then, MOSA has taken off as a concept and been embraced by all tiers of the defense industry, with the FACE Consortium helping pave the way. The FACE approach was being adopted long before issuance of the memo, as the Naval Air Systems Command was an early adopter of the standard.
“PMA 209 was an early adopter [of] FACE [Technical Standard],” says Capt. Jarrod Hair, U.S. Navy, Program Manager for the Navy’s Air Combat Electronics Program Office (PMA-209) on page 10 of this issue. “Since then, we’ve been working on other open architectures.
[The standard] was incubated in NAVAIR and kicked off in 2010 – which is when the FACE Consortium took it over.
“From the warfighter, aircrew-type perspective, they don’t see whether something is developed using MOSA or other strategies,” Hair continues. “But what’s important to the warfighter is to be able to have high-quality equipment, highquality gear that keeps up the pace of technology [insertion] that we need, so the warfighter gets it in a timeline that’s relevant. Those are items that we can reach better with a MOSA-type solution because that enables us to both compete those to get best-of-breed [solutions] for fielding the equipment and allow us to do that integration and fielding faster.”
Since those early years, solutions certified conformant and aligned to the FACE Technical Standard are being leveraged in aviation platforms such as the Army’s UH-60V Black Hawk helicopter (featured in last year’s FACE Special Edition).
New uncrewed platforms are also leveraging MOSA and the FACE approach, like the Gray Eagle 25M from General Atomics-Aeronautical Systems Inc. (GAASI). “The Gray Eagle 25M’s Open Architecture allows easy implementation of [the] FACE [Technical Standard] across control interfaces, avionics, datalinks, and provides the ability to integrate a customizable suite of multi-INT sensors providing the stand-off survivability with stand-In capability required for multi-domain operations,” according to a GA-ASI release. (See the Gray Eagle 25M on our cover).
Along those lines, Parry Labs is providing the Gray Eagle Miniature Mission Interface (GEMMI) for integration with the MQ-1C–25M aircraft as part of a contract with the U.S. Army Product Manager
Office Endurance Unmanned Aircraft Systems (PdM EUAS) “to facilitate the transition and initial fielding of GEMMI for the MQ-1C Program of Record,” according to a Parry release. The program’s command and control software will be upgraded under the Ground Modernization Software Suite (GMSS), which will leverage a MOSA [strategy] “using a government-owned and provided system architecture (that will instantiate the first FACE conformant Units of Portability (UoPs) for PM UAS.”
Such examples add to the momentum of the FACE Technical Standard and the FACE Consortium. “The Consortium continues to do amazing work enhancing and maturing the Technical Standard and the business processes around it,” says Alan Hammond, chair of the FACE Steering Committee in a Q and A on page 6.
As MOSA approaches like FACE and SOSA continue to thrive, we will continue to cover them 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, Reggie Hammond, and their colleagues at The Open Group. A big thank you as well to Sally Bixby of Precise Systems 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 and our Avionics Design e-newsletter, reach out to me (john.mchale@opensysmedia.com) and assistant managing editor Lisa Daigle (lisa.daigle@opensysmedia.com). Thanks for joining us.
Q and A with Alan Hammond, Chairperson of The Open Group FACE Consortium
THE OPEN GROUP: What prompted you to accept the nomination for Chair to the Steering Committee?
HAMMOND: The last 10 years of my career of working on aviation platform integration efforts has been significantly impacted by the work of the FACE Consortium. It has had such a positive impact on the acquisition and development of aviation software and how we now think about the entire software life cycle. After spending the past year with the Steering Committee, I am impressed with the dedication of so many companies and individuals willing to give of their time and resources to advance such this worthy endeavor. Knowing the effort and dedication of the people supporting the various committees and working groups, being nominated to chair the Steering Committee was really an honor, so accepting the nomination was a nobrainer for me.
THE OPEN GROUP: How do you see the future of the FACE Consortium?
HAMMOND: The Consortium continues to do amazing work enhancing and maturing the Technical Standard and the business processes around it. As we continue to gain international participation, the work of the Consortium will provide even greater value to the aviation industry and government partners for years to come.
THE OPEN GROUP: What do you hope to accomplish in the next year as FACE Steering Committee Chair?
HAMMOND: Primarily, I want to keep the Consortium moving the direction it has. We have been moving in a very positive direction for a long time and doing
really good work. I do want to see the MBSE [model-based systems engineering] work come to fruition with a released Consortium product. With the DoD and industry movement to digital engineering, this will be one of most useful products for supporting future developments and [it] better integrates into the digital processes. I think it is also important to continue to clarify requirements in a way that is meaningful for an improved conformance program. Finally, I would like to see more dedicated attention to address real and perceived barriers to major version adoption, especially as it pertains to airworthiness recertification or reuse.
THE OPEN GROUP: How aggressively would you like to see corporate membership expand from the four new countries (Australia, Canada, New Zealand, and the United Kingdom)?
HAMMOND: Gaining traction with strategic partners is a key strategy to growth of FACE adoption. This will significantly increase the pool of customers for our industry base as well as provide the additional competition that our government needs to fully realize its MOSA business objectives. As such, I believe the Consortium should be very aggressive in expanding corporate membership within this group of allied nations.
THE OPEN GROUP: Do you think membership should be expanded to more countries, and what would be a rough time frame for doing that?
HAMMOND: Expanding the pool of participants will motivate more companies, home and abroad, to adopt our standard. Our current focus remains expanding corporate participation in Australia, Canada, New Zealand, and United Kingdom.
THE OPEN GROUP: Should the FACE Consortium see greater alignment with European avionics open standards like PYRAMID, and what are the mechanisms to do so?
HAMMOND: Absolutely. It is imperative that we align with European avionics open standards.
Alan Hammond is a Technical Fellow with John H. Northrop & Associates, Inc. (JHNA) supporting U.S. Army Program Executive Office (PEO) Aviation (AVN) as the Architecture Development Lead within Assistant PEO (APEO) Engineering & Architecture (E&A). He provides subject-matter expertise to the Chief Technical Architect and leads the definition and development of the PEO AVN Enterprise Architecture and its guiding framework. He additionally represents PEO AVN within the Future Airborne Capability Environment, or FACE, Consortium as the Steering Committee Chair. Alan has 24 years of experience in product development, science and technology, and acquisition for U.S. Department of Defense programs in the areas of radar, environmental effects, missile defense, modeling and simulation, force tracking, and aviation.
FACE Consortium https://www.opengroup.org/face
The Promise of MOSA is Realized through the FACE® Approach
By Sean Mulholland, President/Co-founder of TES-SAVi (SAVi) –Tucson Embedded Systems (TES-i) subsidiary
The Open Group FACE® Consortium Technical Standard is key to realizing program modular open systems approach (MOSA) technical and business objectives for mission- and flight-critical software. Specifically, FACE conformant software components have achieved reduced integration effort and schedule by:
• Enabling efficient modifications to support continuous delivery of capability (Adaptability)
• Enabling faster fielding of innovations (Overmatch)
• Reducing total lifecycle affordability and resiliency (Competition)
• Increasing interoperability; reducing qualification and sustainment burden; and complying with all statute, policy, and regulatory requirements (Commonality)
The FACE Technical Standard continues to improve vertical system integration through enhancements to its operating system (OS) and I/O API abstraction. These features enable portability and component reuse across different hardware platforms.
Further, horizontal integration, i.e., exposure and/or resolution of differences in component to component message and data exchange semantics, is addressed through features of the FACE Transport Service Segment (TSS) and FACE Data Architecture. These features enable integrations of components with identical message semantics, varying but semantically identical message semantics, and even support transformation/mapping between semantically dissimilar messages. Planned and opportunistic reuse of existing software components and the addition of new and more advanced capabilities to an existing weapons system is achieved.
Simply put, the promise and benefits of MOSA are significantly and effectively realized by leveraging the FACE Technical Standard as part of the overall systems architecture.
www.TES-SAVi.com
About the FACE ® Consortium
www.opengroup.org/face
The Open Group FACE® Approach integrates technical and business practices that establish a standard common operating environment to support portable capabilities across avionics systems.
The modularity defined in the FACE Approach enables an agile environment for firms to respond to market and customer demands for capability changes and upgrades. Industry has proven its commitment to the success of the FACE Approach by completing FACE conformance certification for its products. This enables military programs to rapidly select precertified software modules to reduce design, integration, and conformance costs for all programs requiring FACE conformance.
FACE SPONSOR
Air Force Life Cycle Management Center
https://www.afrl.af.mil/
Collins Aerospace
https://www.rockwellcollins.com/
Joint Tactical Networking Center https://www.jtnc.mil/
Lockheed Martin
https://www.lockheedmartin.com/ NAVAIR
https://www.navair.navy.mil/
U.S. Army PEO Aviation
https://www.army.mil/PEOAviation
FACE PRINCIPAL
AdaCore
https://www.adacore.com/ BAE Systems Inc.
https://www.baesystems.com/
Bell
https://www.bellflight.com/
Boeing
https://www.boeing.com/ Cubic Corporation
https://www.cubic.com/ Elbit Systems of America
https://www.elbitamerica.com/
GE Aviation Systems
https://www.geaviation.com/
General Dynamics
https://www.gd.com/ Honeywell Aerospace
https://aerospace.honeywell.com/ L3Harris
https://www.l3harris.com/ Leonardo DRS
https://www.leonardodrs.com/
Mercury Systems
https://www.mrcy.com/ Northrop Grumman
https://www.northropgrumman.com/
Parry Labs, LLC
https://parrylabs.com/
RTX
https://www.rtx.com/
Sierra Nevada Corporation https://www.sncorp.com/ Sikorsky Aircraft https://www.lockheedmartin.com/en-us/ capabilities/sikorsky.html
U.S. Army Combat Capabilities Development Command Aviation and Missile Center https://www.army.mil/article/157845/ ccdc_aviation_missile_center
Wind River https://www.windriver.com/
FACE ASSOCIATE
AeroVironment
https://www.avinc.com/
Aitech
https://aitechsystems.com/
Alta Data Technologies, LLC https://www.altadt.com/ Ansys
Defense Standardization Program Office https://www.dsp.dla.mil/ ENSCO Avionics https://www.ensco.com/ EXB Solutions https://exbsolutions.com/ Galois https://galois.com/ GaN Corporation https://www.geeksandnerds.com/
General Atomics https://www.ga.com/
General Micro Systems, Inc. https://www.gms4sbc.com/
Georgia Tech Research Institute https://www.gtri.gatech.edu/ Green Hills Software https://www.ghs.com/ Infinite Dimensions Integration, Inc. http://id-inc.us/
Integrated Solutions for Systems, Inc. https://is4s.com/
Intelligent Artifacts, Inc. https://www.intelligent-artifacts.com/ Intellisense Systems, Inc. https://www.intellisenseinc.com/ Inter-Coastal Electronics, LLC
The QT Company https://www.qt.io/ Trideum Corporation https://www.trideum.com/ TTTech North America, Inc. https://www.tttech.com/ TurbineOne https://www.turbineone.com/ Twin Oaks Computing, Inc. http://www.twinoakscomputing.com/ United Electronic Industries, Inc. https://www.ueidaq.com/
University of Dayton Research Institute https://udayton.edu/udri/ Verocel
https://www.verocel.com/ ViaSat, Inc. https://www.viasat.com/ wolfSSL https://www.wolfssl.com/ Wolf Advanced Technology Canada Inc. https://wolfadvancedtechnology.com/ Wolf Advanced Technology USA Inc. https://wolfadvancedtechnology.com/ ZDEN Technologies LLC https://www.zden.tech/
**List as of 7/29/2024
Mission impossible
VPX AND SOSA ALIGNED SOLUTIONS FOR ANY MISSION
LCR products enable the fullest capabilities of the best aspects of VPX and SOSA aligned system architectures. Integrated systems, chassis, backplanes and development platforms that help streamline the journey from early development to deployment.
Look to LCR to realize what’s possible in demanding environments across a wide range of defense applications.
NAVAIR leveraging MOSA in avionics systems
By John McHale, Group Editorial Director
Jarrod Hair
U.S. Navy, PMA-209 Program Manager
The U.S. Navy’s Naval Air Systems Command (NAVAIR) was an early adopter and supporter of the Future Airborne Capability Environment, or FACE, Technical Standard and is at the forefront of open architecture development and leveraging modular open systems approach strategies (MOSA) in Navy avionics applications. During the MOSA Summit & Expo I sat down with Capt. Jarrod Hair, U.S. Navy, PMA-209 Program Manager, where we covered how NAVAIR leverages MOSA initiatives like the FACE standard, the challenges with data rights, and how the defense community – government and industry – is embracing MOSA. Along those lines, at the NAVAIR booth at the expo, Capt. Hair hosted keynote speaker Hon. Nickolas Guertin, where he led an interactive discussion elaborating on current MOSA efforts in his role as Director of Operational Test and Evaluation. Guertin is a White House nominee for Assistant Secretary of the Navy for Research, Development, and Acquisition. Edited excerpts of the interview are below.
MILITARY EMBEDDED SYSTEMS: Please tell me about your role as Program Manager for the U.S. Navy’s Air Combat Electronics Program Office (PMA-209).
HAIR: I started flying helicopters. First, the SH-60B, then flight test, and then went back out to the Fleet to fly the MH-60R. I gained a great deal of experience actually using NAVAIR [Naval Air Systems Command] systems. The test time was a great bit of insight into how we develop and look at some of those systems. [It] was awesome going back out to the fleet with that experience. After my department-head tour, I wanted to get back into that side of the Navy and how we develop, acquire, and field systems. So that brought me back into NAVAIR and I’ve been in various program offices here since 2015.
Most recently, I was in the Pentagon under ASN RDA [Assistant Secretary of the Navy (Research, Development and Acquisition)] staff, which gave me good insight across the portfolio for naval aviation systems. [After that], I was fortunate enough to get picked up for PMA-209, which the Air Combat Electronics program office. We cover a very broad spectrum of systems that go across naval aviation platforms.
We also have systems in other services [such as] the Air Force, and domestic federal agencies as well. Our systems are primarily focused around the flight school basics of “aviate, navigate, communicate.” For the “aviate” part we have safety of flight systems such as TAWS [Terrain Awareness Warning System]. For “navigate” we
have Tactical Air Navigation (TACAN), Required Navigation Performance Area Navigation (RNP RNAV), and Tactical Air Moving Map Capability (TAMMAC), and for “communicate” one of the big ones is the ARC 210 radio.
One of the newer areas we are working is the DI MANGL, which stands for Digital Interface (DI) MAGTF Air Network Gateway Link (MANGL). MAGTF stands for Marine Air Ground Task Force.
DI MANGL is a situational-awareness enhancer for the Marine Corps using a tablet device and radios that connect the user to a tablet device and to other users in the network.
MILITARY EMBEDDED SYSTEMS: Is that like a JADC2 [Joint All-Domain Command and Control] concept?
HAIR: It’s similar in concept, but it’s not directly connected. [With MANGL] we take different networks and mesh those together with the Gateway link. Then we transmit that to a tablet so the Marines in the air and on the ground can have the same overall situational awareness.
MILITARY EMBEDDED SYSTEMS:
How does NAVAIR work with the Future Airborne Capability Environment (FACE) Technical Standard and when did you adopt it?
HAIR: PMA 209 was an early adopter [of] FACE. Since then, we’ve been working on other open architectures. FACE was incubated in NAVAIR and kicked off in 2010 – which is when the FACE Consortium took it over.
Since adoption, we have ventured more into the open architecture side. One of our efforts within PMA 209 is for the mission computer alternative (MCA), which is a family of governmentdeveloped organic mission computers that are open architecture [where] we own all the data rights and we can size the capabilities to the needs of platforms that we work with.
MILITARY EMBEDDED SYSTEMS:
The FACE Technical Standard has provisions for safety-certification standards such as DO-178C. How does NAVAIR leverage safetycertification standards like DO-178C and DO-254 in their avionics s ystems? Do you require it?
HAIR: The technical warrant holders at NAVAIR System Safety and Airworthiness don’t strictly require DO-178 or DO-254, as they use the Military Standard (MIL-STD) 882 Level of Rigor processes to establish design assurance for software and complex electronic hardware. However, because the civil and military standards have so much in common, they can, and do, leverage DO-178/254 certifications and artifacts, in part or whole, to satisfy airworthiness requirements for avionics systems. That being said, at this time we at PMA-209 are still working with the technical warrant
holders on finding ways to reap the benefits of the FACE Technical Standards for the applicable safety-certification standards.
MILITARY EMBEDDED SYSTEMS: I heard the data-rights part discussed at the MOSA [modular open systems approach] Summit and Expo in Atlanta. What does that mean from a government and industry perspective? Why is that so important?
HAIR: With that specifically? The normal model in defense acquisition is the private companies develop systems, they develop equipment, we give our requirements, and they develop items to meet our requirements. We buy the parts, the systems, but we don’t necessarily get all of the data behind those such as the software/hardware information to be able to do the engineering – the actual in-depth remanufacturing needed to be able to do that.
[Data rights] is a piece that I’m learning more about in my role here at PMA-209. What I’d like to evaluate with data rights is where the right level is, as I also understand industry perspective – wanting to keep their proprietary information to themselves. But we need enough information to be able to fully integrate the systems and then recompete for upgrades to address obsolescence as necessary. When leveraging open architectures, if we can get the information we need at the right interface level, we can compete that box or recompete it. Maybe there’s a middle ground there, where we don’t always need to have all of the data.
MILITARY EMBEDDED SYSTEMS: From your perspective as a Navy pilot and an engineer: Why are most strategies important and what benefits do those things like FACE and SOSA [Sensor Open Systems Architecture] bring to the warfighter?
HAIR: From the warfighter, aircrew-type perspective, they don’t see whether something is developed using MOSA or other strategies. But what’s important to the warfighter is to be able to have high-quality equipment, high-quality gear that keeps up the pace of technology [insertion] that we need, so the warfighter gets it in a timeline that’s relevant. Those are items that we can reach better with a MOSA-type solution because that enables us to both compete those to get best-of-breed [solutions] for fielding the equipment and allow us to do that integration and fielding faster.
Beyond that, we’re going to continue the MOSA work PMA 209 has been doing well before we got there, which is working with our counterparts in the Army and the Air Force. We’re reaching out to industry and being a part of the overall MOSA effort moving forward so that we can collaborate within the tri-services.
MILITARY EMBEDDED SYSTEMS: There was a lot of enthusiasm at the MOSA Summit and Expo. But there are still MOSA doubters or skeptics in the defense world. During a keynote I hosted with David Tremper earlier this year at our MOSA Virtual Summit, he said that metrics are still needed to help DoD [U.S. Department of Defense] leaders make the case against naysayers. How do you convince most skeptics about the value of this approach?
HAIR: I do agree that it is good to have relevant metrics. I would love to have something that is a clear metric that shows schedule gains and cost benefits from using MOSA right now, because of the pace of developing these large defense acquisition systems. That data will take a while to come in. We need to be able to actually implement some of these strategies to get that data.
As far as convincing naysayers or skeptics on this, it’s why we’ve got the experts in PMA 209. They are very familiar with the details of how to support other program offices and getting the MOSA requirements on contract, understanding the
engineering detail, understanding the standards, and then working with the programs to be able to show the benefits of increasing competition and making integration quicker and easier.
Outside of the metrics, which will take some time, I think it’s really just hands-on and showing the other program officers, especially on the naval aviation side, how we can help them with MOSA initiatives and the MOSA approach.
MILITARY EMBEDDED SYSTEMS: What about communications across the services to push MOSA so there is less duplication of effort?
HAIR: You’re absolutely correct. I think that outside of just MOSA there is big value of forums like this, where we get the other services together.
So far, I’ve had great interactions with counterparts of mine in the Army and the Air Force, with plenty of follow-on conversations scheduled. [This is important] because there can be a tendency for folks to recreate the wheel and then to have the same efforts within multiple silos, which is obviously not a good use of our resources.
MOSA allows us – when we have the standard set right – to compete and get products that were intended for the Air Force, intended for the Army, and use those across the board. We also get additional gains of generally increased collaboration within the acquisition fields within the three services.
RTI Connext TSS
FACE 3.1 Conformant with DO-178C DAL A Safety Evidence
MILITARY EMBEDDED SYSTEMS: What challenges remain for MOSA in aviation programs?
HAIR: I’d say there are a couple of areas: One of them is making sure that we’ve got personnel trained from the contract side, the engineering side, and then with engineering the verification side of MOSA. Being able to set everything up to make that happen is definitely a challenge that we’re [focusing on now].
Another challenge aligned with that is making sure that the people that are acquiring these systems understand the various standards out there and understand where it’s applicable, where they can apply those standards to best use, which ones may or may not be in conflict, and which ones are going to get them the best gain overall in opening up their system to the right vendors. We need to be able to have the right commonalities within the Navy and other services.
MILITARY EMBEDDED SYSTEMS: How is PMA 209 leveraging AI [artificial intelligence] solutions?
HAIR: As of right now, nothing specifically but we – the top of my team – are looking to see what solutions may be out there. I haven’t seen anything yet that really jumps out at me [on the avionics side]. But I’m open to looking at different products.
MILITARY EMBEDDED SYSTEMS:
What was the buzz of the MOSA event in Atlanta? What trends or developments did you see that impressed you?
HAIR: A big, big area that impressed me was the range of vendors that were participating at the MOSA summit and the vendor size – from very small businesses to medium-size to the high-end players that were coming out to tell us what they’re doing in the MOSA space, and how they can best support. They’re really looking like that they are embracing this effort moving forward. Overall, that was incredibly promising, in addition to the alignment that we’re moving toward with the tri-services.
MILITARY EMBEDDED SYSTEMS: Does MOSA open up the defense market for companies new to working with DoD programs?
HAIR: Absolutely. I think part of that is making sure that we’re listening to
industry, talking to industry. And I see it as actually helping the industrial base by allowing other groups to come in and play into the military-acquisition space.
Some of these vendors [in Atlanta] that I was talking to have just recently moved into the defense market. They started in other areas of the market. This is an opportunity for them to move into defense, which definitely helps us to be able to get more innovation into our systems.
MILITARY EMBEDDED SYSTEMS: In your more than two decades as a pilot and as an engineer, what has been the most significant technology game-changer for military aviation systems during that time?
HAIR: For areas related to me, it is the increased communication links and unmanned systems – and you can’t have the unmanned systems [component] without increasing the communication links. During my flying time, it was going from steam gauges – circular gauges on the SH 60B, which was sweet at the time – to the MH-60R and jumping on Link 16 and doing SATCOM [satellite communications] and then adding other communication networks. That was a huge change. We were able to coordinate with a significantly larger number of units at the same time. Instead of just talking to one or two other aircraft or one or two other ships, we could be coordinating operations with three or four ships and [could fly] in groups of up to a dozen or more helicopters. So that was huge. Now moving in UAS [uncrewed aerial system] space, we’re using those links and increasing those communication links to be able to control and to work with our unmanned systems. That’s the most significant change since I’ve joined the military and started flying.
To contact Capt. Hair, email PMA209-AAT@us.navy.mil. ■
MOSA –friend or foe?
By Chip Downing
As I travel to various places around the world, I am surprised by the perception that different government and supplier organizations have of the modular open systems approach (MOSA). MOSA is designed to lower costs for global coalition forces while accelerating new, highly competitive capabilities for the warfighter, but folks still do not understand these benefits and sometimes turn MOSA into something that should be feared.
Let us be clear – MOSA simply wants to enable the rapid insertion of the most competitive warfighter technologies. I looked at three of its architectural and operational capabilities:
1. To drive affordable innovation throughout the supply chain based upon open standards and an open systems architecture (OSA);
2. To leverage the latest advancements in silicon with software that fully enables artificial intelligence (AI) that will augment rapid Combined Joint All-Domain Command and Control (CJADC2) decision-making;
3. To fully enable CJADC2 to deliver the most comprehensive situational-awareness visualizations to the warfighter and commanders for rapid and precise executions of threat responses.
The mandate for MOSA
MOSA is not a new, unproven process for efficiency – it is a remarkably simple and straightforward open systems blueprint for procuring the best, most competitive technologies for creating unequivocal advantages for all coalition armed forces. Ten years ago, MOSA was an interesting purchasing and design concept; today, MOSA is the U.S. Department of Defense (DoD)-preferred method for implementation of open systems and is in fact required by U.S. law. Title 10 U.S.C. 4401(b) states that all major defense-acquisition programs (MDAP) are to be designed and developed using a MOSA that:
› Employs a modular design that uses modular system interfaces between major systems, major system components, and modular systems.
› Is subjected to verification to ensure that relevant modular system interfaces comply with, if available and suitable, widely supported and consensus-based standards.
› Uses a system architecture that allows severable major system components at the appropriate level to be incrementally added, removed, or replaced throughout the life cycle of a major system platform to afford opportunities for enhanced competition and innovation.
› Complies with the technical data rights set forth in 10 U.S.C. 3771-3775.
Core requirements for MOSA
Achieving the benefits of MOSA requires adherence to five major MOSA principles:
1. Establish an enabling environment – A program manager must establish supportive system requirements, business practices, technology development, acquisition, test & evaluation, and product support strategies.
2. Employ modular design – Functionality must be isolated during the design process to enable the system to be easier to develop, maintain, modify, and upgrade. A modular systems design will provide the foundation to upgrade or change functions that change or evolve quickly over time with minimum impact on the rest of the system. This is accomplished using open industry standards for key interfaces.
3. Designate key interfaces – A MOSA system design manages key interfaces to utilize open standards to produce the most life cycle benefits possible.
4. Use open standards – Open hardware and software interface standards must be well-defined, mature, widely used, and readily available, enabling rapid interchangeability, interoperability, interconnection, compatibility, communication, and logistics support. Open standards managed by independent standards organizations enable immediate support from a wide supply chain supporting an existing market with proven commercial products and related safety and security certification evidence.
5. Certify conformance – MOSA module verification and conformance to key interfaces based upon open industry standards is the foundation of program efficiency. Proven conformance notably reduces multiple-supplier integration risk, driving accelerated deployment and higher levels of quality throughout the system.
The use of the FACE standard in MOSA programs
The use of The Open Group Future Airborne Capability Environment, or FACE, Technical Standard and Business Approach is now widely referenced as a proven strategy to use open standards-based software in programs using MOSA. The FACE Business Approach and Technical Standard is independently managed by The Open Group as a consortium; more than 100 government and industry entities have worked to establish this open avionics environment for all military airborne platforms. The consortium was formed in 2010 and is made up of military customers, avionics suppliers, and academia.
The FACE Technical Standard and Business Approach enables the U.S. and coalition partners to enable military aircraft to rapidly refresh their avionics platforms to support the latest advances in computer hardware and software. The FACE Technical Standard, a “standard of standards,” is based upon existing and proven open standards. There are over 60 open standards that the FACE standard supports, and these are managed by independent standards organizations that serve the global avionics community. These organizations include ANSI, ARINC, IEEE, IETF, Khronos Group, Object Management Group (OMG), and The Open Group, and they manage standards as diverse as ARINC 653, C/C++, DDS, IPv6, Java, OpenGL, POSIX, TCP, and Vulkan, with a wealth of existing commercial solutions. Many of these commercial products have existing airworthiness-certification evidence that both reduces risk and accelerates the deployment of critical airborne software.
Conformance eases integration and accelerates deployment
One of the hallmark achievements of the FACE Consortium is the creation of a conformance program to evaluate the presence of the key interfaces defined in the FACE Technical Standard. Conformance is also a key pillar of MOSA. FACE conformance means that a product meets 100% of the applicable FACE Technical Standard requirements. There is no conformance category for a product that does not meet 100% of FACE API requirements – this condition provides greater assurance that conformant products are both portable and reusable, and should accelerate
integration of software modules from a diverse supply chain.
One of the unsung heroes of the FACE approach is the adoption of proven industry standards. Instead of writing an entirely new and unproven set of APIs and a new, proprietary, U.S.-only solution stack, the FACE technical team decided early on that the use of existing avionics standards was the fastest and most feasible path to accelerating new capabilities to the warfighter. This standard-of-standards approach based upon open software standards already proven by global commercial suppliers accelerates military avionics efforts and does not waste industry time rewriting proven standards with yet another new, unproven, and proprietary API. Another benefit of this approach is that many commercial avionics software suppliers already have existing airworthiness certification evidence that is proven in flight – this proof reduces program risk and further accelerates the deployment of critical airborne software.
Is MOSA a friend? Or a foe?
MOSA brings with it a wide range of beneficial qualities. The only entities that should fear MOSA are first, supplier entities that have enjoyed unbridled largesse with government customers because they have a captive supply chain that locks in uncompetitive capabilities to the warfighter, or second, program managers who fear the change that MOSA brings and enjoy a cozy relationship with a single-source supply chain that requires minimum effort to manage. Although MOSA is driven from the top of the U.S. DoD, it is not a USAonly concept, and at its core is designed to be highly inclusive of the exceptional innovation of global defense partners.
MOSA is a friend of our warfighters. Its adoption across all armed forces and their supply chains will increase our global military competitiveness against all adversaries. ■
Chip Downing is the founder of S5 Intelligence Corp.
S5 Intelligence Corp. • www.s5int.com
The Future Airborne Capability Environment, or FACE: A strategic imperative for U.S. military competitiveness
By Tim Reed
In the past, any reflection on America’s military competitiveness looked at how it stacked up against traditional adversaries such as China and Russia. But the world is changing quickly, and the U.S. needs to ensure that its military stays strong and can compete against new threats – Iran, Lebanon, and North Korea, for example – and not just face off with old enemies.
The development of the Joint Concept for Competing (JCC) during the 2023 U.S. Joint Chief of Staff meeting underscores a new set of threats and a new dynamic. The nature of modern strategic competition includes enhancing military capabilities to address these emerging threats alongside those of our historical opponents and non-state actors. The diffused nature of 21st-century conflict encompasses threats from newly empowered state competitors, including Iran and North Korea, alongside more traditional opponents like Russia and China. Meanwhile, non-state actors and international terrorist networks exploit new technologies and expand their capabilities.
Enhancing interoperability and open architecture standards with FACE
In this complex environment, initiatives like the Future Airborne Capability Environment, or FACE, are critical to sustaining U.S. military competitiveness now and into the future. By promoting open architecture standards, interoperability, and the rapid integration of avionics capabilities, the FACE approach fosters the agility, innovation, and cost efficiency needed to counter modern challenges.
As America’s military transitions to meet the demands of competition in the 21st century, embracing initiatives such as FACE will be a strategic imperative.
Furthermore, the FACE approach mitigates many risks associated with cooperating with our allies, including complex compliance requirements, integration challenges, and allocating shared resources, for example. Its emphasis on interoperability and innovation can address adversarial challenges and technological advancements from competitors, making it crucial for U.S. military competitiveness. Let’s dive deeper into each of these areas:
› Compliance requirements. FACE open standards and modular architecture enable the rapid integration of capabilities aligned to common standards, reducing the need for custom compliance efforts when working on collaborative projects such as the Joint Strike Fighter. The emphasis on interoperability also creates alignment on integration requirements early in the design process.
› Integration challenges. The FACE open systems architecture facilitates plugand-play interoperability, minimizing the effort required to leverage disparate allied systems. The ability to swap out modular components also decreases integration timelines and costs. The FACE promotion of common interfaces and data sharing further eases international system integration.
› Resource allocation. The FACE incremental and spiraling development process –a risk-driven software development model – enables allies to share costs in smaller increments that are better aligned to shared priorities; that is, the open architecture lets allied nations develop and integrate capabilities that align with shared standards independently. This approach reduces friction over proprietary limitations and control.
› Fostering innovation. The FACE approach focuses on the interface level and offers ample opportunities for innovation on the prime, OEM, and tier levels. With a standard operating environment established by FACE, vendors can concentrate on implementing new features effectively rather than spending time managing compliance with FACE standards.
U.S. Navy photo of F-35C jet by Mass Communication Specialist 3rd Class August Clawson.
Countering the unexpected with real-time operating systems and enhanced capabilities
The FACE modular open systems architecture enables speedy integration and fielding of new capabilities to better counter unexpected threats. This method makes it easier for the military to pivot in response to adversaries exploiting new vulnerabilities. The ability to spiral-develop and swap capabilities provides operational flexibility to adjust tactics as adversaries evolve.
This is where a FACE conformant, DAL A-certified real-time operating system (RTOS), such as LynxOS-178, can provide additional value. LynxOS-178 is certified conformant to the FACE Technical Standard v3.1 across Arm, x86, and PowerPC. LynxOS-178 is one of several RTOS deployment options included as part of the LYNX MOSA.ic operating environment. By leveraging complementary capabilities like partitioning, virtualization, and trimmeddown unikernel architectures, system architects can achieve improved composability and build robust, resilient platforms that meet real-time requirements while still conforming to open standards. LYNX MOSA.ic multitiered partitioning approach enables strict isolation of components into separate virtual machines with allocated resources while the unikernel deployment option provides further optimized RTOS component runtimes that maximize resource utilization and timing, while minimizing excessive, unused RTOS features. (Figure 1.)
Together, these capabilities empower architects to truly realize the benefits that standards initiatives such as FACE offer, like rapid integration, interoperability, and innovation, while still addressing the performance, safety, and security demands of mission-critical defense and aerospace systems. As experts have stated, conformance testing is only the beginning. To sustain long-term military competitiveness, the U.S. must embrace open standards and innovative technologies that transform those standards into secure, reliable, and adaptable mission-critical computing platforms. The
Figure 1 | By leveraging complementary capabilities like partitioning, virtualization, and trimmed-down unikernel architectures, avionics architects can achieve improved composability and build robust, resilient platforms that meet real-time requirements while still conforming to open standards.
combination of open architectures and hardened real-time capabilities will strengthen the U.S. strategic position in the face of unexpected threats and long-term global competition.
In essence, the FACE approach provides a foundation to rapidly adapt to changing strategic contexts while fostering a vibrant vendor ecosystem. Its focus on modular designs, open standards, and continuous integration enables the U.S. to counter unforeseen challenges. At the same time, the emphasis on open architecture and common standards incentivizes vendors to compete and innovate within a broad, cross-platform market. This vibrant technology ecosystem, enabled by FACE principles, introduces more players and solutions to expand the military’s capabilities.
The critical role of the FACE approach in sustaining U.S. military competitiveness amid global tensions and great power competition cannot be overstated. Embracing open architecture standards comparable to the FACE Technical Standard ensures that the U.S. remains at the forefront of military innovation and preparedness, enhancing its strategic position in an increasingly competitive global landscape. ■
Tim Reed is the CEO of Lynx Software Technologies, a missioncritical edge software company that serves the aerospace, military, and federal markets. Tim joined Lynx in June 2022, after a long tenure with Green Hills Software. During his time at Green Hills, Reed held a variety of roles including senior vice president of the Advanced Products division and a member of the executive leadership team. Tim’s experience spans automotive, industrial, aerospace, and defense end markets. He holds a bachelor’s degree in engineering and applied science from the California Institute of Technology.
Lynx Software Technologies https://www.lynx.com/
Verifying FACE conformance for Ada software
By Benjamin M. Brosgol
The Future Airborne Capability Environment, or FACE, Technical Approach is a government/ industry initiative, managed by the FACE Consortium under the auspices of The Open Group. Its goal is to reduce software development/deployment costs through source code portability and reuse and thereby avoid vendor lock-in. A key element of the FACE approach is an official process and test suite for verifying that software conforms to the requirements specified in the FACE Technical Standard. However, this process currently does not easily accommodate Ada, a language with a long history of successful usage in safety-critical airborne systems, both military and commercial. There is a solution to this hurdle, however: a practical approach to FACE conformance verification for Ada code (both Ada 95 and Ada 2012), in particular for software that is not part of the underlying operating system.
First, a bit of background, or “FACE Conformance Verification 101.” The Future Airborne Capability Environment, or FACE, approach is based on several elements:
› a segmented software architecture that separates portable from platform-specific components › an expressive and language-agnostic data modeling technology that ensures a consistent interpretation for data communicated across components › tiered “profiles” and “capability sets” that impose safety-oriented restrictions on standard software interfaces and language features
Although it is focused on portability and does not address functionality or assurance requirements, the FACE approach accounts for the fact that in practice, an airborne system comprises components at varying levels of safety sensitivity. The FACE Technical Standard thus defines subsets of standard application program interfaces (APIs) – in particular POSIX and ARINC-653 – at several levels (called profiles). In increasing order of criticality, from most permissive to most restrictive, these are General Purpose, Safety Extended, Safety Base, and Security. Analogously, the FACE Technical Standard defines subsets of standard language features for C, C++, Ada 95, Ada 2012, and Java (“capability sets”): General Purpose, Safety Extended, and Safety Base/Security. As an example, the predefined generic package for unbounded strings can be used in the General Purpose capability set for both Ada 95 and Ada 2012, but because of its dependence on dynamic memory management it is excluded from the Safety Extended and Safety Base/Security sets.
To verify that a candidate software component – or in FACE terminology a Unit of Conformance (UoC) – meets the requirements defined in the FACE Technical Standard, the FACE Consortium has established a rigorous process that relies heavily on a Conformance Test Suite (CTS). The specifics depend on whether the UoC is part of the underlying operating system (OS), as the OS implementation is necessarily platform-dependent and does not have the portability requirements of application code. Going forward, we focus on portable components, with the term “UoC” referring to software that is not part of the OS.
Because the UoC might have proprietary or classified content, an underlying principle for FACE conformance is that the UoC supplier should not be required to expose the source code. This principle constrains the conformance procedures and makes
Photo courtesy U.S. Department of Defense/U.S. Air Force.
it unlike other software assurance standards, such as DO-178C. Indeed, the key property checked by the CTS is that there are no uses of language features or external interfaces outside of the ones permitted by the capability set and profile targeted by the UoC. This property can largely be verified by link-time tests. In brief:
› The UoC supplier compiles the source code with a toolchain (either a native or cross development environment). The header files (C and C++) or compilation unit specifications (Ada) should be the same as those used for the Gold Standard Library (see Figure 1).
› The CTS generates the permitted run-time libraries for the toolchain’s target platform, based on the selected profile and capability set. These are stubbed libraries (interfaces only, null code bodies) comprising the following (Figure 1):
• FACE interfaces and data model
■ APIs for FACE services such as IO and inter-UoC data communication that are permitted by the targeted profile, together with APIs generated for the UoC’s data model
• POSIX or ARINC-653 library
■ The APIs from these standards that are permitted for the targeted profile
• Standard run-time subset
■ The APIs defined by the language standard that are permitted by the targeted capability set
• Compiler-specific run-time (CSRT) support
■ APIs that are invoked from the compiled code and which implement run-time functionality that is expressed in standard language syntax (e.g., threading, memory management, and exception handling)
› The CTS attempts to link the UoC object code against these stubbed libraries.
The CTS generates a report with one of three possible outcomes:
› Success. The submitted UoC object code links successfully against the above libraries and does not use features that are permitted but have usage restrictions. The UoC is considered to have met all FACE requirements that can be tested by the CTS. However, some FACE requirements are feature restrictions based on language syntax rather than run-time library support. If the UoC uses such a feature, it may still link successfully against the CTS libraries but is not necessarily FACE conformant. For such requirements the UoC supplier needs to demonstrate, by providing the results of source-code inspection, that the UoC meets the restriction(s) that are not detected by the CTS.
› Inspection required. The submitted UoC object code links successfully against the above libraries and uses a feature that is permitted but has usage restrictions. In this case the UoC supplier needs to substantiate the usage through inspection (of design or code).
› Failure. A failure is reported if the UoC object code fails to link. If there are link errors with unresolved symbols, then the UoC supplier will need to either make appropriate corrections for a subsequent conformance verification attempt, or else provide the relevant additional libraries to resolve the symbols and explain why these libraries should be permitted. (As an example of the latter, if the UoC contains code in both C and Ada that meet the FACE requirements, then the object code in either of these languages will fail to link against the libraries supplied for the other language. The UoC supplier can provide the needed libraries and must substantiate their inclusion.)
For a formal conformance verification, the UoC supplier needs to demonstrate a successful CTS execution and provide the necessary source inspection evidence to an agent from an organization approved by the FACE Consortium as an official Verification Authority.
The challenge for Ada
For C, and to a large extent for C++ (Java introduces some unique issues and is outside the scope of this discussion), the CTS process works effectively: the compiler-specific run-time subset is fairly minimal, for example including numeric routines implemented in software rather than hardware. But for Ada, this library is much more extensive. An Ada program expresses run-time functionality such as threading not by
Figure 1 | Shown: Stubbed run-time libraries used by the FACE Conformance Test Suite.
invoking a standard API (e.g., pthread_create) but rather by using standard programming language syntax that is compiled into calls on subprograms in the CSRT.
Furthermore, it is unrealistic to expect that the features supported by a CSRT will exactly match the features allowed in the targeted capability set. FACE conformance requires the library to supply at least the permitted functionality but permits it to provide more. The challenge for the CTS is to account for several factors:
› The CSRT for a given Ada toolchain will support some features that are prohibited by the targeted capability set (this is also true for C and C++, since some capability set restrictions are unrelated to run-time APIs)
› To show the absence of these features from the UoC, source inspection evidence is required
› The specific features subject to inspection will vary across Ada toolchains
The CTS is flexible enough to be used for verifying FACE conformance for Ada UoCs; however, the process is not clearly defined. Ad hoc procedures need to be used to generate the relevant stubbed libraries, to demonstrate that these libraries are acceptable, and to determine what must be verified by inspection. The overall process has proved to be rather clumsy in practice.
Working within the Operating System Subcommittee of the FACE Technical Working Group, an Ada Conformance Tiger Team led by AdaCore has prepared a practical solution. The proposed approach uses the current CTS as supplemented by two main elements:
› Toolchain assessment package. A test suite comprising Ada code that violates the FACE capability set requirements and a script that attempts to invoke an Ada toolchain to compile and link each test against applicable run-time libraries.
› Toolchain support package. Documentation and other artifacts needed for adapting the CTS so that it generates the needed run-time libraries and performs the link-time testing of the submitted UoC object code
Toolchain assessment package
Toolchain Capability Assessment Test Suite (TCATS): This is a test suite derived from the FACE capability set requirements. In general, a given requirement specifies restrictions on one or more language features and thus yields multiple tests. Each test is a legitimate program in the full Ada language but exercises a feature that violates the requirement.
Comprising well over 100 tests, the TCATS covers all the capability sets and both Ada 95 and Ada 2012. The tests themselves are vendor-neutral, but the results of compiling and linking the tests will vary based on the toolchain and its CSRT.
TCATS results worksheet (template): This Excel file is a spreadsheet that, when completed, will show how a given toolchain processes the TCATS. Each TCATS test is represented by a row in the spreadsheet. For each row, prefilled columns specify a unique ID for the test, the wording of the requirement from which the test was derived, and the capability set(s) and Ada language version(s) for which the test is to be used. An additional column – the result of submitting the test to the toolchain –is blank.
Toolchain invocation script: This script is a standard Ada program (both Ada 95- and Ada 2012-compatible) that takes as input a listing of all the TCATS test files and produces as output a text file documenting the toolchain’s ability to detect the restriction violations embodied in the tests. The script invokes an Ada toolchain on each test and checks whether the test was successfully compiled and linked. If a test fails to compile,
or if it compiles but fails to link, then the script identifies the associated restriction as being verified by the CTS; otherwise, the restriction is noted as requiring verification by inspection. These results are captured in the output file.
The script invokes a nonproprietary Ada toolchain on one of the authorized host conformance verification platforms, namely the GNAT GPL 2017 edition on Windows 10. This version of the GNAT technology has appropriate licensing for use with the CTS, and it supports both Ada 95 and Ada 2012. The script is readily tailorable to other Ada toolchains and other native or cross platforms as needed.
The UoC supplier and the Verification Authority agent can use the script output to complete the toolchain capability worksheet. During official conformance verification, if the UoC successfully links against the CTS libraries, the Verification Authority can use this worksheet to determine which requirements still need to be verified by inspection.
Detecting source code invocations of compiler-specific run-time API
A UoC whose source code invokes functions from the CSRT is not FACE conformant, since the code would clearly be nonportable. However, there is no way for the CTS to detect violations, since CSRT functions can be invoked from a conformant UoC’s object code. Though nonconformant, a UoC whose source code invokes a CSRT function will thus link successfully. This issue is not unique to Ada; it applies to all the FACE supported languages. Detection necessarily requires source code inspection. For Ada, the UoC supplier must demonstrate two properties:
› The only units referenced in the UoC’s “with” clauses are either other compilation units in the UoC, units from the standard run-time library permitted by the targeted capability set, or else units from the POSIX or ARINC-653 library permitted by the targeted profile.
› The only units allowed as parents of child UoC units are other units in the UoC. The UoC is thus not allowed
to define child units of CSRT packages, nor is it allowed to define child units of predefined Ada packages. (In the latter case, such child units could reference private declarations and therefore be non-portable).
The UoC software supplier thus needs to provide the following evidence:
1. The list of all top-level compilation units defined by the UoC
2. The list of all child units defined by the UoC
3. The list of all compilation units “with”ed by units in the UoC
4. Documentation showing that all the units in (3) are in (1), (2), or the Gold Standard Library for the targeted profile and capability set
5. Documentation showing that the root unit of each unit in (2) is a (package or generic package) unit in (1)
Toolchain support package
Given the constraint of no changes to the CTS software, the provider of the toolchain to be used for Ada conformance verification needs to supply the relevant supplementary artifacts (documentation, scripts, installation instructions, configuration files) to enable the UoC provider and the Verification Authority to conduct a conformance verification with the existing CTS. More specifically, the package provided for an Ada toolchain needs to include a CTS users guide supplement with detailed instructions on setting up the toolchain and running it from the CTS:
› Installing and configuring the Ada toolchain
› Generating the Ada Gold Standard Library and the toolchain’s Programming Language Run-Time, based on the targeted capability set and profile
Using this information, the UoC supplier and the Verification Authority can then run the CTS on an Ada UoC: this will entail linking the UoC object code against the Programming Language Run-Time and Gold Standard Library for the targeted capability set/profile and producing a conformance report, just as is done for other languages. The main difference with Ada is the use of the TCATS results worksheet to establish the requirements that need to be verified by inspection.
The larger picture
It is important for a developer to be able to check incrementally (as part of continuous integration/DevOps) that the UoC meets the restrictions imposed by the targeted profile and capability set. Ada offers two solutions:
› Pragma Restrictions, a standard pragma in Ada 95 and Ada 2012, can be supplied with relevant arguments at each compilation to ensure that prohibited features are not used (i.e., the compilation unit will be rejected if it uses such a feature). For example, pragma Restrictions(No_Dependence => Ada.Strings. Unbounded) will detect uses of unbounded strings. As an aid to developers, if a FACE capability set restriction violation can be detected by a standard pragma Restrictions argument, the TCATS Results Worksheet template has an entry associating that argument with the relevant test(s).
› A static analysis tool can be used to detect violations of FACE requirements, including those that are syntactic in nature and are not expressible via arguments to pragma Restrictions. An example of such a tool is GNATcheck, which is part of AdaCore’s GNAT Static Analysis Suite.
The approach to FACE conformance for Ada has exposed several issues that are relevant to the conformance procedures for other languages. One is the use of a test suite (TCATS) to determine whether a violation is detected by the toolchain and its CSRT. It is important for the UoC supplier and the Verification Authority to know with confidence which requirements will entail source code inspection, and a test suite such as the TCATS can serve this function. Moreover, source code references to the CSRT must be detected; this is not testable by the CTS and rules are needed for C/C++/Java around the UOC supplier’s inspection evidence.
Going forward
A well-defined and practical conformance-verification process for Ada is important for the successful adoption of the FACE approach within the defense community, and the solution described here will fill a current gap. It is incremental in nature, working with the existing CTS and using link-time tests as its basis. Although evolutionary, the Ada conformance approach is also innovative and has introduced several elements (a toolchain assessment package and a toolchain support package) that formalize aspects absent from or implicit in the procedures for other languages. Artifacts such as the TCATS and the rules for detecting source code references to compiler-specific APIs are relevant for other languages and may help guide future enhancements to the FACE conformance verification process.
As of early 2024, the Ada approach described here is under consideration within the FACE Consortium, and artifacts comprising sample toolchain assessment and toolchain support packages have been prepared and submitted. Although the final details may vary, a FACE conformance verification solution for Ada based on these packages is expected to be approved in the near future. Further enhancements include procedures for verifying mixed-language UoCs (in particular, when both Ada and C are used) and incorporating the TCATS as part of CTS execution. ■
Dr. Benjamin Brosgol is a senior member of the technical staff at AdaCore. He has been involved with programming language design and implementation throughout his career, concentrating on languages and technologies for high-integrity systems with a focus on Ada and safety certification (DO-178B/C).
Dr. Brosgol is an active member of The Open Group FACE Consortium’s Technical Working Group, and in particular he has been involved with the development of the IDL-to-Ada mapping.
AdaCore • https://www.adacore.com/
MOSA for crewed and uncrewed aviation platforms
By Cynthia Springer
As the aviation industry evolves, the modular open systems approach (MOSA) is expected to play a significant role in the development of innovative and safe avionics systems that enable no-fail operations, whether crewed or uncrewed.
According to an avionics market report from Fortune Business Insights, the global avionics market is projected to reach $75.81 billion by 2027, at a combined annual growth rate [CAGR] of 9.25% from 2019 to 2027, driven by the increasing demand for advanced systems in modern aircraft.
Where security, safety, and reliability are paramount, avionics systems professionals are looking to realize the digital future with software-defined, mission-critical intelligent systems. The modular open systems approach (MOSA) and related standards and solutions are all playing critical roles in enabling next generation capabilities in avionics.
MOSA, in particular, benefits the avionics space in both military and civilian applications, as it enables faster development cycles, reduced costs, increased flexibility, and improved safety.
MOSA enables new technologies
Avionics-systems professionals face the challenge of keeping pace with rapid technological evolution while balancing complex requirements with limited budgets. In today’s digitally defined landscape, the traditional way of designing avionics systems as closed systems, with hardware and software tightly integrated and designed specifically for a particular aircraft, is proving unsustainable.
MOSA can help meet this demand by enabling the integration of new technologies, reducing development costs, and improving performance and reliability. A MOSA design focuses on developing open and interoperable systems using modular, independent components that can be easily modified, replaced, or upgraded. With tools available at the modeling level, these approaches can be used in crewed and uncrewed aviation.
MOSA: A competitive game-changer
MOSA is not itself a standard but rather a strategy for component acquisition and system design that prioritizes use of open standards-based technologies. The goal is systems that are flexible, competitive, and sustainable over their entire life cycle.
MOSA provides a scalable path for building avionics systems, leading to increased efficiency. Cost-effectiveness is another advantage, as each system can be designed using available standard components. This approach eliminates the need for costly bespoke designs and ensures that components can be purchased in bulk from competitive vendors and used across multiple aircraft types, both military and commercial.
Utilizing MOSA with IMA
In complex environments, utilizing MOSA along with other technologies, such as integrated modular avionics (IMA), can further enable flexibility, affordability, and enhanced capabilities. IMA simplifies avionics software development by supporting an integrated architecture of application software portable across common hardware modules. Avionics systems can be designed as individual modules that can be swapped in and out as needed. Complexity is lower, since each module is designed to operate independently, simplifying the overall system design. IMA also uses standard interfaces, which makes it easier to integrate new modules with existing systems.
MOSA and FACE conformance
To provide a common framework for integrating different avionics systems, standards such as the Future Airborne Capability Environment, or FACE, Reference Architecture have emerged. The FACE approach is a collaboration between government and industry that created a software standard to provide an open systems approach for military aviation solutions, delivering softwaredefined capabilities to the end user faster and more affordably.
The FACE architecture consists of several components, including a common operating environment (COE), a portable component framework (PCF), and a data model that defines how components interact with each other. The FACE approach supports MOSA because it backs the IMA concept. (Figure 1.)
Addressing different safety-criticality levels
MOSA enables the development of high-performance systems that can support different safety-criticality levels. Safety-critical systems are defined as systems whose failure could result in injury or loss of life, damage to property, or damage to the environment. Since safety is paramount in avionics, MOSA is useful because it helps mitigate risk by enabling the development of robust, reliable, and flexible systems. To achieve the full benefits of MOSA, it is essential to verify and validate all components against the appropriate safety standards. Meeting standards such as DO-178C for software, DO-254 for hardware, and DO-297 for system architecture in airborne systems is essential for achieving certification and ensuring compliance with regulatory requirements.
Ensuring safety, mitigating risk
Several critical factors must be considered when implementing MOSA in aviation – one of the most important being airworthiness. The Federal Aviation Administration (FAA) defines airworthiness as the measure of an aircraft’s suitability for safe flight.
While the FACE standard is often associated with airworthiness, it is important to note that the FACE standard does not mandate or specify a particular way of achieving airworthiness. Instead, it provides guidelines to build a safety-critical piece of avionics that can be adapted to fit different airworthiness requirements. When building avionics systems using MOSA, it is essential that the system’s features and attributes adhere to the safety profile, which defines the system’s characteristics and requirements that help ensure safe and reliable operation.
Another point: Multicore devices have become increasingly popular in avionics because they offer improved performance, reduced power consumption, and increased redundancy. However, their implementation requires careful consideration of avionics certifications and safety requirements. Risk mitigation is a critical component of MOSA implementation; it requires strict adherence to guidelines to ensure that software safety testing conforms to safety and security guidelines.
MOSA and the intelligent edge
One major development in avionics systems is the move toward intelligent edge devices. Intelligent edge systems collect and process data at the edge, feeding it into a cloud-based environment for analytics. The flexibility enabled by such systems supports incredible potential, including quick upgrades of applications and services on the system. Critical to the security of this approach is use of a DevSecOps environment, or the practice of integrating security testing at every stage of the software-development process.
Containerization – a type of virtualization in which all the components of an application are bundled into a single container image and can be run in isolated user space on the same shared operating system – also plays a critical role in enabling intelligent edge capabilities. Containers are a portable and scalable way to package applications and services, enabling faster deployment and simpler management.
For example, the U.S. Air Force has shown that an F-16 with a container-based server can deploy containers on the aircraft even in flight. This ability offers a range of benefits, including updating and replacing at least some software applications without needing to take the aircraft offline. This option is especially important for military aircraft, where downtime can have significant operational implications.
An evolving field
As the aviation industry evolves, MOSA is expected to play a larger role in the development of innovative and safe avionics systems that enable no-fail operations, whether crewed or uncrewed. MOSA implementation in aviation will be critical to remaining competitive, flexible, and profitable.
With the advent of embedded systems and the intelligent edge, avionics systems are evolving to offer sophisticated, high-performance capabilities with enhanced safety, security, and efficiency features. Avionics developers and engineers must leverage these advancements in MOSA and related technologies and standards, all of which play critical roles in enabling these next-generation capabilities. ■
Cynthia Springer is Director, Industry Solutions for Aerospace and Defense at Wind River. Cynthia has more than 15 years of experience across both the defense and satellite communications industries. Cynthia has a particular interest in MOSA [modular open systems approach] to achieve competitive and affordable acquisition and sustainment over the system life cycle.
Wind River • https://www.windriver.com/
Figure 1 | Capabilities developed for one FACE [Future Airborne Capability Environment] operating system segment can be reused across multiple aircraft platforms. Graphic: U.S. Army via The Open Group.
SBC3513L
The SBC3513L Rugged 3U VPX Single Board Computer from Abaco Systems is designed for high performance and reliability, featuring the Intel® Xeon® W processor (11th Generation Intel Core i7 Technology). Aligned to the Sensor Open Systems Architecture (SOSA™) Technical Standard, it is ideal for applications ranging from industrial to fully rugged environments. A standout feature is its support for deterministic Ethernet with Time Sensitive Networking (TSN), ensuring precise timing and synchronization crucial for automotive, industrial, and aerospace applications. The SBC3513L offers dual-channel DDR4 SDRAM with ECC up to 64GB, up to 480GB NAND Flash, and extensive I/O including DisplayPort, USB 3.2, SATA, and GPIO. Enhanced security features are provided by the Xilinx® Zynq® UltraScale+™ FPGA and Intel Converged Boot Guard. Networking capabilities are robust, with a 100G Ethernet data plane and 25G Ethernet control plane. Comprehensive OS support for Windows® and Linux® enhances its versatility.
https://www.abaco.com/products/sbc3513l
Abaco Systems www.abaco.com
FEATURES
Ą Deterministic Ethernet: Supports 100G Ethernet data plane and 25G Ethernet control plane with Time Sensitive Networking (TSN) for precise timing and synchronization
Ą High Performance Processor: Powered by the Intel® Xeon® W processor (11th Generation Intel Core i7 Technology) with 8 cores at 2.6 GHz and AVX-512 support
Ą Advanced Security: Incorporates Xilinx® Zynq® UltraScale+™ FPGA for secure computing and Intel Converged Boot Guard
Ą Robust I/O Options: Includes DisplayPort, USB 3.2, SATA, GPIO, and serial communication ports
Ą Extensive Memory: Features up to 64GB of DDR4 SDRAM with ECC and up to 480GB NAND Flash storage
Ą Expandable Architecture: Includes an on-board mezzanine expansion site for enhanced system flexibility and additional customization options
M-RTOS is a modular, flexible and affordable operating system, compliant to ARINC 653 and RTCA/DO-178C DAL A, designed for a wide range of aerospace and defense applications, from Commercial Off-The-Shelf (COTS) electronic hardware to federated LRU (Line-Replaceable Unit) aircraft systems, to IMA (Integrated Modular Avionics) platforms.
M-RTOS was developed to minimize memory and timing usage and outperform the competition on key benchmarks. M-RTOS guarantees robust spatial and temporal partitioning and can run on microprocessors incorporating memory protection units.
MANNARINO Systems & Software Inc. provides safety-critical systems, software, and airborne electronic hardware engineering services to the aerospace, defense, space, simulation, power generation and rail industries.
MANNARINO is an authorized Design Approval Organization (DAO) for Airborne Software (RTCA DO-178C) and Airborne Electronic Hardware (AEH) (RTCA DO-254) of the National Aircraft Certification Branch of Transport Canada Civil Aviation (TCCA).
MANNARINO Systems & Software https://www.mss.ca
FEATURES
Ą Unrivaled and Flexible Commercial Terms
Ą Customization with Modular and Scalable Architecture
Ą Designed to Outperform the Competition
Ą Certification Peace of Mind
Ą Unparalleled Customer Support and Service
Ą Supports Multicore Processors
https://www.mss.ca/m-rtos
Enhance Your Code’s Security
To help developers eliminate coding defects during the development cycle – long before malevolent attackers can exploit them – AdaCore presents the GNAT Static Analysis Suite (GNAT SAS).
Defect and Vulnerability Analysis
GNAT SAS helps developers deeply understand their code and build more reliable and secure software systems.
GNAT SAS features an Ada source code analyzer that detects run-time and logic errors. It assesses potential bugs and vulnerabilities before program execution, serving as an automated peer reviewer, helping to find errors easily at any stage of the development life-cycle. It enables you to improve the quality of your code and makes it easier for you to perform safety and/or security analysis.
GNAT SAS is a stand-alone tool that runs on Windows and Linux platforms and may be used with any standard Ada compiler or fully integrated into the GNAT Pro development environment. It can detect several of the “Top 25 Most Dangerous Software Errors” in the Common Weakness Enumeration. It supports all versions of Ada (83, 95, 2005, 2012, 2022).
Coding Standard Verification
GNAT SAS makes reviewing code against best practices less time-consuming and less tedious.
GNAT SAS features an automated coding standard verification tool. It automatically checks Ada applications for compliance with organizational and projectspecific coding standard requirements.
You can think of GNAT SAS as your best-practice shepherd, diligently keeping your code within the safe boundaries of your coding rules. It helps guide your code toward its most secure solution.
Coding Standard verifications have been qualified for use in DO-178B/C, EN 50128, and ISO-26262 environments for our customers who must comply with those standards.
Metric Computations
GNAT SAS helps you meet the reporting requirements of your software verification standard. It takes an Ada source code file as input, computes the necessary measurements, and generates a file containing the metrics data as output. Users can choose which metrics are reported.
FEATURES
Ą Defect and Vulnerability Analysis
Ą Coding Standard Verification
Ą Metric Computations
GNAT Static Analysis Suite
Cybersecurity for Avionics
Does your device or application need FIPS, DO-178 based TLS, Secure Boot, or Cryptography?
wolfSSL products are used by every branch of the U.S. armed services –deployed in everything from tanks and missile systems to satellites and aircraft. Providing secure boot and cryptography software for avionics systems, wolfSSL supports complete DO-178C DAL A certification, offering DO-178 wolfCrypt as well as FIPS compliance, as a commercial off-the-shelf (COTS) solution for avionics applications. We also provide DAL A wolfBoot secure boot for avionics. For enhancing communications security on aircraft, we offer DTLS 1.3 for ensuring data integrity and confidentiality while mitigating MITM, relay, DoS and spoofing attacks. wolfSSL’s embedded (D)TLS library, secure boot, and cryptography are lightweight, portable, C-language-based products which run seamlessly on DO-178 operating systems like SYSGO, Wind River VxWorks, INTEGRITY, and DDC-I Deos, and portable to bare metal and custom OSs.
TES-SAVi’s FAME™ is a complete end-to-end and round-trip solution for developing the FACE® Technical Standard compliant Edition 2.1.X and 3.X UoP Supplied Models (USMs) and Domain-Specific Data Models (DSDMs). FAME™ manages thousands of model elements with superior performance and time-savings promoting robust and manageable agile development toward the end game of achieving FACE conformance.
Create rigorous data models that stay “within the rails” of the FACE Technical Standard. Near continuous model validation and model wizards/forms ensure that data models are built correctly. Visualize, access, and understand complex FACE conformant data models and DSDMs containing thousands of elements with FAME’s filterable auto-diagram and context-driven views. Control and have access to your data, generate digital artifacts from your digital models and data, and work within Windows, Linux, or Mac environments. Take advantage of our world class customer support, resources, and training to ensure success.
https://tes-savi.com/fame/
TES-SAVi
https://tes-savi.com/
FEATURES
Ą Model validation for FACE conformant meta-model, OCL, and Query and Template rules
Ą Wizards/forms for the FACE conformant realization and element creation
Ą Single/minimal click functionality for model element creation and realization
Ą Context-sensitive and grammar-aware editing of Queries and Templates
Ą Builder option for Query and Template creation
Ą Natural language assist for model development, creation, and definition
Ą 7 distinct model views and project management model dashboard
PHENOM and CinC make it easy to develop, integrate, deploy, and update complex safety and mission-critical systems. They enable developers and integrators to work together and solve complex integration issues through modelbased documentation of interfaces, protocols, and system data exchanges. Skayl’s Infrastructure-Centric Integration approach further transforms the way systems handle changes by moving integration updates from applications to the infrastructure.
Unlike other methods that require manual updates and adjustments, PHENOM and CinC use dynamic data models to automatically generate what used to be done by hand. This approach speeds up deployment, reduces errors, and cuts down on repetitive work, making integration and testing more efficient and cost-effective. Our tools support The Open Group Future Airborne Capability Environment® Technical Standard and other specifications, ensuring compatibility across different systems.
PHENOM is a platform for developing, reviewing, validating, and tracking data, integration, and deployment models. It uses the FACE™ Conformant Domain Specific Data Model (DSDM) to improve interoperability with other systems.
https://www.phenomportal.com
LLC www.skayl.com
CinC is designed to enable configurable integration and delta-certification of systems by generating the necessary infrastructure software based on developed data, integration, and deployment models. CinC generates integration code using various templates and functions optimized for integrators, making the process smooth and customizable.
FEATURES
Ą Flexible DO 178 DAL A accredited integration with optimizable and configurable data, behavior, and transport mediation
Ą Eliminates integration ambiguities though automated semantic-based interface matching and discovery
Ą Automates validation & testing of system interfaces and integration logic with generated stimulus functions
Ą Produces always conformant data model exports with advanced guided modeling and tool-assist features
Ą Streamlines model collaboration enabled by dynamic model analytics reports, model health indicators, and automated system impact analysis with temporal backward and forward versioning and impact tracing
Ą Achieves system interoperability over time by leveraging multi-model versioning and advanced configuration management
Ą Post-deployment configurability enables seamless updates to messages, accommodates interface variations, and enables continuous optimization of system performance.
Ą Multi-standard support across the FACE® Technical Standard and other protocol and interface specifications
Ą Streamlines conformance processes with generated test and configuration artifacts
Ą Tool-neutral integration provides user-definable workflow and processes to utilize data model content
Ą Generates integration models and software eliminating manual and error-prone repetitive tasks
