Modelling Case Studies
Case Study: An Elevator Controller
A bank of cars, hall calls and car calls: modelling elevator state, separating dispatch from stop ordering, and keeping the controller single-threaded.
Hard15 min read
By the end of this chapter
- Distinguish hall calls, which a dispatcher assigns, from car calls, which belong to one car
- Model a car's lifecycle as explicit states and transitions
- Put the dispatch algorithm behind a strategy so it can change without touching the cars
- Confine controller state to one thread fed by an event queue
The brief
A building has N floors and M elevator cars. On each floor there are up and down buttons (hall calls); inside each car there is a button per floor (car calls). Design the controller that decides which car answers each hall call and in what order each car visits its stops. Motor physics, door hardware and fire service modes are out of scope, though the design should leave room for them.
- Assume a hall call is assigned to exactly one car once assigned.
- Assume a car serves stops in its current direction before reversing.
- Assume doors must be closed before a car moves — the one safety invariant in scope.
- Assume the dispatch rule will be tuned after launch.
Entities
| Entity | Is the only thing that knows |
|---|---|
| Car | Its current floor, direction, state and pending stops |
| Door | Whether it is open, closing, closed or obstructed |
| HallCall | A floor and a desired direction — a value |
Sign in to keep a note here. It is free, and nobody else can see it.
Sign inYou’ve reached the end
What this chapter was for:
- Two decisions, two owners: the dispatcher picks a car; the car orders its own stops.
- Explicit states make illegal actions — moving with the doors open — impossible to express.
- Dispatch is the requirement most likely to change, so it is the seam.
- Many buttons, one controller thread: concurrency solved by confinement, not locks.