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

From: Nick Tudor < >
Date: Wed, 4 Mar 2015 16:25:14 +0000

In line responses Andrew:

On Wednesday, 4 March 2015, DREW Rae <d.rae_at_xxxxxx

> Michael,
> I need to give more than one example, because the point is general, rather
> than specific to the individual causes. In each case the cumulative
> probability of software failure increases over time.

>>if you can determine the wear out mechanism for software I would agree,
but you can't, so I don't.

  1. Damage to the instruction set
    > e.g. the physical record of the instructions on a storage medium changes
    > very specific e.g. bit flip on a magnetic storage device holding the
    > executable files

> >>this is a hardware issue.

> 2) Increased unreliability of the physical execution environment
> e.g. an increased rate of processor errors
> very specific e.g. dust accumulates on part of the processor card, making
> it run hot and produce calculation errors
> >> this too is hardware.
> 3) Increased unreliability of input hardware
> e.g. software is required to detect and respond correctly to an increased
> rate and variety of sensor failure combinations
> Note: This is the one that challenges "but we're running the software in
> exactly the same hardware environment". Hardware environments change as
> they get older.
> >>ditto

> 4) Software accumulates information during runtime
> e.g. a count of elapsed time
> e.g. increasing volume of stored data
> e.g. memory leak
> >>bad requirements or/and bad verification.
> NB1: In all of these cases I've heard arguments "that's not the software,
> that's X". Those arguments are only relevant if you can control for X when
> collecting data for software reliability calculation. Software without an
> execution environment is a design. It "never fails" in the way that _no_
> design fails. When it does fail, it is subject to the same degredation over
> time as any physical implementation

>> there is no such thing as software reliability so don't use maths (or
rather statistics and claim they are maths) inappropriately.

> NB2: I'm not claiming that failure due to physical degredation is
> significant compared to failure due to errors in the original instructions.
> I'm saying that we don't know, and that not knowing becomes a big issue
> once we've tested to the point of not finding errors in the original
> instructions. At that point, absent evidence to the contrary, we should be
> assuming that physical degredation is signficant.
> >>. No one (I hope) denies that hardware effects may influence software
> calculations. Still doesn't mean that the maths, er Statistics are the
> right tool for the job.

> Drew
> On 4 March 2015 at 12:27, Michael J. Pont <M.Pont_at_xxxxxx > <javascript:_e(%7B%7D,'cvml','M.Pont_at_xxxxxx >
>> Drew,
>> “The underlying point holds, that software _can_ exhibit degraded
>> performance over time.”
>> Can you please give me a simple example of what you mean by this.
>> Thanks,
>> Michael.
>> _______________________________________________
>> The System Safety Mailing List
>> systemsafety_at_xxxxxx >> <javascript:_e(%7B%7D,'cvml','systemsafety_at_xxxxxx >>

Nick Tudor
Tudor Associates Ltd
Mobile: +44(0)7412 074654

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

* <>*

_______________________________________________ The System Safety Mailing List systemsafety_at_xxxxxx
Received on Wed Mar 04 2015 - 17:25:22 CET

This archive was generated by hypermail 2.3.0 : Mon Apr 22 2019 - 00:17:07 CEST