Open IMA: Running Third-Party OS on LYNX MOSA.ic™

A Partitioned, Multi-OS Architecture with Peer Subjects  

Modern avionics systems increasingly require multiple operating environments running concurrently:

• Safety-critical flight control
• Mission processing
• Security services
• Maintenance functions
• AI / GPU acceleration
• Legacy subsystems

Many programs bring legacy RTOS investments (e.g., VxWorks®) that remain mission essential. Rather than forcing replacement, LYNX MOSA.ic ™ enables a true multi-subject architecture, allowing multiple operating systems, including LynxElement®, LynxOS-178®, VxWorks®, Yocto-Linux®, and Zephyr®, to operate side by side within a partitioned system.

This approach reflects open IMA principles: preserving application portability, encouraging architectural openness, and avoiding vendor lock-in.

The key is not the individual OS.
The key is the supervisory partitioning layer beneath them.

Architectural Model  

In a MOSA.ic deployment, a separation kernel / hypervisor layer provides:

• Time partitioning
• Space partitioning
• CPU core allocation
• Device assignment
• Controlled inter-subject communication

Above this layer, multiple subjects execute independently.

High-Level Architecture  

In this model:

• LynxOS-178 is one subject
• LynxElement is one subject
• VxWorks, Yocto-Linux, Zephyr are peer subjects
• All are equally isolated by the underlying partitioning layer

No subject can interfere with the resources allocated to another subject.

Role of LynxOS-178 in This Model  

LynxOS-178 typically serves high-assurance safety domains.

In a mixed-criticality configuration LynxOS-178:

• Hosts safety-critical applications, including DAL A
• Run in its own memory region
• Supports multiple instances across multiple CPU cores
• Operates independently of other RTOS domains

If another subject (e.g., Yocto-Linux) is modified, the LynxOS-178 partition remains unaffected, provided partition boundaries remain unchanged.

This approach model strengthens DO-178C system safety arguments and aligns with IMA and DO-297 best practices.

Role of LynxElement in This Model  

LynxElement may serve as a:

• Secure services domain
• Systems management partition
• I/O consolidation domain
• Gateway or middleware environment
• Safety-critical isolation region for high-change components

LynxElement is not the supervisory hypervisor in this configuration. It runs as a peer subject under the same partitioning controls as the other RTOS instances.

This allows:

• Independent lifecycle management
• Controlled communication channels
• Clear separation between safety and non-safety domains

Boot Flow in a Multi-Subject MOSA.ic System  

Step 1: Platform Initialization

Firmware initializes hardware and verifies system integrity.

Step 2: Separation Kernel / Hypervisor Loads

The partitioning layer becomes the most privileged software component.

It establishes:

• Memory regions
• Core allocation
• Device mapping
• Interrupt routing
• Scheduling configuration

Step 3: Static Partition Configuration Applied

Example configuration:

Partition A: LynxOS-178
Cores: 0-1
Memory: 512 MB
Devices: ARINC 429, Flight I/O

Partition B: LynxElement
Core: 2
Memory: 256 MB
Devices: Ethernet, Storage

Partition C: VxWorks
Core: 3
Memory: 256 MB
Devices: Sensor Bus

Partition D: Yocto-Linux
Shared core windowed schedule
Memory: 256 MB
Devices: Display Controller

Step 4: Subject Launch

Each OS image is loaded into its assigned memory and executed.

From each subject’s perspective:

• It owns its assigned cores/time window
• It cannot access other memory
• It cannot modify global configuration

Isolation is enforced by hardware and hypervisor policy.

Time and Space Partitioning  

Space Partitioning

• Fixed physical memory allocation
• No dynamic cross-access
• IOMMU-protected DMA
• Device ownership statically defined

Time Partitioning

Depending on system design:

• Dedicated core model (strong isolation)
• Static cyclic scheduling model (IMA-style)

This prevents timing interference across subjects.

Inter-Subject Communication  

Subjects may communicate only through defined channels such as:

• Configured shared memory buffers
• Message queues mediated by the hypervisor
• Virtualized network interfaces
• Health monitoring signals

Example:

[LynxOS-178] <---- shared memory ----> [LynxElement]

[LynxElement] <---- message channel ----> [Yocto-Linux]

All communication paths are:

• Declared at configuration time
• Access-controlled
• Size- and rate-limited
• Deterministic

DO-178C Considerations (High-Level)

This peer-subject model supports certification objectives through:

Clear Isolation Boundaries

Safety-critical software (e.g., in LynxOS-178) is protected from lower-criticality domains.

Change Containment

Changes inside a Yocto-Linux or Zephyr partition do not propagate into the LynxOS-178 partition unless shared interfaces are modified.

Deterministic Scheduling

Static configuration supports timing analysis and worst-case execution validation.

Configuration Control

Partition definitions are part of the certified baseline.

The separation kernel provides the enforcement mechanism; each RTOS remains responsible for its internal certification scope.

Why This Matters for MOSA

MOSA is not about replacing operating systems. It is about enabling controlled coexistence.

This architecture allows:

• LynxOS-178 for high-assurance domains
• LynxElement for modular integration
• VxWorks for legacy subsystems
• Yocto-Linux for displays
• Zephyr for embedded peripherals

All within one deterministic, policy-driven framework.

The Architectural Principle

The value of MOSA.ic is not that it dictates which RTOS you must use.

It ensures that:

• No single RTOS decision locks the entire platform
• Domains remain isolated
• Hardware refresh is manageable
• Certification scope remains bounded
• Third-party software can be integrated safely

The operating systems are peers.

The architecture is the authority.

Want to learn more about how Lynx can help you? Connect with us.