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

Peter Bernard Ladkin ladkin at rvs.uni-bielefeld.de
Fri Mar 6 12:56:01 CET 2015


On 2015-03-06 11:55 , Michael J. Pont wrote:
> IEC 61508-7 [2010] Annex D "provides initial guidelines on the use of a
> probabilistic approach to determining software safety integrity for
> pre-developed software based on operational experience. This approach is
> considered particularly appropriate as part of the qualification of
> operating systems, library modules, compilers and other system software."

Yes, it does say that. I am glad in particular you quote the second sentence. It illustrates clearly
that Annex D needs revising. Cf. what Ladkin and Littlewood say about RTOS's.

> In effect, I select an appropriate set of test data, run my system for a
> long time (or run lots of systems for a short time) and conclude - if no
> failures are detected - that the system is safe.  

No and no (numbered below).

1. you collect operational experience, which may include test data but it is clear from
long-standing science that test data alone are unlikely to be sufficient for the levels of trust
required for SILs. (Although there are still people around, twenty-two years later, that understand
neither the Butler-Finelli nor Littlewood-Strigini results.)

2. You do not conclude that the system is safe. There would be two things wrong with such a conclusion.

First, you cannot conclude anything definitely through statistical evaluation, you can only conclude
something *to a level of confidence*.  If you run a piece of software for five minutes and it gives
OK answers, you can conclude that the SW is completely unreliable to a high level of confidence, and
also that the SW is completely reliable to a very low level of confidence. Notice that the
statements you are assessing are contradictory!

Second, you conclude that SW implementing a safety function implements that function to a desired
reliability *to an unspecified level of confidence*.

> The longer that I test for, the higher the SIL level that can be assigned to
> the component that is being evaluated.

No. The SIL ("level" is redundant) is assigned with the function the component implements, and is
part of the overall safety requirements on the system, of which this SW is part. The SIL is
assigned, in other words, through the architecture of the system and its analysis, not through the
behavior of the SW.

> In my book, this is Black-Box testing.

Quite right. Apart from that word "testing."

> If we revise this appendix as Peter proposes, then we may be able to help
> people to select more appropriate test data (and this may be an improvement)
> - but this will still be Black Box testing.

Quite right. That's what the Annex addresses.

> If we can't avoid this appendix altogether (and I'm sure that Bertrand is
> right about this), then we should - surely - be able to require some
> additional "White Box" assessments, such as code reviews, design reviews,
> etc (in line with the rest of the standard).  

Yes, quite right. If those are available, then they should be used in my opinion. All available
evidence pertaining to the fitness for purpose of the SW should be used in assessing the SW.

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






More information about the systemsafety mailing list