Re: [SystemSafety] Fault, Failure and Reliability Again (short)

Date: Wed, 4 Mar 2015 09:03:47 +0100

The issue behind this is failure versus what.

If it is versus the specification, it means the that software is not as it should be to satisfy the specification (requirements). If the software does not meet the requirements, I guess the opponents to the SW failure concept will argue that it is a failure of the test process because the software behaviour (outside influence of the HW) is deterministic versus its codes. With this approach, the software does not fail. It is just the wrong one.

If it is versus the expected behaviour and the SW perfectly satisfy the requirements, then the requirements are wrong.

I would reformulate the debate. Can a SW perfectly satisfying perfect requirements fail ?

Are the statistics we are building representative of the quality of the tests, of the specification, or of the SW itself (test and specification being perfect), or an aggregate ?

Bertrand Ricque
Program Manager
Optronics and Defence Division
Sights Program
Mob : +33 6 87 47 84 64
Tel : +33 1 58 11 96 82

Sent: Tuesday, March 03, 2015 3:09 PM
To: Nick Tudor
Cc: The System Safety List
Subject: Re: [SystemSafety] Fault, Failure and Reliability Again (short)

2015-03-03 11:03 GMT+01:00 Nick Tudor <njt_at_xxxxxx Hi Peter

Tis I

The fault with the logic in your blog is that the design of your system fails to meet the specification; this I hope is obvious. The software is therefore as you suggest 100% reliable. Or not if it hits the one fault.

The term reliability in systems has been hijacked to mean something else in software and is reinterpreted very badly to say that it therefore has a reliability of one in a thousand ( or whatever). Clearly if the software never encounters 20 it never gives an incorrect answer.

Reliability models for software is still not recognised in DO-178C and this means it has not been recognised for over 25 years.

The same spirit for railway domain, no reliability model for software another point, the probability for software failure is 1, yes the software contain many bug and ... it's why we used the DAL or SSIL, I prefer DAL "design assurance Level" ... SSIl is related to to confidence you have in the software and in railway, the confidence is based on independant assessment (mandatory in railway).

Mr Jean-louis Boulanger

" Ce courriel et les documents qui lui sont joints peuvent contenir des informations confidentielles, être soumis aux règlementations relatives au contrôle des exportations ou ayant un caractère privé. S'ils ne vous sont pas destinés, nous vous signalons qu'il est strictement interdit de les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce soit le contenu. Toute exportation ou réexportation non autorisée est interdite Si ce message vous a été transmis par erreur, merci d'en informer l'expéditeur et de supprimer immédiatement de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés."

" This e-mail and any attached documents may contain confidential or proprietary information and may be subject to export control laws and regulations. If you are not the intended recipient, you are notified that any dissemination, copying of this e-mail and any attachments thereto or use of their contents by any means whatsoever is strictly prohibited. Unauthorized export or re-export is prohibited. If you have received this e-mail in error, please advise the sender immediately and delete this e-mail and all attached documents from your computer system."

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Wed Mar 04 2015 - 09:03:57 CET

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