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.

The timescales involved vary by many orders of magnitude, yet the obligation is the same in each case. Spark ignition illustrates the tight end: a four-stroke engine turning at six thousand revolutions per minute completes one crankshaft revolution every ten milliseconds, so a single degree of crank angle spans roughly twenty-eight microseconds, and a controller that must place the spark within a degree or two has correspondingly little margin. A flight control law running at a few tens of hertz allows tens of milliseconds per cycle, and a process-control loop in a chemical plant may allow seconds. What makes all three hard real-time is not the size of the interval but the requirement that the bound never be exceeded.

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.

Buffering is the characteristic soft real-time remedy. Audio sampled at forty-eight kilohertz delivers one sample every twenty-one microseconds, a period far too short to schedule individually, so the driver assembles samples into blocks: a buffer of 128 samples covers about 2.7 milliseconds, and the processing task must merely refill each buffer before the hardware drains it. Enlarging the buffer relaxes the deadline at the cost of added latency, which is why interactive audio uses small buffers and playback of recorded material uses large ones. This exchange of latency for timing slack has no counterpart in hard real-time control, where the deadline is dictated by physics rather than by perception.

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.

Mixed-Criticality Systems

Few modern products belong entirely to one category. A vehicle domain controller may host braking logic, a parking-assistance function, and an infotainment bridge on a single processor, and an avionics module may run flight-critical and advisory software side by side. Systems of this kind are described as mixed-criticality, a formulation introduced by Steve Vestal in 2007 to capture the fact that a single task can carry several execution-time estimates: a pessimistic bound acceptable to a certification authority and a tighter bound representative of normal operation.

The engineering difficulty is that the pessimistic bounds, applied to every function at once, often make the system appear unschedulable even though it never approaches that load in practice. Mixed-criticality designs resolve the tension by isolating functions from one another and by defining what happens when a low-criticality activity exceeds its expected budget: the runtime detects the overrun and suspends or degrades the less critical work so that the safety-related tasks retain their guarantees. Isolation is enforced by partitioning in time and space, the subject of a later section, and the accompanying safety argument must show that a fault in a low-criticality function cannot propagate into a high-criticality one.

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; and when the deadline may exceed the period, so that successive instances of the same task can be pending simultaneously, it is an arbitrary deadline. The three cases demand progressively more elaborate analysis, and much of the classical theory assumes the implicit case because it is the easiest to reason about.

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. Designers typically reserve deliberate slack, both to absorb the estimation error inherent in execution-time bounds and to leave room for the software changes that arrive over a product's life.

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.

Misclassification is a common source of trouble. An event stream that a designer assumes is sporadic, such as messages arriving on a network interface, may in fact burst far above its nominal rate when another node malfunctions. The safe practice is either to establish the minimum separation by construction, through hardware rate limiting or a protocol that polices traffic, or to treat the stream as aperiodic and bound it with a server.

End-to-End Timing and Data Age

Task-level deadlines are a means, not an end. What a control engineer actually requires is a bound on the interval from a physical event to the corresponding physical response, a quantity that spans the sensor, one or more computations, any network hops between them, and the actuator. This end-to-end chain frequently crosses several tasks that run at different rates, and the delays compound in ways that individual deadlines do not reveal.

Two quantities are usually specified for such chains. Reaction time bounds how long a change at the input may take to appear at the output, and data age bounds how stale the information underlying an output may be. Both worsen when a fast task publishes into a slower one, because the consumer may read a value just before the producer refreshes it and then hold that value for a full cycle. Analysis of these chains therefore examines the sampling relationships between communicating tasks, not merely whether each task meets its own deadline, and the usual remedies are harmonically related periods, explicit synchronization, or a time-triggered schedule that fixes the order in which producers and consumers run.

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, where the utilization of a task is its execution time divided by its period: 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. The bound falls as the number of tasks grows, from about 82.8 percent for two tasks to roughly 78.0 percent for three, and it converges from above on the natural logarithm of two, approximately 69.3 percent.

