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.
