[SystemSafety] Degraded software performance [diverged from Fault, Failure and Reliability Again]

Michael J. Pont M.Pont at SafeTTy.net
Thu Mar 5 13:29:06 CET 2015


Dear Bertrand,

My views.

This is an important part of an important (and influential) document.

I believe that there are many people on this list who take the view that
concept of "software reliability" (as used in this appendix) is flawed and
unhelpful.  Replacing this with another appendix that is based on the same
concept does not seem to me to be a huge step forward.

There are other options.

Personally, I think that the appendix needs to be replaced with material
that explains how pre-developed software should be qualified.  The solution
- I suggest - is that such software needs to have been developed according
to the techniques detailed elsewhere in the standard (which is essentially
what is required in a DO-178x project).

Michael.  

-----Original Message-----
From: systemsafety-bounces at lists.techfak.uni-bielefeld.de
[mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of
RICQUE Bertrand (SAGEM DEFENSE SECURITE)
Sent: 05 March 2015 10:48
To: Peter Bernard Ladkin; Nick Tudor; The System Safety List
Subject: Re: [SystemSafety] Degraded software performance [diverged from
Fault, Failure and Reliability Again]

As a member of the maintenance team, my opinion is that :

Annex D is for the moment poorly related to the body of the standard: i.e.
the standard does not account for probability of failure of software as a
design input or as a performance objective for new software. The issue seems
only relevant, for the moment for existing software associated with the
intention to "reuse" it.

The question of the intended scope of applicability of a quantification of
software performance based on probabilities thus arises. Limited to "reuse"
or extended to "new". This will have to be clearly stated somewhere.

It will be difficult to do some progress if we are not able to agree on:
* Do we consider software without hardware ? Which is the mainstream of the
existing standard.
* If we think it is not relevant to segregate HW and SW, is it realistic to
foresee the consequential modifications we would have to implement in part 1
and 2 of the standard ?
* Are we measuring:
     *an intrinsic property of the software (failure rate or probability)?
     *a property of the software development process (quality of the
requirements, quality of the tests)?
     *a property of the SW/HW integration ?
     * an aggregate property of all of the above ?

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

-----Original Message-----
From: systemsafety-bounces at lists.techfak.uni-bielefeld.de
[mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of
Peter Bernard Ladkin
Sent: Thursday, March 05, 2015 11:24 AM
To: Nick Tudor; The System Safety List
Subject: Re: [SystemSafety] Degraded software performance [diverged from
Fault, Failure and Reliability Again]

Nick,

I do think we need to be clear about the situation with IEC 61508 Part 7
Annex D.

On 2015-03-05 10:41 , Nick Tudor wrote:
> .. There is a plan to
> update a standard IEC61508 with material about how one might use 
> software reliability in safety systems.

There is a plan to update a 17-year-old section, Part 7 Annex D, about
statistical evaluation of software in IEC 61508.

> Standards are supposed to represent the consensus of the community and 
> it has been reported by others on this list that many standards do not
recognise this approach.

The new version of IEC 61508 will represent the consensus of the Maintenance
Team charged with updating it, and the vote of approval from participating
national committees.

If we don't fix Annex D in the forthcoming maintenance cycle, it will stay
the same as it is now; I doubt very much if it will be deleted.

I'm just one person. I would imagine there are 25-30 active members of the
maintenance team, some of whom are on this list.

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




_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE
#
" 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 TechFak.Uni-Bielefeld.DE



More information about the systemsafety mailing list