Skip to content

Instantly share code, notes, and snippets.

@amcgregor

amcgregor/elevator--destination-dispatch.md Secret

Last active March 17, 2019 15:24
Show Gist options
  • Save amcgregor/3ac6f394c1d4d31990d13338efb92b0a to your computer and use it in GitHub Desktop.
Save amcgregor/3ac6f394c1d4d31990d13338efb92b0a to your computer and use it in GitHub Desktop.
Download ZIP
"Building Elevators Modernization"
Raw
elevator--destination-dispatch.md

Destination Dispatch: "Overall trip-times can be reduced by 25% with capacity up by 30%."

Destination Dispatch announcement

Concerns

  • If your elevator buttons need a “Pick Language” button, you’ve utterly failed at life.

  • Use of a touch-screen tablet interface precludes access by those wearing gloves or the visually impaired.

  • Open car at lobby with only two people on it, request a floor, get assigned the car that is on the top floor.

  • The interface for floor request management is external to the elevator car; if you sneak on to one, you’re going for a trip everywhere but to your destination unless you are lucky, with no way to explicitly request return to the lobby. (The only interior buttons: open/close doors, alarm, emergency call, and the close door button does nothing.)

  • Doors do not detect obstructions and re-open (or stop), they crush gently and persistently before triggering “out of order” failure of the car. (E.g. someone arriving late and trying to squeeze in ensures nobody goes anywhere.)

  • If the elevator is marked as out of operation (e.g. by holding the doors) the requested floors are immediately and totally forgotten.

  • Mechanical failure rate; Hall effect buttons (detecting a magnetic field moving through a ring or past a sensor) are virtually indestructible; used in nuclear missile silos for their reliability. These are buttons built to survive an apocalypse. Replacing them with a tablet introduces billions of hardware and software moving parts that can fail.

  • Elevators are finite state machines; they are not computers, require no “memory”, etc. (Think: coin returns on vending machines.) This makes them incredibly simple and fault-tolerant. Involving computer coordination… not nearly as reliable.

  • Promises faster and more organized packing, the uncoordinated elevators double or triple the throughput.

  • No way to cancel a floor request; with a set of managed elevators and a set of unmanaged ones which are measurably faster in operation, people call with the managed ones, then get on an unmanaged one which happened to arrive earlier, inconveniencing everyone else in their appointed car. (Who end up visiting a floor for no reason.) Not a problem AT ALL with buttons kept in-car.

  • Open car at lobby with only two people on it, request a floor, get assigned the car that is on the top floor.

  • No visible indication of which floors have already been called. Encourages use of unmanaged cars by new arrivals if existing queue and those already in-queue joining them when they see progress there, inconveniencing a larger number of people.

  • If the system doesn’t count number of requests for the same floor, it misses out on optimizing with knowledge of the number of passengers. If it does, it becomes vulnerable to “dogpile” and denial of service attacks.

  • If there is a failure and people become trapped, there is no indication from the lobby to which floor they are stuck at.

  • Similarly, no identification within the car as to which floor the car is near for emergency identification purposes.

  • Went to floor 2 with 3 and 5 scheduled/visible — there still appear to be "hidden variables".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment