Unformatted text preview: design changes, including hardware safeguards against software errors. Related problems were found in the Therac-20 software. These were not recognized until after the Therac-25 accidents because the Therac-20 included hardware safety interlocks and thus no injuries resulted. Therac-25 , Investigation Findings For the Therac-25 accidents, contributing factors included: management inadequacies and lack of procedures for following through on all reported incidents, overconfidence in the software and removal of hardware interlocks (making the software into a single point of failure that could lead to an accident), presumably less-than-acceptable softwareengineering practices, and unrealistic risk assessments along with overconfidence in the results of these assessments.
An Investigation of the Therac-25 Accidents
IEEE Computer, Vol. 26, No. 7, July 1993, pp. 18-41. Nancy Leveson, University of Washington Clark S. Turner, University of California, Irvine Mars Climate Orbiter Mishap
NASA Project Mars Climate Orbiter (MCO) either burnt up and hit Mars or was thrown into a solar orbit "we're not sure which".
Source <http://physics.uwb.edu.pl/ptf/echa/encyklopedia/woronko/mars-ap.jpg> Ed Weiler, Associate Administrator for Space Science Nasa Headquarters 10 November 1999 MCO Mishap, Root Cause Failure to use metric units in the coding of a ground software file, "Small Forces" used in trajectory models.
Source: Executive Summary of "Mars Climate Orbiter Mishap Investigation Board 1 Report". MCO Mishap, Contributing Causes
Undetected mismodeling of spacecraft velocity changes. Navigation Team unfamiliar with spacecraft. System engineering process did not adequately address transition from development to operations. Inadequate communications between project elements. Inadequate operations Navigation Team staffing. Inadequate training. Verification and validation process did not adequately address ground software.
Source: Executive Summary of "Mars Climate Orbiter Mishap Investigation Board 1 Report". Lessons Learned
Software should not be assigned sole responsibility for safety, and systems should not be designed such that a single software error or software-engineering error can be catastrophic. Software should be subjected to extensive testing and formal analysis (reviews) at the module and software level; system testing alone is not adequate. To facilitate reviews : software audit trails should be designed into the software from the beginning documentation should not be an afterthought. Could outsourcing have prevented the failures ?
London ambulance dispatching system and Therac-25 Probably. Applying software engineering (CMM) standards from the start for these projects would have prevented most problems from occuring. Ariane 5 and Mars Climate Observer Probably not. The best people to detect and correct the errors were on hand. Both NASA and ESA already follow very stringent software engineering norms....
View Full Document
- Fall '11
- Software engineering, Engineering Case Studies