Re: [SystemSafety] Degraded software performance [diverged from Fault, Failure and Reliability Again]

From: Nick Tudor < >
Date: Thu, 5 Mar 2015 09:41:40 +0000


Peter et al

I am going to close my input to this thread with the following:

This thread was started based upon the request for feedback on the idea of software reliability; I think that request has been fulfilled in spades and is a good use of this forum. There is a plan to update a standard IEC61508 with material about how one might use software reliability in safety systems. Standards are supposed to represent the consensus of the community and it has been reported by others on this list that many standards do not recognise this approach. Some of these standards claim to be based upon the template of IEC61508, EN50128 being a good example and ISO26262 being a bad one. Neither of these recognise 'software reliability' and, as I and others have pointed out, the aerospace standard DO-178C and its predecessors don't either. These bodies of work represent quite a consensus in the community that there is no recognised basis for the use of software reliability. While I know that for example, the UK H&SE have been briefed by consultants the notion that such a phenomenon exists, it has, in my and many others views in the UK, held back the sensible use of software in systems. It continues to hamper efforts to update aged and ageing analogue nuclear power systems (for which there are no like-for-like analogue parts manufactured any more) with digital systems. This is costing the industry and, much more importantly, the tax payer and is not necessarily helping make the systems safer, only more costly.

I was fortunately able to support the working groups for DO-178C and continue to do so. Like many in industry, I cannot afford the time nor the money to support more than one. It is therefore beholden upon those who can support such fora that they take note of the wider consensus.

Standards are there to help industry to do many things, one of which is to control costs. Basing development on a phenomenon that does not have consensus across the discipline of computer science/software engineering would be a disservice to the wider community. I therefore request that the proposed update to 61508 removes any reference to software reliability.

Nick Tudor
Tudor Associates Ltd
Mobile: +44(0)7412 074654
www.tudorassoc.com

*77 Barnards Green Road*
*Malvern*
*Worcestershire*
*WR14 3LR*
*Company No. 07642673*
*VAT No:116495996*

*www.aeronautique-associates.com <http://www.aeronautique-associates.com>*

On 5 March 2015 at 06:24, Peter Bernard Ladkin <ladkin_at_xxxxxx wrote:

> I think that Drew has pointed out a number of phenomena which result in
> software changing
> inadvertently and/or unobserved over time. Attributing the causes of those
> phenomena to "SW" or "HW"
> is I suggest of secondary interest. What is of primary interest is that
> they do occur and as a
> result software changes/can so change with the passage of time.
>
> Suppose one wants to talk about that phenomenon. To me, "software
> degradation" seems a reasonable
> term to use. Others may prefer to invent another term.
>
> It's clear to me that the phenomena (maybe not all of them, but at least
> some) do occur/have
> occurred and anyone preserving critical software for any length of time
> should take them into
> account; devise detection and prophylaxis mechanisms and so on. Sort of
> like hardware, really.
>
> 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_xxxxxx >



The System Safety Mailing List
systemsafety_at_xxxxxx Received on Thu Mar 05 2015 - 10:41:48 CET

This archive was generated by hypermail 2.3.0 : Thu Apr 25 2019 - 14:17:07 CEST