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

[Coq, Thierry]

The argument about trusting proven in use components has been completely disproved by the Ariane 501 flight and its consequences.
A proven-in-use component in one environment may be replete with defects that may emerge in another environment.
It also has disproved most ways of thinking probabilities of failure for software-dependent systems.

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 Les Chambers
Sent: dimanche 13 mars 2016 12:57
To: paul_e.bennett at topmail.co.uk; 'Steve Tockey'; 'Derek M Jones'; systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"

Hey wait a minute ... in stating
>The entire system (the car) is designed around a multitude of
>components (probably all selected from a catalogue of components that
>have proven themselves over time).

... Are you not repeating the manifesto of the reductionist. That the whole system will be safe because the individual components are safe.

What about the components proven over time that were never designed for service in this class of application? What about the components proven over time that never interacted with each other in this way?
I'm sorry, I arc up when I hear that phrase "proven over time" it's often used as groupthink to mask horrendous miscarriages of proper engineering process. I've even seen it applied to people. No kidding! "Don't worry this fire protection system was delivered by Kerry. He is a good guy. His work has been proven over time." BS of the worst kind.

I like this statement a little better:

>The emergent behaviour and failure modes become known through the
>design process and with the inspection and testing that ensures the
>final product is as described. Using only certified components and
>frequent review stages throughout the design keeps the behaviour
>(designed or emergent) within bounds.

But this smacks of, "... Trust us, by hook or by crook we'll inspect and test safety into this sucker"
Many of us, including me, got away with this kind of talk in the past. Thorough module, unit, integration, system and acceptance testing can rid a system of many problems but they do not guarantee that no problems exist.

My personal belief that the right answer to my original question should go something like this:
"This system was built using XYZ model which is of high integrity, scalable, practical and suited to this class of application. The operation of the system will be deterministic and comply with specifications because the model has integrity and the opportunities for developers to inject defects is limited to 0.

I wish ...



-----Original Message-----
From: paul_e.bennett at topmail.co.uk [mailto:paul_e.bennett at topmail.co.uk]
Sent: Wednesday, March 2, 2016 10:18 PM
To: Les Chambers; 'Steve Tockey'; 'Derek M Jones'; systemsafety at lists.techfak.uni-bielefeld.de
Subject: RE: [SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"

On 02/03/2016 at 11:22 AM, "Les Chambers" <les at chambers.com.au> wrote:
>
>Sounds interesting. The components are one thing. What about emergent
>properties of the assembled whole. How do you review the interactions.
>The modern zeitgeist seems to be developing systems of dumb objects
>that interact. The problem is that the complexity gets pushed into the
>interaction. This is an abstract thing. Very hard to pick apart in a
>review. Have you any solutions for this?

I shall relay this in an analogy from the mechanical world.

The humble nut and bolt are a pair of components that, according to their data-sheet will exist in a specific environment and be able to be tightened up to a specific toque figure to serve throughout its designated lifetime.

We can use the nut and bolt in a more complex assembly (such as a carburettor for a car) which will perform as indicated in the manufacturers data-sheet as part of the engine component.

The emergent behaviour and failure modes become known through the design process and with the inspection and testing that ensures the final product is as described. Using only certified components and frequent review stages throughout the design keeps the behaviour (designed or emergent) within bounds.

The entire system (the car) is designed around a multitude of components (probably all selected from a catalogue of components that have proven themselves over time).

Note that this analogy is based on vehicle manufacturing before electronics or software became involved. The question I always pose is why electronics and software could not be as certain in its development as those early vehicle designs.

I know it is possible as my electronics and software have survived with zero maintenance effort for more than 20 years (one software system is now operational since 1985 and has just had operational life extension granted until 2030) within very harsh operational environments.

Regards

Paul E. Bennett IEng MIET
Systems Engineer

--
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1392-426688
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************



_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.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.
**************************************************************************************