CS685 - Writing Assignment #2

Therac-25 Analysis

Between June 1985 and January 1987, the Therac-25, a computerized radiation therapy machine, caused
six known radiation overdoses while treating patients. After much company denial, false claims of fixes,
and government intervention, the flaw of the Therac-25 was found and corrected. Failure of the Therac-
25 was technically due to a software design error that did not process user input correctly under a certain
circumstance. The overall reason for the system’s failure was the poor software-engineering practices
used to build the Therac-25.

Analysis of the development of the Therac-25 shows several of the same failure modes that Henry Petroski
cites in his book Design Paradigms. We can see complacency in the design of the Therac-25. Since the
design was based on the Therac-6 and Therac-20, changes to support the Therac-25 were not considered
thoroughly to consider possible introduction of new design flaws. Also, as cited by Petroski, when
inspecting the failure of a system, it is important to look critically at all aspects of the design that went in
to creating the failed system. The company’s false claims and feeble attempts to fix the real problem
showed a lack of thoroughly inspecting the failure mode. Lastly, using software components for critical
system operations can be viewed as pushing the envelope of design, which in turn comes with the
heightened chance of failure. The Therac-25 relied heavily on the complex software components for
critical operations, and as is evident, the chance of failure was significantly increased.

Ariane 5 Analysis

On June 4th, 1996 the maiden flight of the Ariane 5 rocket ended in a failure within 40 seconds after it
took off. An inquiry board investigation found that an internal software component used to calculate the
location and movement of the rocket had encountered a software exception. This software exception
resulted in a complete shutdown of the primary software component as well as the identical backup
software component. Shutdown of both the primary and backup components resulted in the rocket’s
destruction. In addition the inquiry board found several flawed software engineering practices that
perpetuated the failure. Poor software engineering practices included: no validation of design against
real-word data, assumption that complex software is correct until proven incorrect, lack of design change
reviews, and failure to consider the software as a critical component.

Analysis of the development of Ariane 5 shows several of the same failure modes that Henry Petroski cites
in his book Design Paradigms. Basing the Ariane 5 design on the successful Ariane 4 design, any design
changes made to build the Ariane 5 should have resulted in a re-evaluation of design. In addition, testing
and validation of the Ariane 5 components did not consider the Ariane 5 real world trajectory. Relying on
the correct operation of the Ariane 4 flight trajectory proved to be a fatal mistake. This illustrates the
developers assumption that the software was correct, without verifying its correctness.