19-Soft-A4 Real-Time Systems · May 2013
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — May 2013 — 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 and EDF scheduling; Giorgio C. Buttazzo, Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications (Springer, 3rd ed.) — preemptive dynamic-priority scheduling and the optimality of EDF; Hermann Kopetz, Real-Time Systems: Design Principles for Distributed Embedded Applications (Springer, 2nd ed.) — distributed real-time control, network-induced delay and time-triggered protocols; Katsuhiko Ogata, Modern Control Engineering (Pearson, 5th ed.) — frequency-domain stability, phase margin and delay margin; 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.
Part (a) — definition. A real-time system is a system whose correctness depends on two things at once: the logical result of a computation, and the time at which that result is delivered. A conventional program that computes the right answer an hour late has still succeeded; a real-time program that computes the right answer an hour late has failed, because the physical process it is controlling or monitoring does not wait. Formally, each task carries a deadline — the latest instant by which its result must be available — and the system's job is to guarantee those deadlines are met, not merely to compute quickly on average. Real-time systems are usually classed as hard (missing a deadline is a system failure, e.g. an airbag controller), firm (a late result is useless but not catastrophic), or soft (a late result merely degrades quality, e.g. a video decoder dropping a frame).
Part (b) — three examples, with requirement analysis, tasks, execution sequence and deadlines.
Example 1 — automotive airbag deployment (hard real-time). A crash (rapid deceleration) is sensed, the severity is classified, and — if warranted — the pyrotechnic squib is fired before the occupant's forward motion closes the gap to the steering wheel or dash.
| Task | Execution order | Deadline (from impact) |
|---|---|---|
| Sample accelerometer / read crash sensor | 1 | < 2 ms |
| Classify severity (crash algorithm) | 2 | < 10 ms |
| Decide fire / no-fire, arm squib | 3 | < 15 ms |
| Fire pyrotechnic igniter | 4 | < 30 ms total (bag must be inflated before occupant travel closes the gap) |
Example 2 — cardiac pacemaker (hard real-time). The device continuously monitors the heart's intrinsic electrical activity and must deliver a pacing pulse only if a natural beat fails to occur within the programmed escape interval.
| Task | Execution order | Deadline |
|---|---|---|
| Sense intracardiac electrogram | 1 | continuous, sampled every ≈ 1–4 ms |
| Detect natural R-wave (beat) or its absence | 2 | within the escape interval (typ. ≈ 1000 ms at 60 bpm) |
| Decide pace / inhibit | 3 | at expiry of the escape interval, to the millisecond |
| Deliver pacing pulse | 4 | within a few ms of the decision — a late pulse can fall in the vulnerable repolarisation window and trigger arrhythmia |
Example 3 — fly-by-wire flight control (hard real-time). Pilot inputs and aircraft-state sensors are sampled every control cycle and used to compute new control-surface commands; the aircraft is aerodynamically unstable without this loop closing on schedule.
| Task | Execution order | Deadline |
|---|---|---|
| Sample sensors (attitude, rate gyros, stick/pedal position) | 1 | start of each 20 ms control frame |
| Sensor voting / fault detection (redundant channels) | 2 | within the same 20 ms frame |
| Compute control law (surface deflection commands) | 3 | within the same 20 ms frame |
| Command actuators (elevator, aileron, rudder) | 4 | end of the 20 ms frame — every frame, every cycle, indefinitely |
Part (c) — why real-time behaviour is critical here. In all three examples the "plant" being controlled — a crashing vehicle body, a beating heart, an unstable airframe — evolves under its own physics regardless of what the computer is doing, so a correct answer delivered even slightly late is delivered into a physical state the answer no longer matches: the occupant has already reached the wheel, the heart has already missed its beat and entered a dangerous rhythm, or the aircraft has already diverged beyond the control law's small-perturbation assumptions. Missing a deadline in any of these systems is therefore not a performance nuisance but a direct path to injury or loss of control, which is exactly the distinction between a hard real-time deadline and an ordinary throughput target.
