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

[jean-louis Boulanger]

I agree this proposal

Le jeudi 5 mars 2015, Michael J. Pont <M.Pont at safetty.net> a écrit :

> 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 <javascript:;>
> [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de <javascript:;>]
> 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 <javascript:;>
>
> -----Original Message-----
> From: systemsafety-bounces at lists.techfak.uni-bielefeld.de <javascript:;>
> [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de <javascript:;>]
> 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 <javascript:;>
> #
> " 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 <javascript:;>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE <javascript:;>
>


-- 
Mr Jean-louis Boulanger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20150305/04ef9bab/attachment-0001.html>