The article, "Trains, Elevators, and Computer Science", begins with a brief history of trains and elevators and specifically their braking systems. The writer, Dick Lipton, a computer science professor at Georgia Tech university, positions his article as practical by first stating that George Westinghouse was "not a theoretician, but was one of the great inventors of the 1800's", then fully explaining the braking problems and adding little comments such as "Pretty neat" and "extremely clever" after some engineering idea.
After 10 paragraphs of history we finally reach the point where Lipton explains the "general principle" behind both and the relation to computing science. This principle is
...do not rely on an action, but on the structure of the system. Make the default, a passive state, a safe state so that when the system fails, it gets to the safe state by default.
In other, less redundant, words: when a failure occurs, return the system to some "safe" state. Stated in this way, it is an unremarkable "principle". The implementation of this increases in complexity as the size of the state space increases. Again, not very remarkable.
Lipton ends with three questions:
- Could we, for example, make a system that is safe from worm attacks and uses a passive system?
- Is there a formal model of passive vs. active systems that we could use to reason about whether such systems are even possible?
- Is there any way to exploit the power of the passive methods used by Westinghouse and Otis to solve computer questions?
Define "safe", "passive", and "active". I must also ask what worm attacks have to do with software systems.
Modeling the Idea
In any case, these "passive" methods and systems are possible to implement.
Let us define a single function f and assume that the function
modifies the state of the system. Thus, in the above example, there
are two states: s0 and
s1 (s is the set of all
states). Execution of the function looks like this:
s0 -> f ->
s1.
If the function fails, then some action is taken to modify the current
state to s0. We will call
that function g.
So if we have f and g in sequence, the state will change in the
following manner: s0 -> f ->
s1 -> g ->
s0
f
succeeds, then we are in state
s1. If f fails, then we
execute g and return to state
s0.
Modeling the Engineering Examples
We can model the two engineering examples using the above idea.
Let s0 be the train at rest.
Let the function f release the brakes and cause the train to move and
change the state to s1 (the
train in motion).
Thus we have: s0 -> f -> s1
Failures can occur in f and so we must introduce g, the function that
modifies the state to s0. In
this case, g will stop the brake release.
Thus we have the same thing as before: If f succeeds, then we are in
state s1; if f fails, then we
execute g and return to state
s0. We can translate that to
English: if the brakes are released (f is executed), the train is in
motion (state is now s1); if
the brakes could not be released for whatever reason (f is not
executed or has only partially executed), the train is at rest (state
is set to s0 and becomes
"safe").
Conclusion
In software systems we define the rules and, if you will, the laws of physics. Therefore we can design and implement systems where "safe" states exist though the value of this depends on the system. The complexity of reverting or resetting state in a large system may be too intellectually difficult for us humble programmers to understand.
Lipton's second question, "Is there a formal model of passive vs. active systems that we could use to reason about whether such systems are even possible?", is answered: yes, "passive" systems are possible though I still don't know exactly what that mean. The third question is also answered, as others have pointed out. Some research has already been done in ideas related to the subject of the article such as fault-tolerant systems (also known as fail-safe systems) and self-stabilization. So yes, these "passive" methods are being used to solve computing problems.
