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

[Nick Tudor]

In line responses Andrew:

On Wednesday, 4 March 2015, DREW Rae <d.rae at griffith.edu.au> wrote:

> 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 safetty.net
> <javascript:_e(%7B%7D,'cvml','M.Pont at safetty.net');>> wrote:
>
>> 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 TechFak.Uni-Bielefeld.DE
>> <javascript:_e(%7B%7D,'cvml','systemsafety at TechFak.Uni-Bielefeld.DE');>
>>
>
>

-- 
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>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20150304/77b9f9bc/attachment.html>