Question 1 of 6: Pedestrian-Actuated Traffic Intersection

Question 1: Pedestrian-Actuated Traffic Intersection (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. Pedestrian crossing time t_walk = 20 s; vehicle stopping time when the light changes t_stop = 30 s; maximum call-to-service deadline T_resp = 60 s; minimum Red+WALK phase duration t_duration = 30 s; two independent pedestrian push buttons, each with its own idle/pressed state (giving the "four push-button states" of the sub-system, modelled below).

Find. (1) A finite-state model of the intersection controller; (2) a design and a real-time analysis showing the controller is schedulable — i.e. that it can always serve a call inside its deadline and hold the crossing open long enough for both classes of user.

Approach. Model the system as two cooperating finite-state machines — the traffic-light controller (three phases: NS Green, NS Yellow, NS Red+WALK) and the pedestrian call sub-system (four states: Idle, Pressed & Latched, Servicing, Debounce/Reset) — then check the given timing budget against the requirement each state's dwell time must satisfy.

1. Model the light-phase FSM. The through-road defaults to NS Green (major-road priority; the cross-road stop signs always yield, so they need no signal state of their own). A latched call — from either push button, or from the EW-approach vehicle detector implied by "when a car approaches a stop sign" — moves the controller to NS Yellow once the minimum-green interval has elapsed, then to NS Red + WALK, which holds red for both vehicles and pedestrians simultaneously; expiry of the walk/clearance timer resets the call and returns the controller to NS Green.
2. Model the push-button call sub-system as its own 4-state FSM. Each corner's button is physically a simple 2-state device (not-pressed / pressed), but the controller's call-handling logic — which is what the question is really probing, since it must not miss a press while a walk phase is already in progress — is the four-state machine below: Idle (no call), Pressed & Latched (a press from either corner is OR-ed together and held until served, so a second press during Idle re-arms nothing new), Servicing (WALK is lit, the light-phase FSM is in Red+WALK), and Debounce/Reset (a short lockout after WALK ends, so mechanical bounce or a lingering press cannot immediately re-trigger the cycle).
3. Real-time requirement 1 — the phase duration must dominate both safety-critical times. The Red+WALK phase must stay red at least as long as the slower of "a pedestrian needs to finish crossing" and "an approaching vehicle needs to come to a stop," i.e. t_duration ≥ max(t_walk, t_stop). $$t_{\text{required}} = \max(t_{\text{walk}}, t_{\text{stop}}) = \max(20,\,30) = 30\ \text{s}$$ Substituting the given duration, 30 s ≥ 30 s — the requirement is met, but with zero slack: the exam's own numbers place the design exactly on the feasibility boundary, not comfortably inside it.
4. Real-time requirement 2 — the call-to-service deadline bounds worst-case wait. A pedestrian (or stopped EW vehicle) that issues a call must be served — i.e. the controller must reach Red+WALK — within the stated T_resp = 60 s, which upper-bounds the NS-Green dwell the controller may run before it must yield to a pending call (this is the controller's own release-to-response deadline, the same concept examined quantitatively for the task set in Question 5). Combining both bounds, a pedestrian's worst-case total wait from button-press to WALK-lit-and-safe-to-cross is $$T_{\text{worst}} = T_{\text{resp}} + t_{\text{yellow}} \approx 60 + 3 = 63\ \text{s},$$ using a conventional 3 s yellow clearance (not separately specified in the source).