PikeOS Architecture

It enables mixed-criticality systems, where applications with varying Safety and Security requirements — including legacy software and state-of-the-art algorithms — can coexist on the same hardware platform.

Originating from the ARINC 653 Avionics partitioning standard, PikeOS provides:

• Temporal partitioning: Strict CPU time allocation
• Spatial partitioning: Complete memory and I/O isolation
• Controlled inter-partition communication for both Safety and Security compliance

This foundation allows developers to run multiple OS personalities — such as Linux, Android, Windows, ARINC 653, POSIX, Ada runtimes, or PikeOS Native — concurrently and securely.

Partitions

In PikeOS, a partition is an isolated execution environment that operates on top of the PikeOS System Software (PSSW). Each partition can host its own operating system personality or a bare-metal runtime environment.

• Complete Isolation: Hardware and time resources are strictly separated, enabling mixed-criticality systems—for example, running Safety-critical software alongside non-critical systems without mutual interference
• Personality Requirement: Every partition must run at least one personality, which defines the API and runtime environment visible to applications
• Unified Management: Although partitions appear independent, they are managed and scheduled centrally by the hypervisor to meet both hard real-time and best-effort performance goals

Microkernel

The foundation of PikeOS is its microkernel, a minimal yet highly reliable software layer responsible for enforcing isolation, managing CPU resources, and mediating access to hardware.

• Common Software Layer: The same microkernel code base runs on all supported architectures, ensuring consistent functionality across platforms
• Architecture Support Package (ASP): Hardware-specific adaptations for a particular CPU architecture (e.g., x86, ARMv8, PowerPC, RISC-V). This layer contains low-level assembly code, interrupt handling, and MMU configuration logic.
• Platform Support Package (PSP): Hardware-specific adaptations for a particular board or SoC platform—sometimes referred to as a “minimal Board Support Package (BSP)”—containing drivers and initialization routines for platform-specific peripherals

PikeOS System Software (PSSW)

The PSSW is the first user-space component launched after the PikeOS microkernel has initialized the hardware.

• Boot Role: It reads the Virtual Machine Image Table (VMIT), which contains configuration data for all partitions, personalities, and inter-partition communication channels
• Partition Control Server: The PSSW acts as a “system service provider” for all partitions, offering central management for startup, shutdown, fault handling, and communication infrastructure
• Abstraction Layer: By centralizing configuration handling, the PSSW ensures that application partitions are hardware-independent and can be easily ported between supported architectures

Hardware Layer

The hardware layer provides the physical foundation for the PikeOS system, including processors, memory, and peripherals.

• Bootloader: Typically supplied by a third party to initialize the hardware and load the PikeOS microkernel
• Custom Options: SYSGO can deliver tailored boot loaders for specific platforms, adding additional features such as secure boot, chain-of-trust verification, or deterministic startup sequences.
• Peripheral and I/O Interfaces: Supports a wide range of input/output capabilities, such as serial ports, Ethernet, CAN, PCIe, GPIO, or industry-specific buses like AFDX or ARINC 429 (Avionics), depending on the Platform Support Package (PSP).

PikeOS Safety Architecture

PikeOS is built on a minimalistic, formally verified separation kernel designed to meet the highest Safety Integrity Levels (SIL) across industries. Its time and resource partitioning model ensures that faults are contained within their partition, preventing propagation to other critical functions.

Safety Engineering Highlights:

• Deterministic Scheduling: Combines time-driven and priority-driven models to guarantee hard real-time response for Safety-critical tasks
• Spatial Isolation: MMU/MPU-based partitioning ensures memory protection between mixed-criticality applications
• Safety-certifiable: Developed under strict process compliance to standards such as:
• DO-178C DAL A (Avionics)
• ECSS Cat. A (Space)
• ISO 26262 ASIL D (Automotive)
• EN 50128 SIL 4 (Railway)
• IEC 61508 SIL 3/4 (Industrial)
• IEC 62304 (Medical)
• Certification Kits: Pre-prepared documentation, traceability matrices, and test artefacts for streamlined certification

RTOS Safety     |     Safety Certification

PikeOS Security Architecture

PikeOS implements Multiple Independent Levels of Security (MILS), ensuring controlled information flow between isolated domains. The microkernel is formally verified for Security properties and hardened against modern attack vectors.

Security Engineering Highlights:

• Common Criteria EAL 5+: Certified design, engineered for high-assurance evaluations and compliance with stringent Security standards
• DMA Attack Prevention: IOMMU-based filtering blocks malicious or unintended direct memory access from untrusted devices
• Least-Privilege Enforcement: Strict capability-based access model reduces attack surface and mitigates privilege escalation
• Side-Channel Resistance: Cache partitioning and scheduler-level isolation counter timing and speculative execution attacks
• Secure Boot & Binary Verification: Ensures authenticity and integrity of system images before execution
• Cryptographic Communication: Optional built-in encryption modules for inter-partition and external communication

RTOS Security     |     Security Certification

Guest OS Virtualization Models

PikeOS supports two primary virtualization methods:

1. Performance-optimized Para-Virtualization: Minimal changes to guest OS for near-native performance
2. Hardware-assisted Virtualization: Using CPU features (e.g., Intel VT-x, ARM VE) for unmodified guest OS execution

Guest OSes can:

• Access hardware via native drivers, - or -
• Use PikeOS-provided driver infrastructure for unified device access

IOMMU integration prevents untrusted guests from initiating unauthorized DMA transfers.

Guest OSs, RTEs & APIs

Scheduling for Mixed-Criticality Systems

PikeOS implements a hybrid time-driven + priority-based deterministic scheduler:

• Time-driven scheduling ensures deterministic CPU allocation for hard real-time workloads
• Priority-based scheduling allows best-effort processing for non-critical workloads

This design enables:

• Static time slices for guaranteed execution windows
• Dynamic redistribution of unused CPU time to lower-priority tasks without violating real-time guarantees

Example:

• Mid-priority VMs for real-time Avionics control loops
• Low-priority VMs for logging, diagnostics, UI rendering

Multi-Core & Hardware Independence

Execution Models

Supports SMP (Symmetric Multi-Processing) and AMP (Asymmetric Multi-Processing):

• SMP: Partitions share cores dynamically for load balancing
• AMP: Partitions pinned to dedicated cores for strong isolation

Developers can mix models per partition, balancing certification requirements with performance needs.

Hardware Portability

PikeOS' partitioning model is hardware-agnostic — no dependency on specific virtualization extensions. Porting is simplified via PikeOS’ Architecture Support Package (ASP) and Platform Support Package (PSP) separation.

Certification Advantages

Partition-centric Certification

Each partition can be certified independently, reducing scope and cost:

• Avionics Safety-critical partition: DO-178C DAL A
• Linux-based HMI partition: No safety certification needed

Certification Kits

Available documentation & artefacts:

• Source code evidence for the microkernel
• Safety / Security manuals
• Traceability matrices
• Test reports & qualification tools

Advanced Health Monitoring & Recovery

Integrated ARINC 653-compliant Health Monitoring:

• Detects partition faults & hardware errors
• Executes predefined recovery actions (restart, isolate, or fail-safe switch)
• Ensures predictable system recovery under fault conditions

Energy & Resource Efficiency

• Partition-level power management: Selectively throttle or suspend idle partitions
• Consolidation of multiple devices into one hardware platform reduces weight, energy consumption, cabling, and BOM costs