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

[Peter Bernard Ladkin]

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



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20160314/ef7cfbf0/attachment.pgp>