Real-Time Operating Systems

Introduction

A Real-Time Operating System (RTOS) is designed to process data and respond to events within strict, predictable time constraints. Unlike general-purpose operating systems where "fast" is desirable, in an RTOS "on time" is mandatory. Missing a deadline in a real-time system can range from annoying (a dropped video frame) to catastrophic (an airbag deploying too late).

Consider a car's anti-lock braking system. When sensors detect wheel lockup, the system must release brake pressure within milliseconds. If the OS is busy running a background task and delays this response, the consequences are potentially fatal. This is why real-time systems require fundamentally different design principles than your desktop operating system.

Hard Real-Time vs. Soft Real-Time

Hard Real-Time Systems

In hard real-time systems, missing a deadline is a system failure. The correctness of the computation depends not only on producing the right result but producing it within the deadline.

Examples:

• Aircraft flight control systems
• Cardiac pacemakers
• Industrial robot controllers
• Nuclear reactor monitoring
• Anti-lock braking systems (ABS)

Characteristics: Deterministic behavior guaranteed, worst-case execution time (WCET) analyzed for all tasks, no virtual memory or dynamic memory allocation (unpredictable latency).

Soft Real-Time Systems

Soft real-time systems have deadlines, but occasional misses degrade quality rather than causing failure. The system continues to function, just with reduced performance.

Examples:

• Video streaming (dropped frames cause stuttering, not crashes)
• Online gaming (lag is annoying but recoverable)
• VoIP calls (occasional audio glitches)
• GPS navigation display updates

Characteristics: Statistical guarantees (meet deadlines 99% of the time), graceful degradation on overload, may use general-purpose OS with real-time extensions.

RTOS Architecture

An RTOS kernel is minimal and predictable. Its key components are:

Scheduler

The scheduler is the heart of an RTOS. It must make scheduling decisions in bounded time — typically O(1) or O(log n). Priority-based preemptive scheduling is standard: the highest-priority ready task always runs immediately.

Interrupt Latency

Interrupt latency — the time between an interrupt occurring and the handler starting — is a critical RTOS metric. A good RTOS guarantees worst-case interrupt latency in the microsecond range.

Components of interrupt latency:

1. Hardware recognition time
2. Time to save current context
3. Time to identify interrupt source
4. Time to start handler execution

Context Switch Time

RTOS context switches must be fast and deterministic. While Linux might take 5-20 microseconds for a context switch, an RTOS like FreeRTOS on a Cortex-M4 completes it in under 1 microsecond.

Real-Time Scheduling Algorithms

Rate Monotonic Scheduling (RMS)

A static-priority algorithm where tasks with shorter periods get higher priority. It is optimal among fixed-priority algorithms.

Rules:

• Each task has a fixed period and worst-case execution time
• Priority assigned inversely proportional to period (shorter period = higher priority)
• Preemptive — higher priority task immediately preempts lower

Schedulability Test:

For large n, the utilization bound converges to ln(2) ≈ 0.693. So if total CPU utilization is below 69.3%, RMS guarantees all deadlines are met.

Earliest Deadline First (EDF)

A dynamic-priority algorithm where the task with the nearest deadline gets highest priority. It is theoretically optimal — it can schedule any task set that is schedulable.

Schedulability Test:

EDF achieves 100% CPU utilization (compared to RMS's ~69.3%), but it is harder to implement and behaves unpredictably under overload.

Priority Inversion Problem

When a high-priority task is blocked waiting for a resource held by a low-priority task, and a medium-priority task preempts the low-priority task, the high-priority task is effectively blocked by the medium-priority task.

Solutions:

• Priority Inheritance: Temporarily raise the blocking task's priority to that of the highest-priority waiting task
• Priority Ceiling: Each resource has a ceiling priority; any task locking it runs at ceiling priority

The Mars Pathfinder incident (1997) is a famous example where priority inversion caused system resets until engineers patched the software remotely.

Popular RTOS Examples

RTOS vs. General-Purpose OS

Designing for Real-Time

When developing for an RTOS, follow these principles:

1. Analyze worst-case execution time for every task — average case is irrelevant
2. Avoid dynamic memory allocation — malloc/free have unpredictable timing
3. Minimize critical sections — long critical sections increase blocking time
4. Use priority inheritance for shared resources
5. Keep ISRs short — defer processing to tasks using deferred procedure calls
6. Test under maximum load — a system that works at 50% load may fail at 90%

Applications in Modern Systems

Real-time operating systems are invisible but everywhere:

• Your car has 30-100 microcontrollers running RTOS for engine control, braking, airbags
• Medical devices (infusion pumps, ventilators) use RTOS for patient safety
• 5G base stations use RTOS for signal processing with microsecond timing
• Industrial PLCs run RTOS for factory automation
• Drones use RTOS for flight controller stability

Key Takeaways

• Real-time means "correct AND on time" — not just "fast"
• Hard real-time: deadline miss = failure; Soft real-time: deadline miss = quality loss
• RMS is optimal for fixed-priority; EDF is optimal for dynamic-priority
• Priority inversion must be solved with inheritance or ceiling protocols
• RTOS kernels are minimal, deterministic, and avoid unpredictable operations