Up Peak — a lift simulator: change one thing about the building and watch the same morning run again
- Clock
- 8:00:00
- Delivered
- 0
- Average wait
- —
- Gap between cars
- — floors
4 lifts · 20 floors · 1.6 m/s · 13 people · morning rush
Change one thing
The building above is running an ordinary morning. Press one and it runs the same morning again with that changed — the same people, wanting the same floors, at the same seconds.
What you are actually looking at
A twenty-storey office building with four lifts, at the worst hour it has: the morning arrival, when almost everybody is starting at the ground floor and going somewhere different. Lift engineers call it the up peak, and it is the hour every lift group in the world is sized against.
The simulation is discrete-event. The whole morning is computed before anything is drawn — the clock jumps from one thing happening to the next thing happening — and the animation is a separate layer that asks the finished morning where everybody was at a given second. That is why the speed control can go to sixty times real time without anything struggling, and why twelve mornings can be run in the time it takes to release a button.
Cars accelerate at 1 m/s² on a trapezoidal profile with an allowance for the rounded corners a real drive uses, so a car crossing three floors never reaches its rated speed and the simulation knows it. A car that has passed its braking distance cannot stop for a call, so it goes by. Door cycles are charged in full at every stop, people cross the threshold one at a time, and a full car leaves people standing and relights their button.
What is not modelled: jerk as a controlled quantity rather than a fixed allowance; levelling and creep at the floor; rope stretch and compensation, which start mattering above roughly two hundred metres of travel; lobby crowding as a physical constraint; anybody holding the doors for a colleague. Traffic arrives as a Poisson process, which is smoother than a real lobby fed by trains and car parks — a conservative choice, since burstiness would make every argument on this page stronger.
Why the average is the wrong number
Every lift specification you will ever read quotes an average waiting time. This one runs twelve mornings and shows you all of them, because the average is hiding the only thing worth knowing.
A lift group near its capacity is a queueing system near its capacity, and those do not get gradually worse — they fall over. The same building with the same average demand produces a twenty-second morning and a two-minute morning depending on something nobody controls: whether the cars happen to fall into a convoy early on. Once they have, they stay in it, and the building spends the rest of the hour with four lifts behaving like one.
This is why the most interesting result on this page is not the fastest option. It is the one that leaves the median almost untouched and quietly deletes the bad mornings.
Where the time actually goes
A journey feels like travel, so every conversation about lifts is about speed. In this simulation the cars spend roughly as much of their working time opening, holding and closing doors as they spend moving, and that ratio is what governs everything else.
It follows that the useful question is never how fast but how many stops. Grouping passengers by destination removes stops. A bigger car removes trips but adds stops to the ones that remain, which is why it helps less than the arithmetic suggests. And taking two and a half seconds off a door cycle applies to every stop of every trip for the next thirty years, which is why lift modernisation contracts are full of door operators and rather short on motors.
The three controllers
Serve calls in order. The obvious algorithm, and the reason this page exists: it is what everybody assumes a lift does, and it is catastrophically worse than what a lift actually does. A car takes one call, delivers the people it collected, and only then looks at the queue again.
Collective control. The ordinary lift, and the same idea as the disk scheduling algorithm computer science named after it. Keep going one way while anything ahead wants that way; take everybody going your way; then turn round. It knows a direction, never a destination, until somebody is inside pressing a number.
Destination dispatch. The keypad in the lobby. Because the request names both ends of the journey before anybody boards, the controller can group people heading for the same floors into the same car. Critically, it is allocating against the whole group's time rather than the next passenger's — put greedily, it scatters people across cars, groups nobody, and is a destination system with all of the hardware and none of the benefit.
Questions people actually search for
How do lifts decide which one comes?
In an ordinary building, nothing decides. The hall button registers a call for a direction, not a destination, and any car already travelling that way will stop for it — that is what "collective control" means. A group supervisor allocates the calls nobody is going to answer incidentally, usually to whichever car can get there soonest. This is why pressing the button again does nothing and why the lift that comes is sometimes not the nearest one: the nearest one is already committed to a sweep in the other direction.
Why did the lift go straight past my floor?
Two reasons, and only one of them is annoying. If it was travelling the other way, it was not going to stop — a car sweeping down does not pick up people going up, because it would have to carry them the wrong way first. If it was travelling your way and still went past, you pressed the button after it passed its commit point: the distance it needs to decelerate comfortably. At 2.5 m/s that is around three metres, so the last second before it reaches you is too late. This simulator models that commit point, which is why calls registered late get served on the next pass.
Why do two lifts always turn up together?
Positive feedback. A car that falls slightly behind meets a slightly larger crowd, so it spends longer with its doors open, so it falls further behind. The car following it meets a thinner crowd, moves quicker, and catches up. Once two cars are together they stay together, and a four-car group quietly becomes a two-car group. In this simulator that is not scripted — the cars are given no instruction to bunch and it happens anyway. You can watch the gap between them collapse in the readout, and the mornings it happens on are the tall bars behind the average.
Is a faster lift actually better?
Less than you would expect, and it stops helping abruptly. A twenty-storey building is about sixty-eight metres tall, and a car at 1.6 m/s that has to accelerate at both ends spends most of a full-height trip at speed. Doubling the rated speed does help. Doubling it again barely does, because the car now spends the whole trip getting up to speed and slowing down again, and never sees the number on the nameplate. Rated speed is a claim about a journey almost nobody makes.
Why are the doors such a big part of it?
Because they happen at every stop and the journey happens once. Opening, holding, letting people cross the threshold and closing again costs the better part of ten seconds, and in this simulation the cars spend roughly as long working their doors as they spend moving. That is why the number of stops matters more than the distance, and why every serious control strategy is ultimately a strategy for making fewer stops.
What does destination dispatch actually do?
It moves the question from "which way are you going" to "where are you going", and it asks it before you get in. Knowing the whole journey at the moment of the request lets the controller put people who want the same floors into the same car, so each trip makes fewer stops. What it does not reliably do is make you wait less — quite often you wait longer at the lobby and arrive sooner, which is why people dislike it. In this simulation its real gift is different again: it makes the bad mornings stop happening. Press it and look at the range, not the median.
Are these numbers real?
They are real outputs of a model, and the model is described honestly below. Nothing on this page is a measurement of a real building, no number is written down in advance, and every figure you see was produced by simulating the mornings while you waited. The physics — trapezoidal velocity profiles, braking distances, counterweight balance — is the standard textbook treatment. The traffic mix and the door timings are conventional design figures. Where the model is thin, it says so.
Why is the same building sometimes fine and sometimes terrible?
Because it is running close to its capacity, and queues near capacity do not degrade gently — they fall over. Twelve mornings with identical average demand produce wildly different days, because whether the cars bunch early is a matter of luck. This is the single most important thing about a lift group and it is invisible in every published specification, all of which quote an average.
What this is, and what happens to it
This is an experiment. It might be gone next month. It exists to find out whether a simulation you can argue with teaches a system better than an article about it can — and the way that gets answered is not by anybody saying so, but by whether people who change one thing go on to change three.
It is exp-0023. Nothing is stored about you: there is no account, no cookie for this and nothing about what you pressed leaves your browser except plain counts of how many people reached each stage, which are the same numbers published on its page.