Logic behind elevator (lift) control in office building

Hi there,

I work in a newish office building, where you type in your destination floor (“17”) on a totem on the ground floor and the system assigns you a lift (elevator) → (“A”) that will take you to your desired floor. Fairly standard for newish buildings, I recon - most of you should be able to relate to that scenario.

Every day I wonder (but cannot come up with a basic “logic”) behind the system of which lift is assigned to my trip.

For discussion’s sake - and to keep things simple, lets assume:

  • a 20 story building,
  • 4 lifts (A,B,C,D),
  • multi-party-office building of 20 companies, one per floor (so presumable very few trips from e.g. floor 6 to floor 18) and
  • no underground (parking) floors.

Potential a-priori algorithms I could come up (all disapproved by my every day observations):

  • some lifts are assigned to even floors, some to odd destination floors (not true)
  • some lifts are assigned to floors 1-10, others 11-20 - or a similar split (not true)

So, based on that context, can we debate the (high level) logics of controlling/assigning trips of random office-folk of 4 lifts to 20 floors, presumably minimizing waiting time and energy-cost (what other variables might there be)?

any takers?

I’ve honestly never seen a system like this in the wild, but I know they exist. Either way, even in “old style” elevator systems with your typical up and down call buttons, the controller would still generally assign the closest available cab. No point in waiting for the one at floor 70 to get down to the ground floor lobby if one is already sitting idle on floor 3, for instance. That means there’s starting states that need to be factored in, and the number of permutations can quickly grow out of control.

There may be no obvious logic. An elevator system controlled by a computer with learning capability may well respond in different ways at different times. For example, it may send empty cars to upper floors at going home time in the expectation that the demand will be up there.

There will almost certainly be no fixed logic like elevators going to specified floors, they will want to ensure usage is evenly distributed amongst the 4 units. If you routinely have many people waiting for an elevator, an option might be to assign the initial person randomly, then assign anyone selecting a nearby floor (± 3 floors) to their elevator, while assigning a new passenger for a distant floor to a different elevator.

It would make little sense to have someone asking for floor 17 ride in elevator A, then immediately assign a person for floor 18 to elevator B.

Another option is to spread out the passengers so that there aren’t 10 different floors being serviced by one elevator trip. This likely uses more energy, but provides better service.

I know I don’t know, but from watching these sorts of elevators in many busy hotels on many occasions, I’d suggest these two ideas pretty well convey what the central control logic is doing.

You want to minimize any given car making lots of stops, and you also want to minimize a car traveling long distances empty. But you don’t know, except in generalities, what requests may come in over the next 3-ish minutes that your current known customers will be waiting then using the collection of elevators.

The controller will first look at where each elevator is. Then it will look at which direction the elevators are going. Then it will look at how much demand there is for an elevator. Then it will look at what other calls are in the system. If it is a busy time it may send everyone going to floors 16 to 20 to elevator A, 11 to 15 to elevator B, 6 to 10 to elevator C, and 2 to 5 to elevator D. Assuming all the elevators are no on the ground floor. If they already in use Depending on the wait time for the people already waiting for an elevator it will assign you to the elevator where the best wait time in line with others.

Basically it will look at where the cars and which way they are going. How many people are waiting before you. HOw long it will take to deliver you then pick out the car with the best time. New elevators are computer ran; they no longer use relay logic. Makes a difference in operating. If there is a power glitch where the power goes off for a short period of time the elevator will not restart until the computer reboots. Older relay elevators would restart with in about minute of power being restored. It only stook the time to restart the motor generator set.

How much of a delay is there between you entering your desired floor, and the system assigning you an elevator? If no delay, that significantly hampers the ability of the system to group people together.

Not much of a delay at all. It’s assigned as soon as you push your floor button. I was skeptical at first, but these things do really work smoothly and seem to reduce wait times. (I suppose it could be that they’re used on modern systems that would be equally efficient without this technology)

That is how I would expect it to be. It is not going to wait and see who else is going to select a floor. If you pick 17 and the elevator that is going to 16 or 18 has not left yet then it will direct you to that elevator. If it just left, then by the criteria Described earlier it will assign the next best elevator.

With older buildings of sufficient height there would be elevators (or banks of elevators) dedicated to particular ranges of floors, presumably to make sure that someone going to the 55th floor doesn’t get stuck on a “local” stopping at twenty different floors on the way.

My guess is the algorithm in this new system is too complex to reverse engineer from observation. Twenty years ago the “fuzzy logic” people would have been all over this. Now it’s probably the “AI” people.

ETA: Found this article:

If it’s an AI doing it, I hope they have specified the objective correctly. If they told it to minimize wear and tear on the elevators, it may kill all humans.

No, that would get blood and all sorts of icky stuff all over the equipment. To minimize wear and tear the cars would just sit on the ground floor with the doors closed. If the AI has a robotic helper is could post signs saying “Elevators broken - use stairs.”

I worked on the 68th floor of a building and I remember that one of our company executives asked our group (which had nothing to do with elevators) to come up with a justification for getting one particular elevator shaft reserved for the personal use of him and his cronies, so that he wouldn’t have to spend 30 minutes a day waiting for elevators.

Results were inconclusive.

