Designing Industrial Systems for Mixed RTOS + Linux Architectures (AMP)

Why Industrial Platforms Rarely Run “Only Linux” Anymore

Industrial systems increasingly combine two worlds that historically evolved separately. On one side there is deterministic real-time control with strict latency bounds, often implemented on microcontrollers or RTOS-based cores. On the other side there is high-level logic, connectivity, visualization, analytics, and cybersecurity stacks that benefit from Linux ecosystems.

Modern industrial SoCs frequently integrate heterogeneous cores: for example, high-performance application cores (e.g., Cortex-A class) alongside real-time cores (e.g., Cortex-R or Cortex-M). Instead of virtualizing everything under a single operating system, many designs adopt an asymmetric multiprocessing (AMP) model. In AMP, each core runs its own operating system instance, optimized for its function.

Linux handles networking, cloud connectivity, databases, containerized services, and UI frameworks. The RTOS handles time-critical tasks such as motor control loops, safety monitoring, or fast I/O processing. The separation is architectural, not cosmetic.

The design challenge is not just “running two OSes.” It is ensuring temporal isolation, safe communication, and predictable behavior under fault conditions.

SMP vs AMP: Why Asymmetry Is Often Intentional

In symmetric multiprocessing (SMP), one OS schedules tasks across all cores. This model works well when workloads share similar timing characteristics. Linux SMP systems with PREEMPT_RT patches can deliver soft real-time performance, but they still operate under a unified scheduler.

AMP takes a different approach. Each core or cluster has:

• Its own OS instance
• Independent scheduler
• Dedicated memory regions
• Explicit communication channels

The benefit is strong temporal isolation. A Linux kernel driver spike or container restart cannot preempt a motor control ISR running on a dedicated RTOS core.

This architectural separation is particularly relevant in industrial control, robotics, power electronics, and high-speed measurement systems where deterministic control must not be influenced by non-deterministic workloads.

Partitioning Responsibilities: Control vs Services

A clean AMP design begins with responsibility partitioning. Real-time domains typically include:

• Closed-loop motor control
• Fast ADC/DAC processing
• Safety watchdog logic
• Fieldbus stack timing

Linux domains typically include:

• OPC UA or MQTT stacks
• Web servers and REST APIs
• HMI frameworks
• Data logging and storage
• OTA update logic

The partition must reflect timing criticality, not developer convenience. If a function has a strict deadline in the tens or hundreds of microseconds, it belongs in the RTOS domain. If it tolerates millisecond-level variability, Linux may be appropriate.

Misplacing tasks is one of the most common AMP design errors.

Deterministic Isolation: More Than Core Assignment

Assigning one core to RTOS and another to Linux is not sufficient. Determinism depends on:

• Dedicated interrupt routing
• Separate memory regions
• Controlled DMA ownership
• Cache coherency handling
• Bus arbitration behavior

Industrial SoCs share memory buses, interconnect fabrics, and sometimes last-level caches. Even if Linux runs on a separate core, heavy I/O activity can introduce bus contention affecting RTOS memory access latency.

Designers must analyze worst-case memory latency and bus load. In high-performance systems, quality-of-service (QoS) mechanisms in the interconnect are configured to prioritize real-time masters.

AMP determinism is a system-level property, not a scheduler setting.

Inter-Processor Communication (IPC) Models

RTOS and Linux domains must exchange data. IPC design directly impacts latency, safety, and fault containment.

Common mechanisms include:

• Shared memory with ring buffers
• Message queues via RPMsg
• Mailbox hardware
• VirtIO-based communication

Shared memory is low latency but requires strict ownership and synchronization discipline. Lock-free ring buffers are common in data acquisition systems where the RTOS pushes samples and Linux consumes them asynchronously.

RPMsg is widely used in heterogeneous SoCs supporting OpenAMP frameworks. It abstracts message passing but introduces additional software layers that must be evaluated for latency and failure behavior.

IPC must be bounded and monitored. Uncontrolled blocking between domains defeats isolation goals.

Memory Architecture and Safety Boundaries

Industrial and safety-related systems often require clear separation between safety-critical and non-safety domains. In mixed RTOS + Linux architectures, this separation is implemented through:

