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

From: José Faria < >
Date: Fri, 26 Feb 2016 10:22:30 +0000

>> None is currently (that I know of) widely adopted in the automotive
domain. (Reasons for this would be interesting…)

'Three' words: Tools, tools, tools.

Take, for example, AADL. Despite some *very* interesting efforts like OSATE, it isn't yet what would be considered by most a "full industrially capable" tool.

>> What do those of you who practice in this field understand by “an
unambiguous graphical representation”?
>> How do you know they are unambiguous ? J

Ah, ultimate questions:)

It could be useful to start all the way back from the semiotics tetrahedron, where:

§ The *domain *(/referent /universe of discourse) denotes the existing or conceived reality that is the subject of model creation;

§ The *conception *denotes the image of the real-world (domain) object in the mind of the interpreting person. This notional image comprises a set of properties that the interpreting person associates to the real-world object;

§ The *representation *denotes the result of a human actor describing his/her conceptions using a conceptual modelling language.

With these:

§ The *syntax *of a language defines the atomic language constructs (the symbols) and their valid combinations;

§ The *semantics *defines the meaning of the language constructs (the symbols and their combinations). The semantics is based on the syntactic rules. It is established through the assignment of the representations to the conceptions.

§ The *pragmatics *deals with the effects that the interpretation of the representation has on the interpreting actor. Or, put in other terms, pragmatics studies the ways in which context contributes to meaning.

Given that conceptions are formed by the actor/user/human according to his/her association with the referents in the domain, it is inevitable that different people give different meanings to the same terms and expressions. It is a challenge no matter the universe of discourse or language.

Formality solves the 'first half' of the problem.

A formal method allows us to use a language in which the meaning of an expression is rigorously defined and for which meaning-preserving formal manipulation rules are defined. Like so, expressions can be manipulated with regard only to their form (and not their content, therefore the “formal” designation), which allows automatic (machine) manipulation and verification.

Yet, for the human in the loop, effective and efficient use of formality requires him/her to have a significant degree of maturity, with a clear mental model of what is the semantics of the notation being used.

Yes, a tool can unambiguously (i.e., always with the same interpretation) manipulate a model. Whether that expresses pricesily what the user intended is a different question.

So, provided you have the first -- formal semantics -- you can solve the second half and "know they are unambiguous" if the users are well experienced and trained enough so that they can precisely express themselves and manipulate the language they are using.

It is often the case that the level of maturity required for that is so that people end up using less formal notations because these 'feel' easier to understand and manipulate. Ironically, if 'design/modelling conventions' are commonly agreed and understood among the group of users, so that ambiguity is reduced, this turns out 'practically effective' (when automatic machine manipulation is not required). Most would call these "semi-formal" approaches.

Best regards,

José Miguel Faria
t: +44 (0)7918 200367
e: jmf_at_xxxxxx

On Fri, Feb 26, 2016 at 9:33 AM, David MENTRE <dmentre_at_xxxxxx

> Hello,
> Le 26/02/2016 09:43, Peter Bernard Ladkin a écrit :
>> Another reason is the prevelance of MathLab/Simulink in this domain.
>> Simulink is now an executable
>> specification language. Since there is one supplier, it is de facto
>> unambiguous (there is just one
>> simulator, so the single meaning of a Simulink spec is precisely what
>> that simulator does with the
>> spec).
> Some people have even formally defined the semantics of Simulink or a
> subset of it:
> Except that semantics of MathLab/Simulink is very fragile, e.g. order of
> execution of state machines on a diagram depends on the order they were
> drawn.
> I would not rely on that for a safety-critical system!
> I know, we are not living in a perfect world. :-)
> Best regards,
> david
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx >
-- -- *José Miguel Faria* *Educed *- Engineering made better t: +351 913000266 w: e: jmf_at_xxxxxx
_______________________________________________ The System Safety Mailing List systemsafety_at_xxxxxx
Received on Fri Feb 26 2016 - 11:23:13 CET

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