The Modular Open Systems Approach has become a central part of how defense and aerospace programs think about modernization. Standards such as SOSA, CMOSS, FACE, HOST, OpenVPX, VICTORY, MORA, OMS/UCI, and ARINC 653 all play an important role.
But adopting more open standards does not automatically create an open architecture.
The harder part is making those standards work together across hardware, software, networks, runtime infrastructure, safety, security, and acquisition. That is where the idea of MOSA convergence becomes important. Convergence does not mean collapsing all of these standards into one framework. It means understanding where each standard fits, defining the boundaries between them, and making those boundaries precise enough that the platform can evolve without reopening every integration decision.
That is the real promise of MOSA.
Convergence, Not Acronyms
MOSA is about making standards, runtime architecture, safety, and lifecycle work together.
Why MOSA Standards Exist
Many mission systems still carry the legacy of platform-specific architectures. New capabilities were often introduced as new boxes, each with its own processors, power, cooling, networking, software stack, and integration requirements. Over time, that creates more than a hardware problem. Every new component can introduce additional qualification, verification, configuration, sustainment, and regression work.
Why Standards Exist
Reduce integration cost and make capability insertion faster and more affordable
In many cases, the recurring cost is not the component itself. It is the integration surrounding it. MOSA is intended to change that dynamic by creating stable architectural boundaries where components can evolve more independently.
The goal is not to make every supplier or product look the same. Programs still need room for differentiation. Instead, the focus is on identifying the interfaces that need to remain stable so that hardware, software, or mission functions can be replaced, upgraded, recomposed, or competed without redesigning the platform around them. That is why MOSA is as much a business and acquisition strategy as it is a technical one.
Different Standards Address Different Seams
One reason MOSA discussions can quickly become confusing is that the standards involved are solving different problems.
Then there is a broader set of adjacent standards, including OpenVPX, VICTORY, MORA, OMS/UCI, ARINC 653, POSIX, TSN, and Ethernet, each addressing a narrower part of the overall architecture. The important point is that none of these standards needs to replace the others. A successful architecture uses each one where it adds the most value and then defines how it connects to the layers around it. That is what convergence looks like in practice.
Open the Right Seams
MOSA does not require every internal design choice to be standardized. The more useful question is where change is expected to happen. New processors will arrive. Sensors will evolve. Suppliers will change. Applications will be upgraded. Threats and mission requirements will shift.
Open the Right Seams
Standardize where change happens, not every internal design decision.
Those are the places where stable, controlled interfaces matter most. A good interface contract also has to go beyond simple syntax. It may need to capture semantics, timing, error behavior, resource assumptions, security boundaries, versioning, and the evidence required to show that the interface behaves as expected. This is where vague claims such as “SOSA-aligned” or “FACE-compatible” can fall short.
For a program, the real question is much more specific: which version, which profile, which options, what tailoring, and what evidence? The most valuable artifacts are often the ones that are less visible: interface control documents, machine-readable schemas, data mappings, partition maps, timing allocations, configuration baselines, conformance tests, and regression assets. These are the things that make future integration repeatable.
Standards Address Different Seams
Each standard solves a different part of the problem
Where Safety Makes MOSA Harder
The challenge becomes more complicated when open architectures meet safety-critical and mixed-criticality computing. A portable application is not automatically a certifiable application once it is integrated into a system.
Safety & Mixed Criticality Challenges
Applications may share operating-system services, schedulers, drivers, memory, queues, devices, or communication paths. On multicore processors, even software that does not directly communicate can affect other workloads through shared caches, memory controllers, interconnects, interrupts, I/O, or accelerators. That means certification scope tends to follow coupling, not organizational boundaries.
A change to a low-criticality application can have a much wider impact if it shares enough of the platform with higher-criticality software. As coupling increases, so does the amount of evidence that may need to be revisited. For that reason, safety partitioning should not be treated as a certification activity that comes after the architecture is defined.
It needs to be part of the architecture from the beginning.
Separation as an Architectural Boundary
One way to manage this is to introduce a separation-kernel layer directly on the hardware and use it to create clearly bounded execution domains. With a Type 1 separation-kernel hypervisor such as LynxSecure, CPU cores, memory, devices, interrupts, and communication paths can be explicitly assigned to individual subjects or virtual machines. A high-criticality control function can run in one domain, a mission application in another, a sensor workload in another, while maintenance software or Linux-based services operate separately.
Communication between those domains can then be restricted to explicitly defined paths rather than occurring through shared or accidental state. This does not remove the need for safety analysis or certification evidence. It does, however, make the architecture more explicit. Resource ownership, data flow, and system boundaries become easier to see, review, and test. It also changes the relationship between criticality and hardware.
Different criticality levels no longer have to imply different physical boxes. Multiple functions can share a common compute platform while still operating within separated execution environments and controlled resource boundaries.
The Role of Minimal Runtime Environments
The runtime inside each of those boundaries matters as well. A traditional operating system can provide a broad set of services, which is appropriate for many applications. But some mission-critical functions may need only a small subset of that functionality.
That is where a unikernel approach becomes interesting. With LynxElement, for example, an application can be combined with only the operating-system services it requires to create a focused, single-purpose runtime image. Unused services, drivers, shells, and background processes do not need to be part of that image. Hosted within a separation-kernel partition, that function can then be given explicit CPU, memory, I/O, communication, and timing policies. This can support IMA- and ARINC 653-style architectural objectives in which multiple functions share hardware while remaining separated in space, time, and policy. The architecture still needs the appropriate API profile, scheduling definition, health monitoring, data-flow controls, timing evidence, conformance testing, and system-level analysis. But reducing the amount of runtime software associated with a function can make that environment easier to characterize and reason about.
Minimal Runtime Environments
Unikernels include only what the application needs
MOSA Needs More Than Application and Hardware Interfaces
This points to a broader architectural issue. It is easy to think about MOSA in terms of portable software at the top and interchangeable hardware at the bottom. But there is a critical layer in between: the runtime infrastructure. The operating system provides application services, scheduling, device abstraction, networking, diagnostics, security services, and other platform capabilities. The hypervisor or separation kernel defines the boundaries between execution domains and controls how resources are allocated and shared. Above that, different runtime environments can coexist: RTOS instances, unikernels, Linux guests, bare-metal functions, or legacy software.
MOSA Needs a Runtime Architecture
These runtime decisions are not implementation details. They influence portability, isolation, determinism, security, certification scope, and lifecycle flexibility. They therefore need to be part of the MOSA baseline.
The Real Value Is Reusable Integration
MOSA is often discussed in terms of reusable components, but the larger opportunity is reusable integration. A well-structured architecture can allow applications, cards, operating-system environments, compute hardware, and mission functions to evolve on different timelines. The most valuable assets may not be the components themselves. They may be the interface definitions, configuration models, adapters, performance data, qualification evidence, and automated regression tests that accumulate around them.
If those assets are preserved across refresh cycles, the program does not have to start over each time a component changes. That is when modularity begins to translate into meaningful lifecycle value.
From Standards Compliance to Architecture Discipline
MOSA ultimately comes down to a few practical questions.
And what evidence shows that a new component can be introduced without forcing the rest of the platform to be requalified?
Programs that can answer those questions are moving beyond standards adoption and toward real architectural modularity. The objective should not be to accumulate more acronyms. It should be to create stable seams, explicit runtime boundaries, and reusable evidence.
The Real Payoff: Reusable Integration
When hardware standards, software portability, separation, safety, security, acquisition, and lifecycle governance are designed together, MOSA becomes much more than a compliance requirement. It becomes a practical foundation for continuous capability insertion.
Watch our recent webinar discussing bridging the AI deployment gap with LYNX MOSA.ic.AI. Click here to read our LYNX MOSA.ic technical whitepaper.