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

From: Peter Bernard Ladkin < >
Date: Fri, 26 Feb 2016 09:43:22 +0100


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



The System Safety Mailing List
systemsafety_at_xxxxxx Received on Fri Feb 26 2016 - 09:43:30 CET

This archive was generated by hypermail 2.3.0 : Sun Feb 17 2019 - 08:17:07 CET