[SystemSafety] Software Safety Requirements according to IEC 61508

Peter Bernard Ladkin ladkin at rvs.uni-bielefeld.de
Sun May 22 12:00:14 CEST 2016


On 2016-05-22 09:41 , Matthew Squair wrote:
>>Why do something that demonstrably brings you nothing, but costs resources?
> 
> Because the standard made me? :) 
> 
> Actually the legal formalism implicit in the wise crack above is one justification.

I don't see how.

"Your honour, our prior calculation of reliability of this software-based safety function was
10^(-5) per operating hour. We based this on our development procedures and prior experience with
safety functions of this type that we and others have implemented, and our estimate was accepted by
the assessor as thorough and provisionally accurate.

Neither we nor any of our colleagues and competitors have software, any software, ever, which
implements this safety function which has run for the requisite period of time to achieve a higher
reliability estimate than 10^(-5) or less failure probability per operating hour. In order to
improve this estimate, such a piece of software would have to log some 45 million operating hours
without the slightest alteration in an identical environment to that in which our software runs. If
that had happened, we could be 99% certain that our software had a 10^(-6) or less probability of
failure. That would be an improvement. But no one has ever run any software of that sort, without
change, for that length of time, ever, and we doubt that anybody ever will. So no one has a better
estimate than ours of 10^(-5) failure probability.

Furthermore, we propose that it is not in any sense reasonably practicable to exercise our software
for 45 million operating hours in the exact environment in which it was installed. The ALARP
requirement is fulfilled by our existing estimate.

We are aware that the nominal reliability requirement for this function was set higher. We think
that is a design mistake. We are not responsible for the design. We discharged our responsibility
concerning this design mistake in that we argued to the client at the time that this was
inachievable in any practical sense. Our argument is correct and is mathematically uncontentious. It
must be accepted by any engineer.

Our software achieved, and achieves, what is achievable. No one can do any better, and no one has
any software for this function which they can demonstrate is more reliable.

Far from being grossly negligent, or even negligent, our software is demonstrably amongst the most
carefully developed and most reliable there is for this task. We refute any claim of negligence, and
thereby the opposition's claim for compensation."

This isn't theory. It is what has actually been argued in court. Indeed, I don't see what other
argument would ever be used in these circumstances if this one is available.

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





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20160522/bbe355c8/attachment.pgp>


More information about the systemsafety mailing list