Worst-Case Execution Time

Worst-case execution time is an upper bound on how long a task, interrupt handler, function or code path can take to execute under stated hardware, software and operating assumptions. In real-time systems it is usually represented as:

for task:

WCET is not the same as the slowest timing sample observed in a test. A measured maximum is evidence. A WCET claim is a bounded statement about all executions covered by the assumptions.

Boundary and Assumptions

A useful WCET statement defines the code boundary:

and the platform state:

The execution-time claim is only valid for that boundary and state:

The state should include processor, clock, memory wait states, cache policy, branch prediction, compiler version, optimization flags, operating mode, interrupt nesting, DMA activity, bus contention and input range. Changing any of these can invalidate the bound.

Measurement and Guarded Bounds

If formal static WCET analysis is not available, teams often use measurement-based upper bounds. Let the maximum measured execution time be:

instrumentation allowance be:

clock or hardware guard be:

and stress guard for unobserved phasing be:

A guarded estimate is:

This is not a universal WCET proof. It is a release-screening method that must be justified by test coverage and system risk.

Use in Response-Time Analysis

For a periodic task with deadline:

response-time analysis should use WCET or a justified bound, not average execution time. A simplified response screen is:

where B_i is blocking and I_i is interference from higher-priority work or interrupts. The deadline margin is:

The task passes only when:

under the stated assumptions.

Worked Example

A control computation has measured maximum:

Trace resolution allowance is:

Clock and wait-state guard:

and stress guard:

The guarded bound is:

For a deadline:

and other response terms:

the response screen is:

and the margin is:

The screen passes, but the evidence must still state what stress cases were exercised and why untested paths are not slower.

Sources of Variation

Execution time can vary because of input-dependent loops, branches, cache hits and misses, flash wait states, memory alignment, DMA contention, bus arbitration, interrupt interference, compiler optimization, dynamic allocation, logging, disabled preemption, power states and thermal throttling.

For hard real-time claims, engineers should eliminate or bound variation. That may mean fixed loop limits, static allocation, bounded algorithms, cache locking, memory placement, interrupt budgeting, code review, static analysis and trace tests that cover worst credible phasing.

Validation Evidence

Useful evidence includes code boundary, source revision, compiler version, optimization flags, linker map, hardware revision, clock configuration, input range, path coverage, trace method, timer resolution, measurement overhead, maximum observed value, guard factors, response-time calculation and regression thresholds.

A release package should also state what is excluded. If the task can call logging, allocate memory, wait for a bus, read flash or branch on unbounded input, those paths must either be included in the bound or excluded by design.

Relationship To Neighbor Terms

Deadline miss is the event caused when response exceeds a deadline. WCET is one input to the response-time calculation. Interrupt latency and preemption latency are scheduling and event-response delays around task execution. Jitter is timing variation; WCET bounds one part of that variation. Priority inversion, lock contention and task starvation can make the response time larger than WCET alone.

Algorithmic worst-case complexity is related but not identical. Big O describes growth with input size. WCET is a concrete time bound for a specific implementation and platform.

Common Mistakes

The most common mistake is calling a short lab measurement “WCET” without covering inputs, hardware state or compiler settings. Another is using average execution time in a deadline proof. A third is updating the compiler or enabling logging without invalidating the timing evidence. A fourth is measuring the function alone while the real response path includes interrupt latency, blocking and output update time.

A strong WCET review states the code boundary, assumptions, method, maximum observed or proven bound, guard rationale, response-time use and validation evidence.