Dead Man Control

A UserInterface control designed to return a system to a safe (or neutral) state in the absence of continuous or periodic inputs from a human operator. Originally found in locomotive engines; a pedal which must be continually depressed or the train stops. Purpose was that if the engineer dies (or is otherwise incapicated), the train won't continue on driverless. Other examples:

• The engine cutoff handle on push-model lawnmowers; let go and the engine dies. (Easily defeated with a twist-tie).
• Certain kinds of sink faucets that use water pressure or electricity to automatically shut off the water when nobody is there to crank the faucet handle. (See DesertIslandFallacy)

Users often find deadman controls annoying, and may even try to deactivate/neutralize them. (Train engines have long abandoned pedals that could be weighted down; and now have (last I heard, I'm not a TrainSpotter?) buttons which must be periodically pushed whenever a chime goes off. Threatening engineers with firing if they tampered with the deadman control is apparently insufficient). The technology of which you speak is over 25 years old, the "Automatic Train Stop " which is based on the Engineer not being able to confirm more restrictive signals when received with a result of the locomotive automatically instituting an "Emergency Stop". I am sure that the technology is much more advanced than that now.

The most familiar dead man control in computing is without a doubt the screensaver.

Session management over a stateless protocol (think HTTP). Since the protocol is stateless, neither participant can tell if the other one has gone away or is still there but just keeping quiet. But if (manually-maintained) state is persisting between the participants, then sooner or later "silent" has to be interpreted as "gone", and that state discarded, unless something is heard from the other participant soon enough to prevent it.

---

An interesting variation on this theme, and having a slightly different purpose, is the DeadMansDrop?.

In a typical scenario "James" leaves an envelope addressed to "Max" with "Thomas" along with instructions that if James doesn't phone/email/etc Thomas at least once every 2/7/21/30 days then Thomas is to dispatch the envelope to Max. This device will be familiar to SpyStory? fans.

A more modern version of this is the daemon "endofworld" running on some crucial server and having a mission that, if certain data is not seen every 5/14/45/90 days, it is to erase certain data, broadcast certain data, or interfere in some way with normal operation. This device will be familiar as the "what I really should have done" afterthought following one's having been fired to protect the evil CEO's bonus.

aka Time Bomb.

---

A HardwareWatchdog? is a similar feature in a non-user-interface context. The firmware for a device can start a timer that says "in N seconds, forcibly reset the device." There is no way to turn off the timer or otherwise disable the watchdog, except to reset the countdown clock. This means that even if every program running on the device halts or deadlocks, the device is guaranteed to reset and, hopefully, get out of the "stuck" condition.

---

See: DeadManSwitch

CategoryUserInterface