Archives For requirements

A requirements checklist that can be used to evaluate the adequacy of HMI designs in safety critical applications. Based on the work of Nancy Leveson and Matthew Jaffe.

Over the years a recurring question raised about the design of FBW aircraft has been whether pilots constrained by software embedded protection laws really have the authority to do what is necessary to avoid an accident? But this question falls into the trap of characterising the software as an entity in and of itself. The real question is should the engineers who developed the software be the final authority?

Continue Reading...

Flaws in the glass

19/07/2009

DO-178B and the B-777 9M-MRG Incident

In August 2005 a Boeing 777 experienced an in-flight upset caused by the aircraft’s Air Data Inertial Reference Unit (ADIRU), generating erroneous acceleration data. The software fault that caused this upset raises questions in turn about the DO-178 software development process. A subsequent investigation of the accident by the Australian Transportation Board (ATSB) identified that the following had occured:

  • accelerometer #5 failed on the first of June in a false high value output mode,
  • the ADIRU excluded accelerometer #5 from use in its computations,
  • the ADIRU unit remained in service with this failed component (1),
  • power to the ADIRU was cycled (causing a system reset),
  • accelerometer #6 then failed in-flight,
  • accelerometer #6 was excluded from use by the ADIRU,
  • the ADIRU then re-admitted accelerometer #5 into its computations, and
  • erroneous acceleration values were output to the flight computer.

Continue Reading…

The effect of poorly considered originating requirements (the recommendations of the Waterfall accident commisioner) upon system safety requirements for a passenger emergency door release function.

Continue Reading...