19-Soft-A4 Real-Time Systems · Undated paper
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Note. Pages 3–4 print the same question stem three times side by side with only the supporting data table changed. The six distinct question stems are solved once each below, using the first data variant printed for each; the repeated variants are noted at the end of the relevant question.
National Exams — 04-Soft-A4 Real-Time Systems. Three-hour, closed-book exam (Casio or Sharp approved calculators only). Cover page states: "Any five questions constitute a complete paper. Only the first five questions as they appear in your answer book will be marked. All questions are of equal value (20% each)." All six distinct questions recovered from the source are solved below for completeness. Where a doubt exists as to interpretation, the candidate is expected to state assumptions — engineering assumptions used below are flagged in check callouts.
Reference texts: Jane W. S. Liu, Real-Time Systems (Prentice Hall, 2000) — task models, timing requirements, FCFS/EDF and priority scheduling; Giorgio C. Buttazzo, Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications (Springer, 3rd ed.) — preemptive fixed-priority and dynamic-priority scheduling; Hermann Kopetz, Real-Time Systems: Design Principles for Distributed Embedded Applications (Springer, 2nd ed.) — distributed real-time control, network-induced delay; Katsuhiko Ogata, Modern Control Engineering (Pearson, 5th ed.) — frequency-domain stability, phase margin, transport-lag systems; Ian Sommerville, Software Engineering (Pearson, 10th ed.) — general software-engineering process context.
Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.
Classification background. A real-time task's criticality class (hard / firm / soft) describes the cost of missing its deadline, while its triggering class (time-based / event-based / hybrid) describes what causes the task to be released for execution. Time-based (a.k.a. clock-triggered or periodic) tasks are released by the passage of time — a timer or clock tick; event-based (aperiodic/sporadic) tasks are released by an external occurrence — an interrupt, message, or sensor threshold crossing; hybrid tasks combine both, e.g. a periodic poll that can also be pre-empted by an urgent event. The nine cells below give one worked example each, chosen so the deadline consequence in each row visibly matches its criticality class.
(a) Hard real-time — missing the deadline is a system failure (safety, control-loop instability, or physical damage).
| Trigger | Example | Why it is hard real-time |
|---|---|---|
| Time-based | Flight-control law update every 20 ms control frame on a fly-by-wire aircraft. | The airframe is aerodynamically unstable between updates; a missed frame lets the aircraft diverge before the next correction — deadline is fixed by the control period, not by any external event. |
| Event-based | Automotive airbag deployment triggered by a crash-severity threshold from the accelerometer. | Released only when a crash event occurs; the pyrotechnic squib must fire within milliseconds of that event or the occupant has already reached the wheel — a late fire is worse than no fire. |
| Hybrid | A nuclear reactor's periodic (100 ms) rod-position/temperature poll that can also be pre-empted immediately by a hard-wired scram (emergency shutdown) interrupt. | Normal operation is clock-triggered monitoring, but an out-of-bounds event must instantly interrupt the periodic loop and force the shutdown task to run — both triggering modes carry a hard deadline. |
(b) Firm real-time — a late result is useless and is discarded, but the system itself keeps running (no catastrophic failure, just lost value/quality).
| Trigger | Example | Why it is firm real-time |
|---|---|---|
| Time-based | Financial-market tick-data snapshot sampled every 1 ms for a high-frequency trading algorithm's next quote. | A snapshot that arrives after the sampling window closes is simply dropped and the next periodic sample used instead — no crash, but the stale value is worthless for that trading decision. |
| Event-based | A live sports-broadcast instant-replay clip generated on request from an umpire's challenge event. | Released by the challenge event; if the clip isn't ready before the review window closes, it is discarded (the call stands) — the computation itself is simply abandoned, not retried late. |
| Hybrid | A cellular base-station scheduler that periodically (every TTI) allocates radio resource blocks but must immediately react to an event-triggered handover request from a fast-moving user. | The periodic allocation and the event-triggered handover both have a firm deadline (one TTI): missing it degrades that user's service for one interval rather than crashing the network. |
(c) Soft real-time — a late result still has some value; timeliness affects quality of service rather than correctness.
| Trigger | Example | Why it is soft real-time |
|---|---|---|
| Time-based | A video-conferencing codec that decodes and displays a new frame every 33 ms (30 fps). | A frame that arrives a little late can still be displayed slightly delayed, or the player can drop it and continue — the viewer experiences degraded smoothness, not a system failure. |
| Event-based | A smartphone's on-screen keyboard predictive-text suggestion, triggered by each keystroke event. | If the suggestion computation is slow, the user simply sees it appear a moment later (or not at all for that keystroke); usefulness decays gradually with lateness rather than failing outright. |
| Hybrid | A home thermostat that samples temperature every 30 s (time-based) and also reacts to a manual set-point-change event from the user's app. | Both the periodic sample and the event-triggered response can lag by a few seconds with only minor, gradually-worsening comfort impact — no safety or correctness consequence. |