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

[Nick Tudor]

Hi Malcolm

We have made a business around unambiguous graphical representations, or
rather providing formal (as in Formal Methods) semantics for commonly used
graphical languages and then providing proof that they implement what you
expect. We take English requirements to a mathematical representation and
can show that a design in Simulink/Stateflow implements them by translating
the model to a formal representation.  Others have commented that Simuilink
is a very poorly defined language (too right), but we bless it with an
independent semantics.  Of course there is absolutely no reason to go back
to The Mathworks for their blessing; self defeating exercise in the first
instance and secondly, there are much betters ways of getting the required
independence (which we have done).  The tool is at a beta release and we
are working with parts of the UK automotive industry on case studies
against ISO26262 and the cost benefit.  We are also working in aerospace
against DO-178C (which I helped write - specifically the DO-333 Formal
Methods Supplement and DO-330 Tool qualification).  We are in the process
of building a Requirements to SysML (UML) proof tool and have already got
independent automatic verification of automatically generated code  from
Simulink.  We are also now in the  process of building a tool to prove
Executable Object Code (ie that which operates on the target processor)
against the source code including proof of absence of dead code.  In so
doing we remove the need to undertake vast swathes of reviews and test.

The company's name is D-RisQ and is based in Malvern, UK.  If you want to
know more, by all means drop me a line privately.

Cheers

Nick Tudor
Tudor Associates Ltd
Mobile: +44(0)7412 074654
www.tudorassoc.com

*77 Barnards Green Road*
*Malvern*
*Worcestershire*
*WR14 3LR*
*Company No. 07642673*
*VAT No:116495996*

*www.aeronautique-associates.com <http://www.aeronautique-associates.com>*

On 26 February 2016 at 08:01, Watts Malcolm (AE/ENG1-AU) <
Malcolm.Watts at au.bosch.com> wrote:

> 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*
>
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20160226/f1511c09/attachment-0001.html>