The failures of Ariane-5 include the following:

  1. SRI fails due to software exception--no exception handler.

    2. According to Petroski, any successful designer should always think of the worst case--properly and completely anticipate what can go wrong. Otherwise, disaster can take people by surprise.

  2. This occurred in a code section useless in Ariane 5. The reason for this exception is changed operation profile of Ariane-5--they did not use the new profile to test the software.

    3. According to the Ariane-5 report, the reason to keep this useless code is based on that it is not wise to make changes in software that worked well on Ariane-4. At least they should test the design with valid, new profile no matter how apparent similar it is to the previous one. Another trap is the success syndrome, i.e., people become overconfident after great success like Ariane-4. As a result, they did not bother to test with the new data.

  3. Diagnostic data was interpreted by OBC as sharp change of direction.

    4. This is a supplement to item a: failure considerations and proactive failure analysis are essential for achieving success. OBC could be more robust if it rejects discontinuous data, since abrupt change of direction does not make any sense for a flight mission like this.

  4. The active SRI and its backup failed almost at the same time.

Fundamental errors made at the conceptual design stage can be very elusive. Designers of SRI treat

Failure of software as independent random process, but it is not.

The failures of Therac-25 involve the following:

  1. More faith in software reliability--hardware interlocks and backups not worth the expense.

    2. It always pays to emphasize safety, especially for some unfamiliar area, but economical concerns can compromise this aspect.

  2. The AECL's inability to determine the cause of the accident with any certainty.

    3. Lack of knowledge in historical failures results in poor engineering judgement.

  3. The technical stuff refused to believe the patients' claim despite the apparent evidence.

    4. This is another place where success syndrome comes into play.

  4. Adapt and borrow software from machines of earlier model--old safe error is disastrous in the new model.

    5. Refer to b in Ariane-5 failure list. In addition, scale effects must be considered in any design.

  5. Abductive reasoning about causes of failures--focusing on particular bugs to make the system safe.

    6. This is a logical error.

  6. The Set-Up Test code overflows on 256.

    7. This is another poor engineering judgement.

  7. Race condition in the data-entry routines that allowed the code to proceed to Set-Up Test before the full prescription had been entered and acted upon.

    8. This is caused by the tunnel vision in design. Designer paid too much attention to software interface. As a result, safety is compromised.

  8. Poor documentation of software.

Designers must be able to step back form each design and make changes according to new considerations, as well as original basic requirement. In this regard, well-maintained document is necessary.