[SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"

[Coq, Thierry]

Hi Peter,
I thank you for your additions. The key word on my comment on "proven-in-use" is the word "trust". I do hope the new IEC standard will be rigorous about the "proven-in-use" component and the environment in which it was proven. And that it unifies the way to demonstrate and provide evidence for "proven-in-use" and clearly states any and all limitations, including the need for additional evidence when the environment changes in any manner.

As for the statistical, I haven't found a practical theory yet describing P = F(S,E) where P is the probability of failure, S is the software-dependent system in its environment E and F is some theory linking the three. Usually, we see an disclaimer "don't change the environment in <<pertinent>> ways", and then a whole lot of equations where only the system/component is looked in any depth. I would expect such a theory to have P=F(Sproven, Enew) = F(Snew, Eproven)=1.

Best regards,
Thierry Coq
Mobile +33 06 80 44 57 92
www.dnvgl.com


-----Original Message-----
From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Peter Bernard Ladkin
Sent: lundi 14 mars 2016 10:35
To: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"

On 2016-03-14 09:32 , Coq, Thierry wrote:
> The argument about trusting proven in use components has been
> completely disproved by the Ariane
> 501 flight and its consequences.

It hasn't.

The IEC is about to publish a technical specification on the criteria to be fulfilled for a component to be considered "proven in use".

The Ariana 501 event was a case in which a component which had been reliable in previous use was reused, without anyone apparently determining that the inputs from Ariane 5 to the digital component were different from those it had already successfully handled. There was no valid inference from Ariane 4 success to Ariane 5 success for this component (actually, for more than one). As Ariane Flight 501 unfortunately demonstrated.

Ariane 501 is a good example for why the conditions on reuse must be taken rigorously. I used it in my SSS2016 talk on statistical evaluation of critical software.

> A proven-in-use component in one environment may be replete with
> defects that may emerge in another environment.

That is why the environment for the proposed future use must be the "same" in certain specific ways.

> It also has disproved most ways of thinking probabilities of failure
> for software-dependent systems.

It hasn't vitiated any of the probabilistic material at all. Nobody's had to retract a statistical paper because of it.

People working in the field have been constantly emphasising the need for the "new" environment to be identical in pertinent ways to the environment in which the component has proven its reliability in use. Weaken those conditions at your peril.

The engineering question is the matter of judging when the pertinent conditions have been fulfilled.

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




**************************************************************************************
This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited.
**************************************************************************************