5.5.12 · D3Embedded Systems & Real-Time Software

Worked examples — Real-time constraints — hard and soft deadlines

3,497 words16 min readBack to topic

Before starting, a reminder of the four quantities (all built in the parent topic note): = worst-case execution time (see Worst-Case Execution Time analysis), = period, = relative deadline, = the fraction of the one CPU that task eats.


The scenario matrix

Every schedulability question falls into one of these cells. The examples below are labelled with the cell(s) they hit, and together they touch all of them.

Cell Input situation What must happen
A (over-subscribed) Instant FAIL — physics, no scheduler saves you
B RM bound (quick test passes) PASS proved by sufficient test alone
C RM bound (quick test fails) Verdict UNKNOWN → must run exact RTA
C1 Cell C, RTA converges with PASS despite failing quick test
C2 Cell C, RTA gives some FAIL — confirmed unschedulable
D (single task) Bound ; degenerate limit
E (empty task set) Trivially schedulable;
F exactly equals a bound Boundary — is inclusive?
G RM says FAIL but EDF says PASS Same tasks, scheduler choice matters
H Word problem: hard vs firm vs soft Classify by cost-of-miss, not by numbers
I (deadline shorter than period) Utilisation test alone is invalid

Example 1 — Cell B: the clean PASS

  1. Utilisation. . Why this step? is the first gate: it is the total CPU share demanded. Below we may proceed; above we stop.
  2. RM bound for . . Why this step? Fixed-priority scheduling can waste CPU at bad phasings, so it needs a bound under . This is that bound.
  3. Compare. PASS. Why this step? The Liu–Layland test is sufficient: clearing it is a proof all deadlines are met.

Verify: sits comfortably below — margin . Units: all are dimensionless fractions (seconds/seconds), so summing is legal.


Example 2 — Cell A: instant FAIL by physics

  1. Utilisation. . Why this step? Before any clever test, check if the demand physically fits.
  2. Compare to 1. FAIL, unconditionally. Why this step? You are asking for of one processor. No scheduler — RM, EDF, or magic — can serve more than . Some deadline must slip.

Verify: means over one period of the longer task you demand more CPU-seconds than exist. In s you request CPU-seconds but only exist. Impossible.


The RTA notation, defined once


Example 3 — Cell C + C1: quick test fails, exact test rescues

  1. Utilisation. . Why this step? First gate. , so not physically impossible.
  2. RM bound. . Compare: → quick test FAILS. Why this step? Sufficient test failed → verdict is unknown, NOT "unschedulable". We must escalate.
  3. Exact test on the lowest-priority task (task 3). Apply the RTA equation with (both other tasks have shorter periods, so both can preempt task 3). Why this step? Task 3 has the least priority, so it suffers the most interference and is the hardest to satisfy. The counts how many releases of each higher task land inside task 3's response window and steal the CPU.
  4. Iterate. Start .
    • .
    • .
    • . Converged at . Why this step? We iterate because appears on both sides — a fixed-point. As the window grows, more preemptions might fit; when the value stops changing, no new preemptions appear and we have the true worst-case finish time.
  5. Compare. → task 3 meets its deadline. (Tasks 1 and 2 are even easier — see verify.) → PASS. Why this step? Schedulable iff for every task.

The figure below draws this worst-case timeline: all three tasks are released together at (the "critical instant"), and you can watch task 3 get pushed around by the higher-priority tasks yet still finish at , comfortably before its deadline at .

Figure — Real-time constraints — hard and soft deadlines

Read the figure as three stacked lanes (one per task). Coloured blocks show when each task actually holds the CPU. Notice task 3's block is split: it runs, gets preempted when task 1 is re-released at (the lavender interruption), then resumes and completes at — the point marked . The dashed coral line at is its deadline; the gap between and is the safety margin.

Verify: Task 1 (highest priority) has no interference: . ✓ Task 2: ; iterate , so . ✓ All pass — so this set is schedulable under RM even though the quick bound said "don't know."


Example 4 — Cell C + C2: exact test confirms FAIL

  1. Utilisation. . Why this step? First gate. , so not physically impossible — an exact test is meaningful.
  2. RM bound. . Compare: → quick test FAILS → escalate to RTA. Why this step? Sufficient test failed → verdict unknown, must run the exact test.
  3. RTA for task 2 (; only task 1 preempts it). :
    • .
    • . Converged, . ✓ Why this step? Check the middle task before the bottom one; it passes.
  4. RTA for task 3 (; both preempt it). :
    • .
    • .
    • . FAIL. Why this step? The window keeps growing past the deadline; once we stop — task 3 can never finish in time under worst-case phasing.
  5. Verdict. Task 3 misses → set is unschedulable under RM, even though . Why this step? Schedulable requires every ; one miss condemns the set.

Verify: climbs and exceeds before converging. A set with can still fail under fixed priorities — exactly why the quick test is only sufficient.


