Newsgroup: comp.risks

A portable CD player I was experimenting with, features a safety switch,
located on the hatch door, which turns the unit off once the door is opened.
The role of that switch is to ensure that the laser in the unit will not
operate with the door open.  A number of other appliances (microwave ovens come
to mind) have similar safety switches.

One day I decided to deeply discharge the batteries of the unit (i.e., drain
the them as much as possible) as a precaution against the NicCad "memory
effect."  The unit has an auto-power-off feature whereby when the batterie
voltage falls bellow a certain level it switches itself off.  Every time the
unit switched itself off, I pressed "play" again to switch it on.  The
objective of this procedure was to drain the batteries as much as possible.
After some time the unit crashed.  The display had some strange segments lit
and the auto-power-off feature was no longer functioning.  My first conclusion
was that the auto-power-off was software controlled.  My next move was to check
what other things were software controlled.  I plugged mains power to the unit
so that I would not loose this crashed state and tried opening the hatch door.
As I was expecting the safety switch was also, apperently, software controled
because the unit remained on.  Now, I was faced with a unit turned on, with
full power applied to it and with an open door hatch.

Moral: Software emulation of safety interlocks is not a good idea.  Even with
formaly proven correct software, we would still need hardware that was formaly
proven to correctly function under all probable conditions to implement a safe
product.  Direct control methods (such as a switch connected to the power
supply in this case) are more appropriate.

Diomidis Spinellis, Department of Computing, Imperial College

Unless otherwise expressly stated, all original material on this page created by Diomidis Spinellis is licensed under a Creative Commons Attribution-Share Alike 3.0 Greece License.