Archives For fault hypothesis

I just realised that I’ve used the term ‘design hypothesis’ throughout this blog without a clear definition of what one is. 🙂

So here it is.

A design hypothesis is a prediction that a specific design will result in a specific outcome. A design hypothesis must:

  1. Identify the designs provenance, e.g the theory, practice or standards from it is derived.
  2. Provide a concise description of the design.
  3. State what the design must achieve in a verifiable fashion.
  4. Clearly identify critical assumptions that support the hypothesis.

Note that the concept of a fault hypothesis can be seen as a particular and constrained form of design hypothesis as, after Powell (1992), a fault hypothesis specifies assumptions about the types of faults, the rate at which components fail and how components may fail for fault tolerant computing purposes.

I give a short example of of a design hypothesis in the Titanic Part I post.

References

Powell, D., Failure mode assumptions and assumption coverage. In Proc. of the 22nd IEEE Annual International Symposium on Fault-Tolerant Computing (FTCS-22) , p386–395, Boston, USA, 1992.

Blayais Plant (Image source: Wikipedia Commons)

What a near miss flooding incident at a French nuclear plant in 1999 and the Fukushima 2012 disaster can tell us about fault tolerance and designing for reactor safety

Continue Reading…

Reading the ATSB interim report on the QF72 in flight accident one could easily overlook the statement, “…the crew reported that the (ECAM (1)) messages were constantly scrolling, and they could not effectively interact with the ECAM to action and/or clear the messages.”. So why did the A330 ECAM display fail during such a critical event?

Continue Reading...