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

From: RICQUE Bertrand (SAGEM DEFENSE SECURITE) < >
Date: Thu, 5 Mar 2015 15:18:46 +0100


Hi Michael,

Unfortunately in the committees, texts are approved, meeting after meeting on the basis of the present persons, whatever their competence and track record. There are few volunteers to do the job and the national committees are happy when they can send somebody. I have, for instance, myself no legitimacy, no expertise, such as academic diplomas or publications, in the field of the theories behind our discussion. My vote equals the one of the "true" experts in the meetings.

Second, taking of a whole part of text out of a standard is not as easy as you suggest, even if everybody was agreeing that it is totally wrong: * First there are social engineering issues. This already happened in part 6 and the background issues (persons) that were present between edition 1 and 2, are still valid for edition 3. * Second, there are rules from IEC that are not simple and that would launch a rather complicated process if we wanted to start making "heavy" changes. Maintenance of the standard is not allowed to result in rewriting it ...

So IMHO, it is better to try to add some material that makes de facto obsolete or impossible to use the material you cannot remove. I know, it looks somewhat stupid, but standardisation is primarily a commercial activity and only secondarily a technical one.

Going back to aerospace, it must be noticed that aerospace is progressively and slowly colonised bottom-up by more and more IEC61508 products or derivatives. It is time now for aerospace guys to have some commitment in this standard and bring their knowhow instead of complaining about the quality of standards they didn't want to pay attention to.

Nothing is perfect, and after years of comparing standards and ways of working I think that aerospace is far from being perfect also. The ongoing discussions on ARP versus STAMP are very instructive from this point of view. I begin to be convinced that the long lasting opposition of aerospace to IEC 61508 is primarily based on the fact that IEC ADDS obligations of means over the existing obligations of DO178x that are, as it was mentioned, heavily included in IEC61508.

So let us try to bring some competency and academics into this standard while taking into account some constraints that are not easy to tackle.

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_xxxxxx

-----Original Message-----
Sent: Thursday, March 05, 2015 1:29 PM
To: 'The System Safety List'
Subject: Re: [SystemSafety] Degraded software performance [diverged from Fault, Failure and Reliability Again]

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_xxxxxx [mailto:systemsafety-bounces_at_xxxxxx 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_xxxxxx

-----Original Message-----
From: systemsafety-bounces_at_xxxxxx [mailto:systemsafety-bounces_at_xxxxxx 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_xxxxxx #
" 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

The System Safety Mailing List
systemsafety_at_xxxxxx #
" 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 Thu Mar 05 2015 - 15:19:19 CET

This archive was generated by hypermail 2.3.0 : Fri Feb 22 2019 - 05:17:07 CET