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

[Les Chambers]

Malcolm

I look forward to the day when standards bodies screw up the courage to
mandate the state engine as the core modelling technique in control systems.
They'd only be stating what anyone with any experience in designing,
building and operating these systems has known for decades. Personally I
don't care which species of state engine you use as long as the core
concepts first introduced by Mealy (1955 paper, "A Method for Synthesizing
Sequential Circuits") and Moore (1956 paper, "Gedanken-experiments on
Sequential Machines") are at the core of your design. 

Every time I use this model I reinforce my original opinion as to what a
great idea it is. You use less (simpler) code to achieve the same result and
on reviewing your code 6 to 12 months later what you did and why you did it
is much clearer. I'm currently dealing with 400 files full of my own code
expressed in JavaScript, the jQuery JavaScript libraries, PHP, SQL, MySQL
stored procedures and HTML. Even web applications are now heavily event
oriented requiring a state based point of view. These apps are now redolent
with asynchronous communications turning what used to be a simple job into
something more resembling an operating system kernel hack. The
object-oriented paradigm is also extremely useful, organising your code so
you can find those few lines that are doing something they shouldn't be. 

Without these two fundamental approaches I and many people like me would
have a huge problem understanding our own code two weeks after we wrote it
(I thought I was alone with this problem until a few weeks ago when I
discovered that several other software engineers who are much smarter than
me have the same issue - the problem gets orders of magnitude worse with
large software development teams).

 

When will these standards wonks understand that pussyfooting around using
terms like "unambiguous graphical representation" is unhelpful, creating a
massive ambiguity in the standard itself which, as a flow on effect, spawns
and industry in compliance gaming and wastes developers time - the
beginnings of which we have seen on this list with all the various posts as
to "what does it mean????"

Just tell em, "Use a state engine pilgrim, or be dammed!"

And to Steve Tockey - writing a book on your "representations" - go you good
thing (Rugby metaphor). I'm sure the state engine will be prominent.

Cheers

Les

 

From: systemsafety
[mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of
Watts Malcolm (AE/ENG1-AU)
Sent: Friday, February 26, 2016 6:01 PM
To: systemsafety at TechFak.Uni-Bielefeld.DE
Subject: [SystemSafety] Modelling and coding guidelines: "Unambiguous
Graphical Representation"

 

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 ? J

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/20160229/1a193267/attachment.html>