• Memory Protection Units (MPU) on RTOS cores
• MMU-based isolation on Linux cores
• Hardware firewalls in the SoC interconnect
• Controlled shared memory windows

If Linux is compromised due to a cybersecurity incident, the RTOS domain must remain unaffected. This requires that Linux cannot arbitrarily access RTOS memory or peripherals.

AMP therefore becomes a security architecture as well as a real-time architecture.

Device Ownership and Driver Strategy

Peripheral ownership must be explicitly defined. Ambiguity leads to race conditions or non-deterministic behavior.

In typical industrial AMP systems:

• Time-critical peripherals (PWM, ADC triggers, encoder inputs) are owned by RTOS.
• High-level interfaces (Ethernet stacks, USB, storage) are owned by Linux.

Sometimes Linux needs access to data generated by RTOS-controlled peripherals. In such cases, the RTOS exports processed or buffered data via IPC rather than allowing Linux direct hardware control.

Driver duplication is avoided by defining clear ownership boundaries. Attempting to share device drivers across OS domains often introduces instability.

Latency Analysis in AMP Systems

Designing AMP systems requires explicit latency modeling of cross-domain interactions.

If a control decision depends on data processed in Linux, the end-to-end latency must include:

• RTOS data acquisition delay
• IPC transfer delay
• Linux scheduling delay
• Application processing time
• IPC response delay back to RTOS

This chain often exceeds deterministic budgets. Therefore, time-critical control loops must remain fully contained within the RTOS domain. Linux may supervise, log, or visualize but should not participate in hard real-time control paths.

AMP architectures succeed when cross-domain dependencies are minimized in critical loops.

Boot and Update Strategy

Industrial platforms must support reliable startup and field updates.

In AMP systems:

• Bootloaders initialize hardware and load both OS images.
• RTOS may start first to establish safety monitoring.
• Linux may start later to enable networking and UI.

Over-the-air update mechanisms typically reside in Linux, but RTOS firmware must also be updatable. Secure boot chains must verify both images independently.

Failure scenarios must be defined. If Linux fails to boot, does the RTOS continue operating in degraded mode? If RTOS fails, should Linux shut down?

These policy decisions define system resilience.

Real Deployment Trade-Offs

AMP architectures provide strong isolation and flexibility, but they introduce complexity.

Advantages include deterministic timing isolation, safety domain separation, and the ability to combine rich Linux ecosystems with strict real-time control.

Constraints include increased integration effort, IPC validation overhead, debugging complexity across OS boundaries, and more elaborate boot and update processes.

Compared to a pure Linux PREEMPT_RT system, AMP provides stronger worst-case guarantees. Compared to a pure RTOS system, AMP offers broader connectivity and software reuse.

The correct choice depends on latency requirements, safety goals, cybersecurity exposure, and lifecycle expectations.

Common Failure Modes

Industrial AMP projects often encounter similar issues:

• Underspecified IPC protocols leading to blocking behavior
• Bus contention affecting RTOS timing
• Inadequate cache coherency handling in shared memory
• Over-reliance on Linux for near-real-time tasks
• Lack of unified logging across domains

These are not OS problems; they are architectural mistakes. AMP requires deliberate systems engineering, not incremental feature addition.

When AMP Is the Right Choice

AMP is justified when:

• Hard real-time control must coexist with rich networking or UI stacks
• Safety-critical functions require isolation from user-space applications
• Deterministic fieldbus handling must not be interrupted by cloud traffic
• Lifecycle updates demand Linux-level flexibility

If the system has minimal networking and moderate timing constraints, a single RTOS may be simpler. If timing constraints are soft and integration effort must be minimized, Linux with real-time extensions may suffice.

AMP sits between these extremes.

AI Overview

Mixed RTOS + Linux architectures in industrial systems use asymmetric multiprocessing (AMP) to isolate deterministic control tasks from non-deterministic services. RTOS domains handle hard real-time loops, fieldbus timing, and safety logic, while Linux domains manage connectivity, HMI, and data services. Effective AMP design requires explicit core partitioning, memory and interrupt isolation, controlled inter-processor communication, and careful latency modeling of cross-domain interactions. The approach increases integration complexity but provides stronger temporal and safety isolation than single-OS solutions.