Real-Time Systems: An Overview

A real-time system is one whose correctness depends not only on the logical result of a computation but also on the time at which the result is produced: a late answer is a wrong answer. Cruise control, telecommunications switching, flight control and engine management are typical real-time applications, whereas offline simulation or ordinary user-interface work is not. Real-time does not mean fast; it means the timing is guaranteed to meet a stated bound.

Consider a machine that caps bottles on a moving conveyor. If it acts too early the bottle is not there yet; too late and the bottle has passed, and stopping the line is costly. The range of motion and the belt speed create a window of opportunity, which becomes a timing constraint. If bottles arrive five per second, a new one appears every 200 ms, so the task has a period of 200 ms; if the usable window is 150 ms, the deadline is 150 ms after the bottle enters range. A periodic task repeats at a fixed period and must finish within its deadline each time. Cruise control is similar: the control rate, how often speed is checked, is chosen by the designer to meet the specification without burdening the system.

Not every real-time task is periodic. Aperiodic tasks respond to events that arrive at random, such as a driver pressing the brake pedal. The response time, from the pedal press to the anti-lock braking software actuating the brakes, must stay within a worst-case bound, because a one-second delay could cause an accident. Fastest is not necessarily best: designers also want small, cheap microcontrollers, so the application specifies a worst-case response time and the hardware and software are designed to meet it. Tasks that arrive at random but with a known minimum gap are often called sporadic.

A system is either real-time or not; a non-real-time system can miss any deadline without consequence. Real-time systems are usually classed by how severe a miss is. A hard real-time system cannot afford to miss even one deadline: a flight controller that acts late could leave an aircraft unstable. A soft real-time system tolerates occasional misses, with quality degrading rather than failing; for example, cruise control can reuse the previous speed reading if one sample is late, because the value changes little. A firm real-time system discards a late result as worthless but does not fail catastrophically. The class depends on the consequence of lateness, not the application name.

A predictable real-time system always behaves within an acceptable range, usually stated system-wide, such as all tasks meet all deadlines. To build one, the period, deadline and worst-case execution time of each task must be known, and an appropriate scheduling algorithm is combined with schedulability analysis to prove the deadlines can be met. A deterministic system is a special case where the timing behaviour can be fixed in advance, for example by pre-allocated time slots for each task, which requires known execution times and no anomalies that could break the plan.

Most real-time software runs on a real-time operating system, whose scheduler and interrupt handling are built for bounded latency. Popular open options include FreeRTOS, Zephyr, RTEMS and Eclipse ThreadX, while VxWorks is a long-established commercial RTOS, seL4 is a formally verified microkernel, and Linux with PREEMPT_RT serves larger systems.

Hard real-time systems are often safety-critical, so development follows standards such as ISO 26262 for road vehicles, DO-178C for airborne software and IEC 61508 for functional safety in general. These define processes and evidence, including timing analysis, so use the current published text rather than summaries.

Where to study real-time systems.

Neighbouring pages on this site.