Question 4 of 9: Real-Time Systems

Question 4: Real-Time Systems (a) 4, (b) 6, (c) 10 — 20 marks

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.

(a) Defining Real-Time Software Systems

A real-time software system is a system whose correctness depends not only on the logical result it produces but on the time at which that result is produced — the system must respond to events from its environment within a bounded, application-defined deadline, and a logically correct answer delivered too late is a system failure, not merely a late success.

(b) Why Real-Time Systems Need Concurrent Processes

A real-time system typically has to service multiple independent streams of stimuli from its environment simultaneously — each with its own arrival pattern and its own deadline — and these streams do not politely wait for one another. A single sequential process can only be doing one thing at a time, so if it is in the middle of servicing a slow stimulus when a second, urgent stimulus arrives, the second one is either delayed past its deadline or the first must be interrupted mid-computation; neither option is expressible cleanly in a purely sequential program. Structuring the system as a set of concurrent processes (or tasks), one per logically independent stimulus/response pair, each with an assigned priority reflecting its deadline urgency, lets a scheduler make the interruption decision explicitly and correctly rather than accidentally. For example, in an aircraft's autopilot, a process reading the attitude sensors and adjusting the control surfaces must run on a hard, very short period regardless of what else is happening, while a process logging flight data to a display can be pre-empted whenever the attitude-control process needs to run; only a concurrent structure lets the high-priority task pre-empt the low-priority one on demand. A second, related reason is that many real-time systems are naturally decomposed into logically independent sub-systems (sensor polling, local hazard detection, communication with a remote computer) that would otherwise have to be awkwardly interleaved by hand inside one function if written sequentially; concurrency lets each be programmed, reasoned about, and scheduled independently.

(c) Process Architecture for the Air Quality Monitoring System

The system decomposes cleanly along the boundary the question itself draws: sensors are grouped into 100 neighborhoods, alarm decisions are local to a neighborhood, and only summary reporting is centralized. This suggests a three-tier concurrent process architecture: one lightweight periodic process per sensor group performing the interrogation and local threshold check, running under a central computer that aggregates and reports.

Sizing the design against the numbers given: 5,000 sensors organized into 100 neighborhoods puts 50 sensors in each neighborhood; each sensor is interrogated 4 times per second; the alarm threshold is more than 30% of a neighborhood's sensors reporting below-acceptable air quality; and the central computer's report period is 15 minutes.

1. Per-neighborhood sensor count. $n_{\text{per-nbhd}} = N_{\text{sensors}} / N_{\text{nbhd}} = 5000/100 = \boxed{50 \text{ sensors per neighborhood}}$.
2. Polling rate per process. Each Sensor Poll Process interrogates its 50 sensors at 4 Hz per sensor, so it issues $r = 50 \times 4 = 200$ interrogations/s; system-wide across all 100 neighborhood processes this is $R_{\text{total}} = 5000 \times 4 = \boxed{20{,}000 \text{ sensor reads/s}}$, which is the aggregate I/O load the sensor-poll tier must sustain (distributed across 100 independent processes, i.e. 200 reads/s per process, not one process doing 20,000/s).
3. Local alarm threshold, in sensor counts. "More than 30% of the sensors in a particular neighborhood" out of 50 is $0.30 \times 50 = 15$ sensors, so the Local Threshold Check process raises its Warning Light Driver whenever 16 or more (strictly more than 15) of its 50 sensors read below acceptable quality — this integer threshold, not the raw 30%, is what the local process actually compares against on every poll cycle.
4. Central report cadence. Each sensor is read 4 times/s, so over a 15-minute $=900\text{ s}$ reporting window a single sensor contributes $4 \times 900 = 3600$ readings, and the Central Computer's report process wakes once every $900\text{ s}$ to summarise the accumulated readings from all 5,000 sensors ($5000 \times 3600 = \boxed{1.8\times10^{7}}$ raw readings per report cycle, in practice pre-aggregated by each neighborhood process rather than shipped raw).

The resulting architecture places the deadline-critical work (poll a sensor 4 times a second and react to a local threshold) inside 100 small, independent, high-priority periodic processes, one per neighborhood, each with a hard 250 ms period. This isolates the warning-light response time from anything the central computer is doing, satisfying the safety-relevant part of the requirement even if the central link is briefly slow or the report generation is running. The Central Computer runs a lower-priority periodic process (period 15 minutes) that simply collects the running counts/summaries already computed by each neighborhood process and formats the city-wide report; because the local alarm decision is made entirely within the neighborhood process, the warning lights never wait on the central computer at all.