Real-Time Computing is a computing paradigm in which the correctness of a system depends not only on producing the correct computational result but also on producing that result within specified timing constraints. The central concept is temporal correctness. A real-time system must respond to events, process data or complete tasks before relevant deadlines or within defined timing bounds. This does not necessarily mean that every operation must execute instantaneously or at the maximum possible speed.
Instead, the system must provide predictable timing behaviour appropriate to its requirements. Real-time computing is therefore concerned with latency, deadlines, scheduling, interrupt response, execution-time bounds, jitter and temporal predictability. It is used in applications where delayed information or control can be materially different from correct information or control delivered at the required time.
Real-Time Computing is traditionally divided into hard real-time and soft real-time requirements. In a hard real-time system, missing a specified deadline is considered a system failure or can have unacceptable consequences, making worst-case timing analysis and deterministic scheduling particularly important. Aircraft control systems, certain industrial safety functions and some medical or automotive controls can contain hard real-time components. Soft real-time systems can tolerate occasional deadline violations while experiencing degraded quality or performance; examples include multimedia processing, telecommunications and interactive audio. Some systems are described as firm real-time when late results have little or no value even though a missed deadline is not necessarily catastrophic. These categories describe timing requirements rather than processor speed.
Scheduling is fundamental to Real-Time Computing because multiple tasks may compete for limited processing resources. A scheduler determines which task executes at a given moment, often using priorities, deadlines or fixed scheduling policies. Rate-monotonic scheduling assigns higher priority to tasks with shorter periods under defined assumptions, while earliest-deadline-first scheduling prioritises the task whose deadline occurs soonest.
Priority inversion can occur when a high-priority task is blocked by a lower-priority task holding a required resource, particularly when an intermediate-priority task prevents the lower-priority task from releasing it. Priority inheritance and priority-ceiling protocols can mitigate such problems. Interrupt handlers, deferred processing and task synchronisation must also be designed carefully because excessive interrupt activity or contention can undermine timing guarantees.
Real-time performance depends on more than processor frequency. Interrupt latency is the delay between an event occurring and the system beginning the corresponding response. Scheduling latency reflects delays caused by competing tasks, operating-system activity or resource contention. Jitter describes variation in timing from one execution to another, and can be significant even when average latency appears low. Worst-case execution time attempts to establish an upper bound on how long a task can require under defined conditions. Cache behaviour, branch prediction, memory contention, device interrupts, bus arbitration and operating-system services can make such bounds difficult to establish on complex processors. Consequently, real-time engineering often prioritises predictable behaviour over average benchmark performance.
Real-Time Operating Systems are commonly used when applications require controlled scheduling and timing behaviour. An RTOS typically provides mechanisms for priority-based task scheduling, deterministic interrupt handling, inter-task communication, synchronisation, timers and resource management. Examples of RTOS families include FreeRTOS, Zephyr and VxWorks, although real-time behaviour can also be implemented using specially configured general-purpose operating systems. Linux can support real-time workloads through appropriate kernel configurations and scheduling mechanisms, but its suitability depends on the required guarantees and system design. An RTOS does not automatically make an application hard real-time: guarantees depend on hardware, kernel behaviour, application code, scheduling analysis and the assumptions used to establish timing bounds.
Real-Time Computing is closely connected with Embedded Systems but the concepts are not identical. Many embedded controllers require real-time behaviour because they interact with physical processes whose state changes continuously. However, an embedded device can perform non-real-time tasks, such as logging or configuration management, while a real-time application can operate on conventional computers or Servers. Real-time systems also occur in robotics, telecommunications, industrial automation, radar, financial systems and multimedia. In each case, the precise timing requirement differs. A robotic controller may require millisecond-scale bounded response, while a video system may primarily require sustained throughput and controlled latency. The appropriate architecture therefore follows the timing model of the application rather than the label applied to the computer.
Real-time systems face distinctive engineering trade-offs. Deterministic scheduling and extensive worst-case analysis can increase development effort and constrain hardware or software choices. Resource isolation can improve predictability but reduce overall utilisation. Redundancy may improve reliability but increase cost and complexity. Dynamic memory allocation, garbage collection, background maintenance and uncontrolled operating-system services can complicate timing analysis, so critical systems may use static allocation and carefully bounded operations. Testing is also more demanding because average-case testing cannot establish a worst-case timing guarantee. Trace instrumentation, stress testing, formal analysis and hardware-in-the-loop testing can be used to investigate timing behaviour, but each technique has limitations.
The importance of Real-Time Computing lies in recognising that computational correctness includes a temporal dimension. A temperature controller that eventually produces the correct output may still fail if it responds too late to a dangerous change. An audio application that calculates every sample correctly can still malfunction if processing consistently misses playback deadlines. Real-time design therefore treats time as a system resource that must be specified, scheduled, measured and verified.
The concept should be distinguished from merely fast computing: a system can be extremely fast on average yet unsuitable for strict real-time requirements if its response times are unpredictable, while a comparatively modest processor can satisfy real-time requirements when workload, scheduling and timing behaviour are properly bounded.
