Both for the call buttons at each floor, and the floor buttons in the elevator car, we expect them to respond to pushing by some change in state to show that our command has been received. Nearly always this is some form of a light coming on (background of the button, surrounding the button, rarely a little light right in the button). I will refer to this as the “state indicator”.
In addition to acknowledging our immediate command, the state indicator conveys information to other users of the elevator. When we come to the doors we can see from a distance that the “up” call button has already been pressed, so we don’t have to force our way through the crowd to push it ourselves; and the same thing for the floor button once we’re in the car.
All these buttons have to talk to a central controller (well, or to distributed controllers which talk to each other, thus achieving the same goal as a central controller). For the elevator to actually come when the “up” call light is on, the elevator car itself has to move to that floor, stop, and open its doors. For me to arrive on the 11th floor after pushing that button, the car has to go there, stop, and open its doors.
But there’s a weird thing that happens with many elevators, including the ThyssenKrupp elevator system at the DoubleTree Park Place (where I was for Fourth Street Fantasy Convention last weekend, and where Minicon will be for the first time this coming Easter). Often, if I push a button rather briefly, I will see the state indicator come on briefly, and then go off and stay off. My push does not seem to have “taken”, at least the central controller has not accepted it. (If I wait, the elevator never comes in response to the call I thought I made, but which after the brief blink is not acknowledged. It may of course come to the floor to drop somebody off, and may then continue in the direction I want, but it never comes empty, so I feel safe in saying I have not managed to log my request with the controller.)
How can this happen? The most obvious way to set it up is to have the state indicators simply controlled from the central controller. Thus, if it comes on, the central controller does have the request, and if it doesn’t, it doesn’t (well, or the indicator is burned out, or there’s a wiring fault, or…oh, the heck with it; it doesn’t).
The evidence appears to suggest that this isn’t how it works, for whatever reason.
Okay, rampant speculation based on very little knowledge (said to be a dangerous thing; though actually that’s “learning”) coming up. It’s worth remarking that elevators are fairly old technology, that they’re safety-critical, and that they have been heavily regulated for most of the time they’ve existed. This can tend to limit implementation or design choices sometimes in bizarre ways.
One theory is that getting the request logged in the central controller and the response back to the state indicator is slow enough that people were reacting weirdly (they’d push the button, nothing would happen and then just as they tried again the state indicator would come on, for example). If this is seen (as it probably should be) as a user interface fault, maybe somebody had the bright idea of turning on the state indicator locally briefly, for long enough that the central command to turn it on would have arrived before the local command expired.
But that then raises the question of why the brief push is enough to trigger the local turn-on but not the central controller; surely it makes no sense for the two to have independent access to the exact details of the analog button-press and to make independent decisions about it based on different rules! The local module should decide if the button has been pressed or not, and then both take local action and communicate with the central controller, so they would never be in conflicting states.
It’s possible that, either in these particular elevators (which are fairly old), or in elevator designs by tradition, or perhaps by old regulatory fiat, this approach was adopted at a technological era when it was economically beneficial to put all the intelligence in one central place, and then do extremely simple things locally to work around it (I didn’t test carefully, the local turn-on of the state indicator may be as simple as “while the button is pressed”).
Or it could be weirder and much more interesting; we can always hope.
Speculation, as above, is cheap. Does anybody actually know anything about elevator control systems?
This particular behavior bugs me because the light coming on instantly tends to influence me to making shorter button pushes (I see confirmation!), which makes it more likely that I haven’t actually held the button down long enough to log my request properly.
