16

Most automatic elevators have an algorithm that optimises travel between floors and users. Presumably this can be tailored to a particular building.

The first elevators were hand-operated purely by button pushing and had no intelligence of their own.

I am interested in knowing when the first programmable 'intelligent' elevator was built and what processor and operating system it might have had.

If I need to be more specific about the meaning of 'intelligence' then I'm happy to restrict this to the first use of one or other elevator algorithms,

chasly - supports Monica
  • 1,141
  • 1
  • 6
  • 12
  • 8
    Define 'programmable' a lot of automatic elevators where controlled by relay racks. This meant the could have there logic changed by rewiring the rack, but it would be a complex and expensive task. – user1937198 Nov 04 '20 at 12:26
  • Those algorithms in the link are quite simple and can probably without problem be done with one or more PLCs. A PLC is in the simplest form a programmable relay rack, but they can contain microcontrollers. – UncleBod Nov 04 '20 at 12:52
  • 8
    For a single fixed program, no "operating system" is needed. Maybe there's a common library of interface routines for buttons, lights, etc. – dave Nov 04 '20 at 13:10
  • 3
    @UncleBod, To be more specific, many modern PLCs can be programmed with ladder logic, which is a programming language that was designed specifically to emulate relay racks. Ladder logic programs are ASCII art pictures that resemble the traditional wiring diagrams for said racks. – Solomon Slow Nov 05 '20 at 01:26
  • 1
    @SolomonSlow Do you know of any PLC that cannot be programmed with (maybe a extended) ladder logic? That was the way they were programmed in the beginning at least, as far as I know. – UncleBod Nov 05 '20 at 12:02
  • 1
    In many scenarios, simple algorithms work best. There is a reason why "keep going in one direction until there are no more selected floors that way, then change" is so common, and it isn't that it's so simple to implement. You can optimize this with separate call buttons per direction, but that already starts behaving worse if users believe that pressing both buttons will make the lift appear faster. – Simon Richter Nov 05 '20 at 13:34
  • 1
    @UncleBod there are 4 PLC languages as specified by the IEC 61131-3 - Instruction list, ladder, function block and structured text. I know there are runtimes that only support instruction list, and I have personally authored runtimes that run IL and ST but not ladder or FDB, but to my knowledge there are no current comercial solutions lacking LD functionality. Newer PLC runtimes have also added SFC, C etc as additional languages. – Daniel Vestøl Nov 05 '20 at 14:30
  • @SimonRichter: If one doesn't know where the lift is, pushing both buttons will on average make the lift appear faster. It might in some cases even be useful to the person doing it (to the detriment of other lift users) if e.g. there are no washrooms on the current floor and the person wishing to board the room would be equally happy with the washroom on the floor above or the one below, or if the lift has doors on both sides but there is no other accessible connection between the sides. I don't think either situation would meet modern building standards, but... – supercat Nov 05 '20 at 16:17
  • ...I've encountered both in actual buildings. That having been said, the "elevator algorithm" is optimal when there's only one lift, but things get more complicated in systems with more than one, especially if capacity may be a factor. If a lift is full, having it stop in response to outside call buttons will delay its ability to serve more people from outside. – supercat Nov 05 '20 at 16:24
  • 3
    Historical note: "What if it's used in an elevator controller?" was the go-to example for debates about what should be included in the C core language and is the reason why such "basic" bits as I/O are in the standard library and not built-in language features. – chrylis -cautiouslyoptimistic- Nov 05 '20 at 18:29
  • First ones were mechanical, after that it was by electrical relays, after that it was programmable relays and PLCs. – Mast Nov 06 '20 at 17:51

1 Answers1

38

If I need to be more specific about the meaning of 'intelligence' then I'm happy to restrict this to the first use of one or other elevator algorithms

All the algorithms mentioned in that post have been implemented by means of relays or even high power contactors way before any processor and even less operating system was used.

Most automatic elevators have an algorithm that optimises travel between floors and users. Presumably this can be tailored to a particular building.

Automatic elevators became already a thing in the 1930s, naturally including logic for decisions what to do when there is no immediate request. This included not only waiting level, but also changing that according to time of day - e.g. not moving to a waiting position during the night, wait at the lobby in morning hours and some higher level during afternoon. All of that was implemented by electro mechanic means (relays, controller cylinders and alike).

I am interested in knowing when the first programmable 'intelligent' elevator was built and what processor and operating system it might have had.

