September 2026

Elevators

Somewhere between the ground floor and your office, a small metal room decides whether you spend the next thirty seconds staring at a closed door. We rarely think about that decision, but it is being made constantly, by a controller that can only see a handful of lit buttons and has to guess at everything else.

In this article we'll build an elevator from the ground up, one behaviour at a time, and then use it to compare the strategies a controller can follow. Every demonstration below is a live simulation. In this first one, a single car serves a ten-floor building under light traffic. You can drag the slider to speed time up, and the counters in the corner keep score:

The strategy driving that car is called LOOK, and by the end of the article you'll understand exactly why it goes where it goes, and what it costs when it gets things wrong. Before we can talk about strategy, though, we need a car that moves like a real one. All the animations on this page run at once; if you find them distracting, you can pause them all.

Motion

An elevator car hangs from ropes over a pulley, with a counterweight on the other side. The motor turning that pulley can only pull so hard, and the people inside can only tolerate so much. Both facts shape how the car moves. In the demonstration below, you can pick a floor with the slider and watch the car go there. The gauge shows how fast it is moving:

Notice that the car doesn't jump to full speed. It eases in, cruises, and eases out, arriving without a bump. To see that shape more clearly, let's plot the car's speed and acceleration against time. You can pick trips of different lengths:

The velocity curve has a characteristic S shape at each end, and the acceleration curve is a pair of trapezoids rather than a pair of steps. There are three limits at work. The car has a maximum velocity, which in this building is 1.5 metres per second. It has a maximum acceleration, one metre per second squared, which is roughly what feels brisk without making anyone reach for the handrail. And it has a maximum jerk, the rate at which acceleration itself may change. Jerk is what you feel as a lurch, and it is the limit that rounds the corners of the acceleration curve.

On a one-floor trip the car touches its top speed for only a fraction of a second: nearly the whole trip is spent speeding up and slowing down. This is why short hops feel slow for their distance, and it is the first hint of something we will keep coming back to: every stop is expensive.

You can experiment with all three limits below. Each slider restarts an eight-floor trip:

Raising the velocity limit barely helps a short trip, but it makes a big difference over many floors. Raising acceleration and jerk shortens every trip at the cost of comfort; real installations tune these numbers carefully, and a hospital's elevators will be gentler than a hotel's.

There is one more consequence of these limits that turns out to matter enormously for control. A car moving at full speed needs a certain distance to stop, and no controller can ask for less. The dashed line in the demonstration below marks the nearest point where the car could come to rest if it started braking right now. I'll call the first floor at or beyond it the commitment floor. The car is on its way from the lobby to the top; try pressing a call button on one of the floors along the way, at different moments during the trip:

If you press early, the floor is still ahead of the commitment line and the car stops for you. Press late and the line has already passed your floor; the car sails by and has to come back later. This is not the controller being rude. Physics has already decided. Any strategy we design will have to live with the fact that a moving car's near future is fixed.

To finish this section, let's see what the jerk limit costs in time. The two cars below are identical except for that one limit, and they start the same eight-floor trip together:

The gentle car loses about two seconds per trip. That doesn't sound like much until you remember that a busy elevator might make a stop every twenty seconds all morning long.

Doors and passengers

Moving between floors is only half of what an elevator does. The other half happens while it is standing still. Press the first button below to run a full door cycle, and watch the timeline fill in:

The doors take about a second and a half to open, wait for a while, and take another second and a half to close. That waiting period is called the dwell time. Even with nobody around, a stop costs the car six seconds of standing still, plus the deceleration before and the acceleration after. Try pressing the second button while the doors are closing: a passenger who arrives at the last moment makes them reopen, and the whole cycle stretches.

Real passengers take time to walk on and off. In this simulation each one takes about a second to board or alight, and the dwell timer only starts counting once the last of them is through. The slider controls how many people are waiting on the ground floor:

Ten passengers turn a six-second stop into a sixteen-second one. This is why a single crowded stop at the lobby dominates a car's round trip in the morning, and why the strategies we'll see later care so much about grouping people who want the same thing.

Finally, a car can only hold so many people. In the demonstration below there are more people waiting than fit inside. Use the slider to change the capacity:

When the car fills up, the remaining passengers stay on the landing and the call button lights up again as soon as the doors close. The car has to come back for them, and while it is full it is sensible enough not to stop for anybody else who is waiting to get on.

Traffic

We now have a car that moves, stops, and carries people. What we're missing is the people. In the demonstration below, you can click the up and down buttons on any landing to summon a passenger who wants to travel in that direction. The car is running the same LOOK strategy as the first demonstration; we'll take it apart soon:

Clicking buttons by hand is a fine way to get a feel for a controller, but to compare strategies fairly we need traffic we can repeat exactly. From here on, passengers will arrive at random moments at an adjustable average rate, using a random sequence that is fixed in advance. Two simulations given the same rate will see exactly the same people arrive at exactly the same times, whichever strategy is in charge. Drag the slider to see how the building copes with more and more arrivals:

How many people arrive matters, but so does where they are going. An office building sees a flood of people entering at the lobby in the morning, the reverse in the evening, and a two-way mix around lunch. A hotel or an apartment block sees more traffic between floors. In the demonstration below you can pick one of four patterns; the grid on the right counts trips from each origin floor to each destination:

These patterns are what elevator engineers design for. The morning up-peak is usually the hardest, because everyone wants the same car at the same place at the same time, and we'll use it later to find out how much a strategy can handle before the queue in the lobby grows without limit.

