19-Soft-A4 Real-Time Systems · December 2015
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — December 2015 — 04-Soft-A4 Real-Time Systems. Three-hour, closed-book exam (Casio or Sharp approved calculators only). Format: six questions of equal value (20% each); any five constitute a complete paper and only the first five as they appear in the answer book are marked. All six 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 scheduling, priority-driven scheduling of periodic tasks; Giorgio C. Buttazzo, Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications (Springer, 3rd ed.) — RTOS design, EDF optimality, real-time system design examples; Hermann Kopetz, Real-Time Systems: Design Principles for Distributed Embedded Applications (Springer, 2nd ed.) — distributed/embedded real-time system design; Ian Sommerville, Software Engineering (Pearson, 10th ed.) — embedded and critical-systems context; Transportation Association of Canada, Geometric Design Guide for Canadian Roads — perception-reaction time and stopping-sight-distance practice.
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.
(1) Periodic real-time system — a home programmable thermostat. The thermostat samples room temperature and decides whether to actuate the furnace/AC on a fixed, recurring period (typically every few seconds to a minute), regardless of whether the temperature has changed. This satisfies the periodic criterion precisely because the task itself is released by the clock, not by an external event: every sampling instance is separated from the last by the same interval T, and each instance has an implicit deadline (act before the next sample) that is short relative to the thermal time-constant of the room, so an occasional late sample has negligible physical consequence — the classic profile of a periodic control-loop task.
(2) Deadline-oriented real-time system — a video-conferencing application. Each captured video frame must be encoded, transmitted, decoded and displayed before the next frame is due, or the call visibly stutters. The system is explicitly organised around per-frame deadlines derived from the frame rate (e.g. 33 ms per frame at 30 fps) — the correctness of a decoded frame's pixel values is necessary but not sufficient; it must also arrive on-screen inside its deadline window, which is the defining property the question is probing (a late frame is discarded/skipped rather than shown out of order).
(3) Hard-deadline based real-time system — an automotive airbag deployment controller. The controller must detect a crash-severity threshold and fire the airbag inflator within a few tens of milliseconds of impact onset; a "late" deployment (after the occupant has already moved forward into the steering wheel) provides essentially none of the intended protection and can itself cause injury. This is the canonical hard real-time example: missing the deadline is not a degraded outcome, it is a system failure with direct safety consequences, so the design is verified to guarantee the deadline under every anticipated crash pulse, not merely to meet it "most of the time."
(4) Soft-deadline based real-time system — an ATM or online-banking transaction. A withdrawal or balance-check request has an expected response time (a few seconds); if the network is congested and the response takes longer, the customer is annoyed and the bank's perceived service quality drops, but the transaction itself is not unsafe and eventually still completes correctly. The value of the late response decays with lateness rather than dropping to zero (or negative) instantly — the graceful-degradation signature of a soft-deadline system, in contrast to the airbag's all-or-nothing hard deadline.
(5) Aperiodic task based real-time system — a household smoke/CO detector. The alarm task is not released by a clock and has no predictable inter-arrival time; it is triggered only by the unpredictable, irregular event of smoke or carbon-monoxide concentration crossing a threshold. Once triggered, the system must respond immediately (sound the alarm within a bounded latency of detection), so it combines an aperiodic arrival pattern (the axis this part of the question is testing) with a hard-deadline-like response requirement once triggered — illustrating that "aperiodic" describes when a task is released, which is an independent design axis from whether its deadline is hard or soft.
