[SystemSafety] Fault, Failure and Reliability Again (short)

Wilkinson, Chris Chris.Wilkinson at Honeywell.com
Wed Mar 4 16:35:43 CET 2015


Having watched in amazement this topic go by over the last few days, I'm finally moved to offer a 2-cents worth. In my experience, people do one of two things; ignore it or make something up. In any case, failure is only half the story of unsafety. The other half is software requirements and human-machine interaction errors and omissions neither of which are rationally quantifiable as probabilities. It's not hard to find examples of accidents where there was no failure.

-Chris-


-----Original Message-----
From: systemsafety-bounces at lists.techfak.uni-bielefeld.de [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Peter Bernard Ladkin
Sent: Wednesday, March 04, 2015 9:55 AM
To: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Fault, Failure and Reliability Again (short)



On 2015-03-04 15:22 , Peter Bernard Ladkin wrote:
> I didn't say "standards", I said certification requirements. 

I take that back. I in fact said "certification standards". What I meant was, US 14 CFR 25.1309(b) :

[begin quote]
(b) The airplane systems and associated components, considered separately and in relation to other systems, must be designed so that-
(1) The occurrence of any failure condition which would prevent the continued safe flight and landing of the airplane is extremely improbable, and
(2) The occurrence of any other failure conditions which would reduce the capability of the airplane or the ability of the crew to cope with adverse operating conditions is improbable.
[end quote]

and CS-25.1309(b) :

[begin quote]
(b) The aeroplane systems and associated components, considered separately and in relation to other systems, must be designed so that 
(1) Any catastrophic failure condition
(i) is extremely improbable; and
(ii) does not result from a single failure; and
(2) Any hazardous failure condition is extremely remote; and
(3) Any major failure condition is remote.
[end quote]

Suppose you have a piece of kit whose behavior can result in a failure condition (which would prevent..../ catastrophic), and this kit is digital and its behavior is largely governed by SW logic.

Here's a fault tree / causal failure graph / BBN:

<kit fails catastropically> <--- ((HW fails in such-and-such a way) OR (SW fails in such-and-such a
way))

The regs set a numerical condition on the left-hand node: namely, extremely improbable, which is to say a probability of 10^(-9) per operating hour (used not to mean it, but does now). You've got to get that from equivalent sorts of measures on the RHS.

I take it people are content with doing it for the LH disjunct: HW fails at (less than) probability X per operating hour.

So, now who's going to tell me you don't need to do it for the RH disjunct?

PBL

Prof. Peter Bernard Ladkin, Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany Je suis Charlie
Tel+msg +49 (0)521 880 7319  www.rvs.uni-bielefeld.de




_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE


More information about the systemsafety mailing list