The utilization bound is sufficient but not necessary, and the gap is often large. Many task sets with utilization above the bound are still schedulable; in the important special case of harmonic periods, where every period divides evenly into every longer one, rate-monotonic scheduling meets all deadlines at utilization arbitrarily close to one hundred percent. This is a practical reason to choose task rates such as one, five, ten, and fifty milliseconds rather than arbitrary values. A more precise determination in the general case 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.

Deadline-Monotonic Priority Assignment

Rate-monotonic optimality assumes deadlines equal to periods. When deadlines are shorter than periods, ordering by period can assign low priority to a task that must nonetheless respond quickly. Deadline-monotonic assignment corrects this by ordering priorities according to relative deadline, with the shortest deadline receiving the highest priority. Leung and Whitehead showed in 1982 that this assignment is optimal among fixed-priority orderings for tasks with constrained deadlines, and it reduces to the rate-monotonic ordering when deadlines equal periods.

Optimality nonetheless has limits worth knowing. Once release jitter, blocking, or arbitrary deadlines enter the model, deadline-monotonic ordering is no longer guaranteed to be the best choice, and analysts turn to a search procedure that tests candidate priorities directly, of which Audsley's algorithm is the standard example. Because it depends only on a schedulability test rather than on a closed-form rule, this approach finds a feasible priority ordering in a number of tests that grows with the square of the task count instead of requiring every permutation to be examined.

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 total utilization not exceeding one is both necessary and sufficient for schedulability. It therefore admits every task set that any policy could schedule, whereas the rate-monotonic utilization test guarantees success only up to about sixty-nine percent for arbitrary periods.

The comparison should be read carefully. Sixty-nine percent is the load below which rate-monotonic scheduling is guaranteed to succeed, not a ceiling on what it can achieve; with harmonic periods it too reaches full utilization, and with response-time analysis many higher-utilization sets are shown to be feasible. Where earliest deadline first genuinely helps is in accommodating task sets with awkward, unrelated periods that a fixed-priority ordering cannot fit. When deadlines are shorter than periods, the simple utilization test no longer suffices for either policy, and the exact test for earliest deadline first becomes processor demand analysis, which checks that over every interval the cumulative execution demanded by tasks released and due within that interval does not exceed its length.

Dynamic priority also carries costs. The scheduler must track absolute deadlines and may switch tasks more often, increasing overhead, and comparatively few commercial kernels offer it, so adopting it can constrain the choice of operating system and certification evidence. Behavior under transient overload differs sharply as well: 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, because a task that has already missed its deadline holds the highest priority and continues to displace others. Fixed-priority scheduling consequently remains the norm in safety-critical practice, with dynamic priority appearing more often in multimedia, telecommunications, and general-purpose kernels.

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. Unbounded blocking, in which tasks of intermediate priority repeatedly preempt the lock holder and so extend the wait indefinitely, is the pathology known as priority inversion. Priority inheritance addresses it by temporarily raising the holder to the priority of the highest-priority task waiting on the resource; the priority ceiling protocol goes further, assigning each resource a ceiling equal to the highest priority of any task that uses it, which limits a task to at most one block per activation and prevents deadlock among the protected resources. Many kernels implement the simpler immediate variant, raising a task to the ceiling as soon as it takes the lock.

The consequences of neglecting these protocols are not theoretical. The Mars Pathfinder lander, which reached the Martian surface in July 1997, suffered repeated system resets days into its mission. A high-priority bus-management task was blocked by a low-priority meteorological task holding a shared resource while a medium-priority communications task ran, and a watchdog timer, observing that the bus task had not completed, reset the spacecraft. The priority-inheritance option on the relevant mutex had been left disabled in the VxWorks kernel; enabling it remotely resolved the fault.

Schedulability tests incorporate the blocking term alongside 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. Interrupt handlers deserve particular care, because on most kernels they execute above every task priority and their contribution is therefore a preemption that no priority assignment can defer.

Multiprocessor and Multicore Scheduling

