Observations and ideasabout GraphicalAnnex, and · PDF fileObservations and ideasabout GraphicalAnnex, and States and Modes. ... Member, IEEE IEEE TRANSACTIONS ON SOFTWARE ... (IEEE-Std-91a-1991

Observations and ideas about

Graphical Annex, and

States and Modes.

MONTRÉAL • OTTAWA • CHICAGO │ www.cmcelectronics.ca

exploring AADL Symbology, State Charts, Variability,

Pierre Labrèche

with slides by K. Czarnecki

Purpose of this presentation

Trigger discussions aimed at improving

– Graphical AADL representation

• current symbology can be inconsistent, difficult to grasp, and confusing

– State machines, applying RSML concepts to

• Error Modeling,

• Behavior Modeling,

• Functional Modeling

– Variability Modeling (K. Czarnecki’s slides)

• Variants modeling - needed

• Variation points implementation

2

PART 1. IMPROVING VISUAL AADL

current AADL symbology is inconsistent, difficult to grasp, and confusing

3

Current AADL Symbology (1)

4

AEROSPACE

AEROSPACE

STANDARD

AS5506BIssued 2009-01

Revised Proposed Revision

2012-03-05

Superseding AS5506A

Architecture Analysis & Design Language (AADL)

D.2 AADL Graphical Symbols

Inconsistencies (1)

Name Basic Set, Group Virtual Abstract

bus

subprogram

process

thread

process

subprogram

bus bus

subprogram

group

thread group

data abstract

what does a dashed

outline mean?

process group?

virtual process?

abstract process?

What does a

parallelogram mean?

what does rectangle

mean?

5

Current Access Symbology

6

“The arrow direction indicates whether the

feature is provided or required and aligns with

the direction of the call. “

“The provides data access and

requires data access features are

shown pointing in the direction of

the component requiring data

access.”

Sample feature declarations from the book Model-Based Engineering

with AADL: ... symbology and textual AADL requires mismatch?

From Appendix D Graphical AADL Notation :

Inconsistencies (2)

Access to what ? requires provides

subprogram

subprogram

group

bus

data

memory

access to what ?

... data, bus and

memory have no

specific symbol !

inconsistent

use of

graphical

attributes!

7

same symbol means

requires and

provides!

the plain requires/provides symbol is

is placed in and out

the plain requires/provides symbol is

placed inside, but subprogram access

is placed in and out

arrow

directions

inconsistent?

Visual Languages:

Guidance for Construction

8

Cognitive Dimensions of Information Artefacts: a

tutorialThomas Green and Alan Blackwell

Version 1.2 October 1998

• http://www.cl.cam.ac.uk/~afb21/Cogni

tiveDimensions/

• http://www.cl.cam.ac.uk/~afb21/Cogni

tiveDimensions/CDtutorial.pdf

The “Physics” of Notations: Towards a Scientific

Basis for Constructing Visual Notations in

Software Engineering Daniel L. Moody, Member, IEEE

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 35, NO. 5,

NOVEMBER-DECEMBER 2009 756

• http://www.ajilon.com.au/en-

AU/news/Documents/News_PDFs/100

528_Dr_Daniel_Moody_Software_Engi

neering_Keynote.pdf

• http://www.cs.toronto.edu/~chechik/c

ourses12/csc2125/paper10.pdf

Notational Systems – the Cognitive Dimensions

of Notations frameworkAlan F. Blackwell and Thomas R.G. Green Final version of manuscript as

included in John M. Carroll (Ed.)

HCI Models, Theories, and Frameworks: Toward a Multidisciplinary

Science

San Francisco: Morgan Kaufmann (2003), pp. 103-134.

• http://www.cl.cam.ac.uk/~afb21/public

ations/BlackwellGreen-CDsChapter.pdf

Examples of symbology and notations

• IEEE Std 315-1975, Graphic Symbols for

Electrical and Electronics Diagrams

• IEEE Std 91-1984 (Including IEEE Std 91A-1991

Supplement), Graphic Symbols For Logic

Functions

• Esterel SCADE V6

• MathWorks Simulink

• http://en.wikipedia.org/wiki/MapReduce

9

Modeling Similar Elements

(IEEE-Std-91a-1991 electrical)

10

Could be useful to declutter diagrams

Modeling Similar Elements

(IEEE-Std-91a-1991 electrical)

11

Could be useful to declutter diagrams

A quick shot at renewing

AADL’s visual symbology

• Warning:

– symbology examples presented here were drawnby an AADL beginner (me!)

– Some illustrated concepts may be invalid in AADL.

– These examples may not meet ideal visuallanguage construction goals

• The following symbology just explores different possibilities. Examples are not hard propositions

12

new symbology principles

• Principles– Derived from existing AADL symbology

– Consistent use of graphical attributes

– Easy to draw using common editors

– Easy to draw by hand

– Unambiguous• e.g. moving a symbol does not change its meaning.

• Orthogonal

– Visually pleasant

– Compact

• Example: meaning of a shape’s outline style

basicset/group

(cardinality)Virtual

Abstract or

undefined

13

package, abstract, system, device


package

abstract

(generic)

system

(composite)

device

package

device

system

14

style

1

style

2

data, subprogram, process, thread


data

subprogram

process

thread

process

thread thread *

data

subprogram subprogram *

15

processor, memory, bus, device


processor

memory

bus

processor

memory

bus bus

processor

16

Name Event Data Event+Data source or sink

information

flow path

source

sink

data, event, flow

source, sink

17

color can be used with shape

to reinforce visual

differenciation

Name Sampling port Queueing port Multiple Sampling

ports

Multiple Queueing

Ports

event

port

data

port

event

+ data

port

in ports (style1)

18

in

in1

in2

in3

in1

in2

in3

in1

in2

in3

in1

in2

in3

in1

in2

in3

in1

in2

in3

in

in

in

in

in

in

Illustrating arrays of elements

having the same qualifying

symbols (IEEE-Std-91a-1991)


ports

Multiple Queueing

Ports

event

port

data

port

event

+ data

port

in ports (style2)

in1

in1

in1

in1

in1

in1

in1

in1

in1

in2

in2

in2

in3

in3

in3

in1

in1

in1

in2

in2

in2

in3

in3

in3

19

in


ports

Multiple Queueing

Ports

event

port

data

port

event

+ data

port

out ports

out1

out1

out1

out1

out1

out1

out1

out1

out1

out2

out2

out2

out3

outt3

out3

out1

out1

out1

out2

out2

out2

out3

out3

out3

20

AADL output

ports have no

buffers ?out

inout ports


ports

Multiple Queueing

Ports

event

port

data

port

event

+ data

port

inout1

inout1

inout1

inout1

inout1

inout1 inout1

inout2

inout3

inout1

inout1

inout1

inout2

inout2

inout2

inout3

inout3

inout3

inout1

inout2

inout3

inout1

inout2

inout3

21

inout

ports symbology

Sampling port Queueing port Sampling Ports

vector [N]

Queueing Port vector

inout1 inout1

inout [N]inout [N ]

Name

feature group

reuse

(inheritance,

reuse)

in

out

inout

subprograms and parameters

parameter

parameter

parameter

subprogram

23

FG1FG2

feature group;

requires and provides access

Name

feature

group

(instance of)

access

(style 1)

access

(style 2)

requires provides

24

providesrequires

FG1 FG2

access to memory and bus

Name requires provides

bus access

memory access

bus access

(alternate style)

memory access

(alternate style)

25

access to data,

subprogram, subprogram groups

Name requires provides

data access

subprogram

access

subprogram

library access

26

Name

feature

group type

included

feature

group

ports in port out port

access requires provides

FG3

feature group

out1

out2

out3

in1

in2

in3

FG1 FG2

27

implementation and extension

(device example)

base extension extension

of

extension

type

implementation

base

base

.impl

ext1

ext1

.impl1a

ext1

.impl1b

28

Representing Implementation

(alternate style)

Existing ADELE

representation

With new Symbology

(illustrated with device)

type

implemen

tation

29

Device1

in

in

out1

out1

Device1.Device1

Device1.Device2

Device1.Device3

Source: D. Blouin

Using Array Connection properties

Existing AADL representation?

30

sensor process actuator




data flow switching

(message full replication + merge)

31





X

configAll_to_All

Signal junctions in AADL ?

32

Schematic wire junctions:

1. Old style: (a) connection, (b) no connection.

2. One CAD style: (a) connection, (b) no connection.

3. Recommended CAD Style: (a) connection, (b) no connection

ref: http://en.wikipedia.org/wiki/Circuit_diagram

Vision Electrical

Transmission Paths

IEC Symbology for effects

33

Source: Autodesk web site

Possible use as

a graphical

language for

Error Annex?

IEC Symbology for transmission

34

Source: Autodesk web

site

Map and Fold /

Map and Reduce notation

35

Source: Esterel technologies SCADE Suite modeler

Map-fold notation

could be useful to

replicate design

patterns and

interconnections.

Part 1. AADL Graphical Langage

Key points

• AADL symbology can be inconsistent or incomplete

• Some visual syntax evaluation would be useful – AADL graphical language should be assessed and revised by experts in

visual notations, experts in AADL, an dtool providers.

– Methods presented on page “Visual Language Design: someguidance » should be considered

– There are good visual language features in non-AADL languages and tools that could be used as benchmark or reference for revision

– Doing it seriously is a significant effort.

– Have to move carefully, if revision happens

• How important is it?– Unimportant to experts because “nobody uses graphical AADL editors”

– Graphics are required for introducing the language to non-practitioners

36

PART 2. MODES AND STATES

Improving states and modes:

basing StateCharts on RSML, a best practices per FAA REMH

37

Importance of modes and states (part 2)

• “State/mode requirements state

– the required states and/or modes of the item, or

– the required transition between one state and another state, one mode and another mode, made in one state to mode in another state or

– the response required of the system as a direct consequence of a transition having occurred.

• A "state" is a condition of something required or permitted.

• A "mode" in this context is a related group of functionality for a purpose, i.e. "mode of operation".”

http://www.ppi-int.com/systems-engineering/types-of-requirements.php

38

Importance of modes and states (part 2)

• Significance to the Requirements Analyst:– ... a States & Modes Analysis is performed early, and can contribute

considerably to the capture of missing requirements and the validation of requirements that are already there. Because States & Modes Analysis deals with "big picture" required and permitted dynamics of the system, a States & Modes Analysis is a high return on investment analysis. ...

• Significance to the Specification Writer:– ... states and modes ... can have a huge influence on the effectiveness of that

requirements specification. Some of the older requirements specification standards have directed very damaging practices regarding the states and modes aspects of requirements and their specification.

• Significance to the Designer:– ... states and modes requirements have a soft influence, affecting, because of

their "big picture" orientation, initial conceptualisation of solution alternatives, and subsequently feeding directly (for a given concept) into the more abstract levels of logical design.

39

http://www.ppi-int.com/systems-engineering/types-of-requirements.php

Requirements State Machine

Language

RSML

hierarchical state charts

41

History

• One of the main design goals of RSML was readability and

understandability by non-computer professionals such as end-users,

engineers in the application domain, managers, and representatives from

regulatory agencies.

• RSML was used to specify TCAS-II and this specification was ultimately

adopted by the FAA & RTCA as the official specification for TCAS-II.

Name Basic Example

Mode or state

Mode or State named in

separate tab

Parallel

sub-states

state transition

state transition

bus

StateCharts

Modes and States (RSML)

X

Y

X1 X2

Y1 Y2

Modes

NAVs

A/As

A/Gs

State

State

substate x

substate y

42

State

Representing transitions bus

• Tutorial covering transition bus representations:

• Statechart: A Visual Language for Software Requirement S pecification, International Journal of Machine Learning and Computing, Vol. 2, No. 1, February 2012, W. Zhang, T. Beaubouef, and H. Ye

• http://www.ijmlc.org/papers/89-A928.pdf

43

RSML References

[1] Requirements Specification for Process-Control Systems, Nancy G. Leveson, Mats Per Erik Heimdahl, Student Member, IEEE, Holly Hildreth, and Jon Damon Reese

[2] A METHODOLOGY FOR IMPROVING MODE AWARENESS IN FLIGHT GUIDANCE DESIGN, Steven P. Miller, Sarah Barber, Timothy M. Carlson, David L. Lempia, Alan C. Tribble Rockwell Collins Inc, Cedar Rapids, Iowa

[3] RTCA/DO-185B Minimum Operational Performance Standards for Traffic Alert and Collision Avoidance System II (TCAS II)

44

TCAS Specfication:

RTCA/DO-185

• Traffic Alert and Collision Avoidance System

• “most complex system to be incorporated into the avionics of commercial aircraft”`--

the head of the program at the FAA

• `Volume 2 is a Specification described in 740 pages using RSML

45

Superstates, parallel states

46

Conditional connectives

47

Transition Bus

48

TCAS NOTATION

RTCA/DO-185B

49

AND-OR Tables for state transitions

50

Exemple:

RSML

Machine

51

another RSML example

52

Evolution to RSML-e

• In the course of developing the TCAS-II specification and the subsequent independent verification and validation effort, it became clear that the most common source of errors was this dependence on explicit events.

• To eliminate this problem, the Critical Systems group at the University of Minnesota developed RSML-e (RSML without events).

• As its name implies, RSML-e eliminates the use explicit events and is a synchronous language.

53

[2] A METHODOLOGY FOR IMPROVING MODE

AWARENESS IN FLIGHT GUIDANCE DESIGN

Increase the expressiveness of state machines by embedding

architectural changes within states (e.g. connection of signal

flows)

Proposal:

54

Combining Statecharts with other Architectural

features (1)

A system’s operation is expressed using a statechart; As illustrated below

in SCADE, the signal flows are enabled withing the states of a StateChart.

http://ansys.com/staticassets/ANSYS/staticassets/resourcelibrary/brochure/SCADE-Suite-DataSheet.pdf 55

Unifying variation points, operating mode,

failure mode, and functional behavior

The states of a statechart can be fixed (invariant) or dynamic.

1. Using states that are fixed for a given product instance, a StateChartcan define the variants of a product line. – AADL needs to be coupled with a variability modeling notation, e.g. the

OMG CVL.

– Need to consider binding time of variation

2. Using dynamic states:A. a StateChart can define the « operating modes »

• whereby the states represent an intended mode of operation

• an operating mode is dynamic, and represents the intended operation of a product instance (e.g. take-off, cruise, landing)

• terminology: « operating mode » or « mode of operation »?

B. a StateChart can define the «failure modes »• whereby the states repesent the platform’s condition

C. a StateChart can finally represent a function’s state-driven behavior(functional behavior)

56

Part 2. Modes and States

Key Points

• Modes and States are defined in many places in AADL:– 12. Modes and Mode Transitions

– Annex E: Error Model Annex -- Error Behavior States and Transitions

– Behavior Annex

• Questions – Should graphical RSML be used as the graphical language

for AADL modes and States?

– Should textual and graphical AADL move to full expressivityof RSML (hierarchy, and-or tables, ...)

– Should graphical AADL adopt hierarchical states (modes) with embedded signal flow?

57

PART 3. VARIABILITY

58

Product Line (PL)

is a set of products

sharing common

features

59

Krzysztof Czarnecki, 2013

Software-intensive products

come in many variants

60

Variability Modeling

61

Geometric Performance

VNAV

1..1

…

Feature

Alternative

Variability abstraction

R1 …

R2 VNAV function

R3 Geometric (?)

R4 Performance (?)

R5 …

Requirements

Guidance

Processing

Geometric

VNAV

Performance

VNAV

?

?

Functional models & code

T1 …

T2 …

T3 Geometric (?)

T4 Performance (?)

T5 …

Tests

Variable assets

Binding

Additional Additional

architectural

view!

Variation

point(optional

element)

(Feature model)

R1 …

R2 VNAV function

R3 Geometric (?)

R4 Performance (?)

R5 …

Requirements

Guidance

Processing

Geometric

VNAV

Performance

VNAV

?

?


T1 …

T2 …

T3 Geometric (?)

T4 Performance (?)

T5 …

Tests

Variable assets

Variability Resolution

62

Geometric Performance

VNAV

1..1

…

Variability abstractionPositively resolved

(Feature model)

R1 …

R2 VNAV function

R4 Performance

R5 …

Requirements

Guidance

Processing

Performance

VNAV


T1 …

T2 …

T4 Performance

T5 …

Tests

Asset variants

Variant

63

Performance

VNAV

…

Resolution

Terminology

• Feature– coherent increment of functionality at high level of

abstraction

• Variation point– location in an asset (document, model, code) where

variation occurs

• Variable assets– assets with unresolved variation points

• Configuration– specification of how variability resolved

• Variant– instantiation of assets where all variability resolved

64

Feature View at Lifecycle

Requirements

Architecture

Design & code

Unit & integration test

System test

65

Feature Model

Variation Points

• Location in an asset where variation occurs

• Different variation types

• Different binding times

66

Boot

Time

Link

Time

Compile

Time

Code

Generation

System

Design

Run

Time

Binary

choice

?

Value

parameter

V

Multiple

instantiation

*

Exclusive

choice

↔

Variation Points

• Internal variability realization– Built-in language mechanisms

• if, switch in C, C++

• OO mechanisms & patterns in C++ (strategy, dependency injection)

• Variant subsystem block in Simulink

• …

• External variability realization– External operations on artifacts

• Model transformation

• Preprocessor (#ifdef)

• Code generation

• Linking

67

Variation Points in Simulink

68

Variant Subsystem Block

Variation Points in AADL

69

Variation Points in Doors

70

• Variability is an important aspect of system and software design– Variability can be a stakeholder issue when defining product or

component requirements

– Configuration mechanism when reusing configurable implementations.

• Variation points mechanisms and purpose should be explicit in requirements and architecture

• Feature model notation and mechanisms should be available to configure AADL models

• Benchmark with other ADLs, e.g. AUTOSAR, SysML – Variation points can be implemented by state machines, Data

Parameter Files, ...

– Various binding times should be accommodated

Part 3. Variability

Key Points

71