Example 5 — Cell G: RM fails, EDF passes (same tasks)

  1. EDF bound. For periodic tasks with on one CPU, EDF is schedulable iff . Why this step? EDF always runs the job with the nearest deadline, wasting no CPU at bad phasings — so it can safely use the whole processor.
  2. Compare. PASS under EDF. Why this step? Meeting EDF's exact bound is a proof of schedulability for single-CPU periodic sets.

Verify: Same tasks, two verdicts: RM = FAIL, EDF = PASS. This is why EDF is called optimal for single-CPU periodic sets — it dominates fixed-priority. The RM misses came purely from fixed priorities idling the CPU at the critical instant.


Example 6 — Cells D, E, F: degenerate and boundary inputs

(D) One task, . .

  1. Bound. . Why this step? With a single task there is no interference, so the RM bound equals the EDF bound: the full CPU.
  2. Compare. PASS. Why this step? The single task consumes of the CPU, leaving headroom; clearing the bound of proves it meets its deadline.

Verify: A lone periodic task is schedulable iff , i.e. . Here . ✓

(E) Empty set, . No tasks.

  1. Utilisation. (empty sum). Why this step? With zero tasks there are no terms to add, and an empty sum is by convention — the CPU demands nothing.
  2. Compare. any bound → PASS trivially. Why this step? If there is no task, there is no deadline to miss; the verdict must be schedulable, and clears every possible bound.

Verify: Nothing to miss ⇒ schedulable. The empty-sum convention gives , consistent.

(F) exactly on the bound, . The two-task RM bound is . Pick concrete tasks that hit it exactly. Let task 1 be , so . We need . Choose and , giving .

  1. Total utilisation. . Why this step? We deliberately engineered to sit on the boundary to test the inequality's edge.
  2. Compare. RM bound . The test is , and holds → PASS. Why this step? Liu–Layland uses (inclusive), so landing exactly on the bound is safe.

Verify: Our equals it to six decimals. Being exactly on the bound passes; only strictly greater forces the exact test.


Example 7 — Cell H: the word problem (hard / firm / soft)

  1. (a) is a HARD deadline. A missed stabilisation update = loss of control = catastrophe. The utility of a late result is effectively . Why this step? We classify by the cost of a miss, and here the cost is total system failure — the defining mark of a hard deadline. This loop drives the WCET-based proof obligation and belongs in the RTOS's highest-priority band.
  2. (b) is a FIRM deadline. A frame arriving after its display slot has zero value — you discard it — but nothing breaks. Why this step? Late = worthless but harmless is exactly the firm category; the right action is to drop the stale frame, not display it late.
  3. (c) is a SOFT deadline. A battery reading a little late still has reduced value (roughly right), and occasional lateness is tolerable. Why this step? The utility degrades gently after the deadline rather than collapsing — the signature of a soft deadline. Design goal: bound the statistics (e.g. " within "), and tolerate jitter.

Verify (design mapping):

  • (a) → prove zero misses via a schedulability test + guard against priority inversion.
  • (b) → firm: discard-on-miss, no proof of zero misses needed.
  • (c) → soft: graceful degradation, statistical target. The numbers (//) do not decide the category — the consequence of lateness does. A deadline could be hard in a different system (e.g. a medical infusion controller).

Example 8 — Cell I: deadline shorter than period

  1. Utilisation. . Very low! Why this step? Habit says "low ⇒ fine." But the deadlines are shorter than the periods, so we must not trust it.
  2. The trap. The Liu–Layland utilisation bound assumes . Here , so a low does not prove schedulability (see the matrix remark). We must run RTA and compare against , not . Why this step? Utilisation averages demand over the whole period; a short deadline demands the work early, which cannot see, so only the exact test is valid here.
  3. RTA for task 1 (highest priority, , no one preempts it). . Compare: . ✓ Why this step? The highest-priority task has no interference, so its response time is just its own cost — check it against the tight deadline , not the period .
  4. RTA for task 2 (; task 1 preempts it). :
    • .
    • . Converged, . ✓ Why this step? Iterate the fixed point; task 2 finishes at , within its deadline of .
  5. Verdict. Both meet their (tighter) deadlines → PASS — but only because RTA confirmed it. The number was never a valid proof here. Why this step? In Cell I the utilisation test is silent; the exact test against is the real judge.

Verify: and . Had we trusted alone we'd have skipped the check that actually mattered. Note both response times are compared against the short , not the periods.


Recall Self-test: name the cell for each set

A: → ::: Cell A — , instant FAIL. B: → ::: Cell B — , quick PASS. C1: → ::: Cell C1 — quick test fails () but RTA passes (). C2/G: → ::: Cell C2 under RM (RTA fails, exceeds ), Cell G under EDF (PASS, ). D: single task → ::: Cell D — bound , PASS. E: no tasks → ::: Cell E — , trivially schedulable. F: → ::: Cell F — exactly on the RM bound, PASS (inclusive ). I: → ::: Cell I — but , utilisation test invalid; RTA gives , PASS.