Single-processor results do not carry over to multicore hardware, and the differences are more than a matter of degree. Two families of approach dominate. Partitioned scheduling assigns each task statically to one core and then applies single-processor analysis independently on each, which preserves the familiar theory but turns allocation into a bin-packing problem; because a task whose utilization slightly exceeds one half cannot share a core with another of the same size, the guaranteed utilization bound for partitioned schemes sits at fifty percent of total capacity. Global scheduling keeps a single ready queue and allows tasks to migrate between cores, improving load balance at the cost of migration overhead and far more intricate analysis.

Global scheduling also exhibits a counterintuitive weakness known as the Dhall effect: a task set consisting of many tiny tasks with short deadlines alongside one heavy task with a long deadline can miss deadlines at total utilization barely above one, no matter how many cores are available, because the small tasks collectively crowd out the large one. This result steered research toward partitioned approaches for many years, and hybrid schemes that partition most tasks while allowing limited migration are now common.

The deeper obstacle is hardware rather than policy. Cores on a modern device share last-level caches, memory controllers, and interconnects, so the execution time of a task depends on what its neighbors are doing. These interference channels can inflate execution time by a factor of several relative to a run with the other cores idle, which undermines any analysis that treats per-core timing as independent. Mitigations include partitioning caches by way of coloring or hardware allocation features, regulating each core's memory bandwidth, and reserving cores for critical work. Certification authorities addressed the problem directly: the Certification Authorities Software Team position paper CAST-32A was superseded by EASA's AMC 20-193, published in 2022, and the FAA's corresponding AC 20-193, published in 2024, which require applicants to identify interference channels, mitigate contention for shared resources, and verify worst-case timing with the other cores active.

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 the paths through the program, bounds the iteration counts of loops, models instruction timing including the effects of caches and pipelines, and then combines the results into a single bound, commonly by expressing the problem as an integer linear program over the number of times each basic block executes. Loop bounds that the analyzer cannot infer must be supplied by the engineer as annotations, and an incorrect annotation invalidates the result, so these declarations are treated as requirements to be reviewed rather than as hints.

Measurement-based analysis instead runs the code and records execution times, either end to end or segment by segment, then combines the observations into an estimate. Its weakness is coverage: no realistic test campaign can exercise every path with every cache and pipeline state, so the largest observed time is a lower bound on the true worst case rather than an upper bound, and engineers add a safety margin whose justification is a matter of judgment. Hybrid methods narrow the gap by measuring short segments while deriving the worst-case path through them statically, and probabilistic techniques attach a confidence level to a bound rather than asserting it absolutely. Static analysis yields guaranteed bounds suited to hard real-time certification but demands an accurate hardware model, which vendors do not always publish; measurement-based methods apply to any processor that can be instrumented but cannot by themselves guarantee that the true worst case was observed.

The Influence of Modern Hardware

Features that accelerate average-case performance complicate worst-case analysis, because each of them makes the time taken by an instruction depend on context rather than on the instruction alone. A cache makes memory access time depend on the history of previous accesses, so the same load costs a few cycles on a hit and dozens or hundreds on a miss. Pipelines and out-of-order execution couple the timing of neighboring instructions, branch predictors make it depend on the outcomes of earlier branches, and dynamic frequency scaling makes it depend on thermal conditions. Some of these mechanisms even exhibit timing anomalies, in which a locally faster event, such as a cache hit, produces a globally longer execution, which defeats the intuition that assuming the worst at every step yields the worst overall.

Recovering analyzability generally means giving some performance back. Designers disable or lock down the most troublesome features, lock critical code and data into cache or place them in tightly coupled memory with fixed access time, and in the most demanding applications select timing-predictable processors whose simpler pipelines trade throughput for determinism. Contention between cores, discussed earlier, is the sharpest form of the same problem. The recurring pattern is that average-case speed and worst-case predictability are distinct goals, and a design optimized for one is rarely optimal for the other.

Latency

