Elevator Scheduler

Goals

For users: minimize the transit time (wait time outside + wait time inside) while using the elevator.
For operators: minimize operational energy expenditure, allow for easy maintenance, allow configurability.

Motivation

On a recent trip to Hawaii while staying in a large high-rise building with a bank of 5 elevators, I closely observed the building’s elevator scheduler in action and decided to simulate one myself.

System Requirements

Note: list needs to be segregated by user vs operator requirements::

Capacity is enforced as an upper bound on the aggregate weight of users riding an elevator.
Direction of elevator motion does not change until current destination.
Service speed of a group of elevators managed by a scheduler is identical.
Service capacity of a group of elevators managed by a scheduler may not be uniform.
Service speed and capacity are always known to the elevator scheduler.
Elevator-internal and elevator-external requests need to be separately identified.
Resting point of elevators should be one of the floors with highest external request count.
Elevator-internal requests should not ignored and are serviced by the local elevator.
Elevator-internal requests can be toggled between selected/de-selected states.
Duplicate requests for the same floor are ignored.
Elevator-external requests are scheduled by the elevator scheduler.
Elevator has 3 operational modes - normal, emergency, stopped.
Emergency operational mode disables all external scheduling.
Operators may choose to disable scheduling for certain floors (e.g. floor 13).

System Invariants

Implementation Notes

What amounts to a sub-optimal decision?

Any “change of mind” decision elongates service time for already-made promises. Consider in-flight passengers as promises, elevator scheduler should maintain the direction of travel. It is okay to accept more internal and external requests along the direction of travel assuming they are all scheduled before reversing direction of travel.