Glossary term

Processor Demand Criterion

Engineering definition of the processor demand criterion covering demand-bound functions, constrained deadlines, EDF feasibility, interval checks and validation evidence.

Definition

method

The processor demand criterion is a schedulability check that compares the computation demanded by jobs with deadlines inside an interval against the available processor time in that interval.

The processor demand criterion is used for real-time task sets, especially under EDF-style reasoning and constrained deadlines, when utilization alone does not expose short-deadline demand bursts. A useful review states the task set, demand-bound function, checked intervals, WCET basis, deadlines, release assumptions, blocking exclusions and validation evidence.

The processor demand criterion is a schedulability check that compares the computation demanded by jobs with deadlines inside an interval against the processor time available in that interval. It is useful when a simple utilization screen hides short-deadline bursts.

The method appears in real-time scheduling, EDF feasibility analysis, embedded firmware reviews and safety-related timing evidence. It is most often discussed for independent preemptive uniprocessor task sets with constrained deadlines, but the engineering idea is broader: demand inside any reviewed window must fit the available time.

Demand-Bound Function

For task:

\tau_i=(C_i,T_i,D_i)

where C_i is WCET, T_i is period or minimum inter-arrival time and D_i is relative deadline, a common demand-bound function is:

\displaystyle dbf_i(t)=\max\left(0,\left\lfloor\frac{t-D_i}{T_i}\right\rfloor+1\right)C_i

It estimates the execution demand from jobs that both arrive and have deadlines inside an interval of length:

t

For a task set:

\Gamma=\{\tau_1,\tau_2,\ldots,\tau_n\}

the processor demand screen is:

\sum_i dbf_i(t)\leq t

for the relevant interval lengths.

Why Utilization Is Not Enough

Utilization checks average demand:

\displaystyle U=\sum_i\frac{C_i}{T_i}

A task set may have:

U<1

and still fail if several jobs have short relative deadlines that crowd into a small interval. Processor demand checks the local interval where the crowding happens.

This is especially important when:

D_i<T_i

because the deadline can arrive before the next period would suggest.

Worked Interval Check

Consider two tasks:

\tau_1=(C=1.0,T=5,D=3)
\tau_2=(C=1.4,T=8,D=4)

At interval length:

t=8\ ms

the demand from tau_1 is:

\displaystyle dbf_1(8)=\left(\left\lfloor\frac{8-3}{5}\right\rfloor+1\right)1.0=2.0\ ms

The demand from tau_2 is:

\displaystyle dbf_2(8)=\left(\left\lfloor\frac{8-4}{8}\right\rfloor+1\right)1.4=1.4\ ms

Total demand is:

dbf(8)=2.0+1.4=3.4\ ms

The interval passes because:

3.4\leq8

At a shorter interval:

t=4\ ms

the demand is:

dbf(4)=1.0+1.4=2.4\ ms

which also passes:

2.4\leq4

The example is feasible by this limited interval screen before adding blocking, release jitter or interrupt demand.

Interval Selection

The criterion is only as good as the interval set that is checked. In practice, intervals are chosen from task deadlines, deadline-plus-period combinations or a reviewed finite horizon:

t\in S_{check}

where S_check is the set of interval lengths used for the proof or engineering screen. A weak review checks one convenient interval and misses the shorter window where demand is highest.

For constrained-deadline task sets, useful candidate intervals often occur where a job deadline can land:

t=kT_i+D_i

for integer:

k\geq0

The release note should state whether the interval set is exact, conservative, tool-generated or manually sampled. If it is sampled, the residual risk belongs in the validation evidence.

Validation Boundary

The criterion is mathematical evidence, not a trace by itself. Useful validation includes task tables, WCET basis, relative-deadline definitions, checked interval set, generated demand table, EDF or scheduler configuration, deadline-miss counters and forced bursts near high-demand intervals.

If a real implementation includes blocking, disabled interrupts or release jitter, those terms must be added elsewhere or the criterion must be adapted. A clean demand-bound result does not excuse missing driver timing evidence.

Relationship To Neighbor Terms

Earliest deadline first is a scheduling policy. The processor demand criterion is an analysis method often used to reason about deadline feasibility under EDF-style assumptions. Deadline-monotonic scheduling and fixed-priority response-time analysis use a different proof style.

Sporadic task models provide the minimum inter-arrival time used by the demand function. Hyperperiod and critical instant help with release patterns and validation windows. Deadline miss is the failure event when interval demand, blocking or implementation effects exceed what the schedule can provide.

Common Mistakes

The most common mistake is checking only total utilization. Another is using the period as the deadline when the real requirement is shorter. A third is checking too few intervals and missing a short demand burst. A fourth is ignoring blocking, jitter or ISR load because the demand-bound formula itself looks clean.

A strong processor-demand review states the task model, interval set, demand-bound calculation, utilization context, assumptions excluded from the test, validation traces and change triggers.

REF

See also