Latency is the delay between a triggering event and the system's response to it, and it decomposes into contributions that are measured and bounded separately. Interrupt latency, the interval from the assertion of an interrupt line to the first instruction of its service routine, comprises the time the processor spends finishing or abandoning the current instruction, any interval during which interrupts were disabled by a critical section, the time spent servicing higher-priority interrupts already pending, and the hardware cost of vectoring and saving context. Scheduling latency then covers the additional delay after the handler signals a task before that task actually runs, which includes the kernel's decision overhead and any interval in which the scheduler is locked. Total response latency aggregates these contributions along with the task's own execution.

Bounding latency matters because control loops and communication protocols specify maximum permissible delays, and an unbounded latency invalidates the timing guarantees the system depends on. The dominant term is frequently the longest interval during which the software disables interrupts, a quantity determined by the least disciplined piece of code in the system, including driver and library code the application author did not write. Kernel vendors accordingly publish a maximum interrupt-disable time as a headline characteristic, and integrators measure it on their own configuration rather than relying on the published figure, since a single careless critical section elsewhere in the build can dominate it.

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. The mechanism in control is straightforward: a discrete controller is designed for a fixed sample period, so variation in the interval between samples and in the delay before the computed output reaches the actuator perturbs the loop exactly as an unmodeled disturbance would, reducing phase margin and, in aggressive designs, threatening stability.

Sampling jitter is equally damaging in signal acquisition. When a converter's sampling instants wander, the resulting error grows with the slew rate of the signal being sampled, so the same timing uncertainty costs little on a slowly varying temperature reading and a great deal on a high-frequency waveform. This is why a system that meets every deadline can still fail its measurement requirements, and why jitter is specified separately from deadlines rather than being treated as a consequence of them.

Controlling Latency and Jitter

Designers reduce latency and jitter through several complementary techniques. Keeping interrupt service routines short and deferring lengthy work to scheduled tasks bounds interrupt latency, and auditing every critical section for the time it holds interrupts off addresses the term that usually dominates. Reserving processor headroom rather than provisioning to the analyzed limit shortens queueing delays throughout the system, since response times rise steeply as utilization approaches capacity.

The most effective measure against jitter is to remove software from the timing path altogether. Triggering conversions from a hardware timer, latching results into a peripheral buffer, and moving data by direct memory access make the sampling instant independent of when the processor gets around to the task; the task then reads a value whose timestamp is exact even if the read itself is late. The same reasoning applies at the output, where a compare unit that drives an actuator at a programmed instant removes the scheduler from the actuation path. Where jitter must be suppressed system-wide rather than at individual pins, the time-triggered architectures described among the design patterns below fix activity to a global schedule. The appropriate measure depends on which timing quantity the application most needs to constrain, and the three are not interchangeable: reducing average latency, bounding worst-case latency, and minimizing jitter can call for different and occasionally opposing designs.

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: the major cycle spans the least common multiple of the task periods and divides into minor cycles in which each activity occupies a reserved slot. Because the schedule is fixed, timing is highly deterministic, runtime overhead is minimal, and there is no preemption and hence no need for locks between the scheduled activities.

The costs are borne at design time. Every activity must fit within its slot, so long computations have to be split by hand into pieces that span several minor cycles, and adding or resizing a function can force the whole schedule to be recomputed. This brittleness is the reason dynamic scheduling displaced cyclic execution in most applications, and the determinism is the reason cyclic execution persists in the most safety-critical ones, where a schedule that can be inspected in full is worth more than the convenience of a scheduler that decides at runtime.

Time-Triggered Architectures and Temporal Partitioning

The broader principle behind cyclic execution is the time-triggered architecture, in which activity is initiated by the progression of a global clock rather than by external events. All nodes in such a system share a synchronized time base, communication occurs in preassigned slots, and the schedule is fixed before deployment. Determinism is excellent and a faulty node cannot seize the bus, since it has no slot outside its own. The corresponding weakness is responsiveness to genuinely unpredictable events, which must wait for the next polling instant, and many practical systems are therefore hybrids that reserve a time-triggered core for critical control and handle the remainder with event-triggered mechanisms.

