Glossary term

Hyperperiod

Engineering definition of hyperperiod covering schedule repeat windows, least-common-multiple periods, job counts, exhaustive testing limits and validation evidence.

Definition

concept

A hyperperiod is the time interval after which the release pattern of a set of periodic tasks repeats, equal to the least common multiple of their periods when the periods are integer-compatible.

A hyperperiod is used in real-time scheduling, firmware timing validation and cyclic test planning to understand how long a periodic task set takes to repeat. A useful review states the task periods, units, least-common-multiple calculation, job counts, feasibility assumptions, test duration, phasing coverage and validation evidence.

A hyperperiod is the time interval after which the release pattern of a set of periodic tasks repeats. For integer-compatible task periods, it is the least common multiple of the periods. The concept is useful in real-time scheduling, cyclic executives, firmware timing validation and test planning.

Hyperperiod is not a schedulability proof by itself. It tells an engineer how long the nominal release pattern takes to repeat. A system can have a small hyperperiod and still miss a deadline because of blocking, release jitter or interrupt load. It can also have a huge hyperperiod that makes exhaustive schedule testing impractical.

LCM Definition

For periodic tasks with periods:

T_1,T_2,\ldots,T_n

the hyperperiod is:

H=\operatorname{lcm}(T_1,T_2,\ldots,T_n)

For two integer periods, the least common multiple can be computed with:

\displaystyle \operatorname{lcm}(a,b)=\frac{|ab|}{\operatorname{gcd}(a,b)}

The periods must be expressed in consistent units before the calculation. Mixing milliseconds, ticks and seconds without conversion creates false repeat windows.

Schedule Repeat Window

Inside one hyperperiod, each periodic task releases an integer number of jobs:

\displaystyle N_i=\frac{H}{T_i}

The total number of periodic releases in one repeat window is:

N_{jobs}=\sum_i N_i

That job count matters for test scope. A 1000 ms hyperperiod with hundreds of releases is very different from a 20 ms hyperperiod with only a few releases, even if utilization is similar.

Worked Harmonized Example

Consider three task periods:

T_1=5\ ms,\quad T_2=10\ ms,\quad T_3=20\ ms

The hyperperiod is:

H=\operatorname{lcm}(5,10,20)=20\ ms

The job counts are:

N_1=20/5=4
N_2=20/10=2
N_3=20/20=1

so:

N_{jobs}=4+2+1=7

This task set has a compact repeat window. A trace that covers several hyperperiods can expose repeatable release interactions, although it still does not replace worst-case response-time analysis.

Non-Harmonic Growth

Now consider periods:

T_1=7\ ms,\quad T_2=11\ ms,\quad T_3=13\ ms

The hyperperiod is:

H=\operatorname{lcm}(7,11,13)=1001\ ms

The release pattern repeats only after about one second. If the periods were in milliseconds but the system had many tasks, the repeat window could become minutes or hours. Exhaustive schedule replay may then be too expensive for every build or every hardware variant.

Validation Use

A hyperperiod is useful for choosing trace length, cyclic-executive tables, simulation windows, regression tests and phasing experiments. A common validation rule is to capture at least:

T_{trace}\geq kH

where k is the number of repeat windows required by the test plan. For short hyperperiods, k=3 or more may be practical. For large hyperperiods, targeted worst-case phasing and analytical checks become more important.

The test plan should also state what resets at the hyperperiod boundary. Scheduler releases may repeat, but caches, communication queues, watchdog counters, estimator state and thermal conditions may carry history across repeat windows.

Limits And Hazards

Hyperperiod analysis assumes periodic releases with stable periods. Sporadic tasks, interrupts, queues, event bursts and clock drift can break the apparent repeat pattern. Release jitter can also shift actual start times even when nominal periods repeat.

Large hyperperiods are not automatically bad, but they are a warning about test coverage. A team that claims “we tested one full schedule” should be able to state what the hyperperiod is, how many jobs were exercised and which non-periodic events were excluded or injected separately.

Relationship To Neighbor Terms

Schedulability analysis determines whether deadlines can be met. Hyperperiod identifies a repeat interval in a periodic release model. Rate-monotonic scheduling, deadline-monotonic scheduling and EDF can all be analyzed with task sets that have a hyperperiod, but their pass criteria are not the hyperperiod itself.

WCET, release jitter, non-preemptive sections, interrupt latency and priority inversion affect whether jobs inside the repeat window finish before their deadlines. Timestamp uncertainty and data age affect whether the trace evidence can be trusted.

Common Mistakes

The most common mistake is treating one hyperperiod of test data as proof of hard real-time behavior. Another is calculating the LCM after rounding periods in a way that does not match the actual scheduler tick. A third is ignoring sporadic events and interrupts because they do not fit the periodic repeat window.

A strong hyperperiod review states periods, units, LCM calculation, job counts, trace duration, non-periodic exclusions, worst-case phasing strategy and validation evidence.

REF

See also