[SystemSafety] Software reliability (or whatever you would prefer to call it)

Littlewood, Bev Bev.Littlewood.1 at city.ac.uk
Tue Mar 10 12:44:40 CET 2015


Hi Michael

Seems you are speaking for Nick! (see his most recent posting) Of course the distinction you make here is an important one - I think we can all agree on that. Not least because our actions in response to seeing failures from them will be different (in the case of design faults - inc. software faults - we might wish to remove the offending fault).

But excluding design faults as a source of (un)reliability results in a very restrictive terminology. I realise that appealing to “common sense” in a technical discussion is often the last refuge of the scoundrel… But I don’t think that the man in the street, contemplating his broken-down car (in the rain - let’s pile on the pathos!), would be comforted to be told it was not unreliable, it just had design faults.

And, of course, your interpretation seems to rule out the contribution of human fallibility (e.g. pilots) to the reliability and/or safety of systems. This seems socially unacceptable, at least to me.

Cheers

Bev


On 10 Mar 2015, at 10:34, C. Michael Holloway <c.m.holloway at nasa.gov<mailto:c.m.holloway at nasa.gov>> wrote:

I can't speak for Nick, but I object to the use of the term "reliability" being applied to anything other than failures (using the term loosely) resulting from physical degradation over time.  I believe it is important to maintain a clear distinction between undesired behavior designed into a system, and undesired behavior that arises because something ceases to function according to its design.  (Here "designed / design" is used broadly.  It includes all intellectual activities from requirements to implementation.)

--
cMh

C. Michael Holloway
The words in this message are mine alone; neither blame nor credit NASA for them.

On 3/10/15 5:50 AM, Peter Bishop wrote:
Now I think I understand your point.
You just object to the term *software* reliability

If the term was *system* reliability in an specified
operational environment, and the system contained software
and the failure was always caused by software
- I take it that would be OK?

A alternative term like *software integrity* or some such would be needed to describe the property of being correct or wrong on a given input.
(In a lot of mathematical models this is represented as a "score function" that is either true or false for each possible input)

Peter Bishop

Nick Tudor wrote:
Now back in the office...for a short while.

Good point David - well put.
I would have responded: There exists a person N who knows a bit about mathematics.  Person N applies some mathematics and asserts Truth.  Unfortunately, because of the incorrect application of the mathematics, the claims N now makes cannot be relied upon.  The maths might well be correct, but the application is wrong because - and I have to say it yet again - the application misses fails to acknowledge that it is the environment that is random rather than the software.  Software essentially boils down to a string of one's and nought's. Given the same inputs (and that always comes from the chaotic environment) then the output will always be the same.  It therefore makes no sense to talk about 'software reliability'.

Nick Tudor
Tudor Associates Ltd
Mobile: +44(0)7412 074654
www.tudorassoc.com<http://www.tudorassoc.com/> <http://www.tudorassoc.com><http://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> <http://www.aeronautique-associates.com><http://www.aeronautique-associates.com/>*

