OSNews

Response time. Would you really like a latency of even a second or two for an aircraft after the pilot initiates a given action? It could kill the plane.



You should know this already. It may not necessarily be any one given action that requires microsecond precision; rather, it's often dependent events that require high precision synchronization (ie. emergency systems) where several things need to happen at once when a dangerous condition is detected (eg. dropping of control rods, pumps need to be activated, power needs to be reduced, etc). It's academic.

Response time. Would you really like a latency of even a second or two for an aircraft after the pilot initiates a given action? It could kill the plane.

BTW, what are the actual real time requirements of the nuclear power plant cooling system? Why should it require microsecond precision?

You should know this already. It may not necessarily be any one given action that requires microsecond precision; rather, it's often dependent events that require high precision synchronization (ie. emergency systems) where several things need to happen at once when a dangerous condition is detected (eg. dropping of control rods, pumps need to be activated, power needs to be reduced, etc). It's academic. "

If your safety-critical system relies on precision timing in software - you haven't designed it properly.

For example - control rods in a nuclear core should be physically "floating" in the coolant ... such that if the coolant supply in the core drains for any reason the control rods automatically lower with the coolant level ... and automatically shutting down the reaction as a result.

There are a number of such designs:

http://www.popularmechanics.com/science/research/1282196.html

It is called "failsafe". Software failures ... such as not responding in time for whatever reason ... are prcisely the sort of things failsafe mechanisms should be designed to avoid.

http://www.indopedia.org/Safety_engineering.html
"Safety engineers also identify different modes of safe operation: A "probabilistically safe" system has no single point of failure, and enough redundant sensors, computers and effectors so that it is very unlikely to cause harm (usually "very unlikely" means less than one human life lost in a billion hours of operation). An "inherently safe" system is a clever mechanical arrangement that cannot be made to cause harm- obviously the best arrangement, but this is not always possible. For example, "inherently safe" airplanes are not possible. A "fail-safe" system is one that cannot cause harm when it fails. A "fault-tolerant" system can continue to operate with faults, though its operation may be degraded in some fashion."

One should avoid software as a safety measure in a design wherever possible.

The safest designs are "inherently safe". All nuclear reactors should be so designed, due to the catastrophic level of damage that could occur should they fail.

I shudder to think that anyone would contemplate relying on the correct operation of software ... especially with critical timings involved also ... in order to move the control rods of a nuclear reactor to safety.

Edited 2008-04-21 09:39 UTC