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

From: David MENTRE < >
Date: Fri, 26 Feb 2016 10:27:23 +0100


Dear Mr Watts,

Le 26/02/2016 09:01, Watts Malcolm (AE/ENG1-AU) a écrit :
> I have some “graphical representations” in mind (AADL, PNML from ISO/IEC
> 15909-1:2004, SDL or SDL-RT from the telecoms domain).

Yes, AADL and SDL also come to my mind.

Several tools are available.

As far as I know, AADL is an industrial standard defined by SAE (Society of Automotive Engineers in USA).

At least one open-source tool is available.

The only big downside of SCADE is that it is a proprietary language and only one tool is available, SCADE Suite developed by Esterel Technologies
(http://www.esterel-technologies.com/products/scade-suite/). And this tool is very, very expensive.

SCADE is a derivative of several academics synchronous data-flow languages: Signal, Lustre and Esterel. Those languages could be also good candidates for "unambiguous graphical representation".

> What do those of you who practice in this field understand by “an
> unambiguous graphical representation”?

For me, a graphical representation is unambiguous if, for each graphical construction or combination of constructions, its semantics (i.e. its meaning) is described, in an exhaustive way. Put another way, when somebody sees a diagram, there should be only-one-true-way to understand it.

> (Unambiguous by what criteria ? How does this differ between what one
> might expect in coding guidelines, versus modelling guidelines?)

Sorry, I don't understand this point.

> What “unambiguous graphical representations” do you use in practice ?

We are starting to use SCADE. We (my colleagues) have used SDL in the past.

> How do you know they are unambiguous ? J

Because you can read the formal description and make tools from it. Of course, there is always humans in the loop and so many ways to make mistakes (badly understand the formal description, still some ambiguities in the albeit formal description, ...).

> How is the “lack of ambiguity” property useful? (I know this sounds
> like an odd question, but lack of ambiguity is important for different
> reasons in different contexts; for human understanding, for reliable
> generation of implementation code, for automatic generation of test
> cases, and so on).

For me, human understanding and automatic code generation are equally important. Such languages can be / are used like programming languages: you don't want the program to have a different behaviour that you understood on the drawing or in simulation; you are doing team work and you want everybody to understand the same thing from the diagrams; and you don't want the generated code to have a different behaviour that you understood.

Best regards,
D. Mentré



The System Safety Mailing List
systemsafety_at_xxxxxx Received on Fri Feb 26 2016 - 10:27:33 CET

This archive was generated by hypermail 2.3.0 : Wed Apr 24 2019 - 23:17:08 CEST