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

[Michael J. Pont]

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
provided.]

 

All the best,

 

Michael.

 

Michael J. Pont

SafeTTy Systems Ltd

 <http://www.SafeTTy.net> www.SafeTTy.net  

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