Temporal partitioning applies the same idea to isolating whole applications from one another. Under the ARINC 653 interface used in integrated modular avionics, a major time frame repeats cyclically and each partition receives one or more windows of fixed duration at a fixed offset within it. A partition that overruns is simply suspended when its window ends, so it cannot steal time from another, and the schedulability of each partition can be established independently of what its neighbors do. Combined with memory protection, which supplies the corresponding isolation in space, this arrangement is what allows applications of different criticality levels to be hosted on shared hardware and certified without re-verifying every application whenever one of them changes.

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 runs as an ordinary periodic task, servicing whatever aperiodic requests are pending when it is released and forfeiting its budget when none are waiting, which is simple to analyze but delays a request that arrives just after the server yields. A deferrable server preserves its budget until a request arrives, improving average response at the cost of a small penalty in the guarantees offered to lower-priority tasks. A sporadic server replenishes budget in a manner that makes its interference on other tasks indistinguishable from that of a periodic task of the same parameters, which is why the sporadic server appears in real-time operating system interfaces intended for analyzable systems. All three reconcile the need to respond to unpredictable events with the requirement that no activity may consume unbounded processor time.

Budget Enforcement and Overload Handling

Analysis rests on assumed execution times, and a defensive design does not simply hope that the assumption holds. Execution-time monitoring gives each task a budget that the kernel charges as the task runs and enforces when it is exhausted, so a fault such as an unterminated loop is contained within the offending task rather than propagating as missed deadlines throughout the system. Deadline monitoring provides the complementary check, signaling when an instance completes late or fails to complete at all. AUTOSAR calls the combination timing protection; the concept appears under other names in avionics and industrial kernels.

What the system does after detection is a design decision that belongs in the requirements rather than in the implementation. Options include discarding the late result, skipping the next activation to recover phase, switching to a degraded mode that sheds noncritical functions, handing control to a simpler backup controller, or forcing a reset. Watchdog timers backstop all of these by acting independently of the software they supervise, and a well-formed real-time design specifies both the detection mechanism and the intended reaction for each activity, so that timing faults are handled predictably instead of at whatever point the system happens to break.

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 entries and exits, and application markers to a buffer, producing a timeline that reveals actual response times, latency, and jitter. 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, and stress cases deserve deliberate construction rather than reliance on chance: the critical instant at which every task is released simultaneously, peak interrupt rates, and the fault-handling paths that ordinary operation never enters.

A central concern is the probe effect, whereby instrumentation alters the very timing it seeks to measure. Software instrumentation that writes to a buffer costs a modest but nonzero number of cycles per event, enough to change behavior in a tightly loaded system, and instrumentation removed before release invalidates the measurements taken with it in place. Hardware trace units integrated into the processor, such as the embedded trace macrocells in Arm's CoreSight architecture, mitigate the problem by exporting execution history over dedicated pins without consuming processor cycles. Where such facilities are absent, the practical compromise is to leave lightweight instrumentation permanently enabled and to account for its cost in the timing analysis, so that measurement and shipped configuration remain the same system.

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, published by RTCA and issued by EUROCAE as ED-12C, follows an independent lineage developed for aviation. Each grades rigor by the severity of the consequences: IEC 61508 by safety integrity level, ISO 26262 by automotive safety integrity level from A to D, and DO-178C by design assurance level from E to A, with the most demanding levels requiring the most exhaustive verification and the greatest independence between those who develop and those who verify.

Despite their separate origins, all of these frameworks converge on the same expectations for timing. Requirements must be traceable from the system level down to the code that implements them and back up through the tests that verify them; verification activities must be planned and their results recorded; tools that generate or verify the timing evidence must themselves be qualified for that purpose; and the record must show that worst-case timing was analyzed, that the analysis assumptions were justified, and that measurement on the target confirmed them. 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, and maintaining that case through subsequent modifications is as much a part of the obligation as constructing it.