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

[Nick Tudor]

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 rvs.uni-bielefeld.de>
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 TechFak.Uni-Bielefeld.DE
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20150305/2b56e90e/attachment.html>