Safety issues

8.2 Safety issues

The software quality practitioner must be aware of the following issues surrounding software safety:

  • Improper or inadequate analyses of potential safety problems;

  • Failure to recognize safety needs during the system or software requirements definition and design efforts;

  • Inadequate planning for the mitigation of safety concerns;

  • Inadequate training in safety-critical software development techniques;

  • Inadequate monitoring of safety assurance efforts;

  • Inadequate testing of safety critical software and systems.

8.2.1 Inadequate analysis

One company violated a coding standard by taking a shortcut, which caused a weapon system to fail. Because the company did not perform an analysis of the possible consequences of this shortcut, the system encountered a $30 million failure in testing.

8.2.2 Failure to recognize safety needs

In one example, the danger of overheating in a microwave oven was not recognized. The overheating caused several serious house fires before the ovens were recalled for repair. The manufacturer suffered millions of dollars in repair costs and in restoring lost customer trust and confidence.

8.2.3 Inadequate planning

Identified hazard threats are sometimes built into the software in an attempt to avoid or minimize the hazard's effects should it be encountered. For example, avionics software that evaluates airspeed and rates of climb or descent is expected to warn the pilot if these values are out of correct ranges. Failure to program the software to properly combine the speed and descent rate could result in a crash during landing.

8.2.4 Inadequate training

Little formal education or training is available in the specialized area of safety-critical software development. While research is being conducted, most training is on the job or based on experience. Major enterprises such as NASA and the military conduct in-house training in certain cases. People who manage and develop safety-critical software can also attend occasional conferences. Beyond that, however, training and educational opportunities are scarce.

8.2.5 Inadequate monitoring

Most safety-critical software failures encountered by the author have been the result of inadequate quality management efforts. The application of non-safety-critical software quality efforts are not sufficient for critical software that exhibits any or all of the aspects identified in Section 8.1. Much more extensive reviewing and testing is necessary to reduce the likelihood of failure in critical situations.

8.2.6 Inadequate testing

Testing of safety-critical software must go beyond the does-it-meet-the-requirements level to the how-could-it-fail, or what-if, level. All of the software's safety requirements are rarely known, even by the time testing is thought to be complete.

For example, a home security system had been shown to be impervious to electrical storms. Only after the system had been installed was it found to be susceptible to the magnetic field surrounding a vacuum cleaner.

8.2.7 Combination of issues

The following situations are examples of a combination of safety issues discussed so far.

The developers of the rod lifter, a mechanism that raises and lowers control rods in a nuclear reactor, decided to attach a computer to the rod lifter to download various data elements collected by the mechanism. Management was assured that there would be no interaction between the computer and the rod lifter. The computer was attached, and several tests of the combination were run. An alert quality practitioner asked the following what-if question: What if the operator happens to press a key on the computer while the rod lifter is raising or lowering a rod? The reply was that there is no connection between the computer and the rod lifter. The practitioner asked that the rod lifter be put into action, with the computer attached. As the rod was being lifted, he hit a key on the keyboard. In response, the rod lifter raised the rod three increments but did not record the motion, leaving the rod in a different position from that displayed to the operator. The same result was experienced when the rod was being lowered.

In that case, there was a failure to analyze the possibility and recognize the potential for interaction between the computer and the rod lifter. In fact, such an interaction was summarily dismissed as a possibility. Because it was decided that the situation could not exist, no plans were included for software checks or operator training to preclude any interaction during the movement of the rods. Further, since no safety situation was deemed to exist, no testing was done to determine what would happen if there actually was an interaction.

Another, more software-specific example deals with the modification of an alarm-sensing program. In that case, the software had been in operation for a number of years when it was noticed that, during 15 seconds of each hour, the software was in self-test mode and could not detect alarms during that time. A seemingly simple modification was made to the software and the change tested. The software could now sense alarms during self-test, and the new software was installed. Some time later, an operator noticed that two lamps were illuminated on the console. One lamp indicated that an alarm had been sent to the software, while the other indicated that the software had detected no alarm. The operator immediately shut down the reactor. The problem in that case was the lack of recognition that the modification to the software carried important safety implications. Because the change had been tested, and the software clearly could recognize alarms during self-test, no regression testing of the unchanged software was conducted. It was not seen that the modified software could no longer detect alarms during the non-self-test periods (59 minutes and 45 seconds of each hour).



Practical Guide to Software Quality Management
Practical Guide to Software Quality Management (Artech House Computing Library)
ISBN: 1580535275
EAN: 2147483647
Year: 2002
Pages: 137
Authors: John W. Horch

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net