RTOS Concepts

In embedded systems, the software that manages hardware resources and task execution is called an operating system. A Real-Time Operating System (RTOS) is a specialized OS designed to process tasks within strict, deterministic time constraints. Understanding the difference between RTOS and a General Purpose Operating System (GPOS) is fundamental for any embedded systems engineer or GATE aspirant.

Core Concept Explanation

A General Purpose Operating System (GPOS) like Linux or Windows is designed to maximize average throughput and user experience. It uses time-sharing, which divides CPU time fairly among processes. There is no strict guarantee about when any specific task will get CPU time. This is acceptable for desktop applications where a 50ms delay in rendering is unnoticeable, but completely unacceptable in a pacemaker or an antilock braking system.

An RTOS provides determinism, which means the system guarantees that a specific task will be completed within a known and bounded time. This time bound is called the deadline. The RTOS scheduler always ensures higher-priority tasks preempt lower-priority ones immediately, so critical operations are never delayed by unimportant background work.

RTOS is further classified into hard real-time and soft real-time systems. In a hard real-time system, missing a deadline is considered a system failure (example: engine control unit). In a soft real-time system, occasional deadline misses degrade quality but do not cause catastrophic failure (example: video streaming buffer).

Mathematical Expression

The most important mathematical concept in RTOS scheduling is the CPU utilization bound derived from Rate Monotonic Analysis. For a set of n periodic tasks with periods T1, T2, ..., Tn and execution times C1, C2, ..., Cn, the utilization U is given by the following formula. The scheduler can guarantee all deadlines are met if U is less than or equal to a specific bound.

The utilization formula is: U = sum of (Ci / Ti) for i = 1 to n. For the Rate Monotonic Scheduler, the utilization bound is n(2^(1/n) - 1). As n approaches infinity, this bound converges to ln(2), which is approximately 0.693. This means in the worst case, Rate Monotonic Scheduling can guarantee all deadlines are met as long as total CPU utilization does not exceed about 69.3 percent.

Practical Understanding

In a real embedded system, the RTOS kernel sits between the hardware and the application software. It manages task scheduling, memory allocation, and inter-task communication. The kernel is very small, often just a few kilobytes of code, because embedded systems have limited RAM and flash storage. Popular RTOS kernels include FreeRTOS (widely used in microcontrollers), VxWorks (used in aerospace), and Zephyr (open source, IoT focused).

A GPOS like Linux has a kernel size of several megabytes, a dynamic scheduler optimized for interactive responsiveness, and virtual memory management. These features are unnecessary and even harmful in deeply embedded systems where memory is constrained and response time must be predictable. Some systems use a Real-Time Linux patch (PREEMPT_RT) to bring deterministic behavior to Linux, but a purpose-built RTOS is always preferred for hard real-time requirements.

Given:
2 periodic tasks:
Task 1: Execution time C1 = 2 ms, Period T1 = 10 ms
Task 2: Execution time C2 = 3 ms, Period T2 = 15 ms

Why this formula applies:
Rate Monotonic Scheduling requires total CPU utilization to be within the schedulability bound.

Formula:
U = (C1/T1) + (C2/T2)
Bound for n=2: U <= 2(2^(1/2) - 1) = 2(1.414 - 1) = 0.828

Substitution:
U = (2/10) + (3/15)
U = 0.2 + 0.2

Calculation:
U = 0.4

Final Answer:
U = 0.4 (40%), which is well below 0.828. All deadlines are guaranteed to be met.

Exam Tip: In GATE, when asked about schedulability in Rate Monotonic Scheduling, always compute U = sum(Ci/Ti) and compare with n(2^(1/n)-1). If U <= 0.693, it is always schedulable regardless of n. If U > 1.0, it is never schedulable.

Mechanism - How RTOS Scheduling Works

• The RTOS kernel maintains a ready queue sorted by task priority. The highest-priority ready task always gets the CPU immediately.
• When a higher-priority task becomes ready (due to an interrupt or timer), the kernel performs a context switch, saving the current task state and loading the new task state.
• The kernel tick timer (typically 1ms to 10ms interval) drives time-based scheduling decisions such as unblocking a delayed task.
• Hard real-time systems rely on interrupt-driven task activation to meet microsecond-range deadlines without polling overhead.
• GPOS schedulers use Completely Fair Scheduler (CFS) or similar algorithms that aim for throughput fairness, not deterministic latency.

Quick Revision

• RTOS provides deterministic, deadline-guaranteed task execution. GPOS provides best-effort, throughput-optimized scheduling.
• Hard real-time: missing deadline = failure. Soft real-time: missing deadline = degraded quality.
• CPU Utilization: U = sum(Ci/Ti). Must satisfy schedulability bound for Rate Monotonic: U <= n(2^(1/n) - 1).
• As n -> infinity, the bound approaches ln(2) = 0.693. If U <= 0.693, schedulability is always guaranteed.
• Popular RTOS: FreeRTOS, VxWorks, Zephyr, RTX. GPOS: Linux, Windows, macOS.
• Exam trap: U > schedulability bound does NOT mean the task set is unschedulable, only that the bound test is inconclusive. U > 1 is definitively unschedulable.