As soon as there are preferences for what to do when there is no immediate request, there must be ways of setup, or as you call it 'programmable' and 'intelligent'. Programming the waiting region for each mode happened by plugging wires or setting pins on controller cylinders. Similar time-dependent settings were put as contact pins on clock driven controller cylinders and so on.

I got interested in this when our department moved into a 12-storey building in 1980. The building was erected in 1972 and had only three elevators. We occupied the upper 5 floors and waiting was sometimes less than satisfying. So our CEO, a engineer by trade, became, let's say, 'interested' in their workings. This included real-time monitoring on his desk and us optimizing the programming ... a quite nifty mixture of TTL, relays and contactors. Capable of doing example #1, #2 and #3 on the list - no need for #4, as Munich isn't New York :) But sorry, no processor or OS.

A Little Rant

(Not implying anything about the OP)

The question reminds of the problems we often have looking into the past, as we automatic apply today's point of view. Today we use microprocessors to control even such a simple issue as the charge of a battery, and more often than not they are way more complex than a classic 8-bit microcontroller and run some OS - heck, some even an off-the-shelf Linux. All for a task that could as well be done with a Zener diode and a resistor.

We automatically assume that everything more complex than an on/off switch will need some processor to perform, and doing so the application will of course need an OS to run on.

But development was different. Tasks like controlling a lift are rather simple sequences of logic that can be easily done using switches and contactors - adding relays only pays when it gets more complex and there's a saving to be made by adding voltage conversion. Replacing this by some TTL logic is neither a mandatory nor even a logical step. There needs to be a saving that makes a redesign necessary - after all, engineering hours to develop new circuitry are way more expensive than just continuing to build the existing one.

Same when switching to a microprocessor. And even if there's a switch, why go for a high end version capable of running an OS, when all the task needs is to check a few signals and perform simple decisions? Any minimalist (8080 or 8042 or alike) system will do it and programming is a few hundred bytes on bare metal.

The fact that today, 40+ years after the first micros, even the most basic systems offer more than some top end system of the 80s should is no reason to project today's methods back into the past.

Toby Speight
  • 1,611
  • 14
  • 31
Raffzahn
  • 222,541
  • 22
  • 631
  • 918
  • Comments are not for extended discussion; this conversation has been moved to chat. – Chenmunka Nov 06 '20 at 18:47
  • MTBF for TTL logic is way longer than for a mechanical controller, though. – scruss Nov 07 '20 at 17:18
  • Modern yes, early (pre 1980) TTL was not as reliable as one might assume. Not to mention common ageing problems of early printed boards. Examples of Contactors are known to have worked reliable for many decades. A generic better or worse is hard to tell. – Raffzahn Nov 07 '20 at 17:30
  • Those mythical chargers with a Zener diode? Those caused so much e-waste from prematurely cooked batteries that it’s not even funny. There is no rechargeable battery chemistry in wide use other than lead acid that could be charged properly with such a simplistic circuit. You can buy plenty of battery charger chips nowadays, and they always consist of a digital logic state machine and analog circuitry, and some comparators as the input interface from analog to digital. Implementing those algorithms in a small 8 bit MCU isn’t all that wasteful: universal takes over specialized. – Kuba hasn't forgotten Monica Nov 27 '20 at 20:00
  • And doing charge management on multi-cell batteries takes multi-cell monitoring and balancing and implementing that using bespoke analog computing with a simple state machine is not effective use of any resource whatsoever. A microcontroller can do the job for less money, less environmental impact (it already exists - simple firmware is less overhead than chip design). It is only now that we have established chemistries reach their full potential: MCUs have enabled that, since they keep the cells well within their preferred operating limits. I hate dumb battery packs without charge balancing! – Kuba hasn't forgotten Monica Nov 27 '20 at 20:07
  • I’d estimate that simplistic (read: wholly inadequate) battery charging has caused orders of magnitude more environmental impact - resource use and waste - than whatever it would take to do it right. The development costs for a battery charger/cell balancer and monitor are borne once, and then they prevent waste and extend battery life. When it comes to battery management, “simple” is not your friend - it’s the enemy, it’s dreadful. You don’t want that. – Kuba hasn't forgotten Monica Nov 27 '20 at 20:12
  • @UnslanderMonica Nice rant, except the one I was referring to was not for a rechargeable system :)) – Raffzahn Nov 27 '20 at 20:37