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

[Les Chambers]

Paul
Please do write the book. Whether we like it or not we are all involved in component based design. My experience with software libraries is that there are some good ones out there that are quite stable. On the negative side I have two problems with them:
1. They are almost universally very poorly documented so you can waste a day trying to achieve a trivial outcome.
2. The authors seem to have no concept of backward compatibility. If you make the mistake of upgrading to the latest version you can trash your complete application: data structure changes, even method name changes. Amazing!
All in all though we are joined at the hip with these things because writing from scratch is just not an option. ... Which raises huge problems with safety and security critical systems ... How do you validate product that seems to work but has no documentation to validate against. I guess if you're automating a nuclear reactor the only place to be is at scratch.

Les



-----Original Message-----
From: paul_e.bennett at topmail.co.uk [mailto:paul_e.bennett at topmail.co.uk] 
Sent: Sunday, March 13, 2016 10:37 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 13/03/2016 at 11:57 AM, "Les Chambers" <les at chambers.com.au> wrote:
>
>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. 

It may look a little like that, but component selection to suit all environmental, 
performance and dependability requirements is much more work than implied 
in that statement.

>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? 

Which is why all components need a full data-sheet technical specification
that describes not only functionality but the constraints and limitations
within which continued functionality and  performance is guaranteed. You
would not include an electronic component into a harsh environment
without first inspecting it's data-sheet to ensure it would survive in the 
intended operational and maintenance environment. Even with nuts and
bolts you would have selected and made calculations of the expected 
applied forces to ensure your design did not overstep the mark with those
components.

Of course some modelling is used (all calculations performed to confirm
limitations are not overstepped are a model of sorts).

>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.

The best components "proven over time" get re-use in several situations
but that does not mean nobody checks that the component selection was
not appropriate. This is why you need a development process that ensures
plenty of review points to check and recheck that component selection has
been appropriate throughout the development.

>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.

The development process should leave a clear audit trail that can 
easily be examined to ensure that the process itself has been applied
thoroughly. It is not just a case of "Trust us" it is "Satisfy yourself that
we are trustworthy".

>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 ...

Even model selection can be a tricky process and you should not use
a model that you cannot confirm matches reality close enough for the
purpose.

I can see from some of the comments that I am going to have to write
the book on "Component Oriented Design and Development for High 
Integrity Products". These short exchanges are not enough room to 
thoroughly treat such a subject.


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..
********************************************************************