Electronics Guide

Hard Real-Time

In a hard real-time system, missing a deadline constitutes a failure, potentially with catastrophic consequences. Airbag deployment controllers, pacemakers, engine ignition timing, and aircraft flight control surfaces fall into this category. The system must be designed and analyzed so that every deadline is provably met under all anticipated conditions, including the worst case. Hard real-time design therefore relies on conservative worst-case analysis rather than average-case measurement, because an occasional miss is unacceptable.

Soft Real-Time

In a soft real-time system, deadlines express desired timing, and occasional misses degrade quality of service without causing failure. Audio and video playback, online gaming, and many user-interface responses are soft real-time: a delayed frame produces a momentary glitch rather than a hazard, and the value of a result diminishes gradually after its deadline rather than vanishing. Soft real-time systems can often be engineered with statistical guarantees and average-case provisioning, tolerating rare overruns in exchange for higher resource efficiency.

Firm Real-Time

Firm real-time occupies the ground between hard and soft. A result produced after its deadline has no value and is discarded, yet an isolated miss does not cause catastrophic failure provided misses remain infrequent. Some sensor-fusion and industrial-quality-control tasks behave this way: a late measurement is simply dropped, and the system continues with the next sample. The distinction matters because firm real-time systems tolerate a bounded rate of discarded results, which relaxes provisioning relative to hard real-time while still requiring that the late results be detected and discarded rather than used.

Tasks, Periods, and Release

Real-time workloads are modeled as a set of recurring tasks. A periodic task is released at fixed intervals separated by its period, denoted T. A sporadic task may be released irregularly but with a known minimum interval between releases, which permits worst-case analysis as though it were periodic at that minimum interval. An aperiodic task arrives at arbitrary times with no minimum separation and therefore requires special handling to bound its demand on the processor. The release time marks the instant at which a task instance becomes ready to execute.

Deadlines and Response Time

The relative deadline, denoted D, specifies the interval after release within which a task instance must complete. When the relative deadline equals the period, the task is said to have an implicit deadline; when the deadline is shorter than the period, it is a constrained deadline. The response time of a task instance is the elapsed time from its release to its completion, and the system meets its requirements when the worst-case response time of every task does not exceed its deadline. The slack of an instance is the difference between its deadline and its response time, a margin that indicates how close the system runs to a timing violation.

Periodic, Sporadic, and Aperiodic Demand

Distinguishing these arrival patterns is central to analysis. Periodic and sporadic tasks present bounded demand because their releases are separated by known minimum intervals, allowing the analyst to compute the worst-case processor load they impose. Aperiodic tasks, lacking such a bound, can in principle demand the processor continuously, so real-time designs confine them within servers that allocate a fixed execution budget. Modeling each activity correctly as periodic, sporadic, or aperiodic is a prerequisite for any meaningful timing guarantee.

Rate-Monotonic Scheduling

Rate-monotonic scheduling is a fixed-priority policy that assigns higher priority to tasks with shorter periods. For a set of independent periodic tasks with deadlines equal to their periods, the rate-monotonic assignment is optimal among all fixed-priority assignments, meaning that if any fixed-priority ordering can schedule the set, the rate-monotonic ordering can as well. Liu and Layland established in 1973 a sufficient schedulability test based on processor utilization: a set of n tasks is schedulable if the total utilization does not exceed n times the quantity two raised to the power of one over n, minus one. This bound decreases as the number of tasks grows and approaches the natural logarithm of two, approximately 0.693, in the limit.

The utilization bound is sufficient but not necessary. Many task sets with utilization above the bound are still schedulable, and a more precise determination comes from response-time analysis, which iteratively computes the worst-case response time of each task by accounting for the interference it suffers from higher-priority tasks. Response-time analysis provides an exact test for fixed-priority scheduling and accommodates real-world factors such as blocking and release jitter.

Earliest Deadline First

Earliest deadline first is a dynamic-priority policy that, at every scheduling decision, runs the ready task whose absolute deadline is nearest. Unlike rate-monotonic scheduling, the priority of a task instance changes as deadlines approach. For independent periodic and sporadic tasks with deadlines equal to periods on a single processor, earliest deadline first is optimal and can schedule any task set whose total utilization does not exceed one, achieving full processor utilization where rate-monotonic scheduling is limited to roughly sixty-nine percent.

This higher utilization comes with trade-offs. The scheduler must track absolute deadlines and may switch tasks more often, increasing overhead. Behavior under transient overload also differs: rate-monotonic scheduling degrades predictably, causing the lowest-priority tasks to miss first, whereas earliest deadline first can cascade into widespread misses once demand exceeds capacity. These characteristics inform the choice between fixed and dynamic priority in a given application.

Accounting for Blocking and Overhead

Idealized analysis assumes tasks are independent, but real systems share resources and incur kernel overhead. When a high-priority task waits for a resource held by a lower-priority task, it suffers blocking, which protocols such as priority inheritance and the priority ceiling protocol bound to a known maximum. Schedulability tests incorporate this blocking term, along with the cost of context switches, interrupt handling, and timer ticks, so that the analysis reflects the system as it will actually run rather than an idealization of it.

Why the Worst Case Matters