Oddly enough, I recall Novell did some analysis of a similar problem decades ago to optimize disk head seeking when multiple users were accessing the same drive(s) in a server. They called it “elevator seeking,” natch.

Pretty much the only difference was that wait times were measured in milliseconds instead of minutes. The goal was several-fold: to minimize the head movement and wait times in a network environment.

Novell used a sophisticated algorithm where all seek requests were sorted according to the location on the disk, and when enough time had passed, started the seek operation from the outside cylinder to the inside one, hitting all locations in one pass, sequentially, then repeating the process from inside to outside. That sounds a lot like the human elevator problem posed here.

(I wasn’t a developer for this project, I just read a detailed technical paper they released.)

I remember long ago a Dave Berg cartoon in Mad magazine, “In a Las Vegas Lobby.”

A guy in a cowboy hat comes up to a bank of three elevators and pushes the Up button. After a couple panels of waiting all three go “bing” at the same time, the doors on the middle cab open, and he’s buried under a cascade of coins.

I wonder if something similar would happen to me as i stand in my apartment lobby watching the floor numbers change above each of the three elevator doors. What happens when all three show “7” at rhe same time?

Once you’ve typed in your desired floor on the central console, you need to move out of the way to let other people type their destinations. This works best if the system shows you immediately which elevator to go to. “You want floor 17? Go wait for elevator #4. Next!” Even a 30-second delay would add logistical complications.

I was in a hotel with this system, and it seemed it worked that way. But you can’t reverse engineer it from the ground since calls on upper floors would affect the car selection also.

Yeah. There was a lot of effort put into disk seeking algorithms. The basic elevator algorithm was what we taught to the computer systems class. It was always interesting to compare any algorithm with pure random selection of the next request. Disks were interesting in that seek time was in competition with rotational latency, but the time to start the head moving, and then stop it and let the heads settle again was a significant cost. So not dissimilar to an elevator, where the time to stop, open doors, move people in and out, close doors, and accelerate again may be a significant cost. The edge to edge sweep made a lot of sense. Especially as there was often locality with many sectors on the same cylinder bunched together. The algorithm encouraged such clustering.

Disk scheduling algorithms became something of the secret sauce of manufacturers, and it became impossible to get a straight answer on performance. Once disks got caches all bets were off.

When it comes to elevators, I doubt that there is all that much more sophisticated than: when a button is pressed the system looks for the nearest car that is heading your way and allocates that one. Engineers are going to be especially cautious about being overly sophisticated here. Interacting optimisation of multiple elevators is a nice start on finding yourself an edge case that yields an unstable system. Some optimisation is probably useful when a car becomes unused. Sending it to a location that is most likely to be useful next would come at little cost. Some additional useful input might be measuring the weight of the car to determine if it isn’t worth scheduling it because it seems to be full.

In times yore, when systems were simple and robust, elevators were programmed in ladder logic. Essentially a finite state automata. Ladder logic because that was how you drew the design out, and then translated it into a huge pile of relays. Modern day PLCs for purpose may be no more sophisticated. Just smaller. There is a lot to be said for a system that can be formally analysed and proved correct.

As I recall with the disk seek algorithm, one key was the longer a particular read request waited, the higher priority it got, since everyone needed timely service. Usually head move time was the biggest delay so another consideration would be like sharing a taxi (or elevator?) that you can drop another passenger off or pick them up if they happened to be close to the path already in progress.

Did the upper floors also have a selection button or simply UP and DOWN? Was the assumption the downward passengers are all going to the lobby, or was there a mezzanine and basement parking typical destination too?

I worked as a security guard in college, and noted that in a high-rise building of about 12 floors with two or 3 elevators, the default in quiet times was the system would locate the elevators on the ground floor except for one positioned about 2/3 the way up (say 7 or 8 of 12). Elementary scheduling.

If I were programming this “fuzzy” I’d do something like imagine the destination you punched in as a fuzzy mark and assign it to an elevator that’s near and (will be?) free. Sort of - your destination is the peak of a bell curve around X nearby floors. Next customer - if their destination falls within that curve, add to that elevator which has not yet arrived/departed. If not close, assign another elevator. SO if the elevators are busy, you will build a list of people - let’s say - who are going to top 5 floors, or floors 13-18, or 1-7 or 4-10. How full and how long to wait for next elevator, also considerations. The spread of the bell curve is determined by elevator speed.

Obvious rules - no back and forth - nobody wants to ride up to 14 then back down to 12, you always stop along the way. Avoid stuffing the elevators, since the computer cannot know that you entered the floor because your party of 6 just came back from lunch, or Bob is pushing a luggage cart. Plus, too many destinations in the same elevator makes the trip really slow for the last person.

With modern high-speed elevators, it can take almost as much time to go 1 or 2 floors due to slowing down, than to do 5 or 6 floors - so the key is maybe schedule the people whose floors are close together in the same elevator or allow for 2 clusters. AI algorithms can also map out traffic patterns and adjust accordingly (many arrivals in the morning, departures at 5PM, which destinations hold and seem to take forever to load/unload, etc.)

But ultimately, the logic would probably work on assigning a dynamic weight system to each trip - 2 dimensions, floor number(s) and priority. Closest match of elevator and person is assigned. That then changes the elevator’s weights, which affects which elevator the next customer gets.