Sporadic Task

A sporadic task is an event-driven real-time task whose releases are not strictly periodic but are separated by a stated minimum inter-arrival time. It is used when a sensor, interrupt, message, alarm or operator event can occur irregularly, but cannot legitimately arrive faster than a documented bound.

The term matters because schedulability analysis needs a worst-case arrival model. Treating an event source as “occasional” is not enough. A sporadic task must have a release contract that can be measured, enforced or justified.

Task Model

A sporadic task is commonly represented as:

where C_i is worst-case execution time, T_i is minimum inter-arrival time, D_i is relative deadline, J_i is release jitter and B_i is blocking.

For releases:

the sporadic arrival constraint is:

This is the key difference from a purely aperiodic task, which may not have a useful arrival bound.

Periodic Versus Sporadic

A periodic task releases at a regular interval:

A sporadic task only promises a minimum separation:

Periodic tasks are easier to schedule because the release pattern repeats. Sporadic tasks are more realistic for interrupts, field-bus messages, network packets, fault events and user commands, but their event-source assumptions need stronger validation.

Utilization Screen

For a sporadic task with minimum inter-arrival time T_i, a conservative utilization contribution is:

The task should be analyzed as if releases can occur at the minimum legal spacing. If the real source can burst faster than T_i, the model is false and the schedulability result is not valid.

For a task set:

is only a screen. Priority, blocking, deadlines, release jitter and overload behavior still need detailed analysis.

Worked Arrival Check

Assume a sporadic diagnostic task has:

and:

Its utilization contribution is:

Suppose captured release times are:

The observed separations are:

The last separation violates the model because:

The correct action is not to keep the old analysis. The event filter, debounce logic, interrupt coalescing, message admission rule or task model must be fixed.

Deadline Evidence

For a release at time:

the absolute deadline is:

If completion time is:

then deadline margin is:

The task meets its deadline only if:

for all validated worst-case releases. Average latency does not prove a sporadic task safe.

Implementation Hazards

The hardest part of a sporadic task is often the event source. Mechanical bounce, noisy sensors, repeated bus frames, retry storms, interrupt re-entry, DMA completion bursts or network batching can violate the assumed minimum inter-arrival time.

Software should either enforce the bound or model the real burst. Common mechanisms include debounce windows, admission control, sequence counters, queue backpressure, token buckets, interrupt masking limits and safe degradation.

Relationship To Neighbor Terms

Schedulability analysis uses sporadic task models to convert irregular releases into bounded demand. Rate-monotonic scheduling, deadline-monotonic scheduling and EDF can schedule sporadic tasks if the assumptions match the policy and analysis method.

A sporadic server is different: it is a budgeted mechanism for serving aperiodic or sporadic work. A sporadic task is the workload model itself. WCET, release jitter, non-preemptive sections, interrupt latency and priority inversion are inputs that can change the timing result.

Validation Evidence

Useful evidence includes event-source specification, minimum inter-arrival measurement, release trace, timestamp uncertainty, filter or debounce configuration, queue depth, admission logs, WCET basis, deadline-miss counters and stress tests that force bursts.

The validation should explicitly compare measured minimum separation with the model:

If not, the task must be modeled with a shorter T_i, a burst model, or an overload policy.

Common Mistakes

The most common mistake is calling a task sporadic because it happens irregularly, while omitting the minimum inter-arrival contract. Another is using average event rate instead of the shortest credible separation. A third is validating the task body but not the interrupt, driver, queue or network path that releases it.

A strong sporadic-task review states WCET, minimum inter-arrival time, deadline, jitter, blocking, event-source enforcement, overload behavior and trace evidence.