Question 9 of 9: Real-Time Software Systems

Question 9: Real-Time Software Systems (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) Definition of a Real-Time Software System

A real-time software system is one whose correctness depends not only on the logical result it produces but also on the time at which that result is produced. It must sense and respond to stimuli arising from its physical environment — usually as an embedded component controlling or monitoring hardware — within deadlines that are dictated by that environment rather than chosen by the software designer; a logically correct output delivered after its deadline is, for a real-time system, a failure of the same kind as a logically incorrect output.

(b) Soft vs. Hard Real-Time Systems

In a hard real-time system, missing a deadline constitutes a system failure with unacceptable or catastrophic consequences — the deadline is absolute, and the correctness of the whole system depends on every relevant deadline being met (a flight-control surface command, an engine-ignition timing pulse, an insulin-pump dosing cycle). In a soft real-time system, an occasional missed deadline degrades the quality or usefulness of the result but does not constitute outright failure and does not endanger the system — a late video frame causes a visible glitch, a late audio sample causes an audible click — and the system's acceptability is judged statistically (the proportion of deadlines that may be missed) rather than by an absolute guarantee on every single one.

(c) State Machine Model of the Telephone Answering Machine

The machine begins on-hook in Idle. An incoming call moves it to Ringing, and after the configured number of rings it auto-answers into Play Greeting. Once the greeting completes, the machine moves to Listen for DTMF Tones — this single state serves both the ordinary caller (who says nothing and simply waits) and the telephone owner dialling in remotely (who enters a numeric code as DTMF tones). If a valid owner code is detected before the listening window expires, the machine transitions to Remote Playback and plays back the stored messages over the phone line; when the owner hangs up or playback finishes, the machine returns directly to Idle with no message count change, since remote access is not itself an incoming message. If no tones arrive, or an invalid code is entered, the machine instead transitions to Recording Message and records the caller's message; when the caller hangs up or the maximum recording length is reached, the machine increments its accepted-message counter, updates the LED display, and returns to Idle.

The system as a whole is closer to soft real-time — an answering machine that is a fraction of a second slow to pick up after the Nth ring, or that pauses briefly before starting playback, only degrades the user's experience rather than failing outright. The one part of the system with a genuinely hard real-time constraint is the DTMF tone-decoding sampling loop itself: correctly discriminating between the standard DTMF tone-pair frequencies requires sampling and processing the audio signal within tight, fixed timing windows, and missing that timing does not just degrade quality but causes an outright misread digit (rejecting a valid owner code, or worse, admitting an invalid one), so that inner loop must meet its timing budget on every cycle.