Schedulability analysis is only as trustworthy as its execution-time inputs. An underestimate risks missed deadlines in operation, while an overestimate wastes processor capacity and may force an unnecessarily powerful and costly processor. The worst-case execution time is the longest time a task can take to execute in isolation, considering every feasible path through its code and the slowest behavior of the hardware on which it runs.

Static and Measurement-Based Analysis

Static analysis examines the code and a model of the processor to derive a guaranteed upper bound without executing the program. It performs control-flow analysis to enumerate paths, bounds the iteration counts of loops, and models instruction timing including the effects of caches and pipelines. Measurement-based analysis instead runs the code under test conditions and records execution times, then extrapolates to estimate the worst case. Static analysis yields guaranteed bounds suited to hard real-time certification but demands an accurate hardware model, whereas measurement-based methods are simpler but cannot by themselves guarantee that the true worst case was observed. Hybrid approaches combine the two.

The Influence of Modern Hardware

Features that accelerate average-case performance complicate worst-case analysis. Caches make memory access time depend on history, pipelines and branch predictors couple the timing of one instruction to those around it, and on multicore processors contention for shared memory and interconnects introduces interference between cores. Timing-predictable architectures, cache partitioning, and conservative isolation techniques help recover analyzability, sometimes at the expense of peak throughput, illustrating the tension between speed and predictability that pervades real-time design.

Latency

Latency is the delay between a triggering event and the system's response to it. Interrupt latency, the interval from the assertion of an interrupt to the start of its service routine, is a critical component, as is scheduling latency, the additional delay before the responsible task actually runs. Total response latency aggregates these contributions. Bounding latency is essential because control loops and communication protocols specify maximum permissible delays, and an unbounded latency invalidates the timing guarantees the system depends on.

Jitter

Jitter is the variation in a timing quantity from one instance to the next, such as the spread in the actual release or completion times of a periodic task around its nominal schedule. Even when every deadline is met, excessive jitter degrades the performance of digital control loops, distorts sampled signals, and disrupts time-sensitive communication. Sampling jitter, in which sensor readings are not taken at perfectly uniform intervals, introduces error into control and signal-processing algorithms that assume a fixed sample period.

Controlling Latency and Jitter

Designers reduce latency and jitter through several techniques. Keeping interrupt service routines short and deferring lengthy work to scheduled tasks bounds interrupt latency. Driving sampling and actuation directly from hardware timers, rather than from software scheduling, minimizes jitter at the points where it matters most. Reserving processor capacity, limiting the disabling of interrupts, and using time-triggered architectures that fix activity to a global schedule further improve temporal stability. The appropriate measures depend on which timing quantity the application most needs to constrain.

Rate Groups and Cyclic Execution

Organizing periodic activities into rate groups, sets of tasks sharing a common period, simplifies scheduling and analysis, particularly when the periods are harmonically related. A cyclic executive carries this further by arranging all activity into a fixed, repeating schedule computed offline, which yields highly deterministic timing with minimal runtime overhead at the cost of flexibility. This pattern remains common in the most safety-critical applications, where predictability outweighs the convenience of dynamic scheduling.

Deferred Interrupt Processing

To keep interrupt latency low and timing analyzable, real-time designs separate the brief, time-critical portion of interrupt handling from the longer processing it triggers. The interrupt service routine performs only the minimal work required, then signals a task that completes the remaining processing under the scheduler's control. This split, sometimes described in terms of top and bottom halves, bounds the time spent at interrupt level and brings the bulk of the work within the scope of schedulability analysis.

Servers for Aperiodic Work

Because aperiodic events lack a guaranteed minimum separation, real-time systems handle them through server mechanisms that allocate a bounded execution budget. A polling server services pending aperiodic requests at fixed intervals within its budget, while deferrable and sporadic servers improve responsiveness while preserving the schedulability guarantees of the periodic task set. These patterns reconcile the need to respond to unpredictable events with the requirement that no activity may consume unbounded processor time.

Static Verification

Static verification examines the system without executing it. Schedulability analysis and worst-case execution time analysis are themselves static techniques, and formal methods extend this approach by mathematically proving that timing properties hold across all reachable states. Model checking explores a system's state space exhaustively to confirm that deadlines are never violated, and theorem proving constructs rigorous proofs of timing properties. These methods provide the strongest assurance and are applied where the highest integrity levels demand it.

Dynamic Testing and Tracing

Dynamic methods observe the system as it runs. Trace tools record context switches, interrupt events, and application markers to a buffer, producing a timeline that reveals actual response times, latency, and jitter with minimal perturbation. Profiling measures execution-time distributions and compares them against worst-case estimates to confirm that analysis margins hold. Long-duration testing under representative and stress conditions exposes rare timing scenarios that brief tests would miss. A central concern is the probe effect, whereby intrusive instrumentation alters the very timing it seeks to measure; non-intrusive trace hardware mitigates this risk.

Certification Evidence

Safety-critical domains require documented evidence that timing requirements are met. The road-vehicle functional safety standard ISO 26262 is a domain-specific adaptation of the base functional-safety standard IEC 61508, while the airborne software standard DO-178C follows an independent lineage developed by RTCA and EUROCAE for aviation. Despite their separate origins, both mandate requirements traceability, defined verification activities, and records demonstrating that worst-case timing has been analyzed and confirmed. The combination of static analysis, dynamic testing, and structured documentation forms the assurance case that a real-time system will behave correctly in time throughout its service life.