1. When Time Becomes Part of Correctness

For a general-purpose application, executing an operation successfully is the primary goal:

The system tries to complete the request as quickly as practical, but if a high workload causes a delay, the result remains correct—it is simply delivered late.

For a real-time system, completing the operation is only half the battle. The correctness of the computation depends not just on the logical result, but on the exact time the result is produced:

If the system delivers the correct mathematical output but finishes after the assigned deadline, the entire operation has failed. In real-time environments, the timing of the result is part of correctness.

2. Soft Real-Time

In a soft real-time system, meeting deadlines is important for performance, but an occasional missed deadline is tolerated:

Examples of soft real-time workloads include: * Audio and video playback streaming. * Interactive graphical interfaces and gaming. * Telecommunication network packet processing.

Missing a deadline decreases the system's quality of service, but it does not cause a crash or system failure.

3. Hard Real-Time

In a hard real-time system, deadlines are absolute constraints:

Examples of hard real-time systems include: * Automotive airbag deployment controllers. * Flight-control surface stabilizers. * Industrial motor protection switches. * Embedded medical devices (such as pacemakers).

4. Is an RTOS a Completely Different Operating System?

No. A Real-Time Operating System (RTOS) performs the same core resource-management duties as any general-purpose OS:

The difference is not the presence of these responsibilities, but how they are prioritized and configured.

5. What Changes?

The design priorities of a General-Purpose OS versus a Real-Time OS are contrasting:

General-Purpose OS * Throughput: Maximizing total instructions executed per second. * Fairness: Giving every thread an equal chance to run. * Average Responsiveness: Making sure standard operations complete quickly on average. * Flexibility: Adapting to dynamic, unpredictable user application workloads.

RTOS * Predictability: Bounding the worst-case execution time (WCET). * Deterministic Behavior: Ensuring that a specific event always triggers its handler task within a fixed number of CPU cycles. * Deadline Compliance: Prioritizing tasks based on their timing urgency.

An RTOS does not necessarily mean "everything is faster." It means the system is designed so that important timing behavior can be reasoned about and bounded.

6. Everything We Learned Still Exists

The architectural concepts explored in this branch apply directly to the real-time model, adjusted for predictability:

Process Management * Previously: How does the OS schedule competing workloads fairly? * Now: How does the scheduler guarantee that the highest-priority real-time task meets its execution deadline?

Memory Management * Previously: How does virtual paging expand available memory? * Now: How does dynamic memory allocation affect predictability? Real-time threads often disable virtual paging and partition RAM statically to avoid the timing delays of page faults.

File / Storage Management * Previously: How are files structured on physical storage blocks? * Now: How does the delay of reading from disk affect timing? RTOS tasks often buffer files in RAM or use low-overhead, contiguous file allocation methods.

I/O & Protection * Previously: How does the kernel isolate user tasks from hardware? * Now: How quickly does the driver respond to device interrupts? Real-time systems often reduce abstraction layers to minimize system call overhead.

7. Connecting to Embedded Mechanisms

The real-time operating system coordinates several key components to keep systems on track: * Tasks: Bounded threads of execution containing dedicated priorities. * Scheduling: Preemptive priority schedulers that ensure a high-priority task immediately preempts a lower-priority task when ready. * Synchronization: Semaphores, mutexes, and queues used to pass messages between tasks without causing priority inversions. * Interrupts: Bounded latency ISRs that service hardware signals immediately.

We have already encountered many of these mechanisms individually. In an RTOS, they come together around one central requirement: predictable response to events and deadlines.

8. There Is No Single RTOS

Different embedded devices require different RTOS designs based on their target architecture: * Processor Class: Low-power microcontrollers (such as ARM Cortex-M) versus high-performance multi-core processors. * Footprint limits: Fitting within 10 KB of RAM versus hosting hundreds of megabytes. * Safety Certification: Meeting aviation (DO-178C) or automotive (ISO 26262) safety standards.

Consequently, the embedded ecosystem has developed different RTOS kernels to fit these needs.

9. A Small RTOS Landscape

Below are five representative real-time operating systems widely used across the engineering landscape:

FreeRTOS A lightweight, open-source kernel designed for resource-constrained microcontrollers. It provides minimal multitasking primitives with a tiny memory footprint.

Zephyr A modern, open-source RTOS designed for connected IoT devices, offering built-in networking stacks, driver models, and resource isolation tools.

SafeRTOS A safety-certified version of the FreeRTOS functional model, documented and validated for medical, industrial, and safety-critical devices.

AUTOSAR OS A standardized RTOS specification designed for automotive ECUs, supporting tight scheduling, memory protection, and hardware abstraction frameworks.

VxWorks A high-performance, commercial RTOS used in critical systems (such as aerospace, robotics, and industrial control arrays) requiring extensive debugging tools and high reliability.

10. Selection Criteria

When selecting an RTOS for a physical device, developers evaluate several engineering trade-offs:

The chosen RTOS must fit within the processor's memory constraints, support the target compiler ecosystem, provide the required level of safety documentation, and integrate smoothly with existing vendor hardware abstraction layers.

An RTOS is still an operating system. It still manages computation, memory, I/O, synchronization and resources.

The difference is what the system considers correct.

For a general-purpose system, doing the right thing quickly is often enough. For a real-time system, doing the right thing at the required time is part of correctness.

And there is no single RTOS for every machine. The controller, domain, constraints and required guarantees shape the choice.

So when we eventually encounter a specific machine or domain, which real-time system will be waiting underneath it?