First come, first served

With the building in place we can finally talk about what the controller should do. It sees a small amount of information: which hall buttons are lit on the landings, which floor buttons are lit inside the car, and where the car is. It does not know how many people are waiting or where they want to go until they get in and press a button.

The simplest possible rule is to serve requests in the order they were made. Someone presses a button, it goes to the back of a queue, and the car works through the queue from the front. Press Run the scenario below to see three people appear in sequence, and watch the queue on the right. You can also click the landing buttons yourself:

The car does exactly what it was told, and the result is absurd. It collects all three passengers on the way up, then delivers them strictly in the order their buttons were pressed: up to 7, back down to 3, and up again to 8. Every request is honoured in perfect fairness, and the passenger bound for floor 8 takes a detour to floor 3 on the way.

To judge a strategy we need a number. The one that matters most to a passenger is the wait time: the seconds between pressing the hall button and the doors opening in front of them. In the demonstration below the same first come, first served controller is handling random traffic, and the chart on the right collects every completed wait into a histogram:

The average is bad, but look at the long tail on the right. A few unlucky passengers wait for minutes while the car criss-crosses the building serving requests in an order that has nothing to do with geography. We can do much better by paying attention to where the car already is.

Collective control

Here is a better idea: keep going in the direction you are already travelling, and pick up everyone along the way who wants to go that way too. Only when there is nothing left ahead do you turn around. Controllers that follow this rule are said to use collective control, and there are two classic versions.

The first is called SCAN, because the car scans the building end to end like a windscreen wiper. It goes all the way to the top floor, reverses, goes all the way to the bottom, and reverses again, stopping wherever there is a request. Run the scenario below and watch what happens after the car drops off its first passenger:

The car has nothing to do above floor 3, but SCAN insists on visiting the top anyway before coming back down for the passenger waiting on floor 2. The rule is simple and predictable, and in the world of hard drives, where it was first named, that predictability is worth a lot. In a building it wastes a trip.

The second version fixes exactly this. LOOK keeps the sweeping motion but reverses as soon as there are no more requests ahead, instead of at the end of the shaft. Here is the same scenario again:

Same two passengers, one fewer trip to the top. Now that we have three strategies, let's put them under identical traffic and compare. The demonstration below runs first come, first served on the left and LOOK on the right. Both see exactly the same passengers arrive at exactly the same moments:

LOOK's average wait comes out lower, and the gap widens as the building gets busier. Under very light traffic the two strategies make almost the same decisions; as calls pile up, first come, first served spends more and more of its time driving past people it could have collected on the way, while LOOK also delivers more passengers and drives the car less far. This is the single most important idea in elevator control, and every real system builds on it.

SCAN and LOOK are closer to each other, but the extra trips to the ends of the shaft add up. Here they are side by side; the readouts under the buildings include the total distance each car has travelled:

Collective control is not without its own unfairness. Imagine you press the down button on floor 2 just as the car passes you on its way up to the top. It is already committed to going up, and it will collect everybody else on the way before it turns around. The buttons below start such a trip and spawn exactly that passenger; try pressing the second one at different moments and watch how long they wait:

That passenger waits for a full round trip, and there is nothing LOOK can do about it. Average wait improves enormously; the worst case does not vanish. Keep that in mind for when we later add more cars.

Variations

LOOK as I've described it has a few knobs, and turning them teaches us something about why elevators are built the way they are.

The first knob is the direction on the hall button. Why have two buttons on the landing instead of one? In the demonstration below the controller on the left only stops for people who want to travel the way it is going. The one on the right stops at every lit button it passes, up or down, as if the landing had a single button. Both are running the same light inter-floor traffic:

The right-hand car makes noticeably more stops, and the extra ones are useless: the doors open, the person waiting is going the other way, and nobody gets on. Every one of those stops costs six seconds and a braking distance. The two buttons are there to give the controller exactly one extra bit of information, and that bit is worth a lot.

The second knob is what to do when there is nothing to do. An idle car can sit where it last stopped, or it can return to a home floor. In the morning, when most trips start at the lobby, parking there means the next passenger finds the doors already waiting. When traffic is spread across the building, the trip home is wasted motion. Below, the left car stays put and the right car parks at the lobby after a few seconds of idleness; you can switch between the two traffic patterns:

Finally, let's ask the question an elevator engineer actually cares about: how much traffic can this building handle? The chart below is not animated. It runs a ten-minute simulation for each arrival rate and each strategy and plots the results. The left chart shows the average wait; the right one shows how many passengers the car delivered in the final five minutes:

Both strategies handle light traffic. As arrivals increase, first come, first served saturates early: its wait times shoot up and its delivered count flattens, because the car spends its time travelling rather than carrying. LOOK keeps up a little longer and delivers more people at every rate, but it too hits a wall. Past that point the queue in the lobby grows without bound, and no cleverness in a single car can fix it. The remedy is more cars, and deciding which of them should answer a call is where the interesting algorithms live. That is the subject of the next part of this series.

Final words

We started with a metal box and three numbers describing how it is allowed to move, and ended with a controller that makes reasonable decisions using nothing but a few lit buttons. The most surprising part, to me, is how much of the behaviour is dictated by things the controller cannot change: the braking distance, the door cycle, the second per passenger. A dispatching algorithm is not so much a clever brain as a careful negotiation with those constraints.

Next time you're waiting for an elevator that seems to be ignoring you, glance at the direction lamp. The car probably isn't ignoring you at all. It has simply already committed.