On 9 March 2015 at 12:26, David Haworth <david.haworth at elektrobit.com<mailto:david.haworth at elektrobit.com> <mailto:david.haworth at elektrobit.com><mailto:david.haworth at elektrobit.com>> wrote:

    Peter,

    there's nothing wrong with the mathematics, but I've got
    one little nit-pick about its application in the real world.

    The mathematics you describe gives two functions f and g,
    one of which is the model, the other is the implementation.

    In practice, your implementation runs on a computer and so the
    domain and range are not "the continuum". If your model is mathematical
    (or even runs on a different computer), the output of one will
    necessarily be different from the output of the other. That
    may not be a problem in the discrete sense - you simply specify a
    tolerance t > 0 in the form of:

    Corr-f-g(i) = 0 if and only if |f(i)-g(i)| < t

    etc.

    The problem becomes much larger in the real world of control
    systems where the output influences the next input of the
    sequence. The implementation and the model will tend to drift
    apart. In the worst case what might be nice and stable in the
    model might exhibit unstable behaviour in the implementation.

    You're then in the subject of mathematical chaos, where a
    perfectly deterministic system exhibits unstable and unpredictable
    behaviour. However, this email is too small to describe it. :-)

    Cheers,
    Dave

    On 2015-03-09 11:48:57 +0100, Peter Bernard Ladkin wrote:
     > Nick,
     >
     > Consider a mathematical function, f with domain D and range R.
    Given input i \in D, the output is f(i).
     >
     > Consider another function, g, let us say for simplicity with the
    same input domain D and range R.
     >
     > Define a Boolean function on D, Corr-f-g(i):
     >
     > Corr-f-g(i) = 0 if and only if f(i)=g(i);
     > Corr-f-g(i) = 1 if and only if f(i) NOT-EQUAL g(i)
     >
     > If X is a random variable taking values in D, then f(X), g(X) are
    random variables taking values in
     > R, and Corr-f-g(X) is a random variable taking values in {0,1}.
     >
     > If S is a sequence of values of X, then let Corr-f-g(S) be the
    sequence of values of Corr-f-g
     > corresponding to the sequence S of X-values.
     >
     > Define Min-1(S) to be the least place in Corr-f-g(S) containing a
    1; and to be 0 if there is no such
     > place.
     >
     > Suppose I construct a collection of sequences S.i, each of length
    1,000,000,000, by repeated
     > sampling from Distr(X). Suppose there are 100,000,000 sequences I
    construct.
     >
     > I can now construct the average of Min-1(S) over all the
    1,000,000,000sequences S.i.
     >
     > All these things are mathematically well-defined.
     >
     > Now, suppose I have deterministic software, S. Let f(i) be the
    output of S on input i. Let g(i) be
     > what the specification of S says should be output by S on input
    i. Corr-f-g is the correctness
     > function of S, and Mean(Min-1(S)) will likely be very close to
    the mean time/number-of-demands to
     > failure of S if you believe the Laws of Large Numbers.
     >
     > I have no idea why you want to suggest that all this is
    nonsensical and/or wrong. It is obviously
     > quite legitimate well-defined mathematics.
     >
     > 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<http://www.rvs.uni-bielefeld.de/>
    <http://www.rvs.uni-bielefeld.de><http://www.rvs.uni-bielefeld.de/>
     >
     >
     >
     >
     > _______________________________________________
     > The System Safety Mailing List
     > systemsafety at TechFak.Uni-Bielefeld.DE<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
    <mailto:systemsafety at TechFak.Uni-Bielefeld.DE><mailto:systemsafety at TechFak.Uni-Bielefeld.DE>

    --
    David Haworth B.Sc.(Hons.), OS Kernel Developer       david.haworth at elektrobit.com<mailto:david.haworth at elektrobit.com> <mailto:david.haworth at elektrobit.com><mailto:david.haworth at elektrobit.com>
    Tel: +49 9131 7701-6154 <tel:%2B49%209131%207701-6154><tel:%2B49%209131%207701-6154>     Fax:
    -6333                  Keys: keyserver.pgp.com<http://keyserver.pgp.com>
    <http://keyserver.pgp.com><http://keyserver.pgp.com/>
    Elektrobit Automotive GmbH           Am Wolfsmantel 46, 91058
    Erlangen, Germany
    Geschäftsführer: Alexander Kocher, Gregor Zink       Amtsgericht
    Fürth HRB 4886

    Disclaimer: my opinion, not necessarily that of my employer.

    _______________________________________________
    The System Safety Mailing List
    systemsafety at TechFak.Uni-Bielefeld.DE<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
    <mailto:systemsafety at TechFak.Uni-Bielefeld.DE><mailto:systemsafety at TechFak.Uni-Bielefeld.DE>



------------------------------------------------------------------------

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>


_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>

_______________________________________________

Bev Littlewood
Professor of Software Engineering
Centre for Software Reliability
City University London EC1V 0HB

Phone: +44 (0)20 7040 8420  Fax: +44 (0)20 7040 8585

Email: b.littlewood at csr.city.ac.uk<mailto:b.littlewood at csr.city.ac.uk>

http://www.csr.city.ac.uk/
_______________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20150310/f1cb7267/attachment-0001.html>


More information about the systemsafety mailing list