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

From: Nick Tudor < >
Date: Fri, 26 Feb 2016 13:33:25 +0000


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_xxxxxx

> 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_xxxxxx >
>



The System Safety Mailing List
systemsafety_at_xxxxxx Received on Fri Feb 26 2016 - 14:33:33 CET

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