Real-time operating systems

Why it matters

Embedded teams need a route that combines least authority with deterministic execution and supported peripherals.

In brief

Real-time operating systems bring scheduling, interrupt, latency, memory and certification constraints that differ from general-purpose OS work. CHERI and CHERIoT can add memory protection and compartments, but the whole RTOS and SoC must preserve required timing and safety behaviour.

Key considerations

1. Model

Compare CHERIoT RTOS, FreeRTOS adaptations and other current projects by architecture and compartment model.

2. Timing

Measure worst-case paths, interrupt behaviour, context switches and fault recovery on target hardware.

3. Assurance

Trace toolchain, kernel, libraries, drivers and application components to the evidence required by the product domain.

Evidence and caveats

Functional memory-safety evidence does not establish real-time deadlines or safety certification. Validate these independently and together.

Treat build, test, integration, upstream and maintained support as distinct states. Name the target and last verified date.

Primary routes

• CHERIoT project
• University of Cambridge CHERI software