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

[Peter Bernard Ladkin]

On 2016-02-26 09:01 , Watts Malcolm (AE/ENG1-AU) wrote:
> ... ISO 26262..... Table 1 in Part 6 (Software Development) there currently is a recommendation for
> the “Use of unambiguous graphical representation”  as a part of coding and modelling guidelines.
>  
> ... “It would help practitioners if what was intended by this
> entry was clearly defined, and some examples of acceptable practice provided”.
> 
> I have some “graphical representations” in mind (AADL, PNML from ISO/IEC 15909-1:2004, SDL or SDL-RT
> from the telecoms domain).

Neither SDL nor SDL-RT is unambiguous. I don't really know much about AADL, and I don't know PNML at
all.

Message Sequence Charts are unambiguous if you use the Ladkin-Leue semantics, or the later
Damm-Harel semantics. I don't know, though, whether those or alternatives are normative in the
current standard.

> None is currently (that I know of) widely adopted in the automotive domain.  (Reasons for this would
> be interesting…)

Amongst other things, because they are not unambiguous. This from one major auto company.

Another reason is the prevelance of MathLab/Simulink in this domain. Simulink is now an executable
specification language. Since there is one supplier, it is de facto unambiguous (there is just one
simulator, so the single meaning of a Simulink spec is precisely what that simulator does with the
spec).

One major tier-one supplier bases development on Simulink specs, but then hand-translates into
very-low-level specs for programming the production systems.

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

The graphical objects are specified in a discursive formal language and that formal language has
a formal semantics with an intuitive counterpart. That usually, but not inevitably, means an
SOS-style operational semantics, rather than Abstract Interpretation. But I do admit to having once
written a quick-and-dirty denotational semantics for some OO constructs for someone else who needed one.

If you want to know what a semantics for graphical representations looks like in general, there is a
book "Logical Reasoning with Diagrams" from two decades ago (authors Allwein and Barwise). There is
also, by now, a plethora of subsequent literature.

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

My answer sorts that question. What you get from coding guidelines has little to do with an
unambigous semantics. You can write coding guidelines for any programming language, whether
unambiguous or not, whether graphical or not. C for example. UML for example.

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

Why-Because Graphs and Causal Fault Graphs. Formerly, Message Sequence Charts (or, as I/Leue/Simons
prefer to call our subset, Message Flow Graphs. We couldn't stomach the entire baroque set of MSC
symbols).

> How do you know they are unambiguous ? 

Because we defined the semantics and we believe ourselves, as do others. That reasoning notoriously
won't work for everyone.......

> How is the “lack of ambiguity” property useful?  

The very best answers to this question have been given by Praxis, now Altran UK, and AdaCore over
the course of three decades in a variety of public documents.

> (I know this sounds like an odd question,

It doesn't sound odd. It is the key question.

PBL
Prof. Peter Bernard Ladkin, Faculty of Technology, University of Bielefeld, 33594 Bielefeld, Germany
Je suis Charlie
Tel+msg +49 (0)521 880 7319  www.rvs.uni-bielefeld.de





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20160226/1dd85e0b/attachment.pgp>