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

[Ross - Sigma]

>From an aeronautical software perspective it is the contribution of software
to aircraft level Failure Conditions that is considered. No attempt is made
to quantify that contribution numerically. The terminology used in the
software domain (RTCA/DO-178BC (EUROCAE ED-12C) and RTCA/DO-278A (EUROCAE
ED-109A) is consistent with that contained in the appropriate regulations
(albeit EASA have modified a couple of the definitions very slightly in
their Certification Memos for Software and Complex Electronic Hardware). 

Figure 2-2 in each of the above documents provides a visual representation
of how a latent software Error in the data or executable code could
potentially manifest itself (visible or not) as a Fault at the software
boundary. That Fault could potentially manifest itself (visible or not) as a
Failure at the system boundary. And that Failure could potentially
contribution to a Failure Condition at an aircraft or equipment level. 

The definitions of these terms are:

Error - With respect to software, a mistake in requirements, design, or
code.

Fault - A manifestation of an error in software. A fault, if it occurs, may
cause a failure.

Failure - The inability of a system or system component to perform a
required function
within specified limits. A failure may be produced when a fault is
encountered.

Failure condition - The effect on the aircraft and its occupants both direct
and
consequential caused or contributed to by one or more failures, considering
relevant
adverse operational and environmental conditions. A failure condition is
classified
according to the severity of its effect as defined in advisory material
issued by the
certification authority.

or

Failure condition - The effect on a CNS/ATM system or equipment, both direct
and
consequential, caused or contributed to by one or more failures which may be
attributed to, for example, a latent software error in the executable code
or data
considering relevant adverse operational and environmental conditions.

I don't see any need to change or rewrite any of the aeronautical software
standards.

Ross Hannan

-----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: 04 March 2015 13:39
To: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Fault, Failure and Reliability Again (short)

Michael,

On 2015-03-04 13:54 , C. Michael Holloway wrote:
> On 3/4/15 7:14 AM, Peter Bernard Ladkin wrote:
>> Although I do find reconciling concepts a less odd activity than 
>> responding to suggestions that the field in which some of the 
>> scientists I most respect have worked for four decades actually doesn't
exist!
> I don't think anyone has claimed that the field doesn't exist.  

Have you been dreaming or have I? At least two people here have claimed that
software can't have failures, and so any notion of assessing a rate of
railure per demand or per time unit is meaningless.

That is saying that the field, of studying the rate of failure of software
per demand or per time unit, does not exist.

> Some have claimed that the work
> conducted in the field has not yet borne any healthy fruit. Some, myself
included, doubt it ever will.
> 
> No one should be surprised if those claims and doubts turn out to be 
> accurate.  Even a casual look at the history of science will show that 
> it is not all that uncommon for respected scientists to work for decades
in areas that turn out to be (at best) fruitless.

Both the civil large-aeroplace certification standards and IEC 61508 specify
criteria for the reliability of kit, which includes elements whose behavior
is largely driven by software, in terms of dangerous failure rates, either
per demand or per time unit. That inevitably (as I have argued) puts similar
such demands on the software itself.

If certification requirements, respectively safety standards, require such
measures to be demonstrated, then people will be studying them in terms of
engineering science and obtaining what helpful results they can obtain.

If that's all futile because the "area.... turn[s] out to be fruitless" then
those standards had better be rewritten pronto, because they obviously can't
be fit for purpose if they demand properties of kit that cannot be shown and
have no hope of being shown.

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