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

From: Michael J. Pont < >
Date: Sat, 27 Feb 2016 10:45:40 -0000

Dear Malcolm,  

You wrote:

'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".'  

I agree completely.  

You asked:

'What do those of you who practice in this field understand by "an
unambiguous graphical representation"?'  

The organisations that we work with on ISO 26262 (and similar) projects are not yet ready to embrace formal methods. I suspect that this is the case for the majority of users of ISO 26262 at this time.  

To address what I see as this gap in the standard in a practical way, I'd suggest that each graphical notation that is used in a project needs to be accompanied by a table that lays out what is meant by each element that is employed (such as bubbles, lines, dotted lines, boxes, etc). I'm thinking in terms of a description of each element in text form (e.g. English): "A bubble represents a function that is called periodically by the task scheduler ..."  

To be clear: my proposal is that Unambiguous Graphical Notation" should be defined as meaning a combination of: [i] one or more diagrams that are created using a finite number of symbols; plus [ii] one or more tables that explain what each of these symbols means in the context of the project concerned.  

In some cases these tables may - of course - already exist: in other cases, they will need to be created as part of the project. This will take a little effort, but it should be possible to re-use the tables in future projects.  

Simply requiring that design diagrams are accompanied by such a "key" would - in my view - be a significant step forward for many organisations: a small "tweak" to the standard would encourage this.  



While I'm here .


One of my "pet hates" in ISO 26262 is that defined terms (from Part 1) are
not clearly identified at later points in the text.  


In a legal contract (for example) we would usually start by defining terms
such as "Dual-Point Failure" at the start of the document (with the initial
capitals, or a different font, etc, used in the definition).  References to
these terms that appeared later in the document would then be easily
identified (because Dual-Point Failure, for example, would always appear in
the same format).  


This doesn't happen in ISO 26262 - and I think we should try to change this
in the next edition.


[One side-effect of this small change might be that it would be easier to
spot terms that are used in the document for which no definition has been


All the best,




Michael J. Pont

SafeTTy Systems Ltd


_______________________________________________ The System Safety Mailing List systemsafety_at_xxxxxx
Received on Sat Feb 27 2016 - 11:45:54 CET

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