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

From: Ross - Sigma < >
Date: Wed, 4 Mar 2015 14:07:42 -0000

>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.


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_xxxxxx [mailto:systemsafety-bounces_at_xxxxxx Peter Bernard Ladkin
Sent: 04 March 2015 13:39
To: systemsafety_at_xxxxxx Subject: Re: [SystemSafety] Fault, Failure and Reliability Again (short)


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
> 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

The System Safety Mailing List

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Wed Mar 04 2015 - 15:07:58 CET

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:07 CEST