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.
Parts (1)–(2) — system states and the state diagram. Because two trains can approach the crossing from opposite directions at the same time, the controller cannot simply model "gate down" as a single momentary event tied to one train — it must LATCH occupancy so that a second train's approach, arriving while the gate is already closing or closed for the first, never causes the gate to lift early. Six states capture the full behaviour: Track Clear (gates up, road open, both track sensors idle); Approach Latched (an on-coming-train sensor on either track has tripped; the controller commits to closing and starts the 10 s descend sequence); Gate Descending (the 10 s physical actuation of the barrier motor); Track Occupied (gate fully down; one or both trains are on the crossing — a fresh approach-latch from the opposite track while already in this state re-arms nothing new, it simply holds Occupied, since the gate cannot get "more closed"); Gate Ascending (the 10 s reverse actuation, entered only once the outgoing sensor(s) confirm every train that was latched has cleared); and Clearance Check (a brief confirmation state before returning to Track Clear, guarding against a barrier that has not yet reached its fully-open end-stop).
Given. Gate actuation time (each direction), t_gate = 10 s; maximum train speed, v_train = 200 km/h; maximum automobile speed, v_auto = 100 km/h; driver sightline to the red light, d_sight = 50 m; outgoing-train sensor offset from centreline, d_out = 20 m.
Find. (3) The minimum distance d_min from the crossing at which the on-coming-train sensor must be placed so that, even for the fastest possible train, the gate is always fully down before the train reaches the crossing.
Approach. The hard real-time requirement is: the gate must complete its full 10 s descent before the fastest physically possible train can travel from the sensor to the crossing. Sizing the sensor distance against the train's own stated maximum speed — rather than a "typical" or average speed — is what supplies the 100% safety margin: no train the system will ever encounter can out-run a distance derived from its own top speed, so the design has zero probability of a late gate by definition, not merely a statistically low one.
d reaches the crossing before the gate has finished closing, the crossing is unsafe; the boundary (zero-slack) case is transit time exactly equal to t_gate.
$$\frac{d_{\min}}{v_{\text{train}}} \ge t_{\text{gate}} \quad\Longrightarrow\quad d_{\min} = v_{\text{train}}\cdot t_{\text{gate}}$$d_min ≈ 556 m (rounding up, never down, for a physical installation) from the crossing on each track guarantees that even a train travelling at the maximum rated 200 km/h cannot arrive before the barrier has completed its full 10 s descent — a 100% margin against every slower, and therefore every real, train movement.| Quantity | Value |
|---|---|
Governing train speed, v_train | 200 km/h = 55.56 m/s |
Gate descend time, t_gate | 10 s |
Minimum on-coming-train sensor distance, d_min | ≈ 556 m from the crossing |
Part (4) — real-time requirements analysis. The controller's end-to-end timeline is: sensor detection (instantaneous, in the idealised model) → 10 s Gate Descending → Track Occupied for the duration both trains actually take to clear (a variable, train-length- and speed-dependent interval that the design does not need to bound, because Track Occupied is held open-endedly until the outgoing sensors confirm clearance — this is precisely why it is an aperiodic, event-triggered system rather than a fixed-duration timer) → 10 s Gate Ascending. Motorist safety is satisfied because d_min is sized off the train's own maximum speed with zero slack margin (part 3), so the gate is provably down before any train arrives, and efficient operation is preserved because the gate re-opens as soon as (not later than) the outgoing sensor confirms the last train has cleared 20 m past the centreline, rather than on a fixed worst-case timer that would hold automobile traffic longer than necessary.
v_auto = 100 km/h = 27.78 m/s needs a full-stop distance of v²/(2a) = 27.78²/6.0 ≈ 129 m — nearly 2.6× the 50 m sightline. This confirms that the 50 m figure is meant as the final visual confirmation cue, not the sole warning: consistent with standard level-crossing practice, the flashing-light/bell warning must activate well upstream of the 50 m sightline (independent of this sensor placement) so an approaching motorist already has advance notice before the gate itself becomes visible.