NivaarExam PrepOfficial exam papers ↗

19-Soft-A4 Real-Time Systems · Undated paper

Question 2 of 6: Automotive Collision-Avoidance System — State Diagram and Real-Time Requirement Analysis

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

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 2: Automotive Collision-Avoidance System — State Diagram and Real-Time Requirement Analysis (20%)

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.

Given.

QuantityValue
Warning threshold, $d_{\text{warn}}$15 m
Auto-brake threshold, $d_{\text{auto}}$10 m
Required safe standoff at rest, $d_{\text{safe}}$3 m
Vehicle speed, $v$50 km/h
Mechanical braking distance, $d_{\text{brake}}$7 m

Find. (1) A state diagram covering both a stationary and a slow-moving object ahead. (2) The real-time requirement (deadline budget) on each of the sensor, decision unit and actuator. (3) How speed, reaction time and braking distance relate, and what that implies for this design.

(1) State diagram. Radar continuously reports the closing distance $d$ (for a stationary object this is simply the car's own approach distance; for a slow-moving object ahead it is the relative distance, i.e. closing speed = own speed − lead-object speed, which the same threshold logic applies to once expressed in relative terms). The system has four operating states, driven purely by threshold crossings on $d$:

Clear(d > 15 m)Warning(10 < d <= 15 m)audible alertAuto-brake(d <= 10 m)controller applies brakeStopped(v = 0)object entersrange, d <= 15 md <= 10 m,no manual brake yetvehicle speedreaches 0object removed /driver resumes ->return to Clearobject moves away,d > 15 m again
Figure 1 — collision-avoidance state diagram. Solid arrows = the forward closing sequence (both the stationary- and moving-object cases follow the same threshold logic once d is read as the relative gap); dashed red arrows = recovery once the gap re-opens or the object clears. The same diagram covers a parked car (own speed = closing speed) and a slow lead vehicle (closing speed = own speed − lead speed) — only the numeric rate at which d shrinks differs between the two cases, not the state logic.

(2) Real-time requirement analysis. Each of the three subsystems has a distinct, chained deadline within the overall stopping-time budget:

SubsystemTaskReal-time requirement
Sensor (radar)Sample range $d$ continuously and report a fresh reading.Hard, periodic/time-based: must sample fast enough that $d$ cannot cross a full threshold band (15→10 m) undetected between samples — at $v=13.9$ m/s a 5 m band is crossed in 0.36 s, so the radar update period must be a small fraction of that (a few tens of ms is typical for automotive radar).
Decision-making unitCompare $d$ to the 15 m / 10 m thresholds and select Warning vs. Auto-brake.Hard, event-based: triggered by each new radar sample; must complete well within one sensor period so its output is still current when the actuator acts on it.
Automatic brake (actuator)Apply braking torque once Auto-brake state is entered.Hard, event-based, and — as shown in Part (3) below — has essentially zero slack at these numbers: the combined sensor+decision+actuator latency must be met with (in the worst case) no additional margin, which is exactly why this loop is hard real-time rather than merely fast.

(3) Relationship between speed, reaction time and braking distance. Once the system decides to brake, the vehicle needs a total stopping distance $d_{\text{stop}} = d_{\text{react}} + d_{\text{brake}}$, where the reaction distance $d_{\text{react}} = v\,t_{\text{react}}$ is the distance covered during the sensor+decision+actuator latency before the brakes physically start decelerating the car, and $d_{\text{brake}}$ is the purely mechanical distance covered while decelerating. Converting speed to consistent units and applying the safe-standoff requirement to each threshold gives the allowable stopping budget in each case:

  1. Speed in SI units. $$v = 50\ \text{km/h} \times \frac{1}{3.6} = \boxed{13.89\ \text{m/s}}.$$
  2. Auto-brake case — available stopping budget. Braking must complete before the car closes to within $d_{\text{safe}}=3$ m of the object, starting from the 10 m trigger point: $$d_{\text{budget,auto}} = d_{\text{auto}} - d_{\text{safe}} = 10 - 3 = \boxed{7\ \text{m}}.$$
  3. Reaction-distance margin for the auto-brake loop. $$d_{\text{react,auto}} = d_{\text{budget,auto}} - d_{\text{brake}} = 7 - 7 = \boxed{0\ \text{m}} \;\Rightarrow\; t_{\text{react,auto}} = \frac{0}{13.89} = \boxed{0\ \text{s}}.$$
  4. Warning case — available budget for a human driver's manual response. $$d_{\text{budget,warn}} = d_{\text{warn}} - d_{\text{safe}} = 15 - 3 = \boxed{12\ \text{m}}, \qquad d_{\text{react,warn}} = 12 - 7 = \boxed{5\ \text{m}}.$$ $$t_{\text{react,warn}} = \frac{5\ \text{m}}{13.89\ \text{m/s}} = \boxed{0.36\ \text{s} \;(360\ \text{ms})}.$$
QuantityResult
Speed, $v$13.89 m/s
Auto-brake reaction-distance margin0 m (0 s system latency budget)
Warning (manual) reaction-distance margin5 m
Manual driver reaction-time budget≈ 0.36 s (360 ms)
Check: at the given numbers the auto-brake trigger (10 m) leaves exactly zero slack once the 7 m mechanical braking distance is subtracted from the 7 m available budget — i.e. the sensor+decision+actuator chain must respond with essentially zero added latency for these parameters to guarantee the 3 m standoff. This is presented as the intended pedagogical result (it demonstrates precisely why the sensor→decision→actuator loop is hard real-time rather than merely fast), not as an error in the given data; a real design would trigger auto-braking slightly earlier than 10 m to build in a positive latency margin.