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

[Watts Malcolm (AE/ENG1-AU)]

Hello all;

I've been asked to comment on an issue in a draft of the next version of automotive functional safety standard ISO 26262.

Specifically, in 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.

My initial comment was along the lines of "It would help practitioners if what was intended by this entry was clearly defined, and some examples of acceptable practice provided".

Ironically, I have now been asked to provide some examples of "unambiguous graphical representation".
I thought I should call upon the experts...

I have some "graphical representations" in mind (AADL, PNML from ISO/IEC 15909-1:2004, SDL or SDL-RT from the telecoms domain).
Each is in some measure or other "unambiguous" in syntax and/or semantics. Some have decades of experience with practical implementation.
None is currently (that I know of) widely adopted in the automotive domain.  (Reasons for this would be interesting...)

Before I reply to my colleagues...

What do those of you who practice in this field understand by "an unambiguous graphical representation"?
(Unambiguous by what criteria ? How does this differ between what one might expect in coding guidelines, versus modelling guidelines?)

What "unambiguous graphical representations" do you use in practice ?
How do you know they are unambiguous ? :)
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).

Thanks for thoughts...

Best regards

Malcolm Watts

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20160226/9f5ad163/attachment.html>