MOSA Convergence: How SOSA, CMOSS, FACE and Related Standards Work Together on Real Platforms
At Military Embedded Systems' 2026 MOSA Summer Virtual Summit, Ethan Salehi, a technical account manager at Lynx, asked a useful question: how do standards like SOSA, CMOSS and FACE actually function together on a fielded system, and where do the seams between them create risk?
MOSA isn't a single standard. It's a strategy for managing a platform's entire lifecycle. Defense systems have historically been built from proprietary boxes and custom data paths, which makes every upgrade slow and costly. MOSA aims to pinpoint the interfaces most likely to change over time, whether that's a supplier, a mission requirement, or a new threat, and define those interfaces with real precision, down to timing, error behavior, and security constraints.
In his presentation, Salehi walked through where the major standards fit: SOSA for hardware interoperability, CMOSS for consolidating electronic warfare and C5ISR gear into a shared chassis, and FACE for portable avionics software. None of them compete with each other; the work is deciding which standard governs which layer, then documenting the boundaries between them clearly enough that suppliers and integrators can actually build to them.
The second half of the session turned to a harder problem: what happens when multiple applications of different criticality levels share the same processor? Salehi explained how two programs can end up coupled through shared hardware, like memory controllers or caches, even with no direct software connection between them, and why that hidden coupling has to be proven safe rather than assumed.
The session ended with an audience Q&A. Those answers follow below, lightly edited for readability.
Could you define the roles and responsibilities involved in a program interface contract? I understand the MOSA convergence drivers, but the mechanisms need to translate into behaviors for both acquirers and integrators. How can they best affect this change?
With MOSA convergence, especially given the evidence, the contract needs to explicitly define how the standards and interfaces get allocated between the parties involved. The operating system plays a big role here. It has to support the standards and interfaces application developers need, but it also has to prove the assurance, validation, and verification evidence showing that those standards and libraries are actually certified. That gives you the highest degree of assurance and lets you move through the certification path without hitting a wall. MOSA-aligned standards help by providing common, open interfaces that reduce proprietary lock-in, make it easier to adapt to new technology, and smooth the certification roadmap.
Where do you see a separation-kernel hypervisor fitting into a MOSA architecture, especially as platforms consolidate more mixed-criticality workloads onto shared compute?
I'd describe the separation kernel as the runtime mechanism that turns an open architecture into a controlled execution architecture. MOSA gives you modularity at the interfaces, but once you start consolidating multiple workloads onto the same hardware, you also have to manage what those workloads are allowed to do and how they affect each other. That becomes particularly important with mixed criticality. A separation kernel lets you explicitly define the boundaries and interfaces controlling those workloads: allocating CPU, memory, devices, and interrupts, and defining exactly what information flow is permitted between one subject and another.
That gives you two main benefits. First, fault and resource containment. A lower-criticality workload doesn't automatically get to interface with a higher-criticality one just because they're on the same processor. If the lower-criticality function fails, it shouldn't touch the higher-criticality one, and you can build a fault mitigation plan around that lower-criticality box or application without putting the higher-criticality function at risk. The second is lifecycle flexibility. You can update or replace one subject without rebuilding the entire software domain around it, which checks a box for safety certification.
If a program wants to adopt MOSA today, what should it think about early in the architecture to avoid creating another form of vendor lock-in?
Having something that says "I'm FACE conformant" or "I'm SOSA conformant" is good, but it doesn't mean you're free from vendor lock-in. You need to ask the vendor directly: if I want to replace this interface later, does that require extra regression testing? What are the requirements if I change the underlying technology? What gets affected during that transition? When you're evaluating system requirements and adopting a MOSA-aligned or FACE-conformant approach, you also need to confirm it won't change overall system performance or timing behavior. That's what needs to get worked out at the earliest stage, rather than picking a processor and a piece of software and assuming conformance alone solves the problem.
You talked about unikernels during the presentation. Where does something like LynxElement make sense compared with using a traditional RTOS or Linux guest?
A unikernel isn't a replacement for every RTOS or general-purpose operating system. Each one serves its own purpose. But when you're looking at multicore certification and need mixed-criticality components to work together with less burden from interface analysis and shared-resource concerns, that's where the unikernel approach earns its place. LynxSecure paired with LynxElement can solve that problem. If someone needs rich libraries and interfaces, say, for software testing in a language like Python that isn't built for safety-critical work, a general-purpose operating system is the better fit. It comes down to whether you have safety or security requirements to mitigate and whether you're working with heterogeneous multicore systems. Those factors determine whether a unikernel or a broader, library-rich operating system makes more sense.
Traditional integrated modular avionics and ARINC 653 scheduling are often associated with static cyclic schedules. As we move toward multicore and heterogeneous compute, does that model still scale, or do we need a different approach?
Combining a unikernel approach with LynxSecure isn't about replacing the entire IMA architecture. It's about bringing a more deterministic approach to IMA and making certification more approachable. An applicant who goes the unikernel route while satisfying IMA requirements frees themselves from vendor lock-in, whether that unikernel comes from Lynx or another provider down the road. It reduces application overhead and gives you a compiled execution boundary that stays open and standards-aligned, while still delivering timing and space partitioning. The model isn't meant to change application behavior or how integration with other hardware modules works. It's meant to make that path more robust and less complex going forward.
Do you find any common misconceptions about MOSA and the related standards?
The most common one is people treating MOSA as if it were a standard itself, rather than an approach. MOSA isn't a document you can pull requirements from and apply directly to a software development lifecycle. It's a philosophy, and understanding that distinction matters. MOSA has also matured well beyond the U.S. European countries are adopting it, allied nations across Eastern Asia are applying MOSA-style approaches under different names, and FACE conformance is showing up on platforms globally. That international traction says a lot about the value MOSA is bringing to avionics software and hardware today.
Watch the live recording and learn more: LYNX MOSA Virtual Summit