Elevator Scheduling Algorithms: LOOK, RSR, and Destination Dispatch

Elevator wait times depend heavily on the dispatch algorithm used to assign cars to hall calls. Simpler algorithms like LOOK often provide better or comparable performance to more complex schemes such as Otis' RSR or Destination Dispatch, especially in typical office buildings.

One Car: SCAN and LOOK

The LOOK algorithm, a variant of SCAN, serves as the baseline expectation for elevator movement. It starts at the lobby, travels upward only as far as the highest pending request, then reverses and serves downward requests, picking up and dropping off passengers along the way. This differs from the original SCAN (or "elevator" ) patent, which always proceeds to the top floor before reversing.

Multiple Cars and Basic Coordination

With multiple cars, a central scheduler assigns each hall call to the nearest idle elevator. This nearest‑car rule ignores how many passengers are already aboard and whether the car is moving toward or away from the caller, which can lead to suboptimal assignments when the nearest car is full or heading the wrong direction.

Measuring Performance: Wait‑Time Distributions

Engineers evaluate algorithms using wait‑time percentiles rather than averages because riders remember long waits. A p50 of 1 minute means half of all rides wait one minute or less; a p90 of 2 minutes means 90 % of rides wait two minutes or less. The article’s histograms show these metrics under various flow rates—for example, at 14 requests per minute the LOOK algorithm yields a p90 around 2 minutes, while at 8 requests per minute the p90 improves.

Morning Rush and Traffic Patterns

Traffic is highly directional during peak periods. In a large corporate office, morning traffic is dominated by trips from the lobby to upper floors, evening traffic reverses, and lunchtime mixes both directions. This asymmetry makes morning rush the worst case for wait‑time statistics, as elevators spend much of their travel serving one‑way flow.

Smarter Elevators: Otis’ RSR

RSR adds nuanced penalties and bonuses to the basic ETA‑to‑pickup score:

  • ETA to pickup – time for the car to reach the hall call.
  • Onboard load penalty – increases with current passenger count.
  • Same‑direction anti‑bunching penalty – discourages sending a car to a floor already targeted by another car moving the same way.
  • Direction‑match bonus – rewards cars already traveling in the desired direction.
  • Idle‑nearby bonus – favors idle cars within two floors of the caller.
  • Low‑load bonus – prefers cars with fewer passengers. The system recomputes these scores every five seconds, allowing a passenger initially assigned to elevator A to be rerouted to elevator B if delays occur.

LOOK vs RSR: Benchmark Results

Simulation results in the article compare LOOK and RSR across flow rates:

  • At 14 requests per minute, LOOK and RSR show comparable wait‑< 30 s and wait‑< 90 s percentages.
  • At 8 requests per minute, RSR achieves slightly better wait‑< 30 s and wait‑< 90 s numbers.
  • As flow increases, LOOK begins to outperform RSR because when cars are consistently full and stopping on every floor, the extra RSR rules provide little benefit.
  • LOOK also tends to beat RSR in small buildings with fewer cars per bank, where simplicity reduces overhead. These findings echo the comment that "simplicity often beats complexity"【@heironimus】.

Destination Dispatch: Trade‑offs

Destination Dispatch replaces hall‑call buttons with floor‑kiosks that tell passengers which specific elevator to board. While this gives the scheduler full destination information, it introduces rigidity: once a car is assigned, the passenger cannot switch to another elevator even if conditions change. The article notes that this loss of flexibility often makes Destination Dispatch worse for wait times than traditional up/down buttons, except in very tall buildings with eight or more cars per bank. This counterintuitive result stems from the five‑second re‑optimization loop: "The kiosk enforces rigidity, you must get in the assigned elevator. The state of the world 30 sec after you called your elevator might be very different but the system is unable to adapt"【@JoshTriplett】. However, Destination Dispatch can excel when traffic consists of large groups heading to the same floor, as it batches those passengers together【@omoikane】.

Full Simulation Insights

The interactive simulator lets users vary floor count, car count, and request flow. Adjusting these parameters shows how the balance between LOOK, RSR, and Destination Dispatch shifts—for example, with 8 floors, 4 cars, and 18 requests per minute the simulator displays wait‑time percentages for each algorithm. This reinforces that the optimal algorithm depends on the specific building’s traffic pattern and elevator capacity.

Human Factors and Practical Considerations

Real‑world elevator performance is affected by more than pure scheduling logic:

  • User behavior: Many riders press both the up and down buttons, mistakenly believing it speeds arrival, which actually causes unnecessary stops and confusion【@olex】.
  • Capacity sensing: Without a reliable full‑car detector, elevators may stop at every floor despite being packed, creating frustrating scenes where crowds wait outside a full car【@vova_hn2】.
  • Wear and tear: Aggressive repositioning to reduce wait times can increase mechanical wear, suggesting a trade‑off between passenger delay and maintenance cost【@taftster】.
  • Psychological wait: Providing distractions or perceived progress during a wait can improve satisfaction even if actual wait time stays the same【@psadri】.
  • Prefetching strategies: Some installations, such as Apple Park, move idle elevators toward the ground floor after a call to reduce future response time【@ladberg】. These factors illustrate why the "best" algorithm in simulation may differ from the one that feels best to passengers in practice.

Sources