[SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"
Les Chambers
les at chambers.com.au
Sun Mar 13 12:57:07 CET 2016
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..
********************************************************************
More information about the systemsafety
mailing list