19-Soft-A4 Real-Time Systems · May 2016
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Paper: National Exams, May 2016, 04-Soft-A4 Real-time Systems, 3 hours, closed book. Any five of the six questions constitute a complete paper (all questions answered below as a full study resource). Reference texts: Liu, Real-Time Systems; Buttazzo, Hard Real-Time Computing Systems; Kopetz, Real-Time Systems: Design Principles for Distributed Embedded Applications; Ogata, Modern Control Engineering.
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.
| Quantity | Symbol | Value |
|---|---|---|
| Door opening time | $t_{\text{open}}$ | 3 s |
| Door closing time | $t_{\text{close}}$ | 5 s |
| Door dwell (held open for boarding/alighting) | $t_{\text{dwell}}$ | 10 s |
| Nonstop travel, floor 1 → floor 5 (4 levels, express) | $t_{\text{full}}$ | 20 s |
| Single-level hop (car stops at that level) | $t_{\text{level}}$ | 7 s |
Find. (1) A finite-state model of the elevator controller. (2) The quickest possible time for a passenger to get out at floor 5, measured from the 'going-up' button press at floor 1. (3) The longest possible time for the same trip. (4) The longest possible time if floor 3 has the highest dispatch priority.
Approach. Model the controller as a finite-state machine, then treat "quickest possible" as the best case (car already idle at the calling floor) and "longest possible" as the worst case (car starts at the farthest floor and is forced to fully serve every intermediate floor in both directions before reaching the passenger).
Part (1) — finite-state model. Figure 1 models the car as a five-state cycle: Idle (door closed, at rest) → Door Opening (3 s) → Door Open / Dwell (10 s) → Door Closing (5 s) → Moving (car in transit) → back to Idle on arrival. A call (car or hall button) is the only external event that can start the cycle from Idle; every other transition is timer- or limit-switch-driven, which is exactly why each state's dwell is itself a hard deadline in the controller's own real-time task.
Part (2) — quickest possible time to get out at floor 5. Best case: the car is already idle at floor 1 with its door closed when the 'going-up' button is pressed, so no travel to reach the caller is needed.
Part (3) — longest possible time (no floor priority). Worst case: the car starts idle at floor 5 (the farthest point from the caller) and, before it can even reach floor 1, is assumed to be flagged down and fully serve every intermediate floor — 4, 3, 2 — on the way down; after our passenger boards at floor 1, the same worst case repeats on the way back up, with full stops at 2, 3, 4, before the car finally reaches floor 5.
Part (4) — longest possible time with floor 3 given highest priority. Giving floor 3 the highest dispatch priority means a fresh floor-3 call can always cut in ahead of any other pending request. In the worst case, such a call arrives just as the car's doors are closing after already serving floor 3 — on both the down-leg and the up-leg of Part (3) — forcing the controller to reopen and repeat the full door cycle before departure is allowed either time.
| Quantity | Result |
|---|---|
| Quickest time to exit at floor 5 (Part 2) | 41 s |
| Longest time to reach floor 5, no priority floor (Part 3) | 185 s |
| Longest time, floor 3 highest priority (Part 4) | 221 s |