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

From: Peter Bernard Ladkin < >
Date: Fri, 06 Mar 2015 12:56:01 +0100

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

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Fri Mar 06 2015 - 12:56:11 CET

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:07 CEST