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

From: Les Chambers < >
Date: Thu, 17 Mar 2016 11:23:33 +1000

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.


-----Original Message-----
Sent: Sunday, March 13, 2016 10:37 PM
To: Les Chambers; 'Steve Tockey'; 'Derek M Jones'; systemsafety_at_xxxxxx Subject: RE: [SystemSafety] Modelling and coding guidelines: "Unambiguous Graphical Representation"

On 13/03/2016 at 11:57 AM, "Les Chambers" <les_at_xxxxxx
>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
>>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.


Paul E. Bennett IEng MIET
Systems Engineer

Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett_at_xxxxxx
Forth based HIDECS Consultancy.............<>
Mob: +44 (0)7811-639972
Tel: +44 (0)1392-426688
Going Forth Safely ..... EBA.

The System Safety Mailing List
Received on Thu Mar 17 2016 - 02:23:57 CET

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:08 CEST