chess toolset user guide - eclipse · chess toolset user guide 1 chess toolset user guide 18 june...

CHESS Toolset User Guide

1


18 June 2016


2

1 Table of Contents 1 Table of Contents ...................................................................................................................................... 2

2 List of Tables .............................................................................................................................................. 9

3 Document history .................................................................................................................................... 10

4 Introduction ............................................................................................................................................. 10

5 The role of MDT Papyrus ......................................................................................................................... 11

6 Creating a new CHESS project ................................................................................................................. 11

7 Creating a new CHESS model .................................................................................................................. 11

7.1 Defining the domain of the CHESS model ....................................................................................... 12

7.2 Naming CHESS model elements ...................................................................................................... 12

8 Creating diagrams .................................................................................................................................... 12

8.1 The CHESS diagram palettes ............................................................................................................ 12

9 Working with the CHESS Views ............................................................................................................... 12

9.1 Requirement View ........................................................................................................................... 13

9.2 System View .................................................................................................................................... 14

9.3 Component View ............................................................................................................................. 15

9.3.1 Functional View ....................................................................................................................... 16

9.3.1.1 Class Diagram ...................................................................................................................... 16

9.3.1.2 Composite Structure Diagram ............................................................................................. 18

9.3.1.3 State Machine Diagram ....................................................................................................... 20

9.3.1.4 Activity Diagram .................................................................................................................. 21

9.3.1.5 Sequence Diagram ............................................................................................................... 21

9.3.2 Extra Functional View .............................................................................................................. 23

9.3.2.1 Class diagram ....................................................................................................................... 23

9.3.2.2 Composite Structure Diagram ............................................................................................. 23

9.3.2.3 State Machine Diagram ....................................................................................................... 24

9.3.2.4 Activity diagram ................................................................................................................... 24

9.3.3 Modeling the SW entities with the Functional and Extra Functional View ............................. 25


3

9.3.3.1 Modeling Data Types ........................................................................................................... 25

9.3.3.2 ComponentTypes ................................................................................................................. 30

9.3.3.3 Interfaces ............................................................................................................................. 30

9.3.3.4 ComponentImplementations .............................................................................................. 32

9.3.3.5 Modeling the SW instances ................................................................................................. 32

9.3.3.6 Modeling Operational Modes ............................................................................................. 33

9.3.3.7 Modelling Timing properties ............................................................................................... 34

9.3.3.7.1 Querying the timing properties ..................................................................................... 36

9.3.4 Instance View........................................................................................................................... 37

9.4 Deployment View ............................................................................................................................ 40

9.4.1 Diagrams .................................................................................................................................. 41

9.4.1.1 Class diagram ....................................................................................................................... 41

9.4.1.2 Composite Structure diagram ............................................................................................. 41

9.4.2 Modeling the HW entities ....................................................................................................... 42

9.4.3 Defining the number of cores for a processor ........................................................................ 42

9.4.4 Modeling Memory Partitions .................................................................................................. 43

9.4.5 Allocating SW instances to HW instances ............................................................................... 45

9.4.5.1 Multicore Support Wizard ................................................................................................... 45

9.4.5.1.1 Assign Components to Cores ......................................................................................... 45

9.4.5.1.2 Assign Tasks to Cores ..................................................................................................... 46

9.4.5.1.3 Generate Task to Core Assignments ............................................................................. 46

9.4.5.2 Manually creating the Assign entities ................................................................................. 46

9.4.5.3 Specifying the Operational Mode ........................................................................................ 47

9.5 Analysis View ................................................................................................................................... 48

9.5.1 Dependability View .................................................................................................................. 48

9.5.1.1 Class diagram ....................................................................................................................... 48

9.5.2 RT Analysis View ...................................................................................................................... 48

10 The instances model ............................................................................................................................ 48

11 Modeling the Data Flow ...................................................................................................................... 52

12 Working with Contracts ....................................................................................................................... 53


4

12.1.1 Selection of weak contract for Block/Component instances .................................................. 56

12.1.2 Contract Refinement ............................................................................................................... 58

12.1.3 About FormalProperties .......................................................................................................... 60

13 Modelling Dependability ..................................................................................................................... 61

13.1 Modeling Criticality.......................................................................................................................... 62

13.1.1 Modelling the criticality level .................................................................................................. 62

13.1.2 CriticalityInterfaceSpecification ............................................................................................... 65

13.2 Editing Failure Propagation rules with XText (content assistance) ................................................. 66

13.2.1.1 Xtext Features .................................................................................................................. 67

14 Domain specific modeling ................................................................................................................... 68

14.1 Avionics ............................................................................................................................................ 68

14.1.1 Creating functional partitions .................................................................................................. 68

14.1.2 IMA Partitions Support Wizard ................................................................................................ 69

14.1.2.1 Assign Components to Partitions .................................................................................... 69

14.1.2.2 Assign Partitions to Cores ................................................................................................ 69

14.1.2.3 Generate Partitions schedule .......................................................................................... 70

14.1.3 ARINC Processes ...................................................................................................................... 70

14.2 Automotive ...................................................................................................................................... 72

14.2.1 AUTOSAR generation ............................................................................................................... 72

15 Model validation .................................................................................................................................. 72

15.1 Configuring the CHESS model validation features .......................................................................... 73

15.2 CHESS Criticality Validation ............................................................................................................. 73

15.2.1 Connection (CV_1) ................................................................................................................... 73

15.2.2 Component that owns a provided port (CV_2) ....................................................................... 73

15.2.3 Assignment of Components to Cores: check on Memory Partitions (CV_3) ........................... 73

15.2.4 Assignment of Component to Core (CV_4) ............................................................................. 74

15.2.5 Access of a Component to a Device (CV_5) ............................................................................. 74

15.3 Functional View (included in “Core Constraints”) ........................................................................... 74


5

15.3.1 Provided/Required ports of Interfaces (Connector_01) ......................................................... 74

15.3.2 Connector: FlowPorts compatibility of direction (Connector_02) .......................................... 75

15.3.3 Connector: FlowPorts compatibility of type (Connector_03) ................................................. 75

15.3.4 FlowPorts not mapped on req/prov operations (FlowPorts_01) ............................................ 75

15.3.5 FlowPorts parameters type compatibility (FlowPorts_02) ...................................................... 75

15.3.6 FlowPorts parameters direction compatibility (FlowPorts_03) .............................................. 75

15.3.7 ComponentType Interface (FV_02) ......................................................................................... 75

15.3.8 ComponentImplementation realization (FV_03) .................................................................... 75

15.3.9 ClientServerPort (FV_05) ......................................................................................................... 76

15.3.10 ClientServerPort SPEC_KIND (FV_06) ................................................................................. 76

15.3.11 ClientServerPort with kind PROREQ (FV_07) ....................................................................... 76

15.3.12 Interfaces (FV_08) ............................................................................................................... 76

15.3.13 Operations (FV_09) .............................................................................................................. 76

15.4 Extra-Functional View (included in “Core Constraints”, for schedulability analysis) ...................... 76

15.4.1 CHRTSpecification Context (EFVRT_01) ................................................................................... 76

15.4.2 CHRTSpecification occKind(EFVRT_02) .................................................................................... 76

15.4.3 CHRTSpecification PeriodicPattern (EFVRT_03) ..................................................................... 76

15.4.4 CHRTSpecification PeriodicPattern (EFVRT_04) ...................................................................... 77

15.4.5 CHRTSpecification partWithPort (EFVRT_05) .......................................................................... 77

15.4.6 CHRTSpecification SporadicPattern (EFVRT_20) ..................................................................... 77

15.4.7 CHRTSpecification priority (EFVRT_30) ................................................................................... 77

15.4.8 CHRTSpecification localWCET (EFVRT_40) .............................................................................. 77

15.5 Deployment View (included in “Core Constraints”) ........................................................................ 77

15.5.1 Component Implementation deployment (DV_01) ................................................................ 77

15.5.2 Assign must have exactly one “from” and one “to” (DV_02) .................................................. 77

15.5.3 HwBus packett (DV_03) ........................................................................................................... 77

15.5.4 HwBus attributes (DV_04) ....................................................................................................... 78


6

15.5.5 Used Functional Partition allocated on exactly one Core (DV_05) ......................................... 78

15.5.6 Un-used Functional Partition allocated on exactly one Core (DV_06) .................................... 78

15.6 Analysis View ................................................................................................................................... 78

15.6.1 AnalysisView unique package AV_01 ...................................................................................... 78

15.6.2 SaAnalysisContext Platform (AV_03) ....................................................................................... 78

16 Supported Analysis .............................................................................................................................. 78

16.1 The Analysis Context ....................................................................................................................... 78

16.2 Timing Analysis ................................................................................................................................ 79

16.2.1 Schedulability Analysis............................................................................................................. 79

16.2.2 End2End Response Time Analysis ........................................................................................... 83

16.3 Dependability Analysis .................................................................................................................... 87

16.4 Performing Formal Verification of Contracts .................................................................................. 88

16.4.1.1 Model Verification ........................................................................................................... 88

16.4.1.2 Contract Refinement Analysis ......................................................................................... 90

17 Ada infrastructural code generation ................................................................................................... 91

18 Appendix .............................................................................................................................................. 92

18.1 Note about the usage of the <<Contract>> ConstraintBlock in the context of the SysML language

92

18.2 Tips................................................................................................................................................... 92

18.3 Tutorial: the CHESS process - protected operation example .......................................................... 93

18.3.1 Create data types..................................................................................................................... 93

18.3.2 Create interfaces ..................................................................................................................... 93

18.3.3 Create component types ......................................................................................................... 95

19 References ........................................................................................................................................... 97

List of Figures

Figure 1: Design Flow ....................................................................................................................................... 13

Figure 2 Requirement View - Requirement Diagram palette .......................................................................... 14

Figure 3 System View - Block Definition Diagram and Internal Block Diagram palettes ................................. 15

Figure 4 Switching between Functional and Extra-functional View ................................................................ 16


7

Figure 5 CHESS Funct View - Class Diagram Palette ........................................................................................ 16

Figure 6: CHESS Funct View - Modeling Interfaces ......................................................................................... 17

Figure 7: CHESS Funct View - Modeling Component Types ............................................................................ 17

Figure 8: CHESS Funct View - Modeling Component Implementations .......................................................... 17

Figure 9 CHESS Funct View - Modeling a Device Broker ................................................................................. 18

Figure 10 The Build Instances command ......................................................................................................... 19

Figure 11: CHESS Funct View: Modeling provided and required Ports in Composite Structure Diagram ...... 19

Figure 12: Modeling Instances in a Composite Structure Diagram ................................................................. 20

Figure 13 Modeling SW component’s access to HW Device in a Composite Structure Diagram ................... 20

Figure 14: Modeling Activity Diagram ............................................................................................................. 21

Figure 15 Functional View - Sequence Diagram palette ................................................................................. 22

Figure 16 Sequence Diagram ........................................................................................................................... 22

Figure 17 Naming convention for message numbering .................................................................................. 23

Figure 18 Extra-functional View ...................................................................................................................... 23

Figure 19 Extra-functional View Composite Structure Diagram Palette ......................................................... 24

Figure 20 Composite Structure Diagram in Extra-functional View modelling Real Time information ............ 24

Figure 21 CHESS Funct View - Modeling Data Types ....................................................................................... 25

Figure 22: Modeling default value for attribute .............................................................................................. 25

Figure 23 Functional View - Property Default Value Setting ........................................................................... 26

Figure 24 Modeling Data Ranges using MARTE BoundedSubtype (1) ............................................................ 26

Figure 25: Modeling Data Ranges using MARTE BoundedSubtype (2) ........................................................... 27

Figure 26 Modeling Arrays using MARTE CollectionType (1) .......................................................................... 27



Figure 29 Modeling Structures using the MARTE VSL TupleType (1) .............................................................. 29



Figure 32: Interface dependencies and realizations ....................................................................................... 31

Figure 33 Selection of Provided (or Required) Interface for a Client Server Port ........................................... 32

Figure 34: Working with the CHRtSpecification in the CSD (as instance view) ............................................... 35

Figure 35: CHESS tab for the CHRtSpecification .............................................................................................. 36

Figure 36: CHRtSpecification property tab ...................................................................................................... 36

Figure 37: InstanceView .................................................................................................................................. 37

Figure 38: Reading with the InstanceView ...................................................................................................... 38

Figure 39: Reading with the InstanceView - hyperlinks .................................................................................. 39

Figure 40: Creating with the InstanceView ..................................................................................................... 40

Figure 41: Updating with the InstanceView .................................................................................................... 40

Figure 42 Designing Packages in a Class Diagram in the Deployment View ................................................... 41

Figure 43 HW Types in a Class Diagram in the Deployment View................................................................... 41

Figure 44 Dependability View Activation ........................................................................................................ 41

Figure 45: Composite Structure Diagram in the Deployment View ................................................................ 42

Figure 46 Deployment View Class Diagram Palette ........................................................................................ 42

Figure 47 Build instances for HW System ........................................................................................................ 43

Figure 48: modelling HW types ....................................................................................................................... 44


8

Figure 49: HW instances, MemoryPartition instances and allocations ........................................................... 45

Figure 50 Assign Components to Cores Wizard .............................................................................................. 46

Figure 51 Assign Tasks to Cores Wizard .......................................................................................................... 46

Figure 52: Modeling the SW to HW allocation ................................................................................................ 47

Figure 53: modelling Allocations constrained to OperationalModes ............................................................. 48

Figure 54 Class Diagram to model dependability concerns in the Analysis View ........................................... 48

Figure 55 CHESS Build Instances command for Sw System ............................................................................. 50

Figure 56 CHESS Build Instances command for HW System ........................................................................... 51

Figure 57: Instances specifications .................................................................................................................. 52

Figure 58 Mapping a Flow Port to a Client Server Port ................................................................................... 53

Figure 59: Editing the Contract’s Assume and Guarantee .............................................................................. 54

Figure 60 Contract and its properties .............................................................................................................. 55

Figure 61 ContractProperty ............................................................................................................................. 56

Figure 62 Modelling Weak/Strong Contract .................................................................................................... 56

Figure 63: Contract tab for instances .............................................................................................................. 57

Figure 64: ComponentInstance stereotype ..................................................................................................... 58

Figure 65 Set Contract Refinement Command ................................................................................................ 59

Figure 66 Refinement Selection ...................................................................................................................... 59

Figure 67: Composiste Aggregation ................................................................................................................ 60

Figure 68 Contract Refinement ....................................................................................................................... 60

Figure 69 Creating a Formal Property ............................................................................................................. 61

Figure 70 ASIL Levels definition example ........................................................................................................ 62

Figure 71: Criticalitites specification ............................................................................................................... 63

Figure 72 Criticality specification with mode .................................................................................................. 64

Figure 73: Assigning criticality to a Core ......................................................................................................... 64

Figure 74: CriticalityInterfaceSpecification ..................................................................................................... 65

Figure 75 Criticality Interface Specification with Mode .................................................................................. 66

Figure 76 Assign Components to Partitions Wizard ........................................................................................ 69

Figure 77 Assign Partitions to Cores Wizard.................................................................................................... 70

Figure 78: ARINCComponentImpl.................................................................................................................... 71

Figure 79: providing real time properties for ARINCProcess and ARINCFunction operations ........................ 72

Figure 80: Schedulability Analysis Context ...................................................................................................... 80

Figure 81 CHESS Schedulability analysis .......................................................................................................... 80

Figure 82 CHESS Select Analysis Context window ........................................................................................... 80

Figure 83 Analysis in execution ....................................................................................................................... 81

Figure 84 Schedulability analysis results ......................................................................................................... 81

Figure 85: Analysis context tab........................................................................................................................ 82

Figure 86 CHESS Compare Analysis Results Command ................................................................................... 82

Figure 87 CHESS Analysis Results Comparison ................................................................................................ 83

Figure 88 End2End Analysis Package ............................................................................................................... 84

Figure 89 End2End Activity in End2End Analysis Package ............................................................................... 84

Figure 90 Setting the Activity properties for End2End Analysis ...................................................................... 85

Figure 91 Activity Diagram for End2End Analysis ............................................................................................ 85

Figure 92 End2End Analysis Context ............................................................................................................... 85


9

Figure 93 End2End Analysis Command ........................................................................................................... 86

Figure 94 End2End Analysis Context selection ................................................................................................ 86

Figure 95 End2End Analysis Result pop-up window ....................................................................................... 86

Figure 96 End2End Analysis results in Activity diagram SaEnd2EndFlow properties ...................................... 87

Figure 97 End2End Context updated with results ........................................................................................... 87

Figure 98 Model verification for NuSMV3 ....................................................................................................... 88

Figure 99 Model verification for NuSMV3 results ........................................................................................... 89

Figure 100 Contract Refinement Analysis ....................................................................................................... 90

Figure 101 System Root Selection ................................................................................................................... 91

Figure 102 Contract Refinement Verification files and results ....................................................................... 91

Figure 103 Creating data types ........................................................................................................................ 93

Figure 104 Creating interfaces ........................................................................................................................ 93

Figure 105 Creating operations ....................................................................................................................... 94

Figure 106 Defining operation's parameters ................................................................................................... 94

Figure 107 Assigning a type to operation parameters .................................................................................... 95

Figure 108 Modeling interfaces and operations ............................................................................................. 95

Figure 109 Creating component types ............................................................................................................ 96

2 List of Tables Table 1 - CHESS to OCRA data types ................................................................................................................ 90


10

3 Document history Date Version Changes

16 June 2015 01 First version

18 June 2016 02 Second version

9.3.4 Instance View

9.4.2 Modeling the HW entities

9.4.3 Defining the number of cores of a processor

9.4.4 Modeling HW Partitions

9.4.5 Allocating SW instances to HW instances

10 The instances model

11 Modeling the data flow

12 Working with Contracts

13 Modeling Dependability

14 Domain specific modeling

15 Model validation

16.3 Dependability Analysis

16.4 Performing Formal Verification of Contracts

Errore. L'origine riferimento non è stata trovata. Working with

the VSL editor to edit stereotype attributes

18.1 Note about the usage of the <<Contract>> ConstraintBlock

in the context of the SysML language

18.3 Tutorial: the CHESS process - protected operation example

4 Introduction This guide provides information about the CHESS Toolset features and their status, as well as basic hints for

the usage of the toolset for modelling system and software models and performing analysis.

The CHESS toolset is an Eclipse based framework that supports the CHESS Methodology. It provides an

editor to model all phases of development: from the definition of requirements, to the modelling of the

system functional, logical and physical architecture, down to the software design and its deployment to


11

hardware components. Finally the CHESS tool offers schedulability and dependability analysis

functionalities: according to the analysis results that are back-propagated onto the model itself, the

modeller can perform some tuning on the model in order to satisfy real time and dependability

requirements.

To find out more about the initial CHESS project (e.g. the methodology and language) see http://chess-

project.org.

5 The role of MDT Papyrus MDT Papyrus is the Eclipse UML editor on which CHESS extensions have been built.

So a basic knowledge of MDT Papyrus (not covered by this user manual) is required to be able to work with

a CHESS model.

General documentation about MDT Papyrus can be found at:

http://wiki.eclipse.org/Papyrus_User_Guide

Also the PAPYRUS USER GUIDE SERIES About UML profiling1 provides useful information about working with

stereotypes and stereotypes values.

6 Creating a new CHESS project To create a CHESS project in the local Eclipse workspace the following actions are needed:

Open the Project Explorer view (if not already visible on the left side of the Eclipse area) by using

the menu Window->Show View->Other…->General->Project Explorer

Right click on the Project Explorer and select New->Other…->CHESS->CHESS Project, provide a

name for the current project and click Finish.

The tool will ask to switch to the Papyrus perspective; this is the right perspective to be used while

working with a CHESS project.

7 Creating a new CHESS model To create a CHESS model:

right click on a CHESS project in Project Explorer view

select New->Other…->CHESS->CHESS Model, then provide a name for the current project.

Right click on the Project Explorer

select New->Other…->CHESS->CHESS Project, then provide a name for the current model and click

Finish.

1

http://www.eclipse.org/modeling/mdt/papyrus/usersTutorials/resources/PapyrusUserGuideSeries_AboutUMLProfile_v1.0.0_d20120606.pdf

http://chess-project.org./

http://chess-project.org./

http://wiki.eclipse.org/Papyrus_User_Guide


12

A CHESS model is created with the CHESS profile automatically applied on it; moreover the default

packages structure supporting the CHESS views is created in the model.

7.1 Defining the domain of the CHESS model In order to define the Domain of the CHESS model:

Click on the CHESS model in the Model Explorer

Select the Properties View

Go to the Applied Stereotypes field

Select the CHESS (from CHESS::Core) Stereotype

Select the “domain” field

Assign the appropriate domain of your model from the scroll list:

o Cross_domain

o Avionics

o Automotive

o Telecom

o Space

o Medical

o Petroleum

7.2 Naming CHESS model elements

Please notice that CHESS model elements should NOT contain spaces in their names.

8 Creating diagrams Model diagrams can be easily created:

From the Model Explorer view, by right clicking on the model element which has to own the new

diagram

From the main Papyrus->Diagrams menu

From the main toolbar by clicking on the desired diagram icon.

Note that in the last two cases the new diagram will be owned by the currently selected model entity.

8.1 The CHESS diagram palettes The CHESS toolset implements dedicated palettes to work with the current view and diagram.

At any time the tool shows the proper palette by considering the current view and selected diagram.

9 Working with the CHESS Views The CHESS toolset implements support for views implementation, where the views are defined by the

CHESS methodology.

Following figure summarizes the design flow addressing the different available views.


13

Figure 1: Design Flow

The following sections summarize the kind of diagrams and entities that can be created for each view.

In the current implementation the Data View and the Behavioral View are implemented with UML standard

diagrams where only a subset of the elements defined by UML is allowed to be managed. In particular Data

View can be managed through UML Class diagrams in the FunctionalView, while Behavioral View can be

managed with UML Activity Diagrams and State Machine Diagrams in the FunctionalView.

9.1 Requirement View Requirements can be modeled in the Requirement View package through the SysML Requirement Diagram.


14

The Requirement View palette allows to create the model entities, as depicted in Figure 2

Figure 2 Requirement View - Requirement Diagram palette

9.2 System View System modeling activities have to be performed inside the System View.

The diagrams allowed in the System View to model the System Architecture are:

Block Definition Diagram (BDD)

Internal Block Diagram (IBD)

SysML entities allowed in each diagram are enforced by the customized palettes, as illustrated in Figure 3


15

Figure 3 System View - Block Definition Diagram and Internal Block Diagram palettes

Note: currently only a subset of the SysML diagrams are proposed by the CHESS editor. In the future other

kinds of diagrams and model entities could be made available through the editor, e.g. for documentation

purposes; in this case this information would not be supported by the model driven methodology, in

particular by the validation analyses.

The System View can also be used to model Socio Technical Systems, by using the dedicated

stereotypes defined in the profile.

9.3 Component View This view allows the design of software components.

The Component View is actually composed by two sub-views, the Functional View (enabled by default) and

the Extra-Functional View.

It is possible to switch between Functional and Extra-functional views using the button with the

Blue/Yellow squares, as illustrated in Figure 4. The blue square indicates that the current view is the

Functional view, while the yellow square indicates the Extra-functional view.


16

Figure 4 Switching between Functional and Extra-functional View

9.3.1 Functional View

Through this view the functional specification of the software can be provided. The next paragraphs

illustrate the diagrams that can be modeled in the Functional View.

9.3.1.1 Class Diagram

Class diagrams are used to model Packages, Data Types, Interfaces, Component Types, Component

Implementations, Operations and Properties.

UML entities allowed in Class Diagrams are enforced by the customized palette, as illustrated in Figure 5.

Figure 5 CHESS Funct View - Class Diagram Palette

Figure 6 illustrates the modeling of Interfaces in a Class Diagram in the CHESS Functional View.


17

Figure 6: CHESS Funct View - Modeling Interfaces

Figure 7 illustrates the modeling of Component Types in a Class Diagram in the CHESS Functional View.

Figure 7: CHESS Funct View - Modeling Component Types

Figure 8 illustrates the modeling of Component Implementations in a Class Diagram in the CHESS Functional

View.

Figure 8: CHESS Funct View - Modeling Component Implementations

Figure 9 illustrates the modeling of a Device Broker in a Class Diagram in the CHESS Functional View.


18

Figure 9 CHESS Funct View - Modeling a Device Broker

A DeviceBroker component is a logical entity (e.g. a driver) which is used to make the hardware devices

accessible for software components. DeviceBrokers components are modelled in the ComponentView,

together with the application SW components.

Each DeviceBroker is associated to one or more Hw Devices (modelled in the DeploymentView), specified in

the devices field (e.g. HW_GPS in the example above).

9.3.1.2 Composite Structure Diagram

A Composite Structure Diagram is created for a given component, to model:

provided/required ClientServerPort

ComponentImplementation instances and connectors; this is not allowed for the

<<ComponentType>> Components.

The information provided through the Composite Structure diagrams in this view are also used by the

tool to automatically build the software Instance Model (using the Build Instances command available

through the Context Menu as depicted in Figure 10).


19

Figure 10 The Build Instances command

See 9.3.3.5 for more information about modeling instances.

Figure 11: CHESS Funct View: Modeling provided and required Ports in Composite Structure Diagram


20

Figure 12: Modeling Instances in a Composite Structure Diagram

Also the fact that a SW component needs to access some specific HW Devices is modeled in the Composite

Structure Diagram, as illustrated in Figure 13.

Figure 13 Modeling SW component’s access to HW Device in a Composite Structure Diagram

Once a DeviceBroker has been defined (in a Class Diagram) specifying its associated HW Device, in the

Composite Structure Diagram it is possible to instantiate DeviceBroker components and connect them

together with the other application SW components instances. The modelling of a connector link between a

SW component A and a DeviceBroker B means that the SW component A needs access to the device linked

to the DeviceBroker B. As for allocations, also the connection between SW components and DeviceBrokers

can be constrained to be allowed for some given operational modes (e.g. Normal or Emergency) only.

9.3.1.3 State Machine Diagram

A State Machine Diagram is created for a given ComponentImplementation, to model functional behavior

for ComponentImplementation.

Also it can be used to model operational modes by using the dedicate stereotypes (see section 9.3.3.6).


21

9.3.1.4 Activity Diagram

An Activity Diagram can be created for a given Operation of a ComponentImplementation to model intra

ComponentImplementation bindings, i.e. the called Operations (information used by Schedulability

Analysis).

An Activity diagram can be created through the Eclipse Model Explorer by right-clicking on the Operation of

the ComponentImplementation and selecting the New Diagram -> Create a New Activity Diagram

command.

Next figure shows an example of activity diagram for the Produce operation implemented by the

Producer_impl Component Implementation shown in Figure 8; the calls to the operations Store and

Consume are modeled in the diagram. In particular see the information provided for CallOperationAction

named Call Store_IF.Store: the OnPort refers the required port Store_IF_RI, defined for Producer_impl,

while the Operation field refers the Store operation which is defined in the Store_IF interface which in turn

is required through the Store_IF_RI port (see Figure 11).

Figure 14: Modeling Activity Diagram

Currently Decision nodes are not supported by the Schedulability analysis.

9.3.1.5 Sequence Diagram

This diagram is used for modelling a sequence of operations on which to perform End2End response time

analysis (see 16.2.2).

A subset of the modeling elements is available from the palette for Sequence Diagrams in the Functional

View, as illustrated in Figure 15.


22

Figure 15 Functional View - Sequence Diagram palette

Message Found is used to represent the starting event of the sequence. It usually corresponds to an event

in the environment.

Figure 16 Sequence Diagram

Sequence diagrams allow to represent ComponentImplementation parts (parts/property owned by

composite components) collaborating together; the parts in the sequence diagram are represented by the

lifelines. To specify the mapping between a part and a lifeline, the value of the Lifeline represents feature

must be set to the given part/property (typed with ComponentImplementation): this can be done through

the UML tab of the Property view.

Ordering of messages is not automatically supported due to a limitation in Papyrus 1.0.1. To enforce

the ordering of messages, required for the End2End response time analysis, it is necessary to use the simple

naming convention for the created messages as illustrated in Figure 17.


23

Figure 17 Naming convention for message numbering

9.3.2 Extra Functional View

Through this view the extra-functional specification of the software can be provided, such as the real time

and dependability attributes. The next paragraphs illustrate the diagrams that can be modeled in the Extra-

functional View.

The Extra-functional View is indicated in the editor with a yellow square.

Figure 18 Extra-functional View

9.3.2.1 Class diagram

Class Diagrams are used in the Extra-functional View to work with stereotypes for StateBased and

FailurePropagation information.

9.3.2.2 Composite Structure Diagram

Composite Structure Diagrams are used in the Extra-functional View to model real time, state based

analysis and failure propagation information for the available ports and parts/instances in the context of

the classifier subject of the composite diagram. For an alternative and more powerful way to model extra

functional properties at instance level the Instance View can be used in place of the composite diagram.

A subset of the modeling elements is available from the palette for Composite Structure Diagrams in the

Extra-Functional View, as illustrated in Figure 19, while other stereotypes concerning extra functional

properties for state based analysis are available in the Profile tab of the Papyrus Properties view.


24

Figure 19 Extra-functional View Composite Structure Diagram Palette

From the main CHESS menu in the toolbar: CHESS->Filters->CHRtSPecification->Show/Hide to manage

CHRtSpecification visibility for the current diagram.

Right click on a ComponentImplementation instance, select Filters->CHRtSPecification->Show/Hide to

manage CHRtSpecification visibility for the current instance.

For info on modeling Real Time properties using the <<CHRtSpecification>> Stereotype see Section 16.2.

Figure 20 Composite Structure Diagram in Extra-functional View modelling Real Time information

9.3.2.3 State Machine Diagram

State Machine Diagrams are used in the Extra-functional View to model dependability ErrorModel for a

given ComponentImpl.

9.3.2.4 Activity diagram

Activity diagrams are not used in the Extra-functional View.


25

9.3.3 Modeling the SW entities with the Functional and Extra Functional View

SW entities are initially defined at classifier level in the Component View (or in its sub-Packages) by creating

ComponentTypes.

9.3.3.1 Modeling Data Types

Primitive Types are supported: they can be created in a Class Diagram in the CHESS FunctionalView, as

illustrated in Figure 21.

Figure 21 CHESS Funct View - Modeling Data Types

In a given Component, Constants can be modeled by selecting the ‘read-only’ attribute of the given

Property (see Figure 22).

Figure 22: Modeling default value for attribute

A Default value can be specified by setting the ‘default value’ attribute of the property, for instance by

using a Literal-Integer (see figure Figure 23).


26

Figure 23 Functional View - Property Default Value Setting

Data ranges: to specify a data type that is an interval, use the MARTE::VSL::DataTypes::BoundedSubtype

stereotype, from the palette (see Figure 24).

Figure 24 Modeling Data Ranges using MARTE BoundedSubtype (1)

From the profile tab below, assign values to the following fields: baseType, minValue, maxValue,

isMinOpen, isMaxOpen, as depicted below.


27

Figure 25: Modeling Data Ranges using MARTE BoundedSubtype (2)

Another possibility for data ranges would be to use the IntervalType from MARTE VSL, but this is currently

not properly implemented in Papyrus.

Arrays can be modeled selecting from the palette the CollectionType from MARTE VSL, as illustrated in

Figure 26.

Figure 26 Modeling Arrays using MARTE CollectionType (1)

Once you have created a CollectionType (e.g. myArray), you must create its property (e.g. myArrayElement)

(selecting the property icon from the palette) and assign it the desired type and multiplicity using the UML

tab in the properties below.


28


Then, from the properties below, select the Profile tab and set the collectionAttrib to the array’s element

that has just been created as illustrated in Figure 28.


Structures can be modeled by selecting from the palette the TupleType from MARTE VSL as illustrated in

Figure 29.


29

Figure 29 Modeling Structures using the MARTE VSL TupleType (1)

Once you have created a TupleType (e.g. MyStructure), you must create its fields (Properties), and assign

them the correct type from the UML tab in the properties below, as depicted in Figure 30.


Finally, once you have created the needed fields, assign the tupleAttrib to the newly created fields from the

Profile tab in the properties below, as depicted in Figure 31.


30


9.3.3.2 ComponentTypes

To create a ComponentType:

Open a Class Diagram

Select ComponentType from the CHESS Funct View palette and click on the diagram

o Give a proper name to the ComponentType

Needed FlowPorts are created and typed for the Component Type in its Composite Structure Diagram.

To create a FlowPort for a ComponentType:

Select the ComponentType from the Model Explorer

Create its Composite Structure Diagram (right-click->Create new Diagram->Composite Structure

Diagram)

Select IN Flow Port or OUT Flow Port icon from the CHESS FunctView palette

Click on the border of the ComponentType

9.3.3.3 Interfaces

For each Component Type, provided and/or required Interfaces are also modeled in the Component View

with the offered operations and parameters.

To create an Interface for a ComponentType:

Open a Class Diagram For instance the one where the ComponentType is depicted

Select the Interface icon from the CHESS FunctView palette

Click in the Class Diagram

Give a proper name to the Interface

To create a ClientServerPort for a ComponentType:

Open the Composite Structure Diagram of the ComponentType

Select the Provided Port or the Required Port icon from the CHESS FunctView palette


31

Click in the Composite Structure Diagram inside the ComponentType

Select “Profile” Tab, select the ClientServerPort applied stereotype

Set the value of property “provInterface” or “reqInterface” (according to the value of the

“kind”property) selecting an interface from the dialog window as shown in Figure 33.

The last step will automatically create and link in the model the ComponentType and the Interface

with a Dependency (required Interface ) or with an InterfaceRealization (provided Interface). Dependency

and InterfaceRealization can be shown in the diagram by drag and drop them from the model browser to

the diagram.

Figure 32: Interface dependencies and realizations

Operations are defined for the Interfaces by selecting the “Operation” icon from the CHESS FunctView

palette and clicking in the operation area of the Interface. If a ComponentType is linked with an

InterfaceRealization to that Interface, the Operation is also automatically added to the ComponentType.

Changes in the Operation name and parameters (name, type and number) are propagated to the linked

ComponentType’s Operation.


32

Figure 33 Selection of Provided (or Required) Interface for a Client Server Port

9.3.3.4 ComponentImplementations

To create a ComponentImplementation:

Open a Class Diagram

Select ComponentImplementation from the CHESS FunctView palette and click on the diagram

o Give a proper name to the ComponentImplementation

Select Realization from the CHESS FunctView palette and trace the link from the

ComponentImplementation to the ComponentType that it is supposed to implement.

The last step will automatically propagate the Ports and the Operations of the ComponentType to

the ComponentImplementation. Changes in the Operations of the Interface are propagated also to

the ComponentImplementation.

9.3.3.5 Modeling the SW instances

UML defines the concept of InstanceSpecification to represent an instance of a given entity (e.g. SW or

HW component). Currently in the tool, components instances can be automatically obtained starting from

the specification of the components themselves. In particular instances owned by a given component can

be represented through UML Composite structure diagrams, so by using the concept of UML part (as part

of a composite component). So starting from a given component, the hierarchy of component instances can

be automatically derived according to the decomposition modelled with the composite diagrams. In the

following we will use the terms “instances” and “parts” to refer to the same concept, where not otherwise

specified.

It is possible to model instances owned by a given Component (note: only one level of decomposition for

component) in the following two ways:


33

in a Composite Structure Diagram: drag a ComponentImplementation from the Papyrus Model

Explorer into the Composite Structure Diagram of the containing entity (Component

Implementation) to model its instantiation as a part of it.

In a Class Diagram: drag a ComponentImplementation and the containing entity (Component

Implementation) from the Papyrus Model Explorer into a Class Diagram and draw an Association

link between them, directed from the container to the component implementation. From the UML

tab select the member end corresponding to the component implementation and set Owner to

“Classifier” (and Aggregation to “composite”). This will instantiate the component implementation

in its container.

Note that only one level of decomposition for a given component can be designed by using the

composite diagram.

When the internal structure of each component has been defined, it is possible to derive the Instance

Model, i.e. the corresponding InstanceSpecification representation, by using the dedicated command in the

CHESS main menu in the toolbar.

Note that the InstanceModel allows to properly represent the instances hierarchy at any level of

decomposition, and in particular to represent the proper extra functional information attached to each

instances/ports, at any level of the hierarchy (this is not possible by using the composite diagram only).

Note that the creation of the InstanceModel is a mandatory step in CHESS, given that several design

steps (e.g. the allocation of software to hardware instances) can only be performed by using the entities

available in the InstanceModel.

9.3.3.6 Modeling Operational Modes

Operation modes can be modelled in the FunctionalView by using stereotyped state machine.

To model operational model, assuming to have a root SW component, perform the following steps:

Create a state machine for the component (in the ModelExplorer view, right click on the

component and select “new diagram-> create a new UML state machine diagram”)

Stereotype the state machine as ModeBehavior (by using the Profile tab in the Properties view)

Crete and Initial State

Create additional States, where each State has to be stereotyped with Mode (so each State

represents an operational mode)

Design transition between states; each transition has to be stereotyped with ModeTransition.

Once the modes have been modelled, it is possible to use them for the specification of the extra functional

properties (so the properties can have different values depending on the given mode) and to model mode-

dependent allocation of SW to HW.


34

9.3.3.7 Modelling Timing properties

CHRtSpecification allows attaching real time properties to an operation provided by a

ComponentImplementation instance.

CHESS allows to use Composite Structure Diagrams (CSD) as object view in the context of a given

component (so without the possibility to focus on a given instance in a well identified level of the instance

model hierarchy); in particular in CSD a Property corresponds to a (software or hardware) instance. Then

the Build Instances command can be used to automatically generate the instance model, together with

their extra functional information eventually modelled in the CSD.

Note that in case of multiple instances of the same decomposed component C, the extra functional

information eventually modelled in the composite diagram of C will be replicated for each instances of C:

this is the limitation of the composite diagram wrt the usage of the instance model. To overcome this

limitation the modeller can use the InstanceView (see section 9.3.4).

So we can state that the usage of CSDs for extra functional annotation upon instances works well for

a given system with only one level of decomposition (i.e. the root system entity together with the owned

components instances).

To create a CHRtSpecification in a composite structure diagram the extra functional view has to be

activated in the ComponentView.

Once the CHRtSpecification has been created, it must be linked to the target port by using the Link item on

the palette; then the following properties of the CHRtSpecification stereotype must be provided through

the Profile tab in the Properties Eclipse view:

partWithPort (only relevant in CSD): the Property subject of the CHRtSpecification, i.e. the Property

owning the Port which has been linked to the CHRtSpecification

context: the operation which has to be decorated with real time properties. The operation must be

owned by the ComponentImplementation which types the partWithPort. Moreover the operation

must be one which is also defined in the interface which is provided by the port linked to the

ChRtSpecification.


35

relativePriority: an integer that represents the priority of the operation that is decorated with real

time properties w.r.t. the other operations. The higher the value, the higher the priority.

Then real time properties can be set through the following CHRtSpecification stereotype fields by using the

MARTE (VSL) language:

occKind: specifies the activation event for the current operation. It can be periodic or sporadic, e.g.:

o periodic(period=(value=125.0,unit=ms) ), phase=(value=10,unit=ms)2))

o sporadic(minInterarrival=(value=125.0,unit=ms))

localWCET: the worst case execution time for the given operation, e.g. (value=45.0,unit=ms)

protection: must be set to

o sequential (for cyclic or sporadic operation)

o guarded (for protected operation)

rlDl: the deadline, e.g. (value=125.0,unit=ms)

Figure 34: Working with the CHRtSpecification in the CSD (as instance view)

The properties of the CHRtSpecification can be edited through the CHESS tab available on the Property

view.

2 The “phase” attribute is optional


36

Figure 35: CHESS tab for the CHRtSpecification

Once the Real Time properties have been modelled as described above, the component instances

need to be created (or simply updated) through the Build Instances Command.

9.3.3.7.1 Querying the timing properties

The real time properties attached to the generated InstanceSpecification can be retrieved in a dedicated

tab-view by selecting the InstanceModel package (the one automatically generated by the Build Instances

Command and stereotyped with <<CHGaResourcePlatform>>) owning the InstanceSpecifications, or

selecting one instanceSpecification.

Figure 36: CHRtSpecification property tab


37

9.3.4 Instance View

The InstanceView can be activated by the Eclipse ShowView menu

Figure 37: InstanceView

The InstanceView can be used to navigate the instances model, the latters as built with the Build Model

Instances command. The InstanceView offers a customized view of the UML instances model, allowing to

represent components instances hierarchies, component ports instances and referred operations through

an intuitive representation Figure 38.


38

Figure 38: Reading with the InstanceView

Double click an item in the InstanceView to make it the current selection in Papyrus (Model Explorer and

diagram, the latter if available) Figure 39.


39

Figure 39: Reading with the InstanceView - hyperlinks

The InstanceView can be used to create CHRtSpecification for a given Operation owned by an Instance

(right click on the Operation and select the kind of decoration to be applied (Figure 40); the operation can

be public or private. A public operation is showed under the port instance which provides the interface

where the operation itself is defined, while private operations appear under the component instance (see

Func3 in the following figure).


40

Figure 40: Creating with the InstanceView

A selection made in the InstanceView becomes the current selection for the other Eclipse views; in

particular the Properties View is updated as well, to allow viewing/updating the properties for the selected

item (Figure 41).

Figure 41: Updating with the InstanceView

9.4 Deployment View The Deployment View is actually composed by two sub-views, the Deployment View (enabled by default)

and the Dependability View.


41

9.4.1 Diagrams


Class Diagrams are used in the deployment view to model:

packages

hardware components

data flow ports

Figure 42 Designing Packages in a Class Diagram in the Deployment View

Figure 43 HW Types in a Class Diagram in the Deployment View

Stereotypes such as <<statefulHardware>> can be applied only from the Dependability View.

To activate the Dependability View toggle the “Activate Dependability View” button, see Figure 44.

Figure 44 Dependability View Activation

9.4.1.2 Composite Structure diagram

Composite Structure diagrams for a given hardware component are used to model:

hardware components instances and connectors owned by a given component


42

Figure 45: Composite Structure Diagram in the Deployment View

CompositeStructure diagrams in this view are also used by the tool to automatically build the hardware

InstanceSpecifications, with the proper extra-functional information attached, through the Build Instances

command from the CHESS Context menu.

9.4.2 Modeling the HW entities

HW entities are initially defined at classifier level in the DeploymentView (or in its sub-packages) by

creating UML::Component and applying stereotypes coming from a set composed of some defined in

CHESS and some others coming from the MARTE::HRM sub-profile, available from the Deployment View

Palette (Figure 46) for Class Diagrams.

Figure 46 Deployment View Class Diagram Palette

9.4.3 Defining the number of cores for a processor

It is possible to define the number of cores that constitute a processor, by assigning the desired value to

the “nbCores” field of the component stereotyped as <<CH_HwProcessor>> in the Deployment View.


43

This operations is completed when the Build Instance command is invoked from the Context Menu (see

Figure 47) and the actual HwSystem Instance Specification is created with its defined cores.

Figure 47 Build instances for HW System

Notice: if the user decreases the number of cores that constitute a processor, active verification is carried

out to request user’s confirmation to delete all assignments (Partition to Core Assignment and Task to Core

Assignment) to the processor whose number of cores has been decreased.

9.4.4 Modeling Memory Partitions

MemoryPartition (from MARTE) represents a virtual address space which insures that each concurrent

resource associated to a specific memory partition can only access and change its own memory space.

MemoryPartitions are created in the deployment view, first at type level in a class diagram, together with

the HW types, in particular processors and physical memories, and then at instance level using the

composite diagram; see Figure 48 and Figure 49 as example.


44

Figure 48: modelling HW types

As an example, in Figure 49 the MARTE HwComputingResource stereotype (as extension of Component) is

used to model a HW entity (ECU) composed by one CPU (CH_HWProcessor) and RAM (HWRAM.

The MemoryPartition is instantiated through the composite structure diagram (see Figure 49), together

with the HW components.

Memory Partitions instances must be modeled inside a container which also contains the associated

Processor instance.

To allow the specification of MemoryPartition properties at instance level, in the composite diagram the

MemoryPartition stereotype has to be manually applied to the properties representing the

MemoryPartitions.

MemoryPartition instances are bound to the given HW memory through the Allocate MARTE relationships.

The MemoryPartition stereotype comes with the MemorySizeFootprint property which can be used to set

the size of the partition, in particular the percentage of the HW memory which is reserved. The


45

MemorySizeFootprint property can be specified by creating an OpaqueExpression (e.g. named size) and

then using natural language to provide its value (see bottom part of Figure 49).

Figure 49: HW instances, MemoryPartition instances and allocations

MemoryPartition component (not instances but classifier) can be decorated with criticality level (e.g. ASIL)

by using the CriticalitySpecification entity (see section 13.1).

Regarding the SW to HW allocation:

SW components are allocated to cores. In case of MemoryPartitions associated to the processor the proper

allocation of the SW component instances to the MemoryPartition instances (of the same HW computing

resource) is not explicitly modelled; it is automatically derived according to the criticalities of the SW

components (typing the instances) and the criticality of the MemoryPartitions.

9.4.5 Allocating SW instances to HW instances

CHESS allows specifying SW to HW deployment by using the Assign MARTE stereotype.

See section 14.1 for Avionics specific customization for SW to HW allocation.

9.4.5.1 Multicore Support Wizard

The wizard presented in this section allows to model the SW to HW instances allocation using a dedicated

wizard; the creation of the Assign entities in the model is done automatically by the tool. The Assign can be

showed in a given diagram by drag&drop them from the ModelExplorer to the diagram itself.

9.4.5.1.1 Assign Components to Cores

In order to assign components to cores: under the “CHESS” command button, select “Multicore Support”

and then “Assign Components to Cores”. This will open a form that allows to assign the Component

Instances (listed on the left side) to the processor’s cores (on the right side), as illustrated in Figure 50.


46

Figure 50 Assign Components to Cores Wizard

9.4.5.1.2 Assign Tasks to Cores

In order to assign tasks to cores, under the “CHESS” command button, select “Multicore Support” and then

“Assign Tasks to Cores”. This will open a form that allows to assign the tasks (listed on the left side) to the

available instances of processor’s cores (on the right side), as illustrated in Figure 77Figure 76.

Figure 51 Assign Tasks to Cores Wizard

9.4.5.1.3 Generate Task to Core Assignments

In order to generate task to core assignments, under the “CHESS” command button, select “Multicore

Support” and then “Generate Task to Core Assignments”. Task to core assignments are generated

according to the Reduction to Uniprocessor algorithm [xxxxxxx]

<TBW>

9.4.5.2 Manually creating the Assign entities

Assign entity can be created in the DeploymentView, e.g. by using the composite structure diagram.

Assign comes with from and to fields which can be set through the MARTE or Profile tab of the

Eclipse Properties view. To specify the allocation of a SW instance to an HW instance:


47

from must be set with the proper SW instance (the one created with the Build Model

Instances command)

to must be set the proper HW instance (the one created with the Build Model Instances

command)

Next figure shows an example of Assign used to model the allocation of the instances showed in

Figure 57; note that the Build Model Instance command has been invoked on the System entity in

order to have the System_CPU0_inst instance available to be referred in the Assign.to field.

Figure 52: Modeling the SW to HW allocation

9.4.5.3 Specifying the Operational Mode

In case of a system with different operational modes it is possible to define different software to

hardware allocations scenarios, one for each operational mode. In this case the MARTE Assign,

already created to model allocations, can be constrained by the MARTE NFPConstraint construct,

where the latter allow specifying the mode on which the given Assign has to apply. For example, in

Figure 5 the allocation of the component instances to the processing resource CPU0 for only the

NormalMode operational mode is modelled.


48

Figure 53: modelling Allocations constrained to OperationalModes

9.5 Analysis View

9.5.1 Dependability View


Class diagrams in the Dependability View are used to model dependability analysis contexts, as depicted in

Figure 54. See section 16.3 for details on the dependability analysis.

Figure 54 Class Diagram to model dependability concerns in the Analysis View

9.5.2 RT Analysis View

Class diagrams in the RTAnalysisView are used to model timing analysis contexts. See section 16.2 for

further details.

10 The instances model Hardware and Software Instances owned by a given component in CHESS can be modeled in the

Deployment and ComponentView respectively through the Composite Structure Diagram, i.e. through

Properties. Each Property comes with its ports, i.e. the ports defined for the Component which types the

Property itself. Properties can be connected together through the ports by using the Connector.


49

UML provides a dedicated set of constructs which can be used to model instances and their properties,

basically the InstanceSpecification and Slot; however there is not a dedicated UML diagram that can be

used to properly work with them to easily model instances of components, ports and connections.

Composite Structure Diagrams come with some limitation concerning the modeling of instances (see

section 9.3.3.7), in particular hierarchical instances with extra functional annotation; so all the information

appearing in the Composite Structure Diagram need to be properly represented in the model by using UML

InstanceSpecifications and Slot entities.

The CHESS toolset allows to automatically derive the InstanceSpecifications and Slot entities by starting

from a root component. In particular each Property and Connector is mapped onto a dedicated

InstanceSpecification, while Ports are mapped onto Slot. Extra functional information (if available, e.g.

modelled in the composite diagram) is attached to InstanceSpecifications and Slots.

To invoke the Build Instance command:

from the Model Explorer, select the CHGaResourcePlatform that represents the SW System (in the

Component View), or the CHGaResourcePlatform that represents the HW configuration on which

the system is deployed (in the Deployment View) as the root entity for which the instance model

has to be created and right click on it,

select the command CHESS-> Build Instances.

Notice that Build Instances must be invoked both for the SW system (Figure 55) and for the HW system

(Figure 56). Different HW systems can be defined (with their corresponding instances created by means of

the Build Instances command) in order to model different deployments of the system and perform

separate analysis on each of the different deployments, for comparing them and identifying the best

deployment configuration.


50

Figure 55 CHESS Build Instances command for Sw System


51

Figure 56 CHESS Build Instances command for HW System

then the InstanceSpecifications/Slots are generated in a dedicated package which is created in the model at

the same level of the selected root entity.

The Next figure shows the instances generated; in particular see the SwSystem_instSpec package in the

Model Explorer. It is possible to see the instance related to the SwSystem entity and the instances related

to the owned Properties (i.e. the ones named SwSystem_Producer_inst, SwSystem_Consumer_inst and

SwSystem_Store_inst); the unnamed instances are the ones related to the designed connectors.


52

Figure 57: Instances specifications

See section 9.3.4 about the InstanceView.

11 Modeling the Data Flow DataFlow between system, software and hardware components can be modeled in the SystemView,

ComponentView, DeploymentView respectively by using ports stereotyped as FlowPorts (from SysML, in

the SystemView, or MARTE, in the Component and DeploymentView).

A special case regards the usage of flow ports in the Component View to model data-flow between

ComponentImplementations.

According to the current CHESS component model definition, data flow ports are not considered during the

PSM generation, i.e. the generation of Containers and Connectors; in other words data-flow ports do not

have support at code generation level. However the design of data-flow for ComponentImplementations is

allowed in CHESS because it can be a useful modelling step, especially in the preliminary phase of the

software design, for instance as derived from a system one; then, in order to complete the software design,

the modeller has to create provided/required operations ports for the ComponentImplementations. The

operations parameters allow to actually implement the data flow originally modelled for the

ComponentImplementations through the data-flow ports.

So CHESS requires that data-flow ports implementing data flow between ComponentImplementation must

be allocated to operations parameters; a FlowPort owned by a ComponentImplementation should be

mapped to an existing ClientServerPort of the component itself in order to model how the flow of data for

the component is actually realized through its provided and required operations.


53

The mappings can be modeled using the “Port” tab in the Property View: Select a FlowPort in the

editor, choose an operation from a provided or required interface and select a parameter that shares the

same type as the FlowPort. The mapping will be created and displayed in the tab.

Note that the latest version of the CHESS component model includes event data ports, this kind of ports

does not need to be allocated to operations parameters.

Figure 58 Mapping a Flow Port to a Client Server Port

12 Working with Contracts Contracts can be created in a BDD (SystemView) and in a Class Diagram (Component and Deployment

View).

To create a Contract:

Open a BDD/Class diagram

Select Contract from the Forever/Contract palette and click on the diagram

o Give a proper name to the Contract


54

The tool automatically creates Assumption and Guarantee FormalProperties for the just created

contract.

The Assumption and the Guarantee properties for a given Contract can be specified in a given language

(e.g. Othello, see section 16.4) through the dedicated Contracts tab in the property editor (Figure 59). To be

able to use the Contracts tab:

Select the Contract to edit, or

Select the Block/Component and then select the ContractProperty (see below) from the

ContractList in the Contracts tab.

Figure 59: Editing the Contract’s Assume and Guarantee

Information about the requirements formalized by the contract can be specified through the corresponding

Contract stereotype attribute available in the Profile tab of the Property view (see next figure).


55

Figure 60 Contract and its properties

To associate a Contract to a Block/Component the following actions need to be performed3:

Create a ContractProperty inside the Block/Component (the ContractProperty acts as a special

attribute of the Block/Property)

Type the just created ContractProperty with the Contract.

3 Note that this is the same approach as used in SysML for the application of a ConstraintBlock to a given Block.


56

Figure 61 ContractProperty

The ContractProperty stereotype comes with the attribute ContractType which can be used to set the

Strong or Weak property of the Contract [1]4 (see Figure 62).

Figure 62 Modelling Weak/Strong Contract

12.1.1 Selection of weak contract for Block/Component instances

While a strong contract associated to a Block/Component (must) hold for all the instances of the

Block/Component, a weak contract associated to a Block/Component can hold for a given instance of the

Block/Component if the environment where the instance is placed met the assumption. So for a given

4 From [1]: “While the strong assumptions and guarantees must be satisfied always in order for component to be

used, the weak pairs offer additional information in some specific contexts where besides the strong assumptions, the weak assumptions are to be met as well.”


57

instance it has to be possible to specify the set of weak contracts specified for the typing Block/Component

(if any) which hold for the instance. To do so, the following steps have to be performed:

Select the instance in the internal block diagram / composite structure diagram.

Apply the ComponentInstance stereotype to the instance.

Select the Contract tab in the properties editor (see Figure 63): the Contract tab shows the strong

and weak contract inherited by the classifier typing the instance. In particular the Weak Contract

area can be used to check the weak contracts that hold for the current instance.

Figure 63: Contract tab for instances

The information about the weak contracts which hold for the given instance is automatically set in the

WeakGuarantees attribute of the ComponentInstance stereotype (Figure 64).


58

Figure 64: ComponentInstance stereotype

12.1.2 Contract Refinement

Once a model component that has a contract has been decomposed, it is possible to define the contract’s

refinement. The refinement of a contract can be specified following these steps:

Select a ContractProperty of a Block

Right-Click and select Formal Verification -> Set Contract Refinement


59

Figure 65 Set Contract Refinement Command

In the new dialog window select the Contract Properties from the list (CTRL-A selects all) and click

OK. This dialog window shows the Contract Properties in the format:

InstanceName.ContractProperty. This allows the selection of instance-based Contract Properties

(instead of type-based).

Figure 66 Refinement Selection

Be sure that the Aggregation kind of the instances is set to composite as shown in the bottom-right

part in the figure below. This is required to let Set Contract Refinement command to work properly.


60

Figure 67: Composiste Aggregation

The information about the refinement is set in the RefinedBy attribute of the ContractProperty

stereotypey of a Block and available in the Profile tab of the Property view:

Figure 68 Contract Refinement

See also Appendix 18.1 for more details about the use of Contracts.

12.1.3 About FormalProperties

As previously stated FormalProperties (i.e. the entities which play the role of Assumption and Guarantee in

a Contract) are automatically created by the tool when a Contract is created.

In alternative FormalProperties can be creates manually (see following section) by using the dedicated tool

in the palette. Then, to specify an Assume (or Guarantee) FormalProperty for a given Contract:

Select the Contract, open the Profile tab in the Property view and set the Assume (or Guarantee)

attribute of the Contract stereotype to the (previously created) FormalProperty.

It is also possible to package a FormalProperty in a Contract by creating the former directly in the latter.


61

To create a FormalProperty in a BDD/Class diagram:

Select FormalProperty from the Forever/Contract palette and click on the BDD

o Give a proper name to the FormalProperty

To create a FormalProperty packaged in a Contract:

Select FormalProperty from the Forever/Contract palette and click on the Contract

o Give a proper name to the FormalProperty

To associate an expression to the FormalProperty:

Select the FormalProperty

In the UML tab of the Properties view edit the current value of the Specification field and provide

the expression in the Value field

Figure 69 Creating a Formal Property

13 Modelling Dependability CHESS toolset allows to work with the CHESS dependability profile.

Basically stereotypes to model failure modes, failure propagation in a qualitative and quantitative way are

available.

more information about dependability profile usage will come soon.


62

13.1 Modeling Criticality

13.1.1 Modelling the criticality level

Criticality levels have to be defined first, according to the new Dependability Profile, e.g. according to the

standard/domain of interest (see typical automotive example in Figure 70).

Figure 70 ASIL Levels definition example

Then criticality can be assigned to entities, e.g. requirements, SW components and HW component using

the CriticalitySpecification stereotype.

Notice that the isHigherThan attribute of CriticalityLevel X must contain the list of all the

CriticalityLevels that are lower than X (as illustrated in the example in Figure 70)

Criticalities must be assigned at classifier level (e.g. ComponentImplementation,

CH_HWComputingResource, MemoryPartition). Criticalities assignment at instance level (e.g. SW

component instances, HW instances) is not currently supported.


63

Figure 71: Criticalitites specification

Different levels of criticality can be related to different operational modes: this is modeled by adding an

NfpConstraint specification stereotype to the CriticalitySpecification, as illustrated in Figure 72.


64

Figure 72 Criticality specification with mode

If a Multi-core Processor has different Criticalities for the different Cores, then the Core to which it is

related must be specified in the Specification field, as a Literal String Value (see Figure 73).

Figure 73: Assigning criticality to a Core


65

13.1.2 CriticalityInterfaceSpecification

Regarding SW components instances, CriticalityInterfaceSpecification stereotype can be used to constrain a

given provided port/interface, in particular to constrain the criticalities that clients must have in order to be

able to access the given provided port/interface.

Figure 74: CriticalityInterfaceSpecification

Different levels of criticality can be related to different operational modes: this is modeled by adding an

NfpConstraint specification stereotype to the CriticalityInterfaceSpecification, as illustrated in Figure 75


66

Figure 75 Criticality Interface Specification with Mode

Note: several constraints can be checked via model validation based on the criticality levels (and

operational modes) assigned to the model elements (see details in 15.2).

13.2 Editing Failure Propagation rules with XText (content assistance) In order to use Xtext features in a CHESS project (or in any project) it is necessary to add the Xtext nature to

it. This can be done from the Project Explorer view of Eclipse by right clicking on the project and selecting

configure->Add Xtext Nature (ignoring possible errors in the Problem View).

Open the CHESS model and select a Component stereotyped as FLABehavior and activate the Extra-

Functional View to edit dependability properties.

Open the CHESS Property tab:

The FPTC property (in red) can be edited clicking the highlighted (in green) Edit button:


67

13.2.1.1 Xtext Features

The editor widget allows the editing of the property with the Xtext support. Press CTRL+SPACE to activate

context assist:

Context assist works for both referring CHESS model elements (Ports in the example) and for selecting

enumeration literals:


68

When “OK” is pressed, the expression is written in the model as shown in the CHESS property tab:

The Xtext-enriched Editor can also highlight errors in the expression (according the defined grammar), for

example, the following expression is missing the closing semicolon:

14 Domain specific modeling This section introduces some domain specific features.

14.1 Avionics

14.1.1 Creating functional partitions

IMA Functional partitions can be modeled in the Component View. In order to model functional partitions,

first of all it is necessary to create a Package named “FunctionalPartitions” inside the Component View. To


69

create a functional partition, simply create a Component in the FunctionalPartitions Package and then

apply the Stereotype <<CHESS::ComponentModel::FunctionalPartition>>. The functional partitions must

then be instantiated as part properties in the <<CHGaResourcePlatform>> Component that represents the

SWSystem in the Component View.

These operations are completed when the Build Instance command is invoked and the actual SwSystem

Instance Specification is created with its defined functional partitions.

Notice: if the user deletes a functional partition that is part of the <<CHGaResourcePlatform>> Component

that represents the SWSystem in the Component View, active verification is carried out to request user’s

confirmation to delete all assignments that involve the functional partition that has been deleted either in

the To field (Component to Partition Assignment), or in the From field (Partition to ProcessorAssignment).

14.1.2 IMA Partitions Support Wizard

14.1.2.1 Assign Components to Partitions

In order to assign components to functional partitions: under the “CHESS” command button, select “IMA

Partitions Support” and then “Assign Components to Partitions”. This will open a form that allows to assign

the Component Instances (listed on the left side) to the functional partitions (on the right side), as

illustrated in Figure 76.

Figure 76 Assign Components to Partitions Wizard

The current implementation does not support resource sharing between partitions.

14.1.2.2 Assign Partitions to Cores

In order to assign functional partitions to cores, under the “CHESS” command button, select “IMA Partitions

Support” and then “Assign Partitions to Cores”. This will open a form that allows to assign the functional


70

partitions (listed on the left side) to the available instances of processor’s cores (on the right side), as

illustrated in Figure 77Figure 76.

Figure 77 Assign Partitions to Cores Wizard

14.1.2.3 Generate Partitions schedule

In order to generate functional partitions schedule, under the “CHESS” command button, select “IMA

Partitions Support” and then “Generate Partitions schedule”.

<TBW>

14.1.3 ARINC Processes

This section provides an example of application of the ARINC related stereotypes.

Figure 78 shows the usage of the ARINCComponentImpl stereotype applied to a

<<ComponentImplementation>> Component owning one <<ARINCProcess>> and three <<ARINCFunction>>

public operations.


71

Figure 78: ARINCComponentImpl

Figure 79 below shows how additional real time properties can be set for the ARINCProcess and the

ARINCFunction operations for a given ARINCComponentImpl component instance, according to the CHESS

profile for ARINC; in particular real time properties are provided through the CHRtSpecification stereotype.


72

Figure 79: providing real time properties for ARINCProcess and ARINCFunction operations

14.2 Automotive

14.2.1 AUTOSAR generation

The AUTOSAR ARXML representation of the software applicative level and the HW to SW allocation

modelled in CHESS can be automatically generated from the CHESS->AUTOSAR integration-

>CHESS2AUTOSAR transformation command.

The generated ARXML can then be fed in input to an AUTOSAR tool to extract the ECUs configuration file.

Details about the implemented mapping will be released soon.

15 Model validation Different types of model validation are provided by the CHESS toolset.

In order to perform model validation starting from a selected entity and all its owned ones, from the

Papyrus Model Explorer select the Model or the entity on which the validation must be performed, right

click and choose:

Validation-> CHESS->Validate core constraints->: performs checks to enforce the CHESS

methodology constraints (including specific preconditions as required by the schedulability

analysis).

Validation->CHESS->Validate model for State Based analysis

Validation->CHESS->Validate model for NuSMV3 analysis tool


73

Validation->CHESS->Validate model for Criticality Specification

Validation->CHESS->Validate model for Automotive 26262 compliance: checks the correctness of

ASIL inheritance and ASIL decomposition in the in the System and Requirements Views according to

the ISO 26262 standard.

15.1 Configuring the CHESS model validation features It is possible to configure which model validation features are enabled in CHESS by selecting from the

Eclipse commands bar “Window”->”Preferences”->”Model Validation”->”Constraints”->”CHESS Model

Constraints”, and finally selecting the constraints to be enabled.

In the following a brief description of the constraints grouped by category.

15.2 CHESS Criticality Validation

15.2.1 Connection (CV_1)

Check that connections between a provided port and a required port are allowed: the Criticality Interface

Specification assigned to the provided port (called “AcceptedCriticalityForClients” which describes the

criticality level accepted for clients) must be identical to the Criticality Specification assigned to the

classifier (type) of the component that owns the required port. The criticality cannot be undefined. If

Operational Modes are specified, this constraint must hold for each Operational Mode.

This constraint has error severity and executes in batch (on-demand) mode.

Modelling assumption: we assume that Criticality Interface Specification of a port is modelled in the

Composite Structure Diagram. We assume that the Criticality Specification is modelled for the Component

Implementation that types the component implementation.

15.2.2 Component that owns a provided port (CV_2)

Check that ownership of provided ports is allowed: the owner of a provided port must have at least the

same Criticality Level as the Criticality Interface Specification assigned to the provided port (which describes

the criticality level accepted for clients). The criticality cannot be undefined. If Operational Modes are

specified, this constraint must hold for each Operational Mode referred by the Criticality Interface

Specification (i.e. it is allowed that the component providing the port/interface refers additional

Operational Modes not considered by the Criticality Interface Specification, while the opposite it is not

allowed).

Modelling assumption: we assume that Criticality Interface Specification of a port is modelled in the

Composite Structure Diagram.

15.2.3 Assignment of Components to Cores: check on Memory Partitions (CV_3)

Check that the assignment of a SW component instance to a Core is allowed: when a SW component

instance is assigned to a Core, check that the classifier of the Processor (owner of the Core) where the

component instance is assigned must have a Memory Partition whose Criticality Level is the same as the

Criticality Level associated to the classifier (type) of the component instance. The criticality cannot be

undefined. If Operational Modes are specified, this constraint must hold for each Operational Mode (there

must be a single Memory Partition that satisfies this constraint for all Operational Modes).


74

Modelling assumption: we assume that a <<CH_HwComputingResource>> Processor instance is modelled

inside a container which also contains all of the Processor’s Memory Partitions instances.

Modelling assumption: we assume that the Criticality Specification of a Memory Partition is defined at

classifier level.

15.2.4 Assignment of Component to Core (CV_4)

Check that the assignment of a SW component instance to a Core is allowed: when a SW component

instance is assigned to a Core, check that the classifier of the Processor (owner of the Core) where the

component instance is assigned has the same criticality level associated to the Core as the classifier of the

SW component instance. Notice that a Processor can have multiple criticality levels associated to a Core

(even for the same Operational Mode). In this case the validation checks that one of the criticality levels

associated to the Core is the same as the SW component instance’s classifier. The criticality cannot be

undefined. If Operational Modes are specified, this constraint must hold for each Operational Mode. If an

Operational Mode is specified for the allocation, then this constraint must hold for such Operational Mode

only.

Modelling assumption: we assume that if a Multi-core Processor has different Criticalities for the different

Cores, then the Core to which it is related is specified in the Specification field, as a Literal String Value (see

Figure 73).

15.2.5 Access of a Component to a Device (CV_5)

Check that the direct access of a SW component instance to a Device is allowed: when a SW component

instance is connected to a DeviceBroker instance, check that the HW device linked to the DeviceBroker has

the same criticality level as the classifier of the SW component instance. The criticality cannot be

undefined. If Operational Modes are specified, this constraint must hold for each Operational Mode. If an

Operational Mode is specified for the SW to DeviceBroker connection, then this constraint must hold for

such Operational Mode only.

Modelling assumption: we assume that direct access of a SW component to a Device is modeled using the

MARTE DeviceBroker entity. A DeviceBroker component is a logical entity (e.g. a driver) which is used to

make the hardware devices accessible for software components. DeviceBrokers components are modelled in

the ComponentView, together with the application SW components. Each DeviceBroker is associated to one

or more Hw Devices (the latter modelled in the DeploymentView). Once defined, DeviceBroker components

can then be instantiated and connected together with the other application SW components instances. The

modelling of a connector link between a SW component A and a DeviceBroker B means that the component

A needs access to the device linked to the DeviceBroker B. As for allocations, also the connection between

SW components and DeviceBrokers can be constrained to be allowed for some given operational modes

only.

15.3 Functional View (included in “Core Constraints”)

15.3.1 Provided/Required ports of Interfaces (Connector_01)

Check if Interfaces provided and/or required in Ports are not compatible, or components are not at the

same level.


75

This constraint has warning severity and executes in live (automatic) mode.

15.3.2 Connector: FlowPorts compatibility of direction (Connector_02)

Check that flow ports on the ends of a connection have compatible directions (i.e. the directions are

opposite, or the connection is a delegation and the directions are the same).

This constraint has error severity and executes in live (automatic) mode.

15.3.3 Connector: FlowPorts compatibility of type (Connector_03)

Check that flow ports on the ends of a connection are compatible in type.


15.3.4 FlowPorts not mapped on req/prov operations (FlowPorts_01)

Check that the FlowPort is not mapped to a parameter of a required or provided operation

This constraint has warning severity and executes in batch (on-demand) mode.

15.3.5 FlowPorts parameters type compatibility (FlowPorts_02)

Check that the FlowPort should be mapped to parameters of the same type.


15.3.6 FlowPorts parameters direction compatibility (FlowPorts_03)

Check that the FlowPort should be mapped to parameters according to their directions, i.e.:

port direction IN -> param direction IN or INOUT (param of PROVIDED operation)

port direction OUT -> param direction OUT or INOUT (param of PROVIDED operation)

port direction IN -> param direction OUT or INOUT (param of REQUIRED operation)

port direction OUT -> param direction IN or INOUT (param of REQUIRED operation)

port direction INOUT -> param direction IN or OUT or INOUT (param of REQUIRED or PROVIDED

operation)


15.3.7 ComponentType Interface (FV_02)

Check if the ComponentType does not provide an Interface.


15.3.8 ComponentImplementation realization (FV_03)

Check that:

the ComponentImplementation must realize exactly one ComponentType

the ComponentImplementation must define the same operation as the ComponentType it realizes



76

15.3.9 ClientServerPort (FV_05)

Check that the Port must be stereotyped by ClientServerPort FlowPort


15.3.10 ClientServerPort SPEC_KIND (FV_06)

Check that the value of ClientServerPort stereotype's attribute SPEC_KIND must be set to INTERFACEBASED


15.3.11 ClientServerPort with kind PROREQ (FV_07)

Check that the ClientServerPorts with kind PROREQ are not allowed in ComponentTypes and

ComponentImplementations


15.3.12 Interfaces (FV_08)

Check that Interfaces should be created only in packages that are descendants of the root package with the

stereotype CHESS::ComponentView


15.3.13 Operations (FV_09)

Check that the Operations should be created only in packages that are descendants of the root package

with the stereotype CHESS::ComponentView


15.4 Extra-Functional View (included in “Core Constraints”, for schedulability

analysis)

15.4.1 CHRTSpecification Context (EFVRT_01)

Check that the attribute 'context' of CHRtSpecification must be set to an operation of the component (e.g.

not of the interface).


15.4.2 CHRTSpecification occKind(EFVRT_02)

Check that the attribute 'occKind' of CHRtSpecification must be set or protection must be 'guarded' or

'concurrent'.


15.4.3 CHRTSpecification PeriodicPattern (EFVRT_03)

Check that the in CHRtSpecification, if occKind is Priodic, then the attributes 'period' and 'WCET' and 'relDl'

must all be >= 0



77

15.4.4 CHRTSpecification PeriodicPattern (EFVRT_04)

Check that in CH_RtSpecification if occKind= Periodic, then phase (if present in occKind) and relativePriority

attributes must both be >= 0


15.4.5 CHRTSpecification partWithPort (EFVRT_05)

Check that CHRtSpecification partWithPort attribute must not be null.


15.4.6 CHRTSpecification SporadicPattern (EFVRT_20)

Check that In CH_RtSpecification if occKind=SporadicPattern, then minInterarrival, WCET and relDl

attributes must all be >= 0


15.4.7 CHRTSpecification priority (EFVRT_30)

Check that CH_RtSpecification if occKind=SporadicPattern, then if relativePriority is set, it must be >= 0


15.4.8 CHRTSpecification localWCET (EFVRT_40)

Check that CH_RtSpecification attribute localWCET must be >= 0


15.5 Deployment View (included in “Core Constraints”)

15.5.1 Component Implementation deployment (DV_01)

Check that the ComponentImplementation instance must be allocated on exactly one Processing Unit (for

each specified deployment) or one Functional Partition.


15.5.2 Assign must have exactly one “from” and one “to” (DV_02)

Check that the attribute “from” and “to” of stereotype Assign must be valued with exactly one Element.

The value of the attribute 'from' in stereotype Assign must be an instance (InstanceSpecification) of a

ComponentImplementation or of a Functional Partition or a <<CHRtPortSlot>> Slot. The value of the

attribute 'to' in stereotype Assign must be an instance (InstanceSpecification) of a CH_HwProcessor or of a

Functional Partition.


15.5.3 HwBus packett (DV_03)

Check that the attribute HW_BUS_PACKETT of stereotype HwBus must be set.



78

15.5.4 HwBus attributes (DV_04)

Check that the attribute 'speedFactor' of stereotype HwBus is null, default (value=1.0) will be used.

The attribute 'blockT' of stereotype HwBus is null, default (worst=0.0,unit=ms) will be used.

The attribute 'speedFactor' of stereotype CH_HwProcessor is null, default (value=1.0) will be used.


15.5.5 Used Functional Partition allocated on exactly one Core (DV_05)

Check that a Functional Partition that has at least one ComponentImplementation instance allocated on it

is allocated on exactly one Core (for each specified deployment).


15.5.6 Un-used Functional Partition allocated on exactly one Core (DV_06)

Check that a Functional Partition that has NO ComponentImplementation instances allocated on it is

allocated on exactly one Core (for each specified deployment).


15.6 Analysis View

15.6.1 AnalysisView unique package AV_01

Check that there is only one root package of the model on which the stereotype CHESS::AnalysisView is

applied.

This constraint has error severity and executes in live mode.

15.6.2 SaAnalysisContext Platform (AV_03)

Check that the SaAnalysisContext classifier in the Analysis View has its “Platform” property correctly valued

with a CHGaResourcePlatform that is a Package in the Component View.


16 Supported Analysis

16.1 The Analysis Context CHESS uses and extend the support given by MARTE for the specification of the analysis context; the

analysis context is a modelling construct which allows to specify all the input needed to run a given analysis

and in particular it stores the reference to the entities of the design to be considered for the given analysis.

In CHESS the entities of the design which can be subject of the analysis are SW and/or HW components

instances, together with their declared behaviour (if provided), relationships and allocations.


79

Basically CHESS uses the MARTE SaAnalysisContext and introduces specializations of the MARTE

GaAnalysisContext (e.g. StateBasedAnalysis, FailurePropagationAnalysis) construct to allow the

specification of the input needed to run the analysis. In CHESS the set of instances subject of the given

analysis must be grouped under packages stereotyped as CHGaResourcePlatform (automatically built using

the BuildInstance command). CHGaResourcePlatform extends the MARTE GarResourcePlatform stereotype,

in fact the latter cannot be used to group resource instances.

Currently, the following analysis context can be created in the AnalysisView (or in its sub-views):

SaAnalysisContext : needed to run schedulability and end-to-end response time analysis,

StateBasedAnalysis (under DendabilityAnalysisView): needed to run state based analysis

FailurePropagationAnalysis (under DendabilityAnalysisView): needed to run failure propagation

analysis (FPTC and FI4FA).

More information about the aforementioned analysis is provided in the following sections.

For each analysis context a link to the relevant CHGaResourcePlatforms to be considered in the analysis

must be set through the platform attribute: the SW platform instance specification and the HW

Deployment platform instance specification must both be specified.

Different analysis contexts can be defined and saved in the CHESS model, allowing to perform real time

analysis on different deployment configurations and then to compare the analysis results, as described in

the following.

16.2 Timing Analysis

16.2.1 Schedulability Analysis

To run the schedulability analysis real time properties have to be modelled for the software components as

described in section 9.3.3.7.

Moreover component instances need to be allocated to the platform entities in the DeploymentView. Then

a SaAnalysisContext needs to be created in the RTAnalysisView:

create a class diagram in the RTAnalysisView

create a SaAnalysisContext

set the SaAnalysisContext.platform attribute to

o the <CHGaResourcePlatform> Package owning the component instances, as generated by

the Build Instance command and

o the <CHGaResourcePlatform> Package owning the HW component instances where the

SW is deployed, as generated by the Build Instance command.

Notice that multiple SaAnalysisContexts can be created in order to perform schedulability analysis on

different deployment configurations for comparison.


80

Figure 80: Schedulability Analysis Context

Then the Schedulability Analysis may be invoked from the CHESS command menu, by selecting CHESS-

>Analysis->Real Time->Schedulability (VERDE), as depicted in Figure 81.

Figure 81 CHESS Schedulability analysis

If multiple anasysisContexts are present in the model, the user is prompted to specify the one to be

considered for the performing the analysis (see Figure 82).

Figure 82 CHESS Select Analysis Context window

Wait while the analysis is executed (may take some time)


81

Figure 83 Analysis in execution

Finally the results will be visualized in a pop-up window as illustrated in Figure 84.

Figure 84 Schedulability analysis results

The first section of the results window represents the utilization of HW resources, while the second section

details, for each operation, the SW instance that executes it, the calculated response time and the defined

deadline. The Result field indicates whether the deadline will be met or not.

Analysis results can also be showed at any time by selecting the AnalysisContext in the model explorer and

then by selecting the AnalysisContext in the Properties view.


82

Figure 85: Analysis context tab

It is possible to compare the results obtained by the analysis of two different deployment configurations:

once both analysis have been run, selecting the two SaAnalysisContexts and using the Context Menu

Command “Compare Analysis Results” as depicted in Figure 86.

Figure 86 CHESS Compare Analysis Results Command

The analysis results obtained for the different deployments are displayed side by side as illustrated in Figure

87.


83

Figure 87 CHESS Analysis Results Comparison

16.2.2 End2End Response Time Analysis

The process for the End2End response time analysis, briefly described in the rest of the paragraph, follows

the MARTE modeling approach and allows to model and analyze different End2End scenarios.

In order to perform End2End response time analysis on a scenario that has been modeled in a Sequence

Diagram in the Component View (see 9.3.1.5), the following modeling steps must be carried out in the

Analysis View:

1. Under RTAnalysisView, create a Package (e.g. E2E_Analysis_Package in this example) to contain

End2End necessary model elements

2. Apply the <<GQAM>> and <<SAM>> MARTE profiles to the newly created package (Figure 88): they

are respectively the Generic Quantitative Analysis Modeling and Schedulability Analysis Modeling

MARTE packages.


84

Figure 88 End2End Analysis Package

3. Create an Activity Diagram (e.g. E2E_AnalysisActivity) inside the previously created package

(E2E_Analysis_Package). This represents the activity of the End2End analysis

4. Apply the <<GaWorkloadBehavior>> and <<SaEndtoEndFlow>> MARTE stereotypes to the newly

created Activity.

Figure 89 End2End Activity in End2End Analysis Package

5. Specify the end2end Deadline in <<SaEndtoEndFlow>> properties. This represents the timing

requirements to be met


85

Figure 90 Setting the Activity properties for End2End Analysis

6. To model the analysis activity, the simplest case is to model a Call Behavior Action element, in the

newly created Activity Diagram, and specify its Behavior referring to the Sequence Diagram (see

9.3.1.5) that represents the scenario on which the End2End analysis will be executed (e.g.

E2E_SafeMotorStop_Scenario).

Figure 91 Activity Diagram for End2End Analysis

7. Create a Class Diagram and there model a Class to represent the analysis context (e.g.

E2E_AnalysisContext)

8. Stereotype the newly created Class as <<SaAnalysisContext>>

9. Set the <<SaAnalysisContext>> Workload property to refer to the analysis Activity modeled above

(e.g. E2E_AnalysisActivity) (Figure 92)

Figure 92 End2End Analysis Context

10. Invoke the End2End Analysis from the CHESS command menu (Figure 93)


86

Figure 93 End2End Analysis Command

11. Select the context for the End2End Analysis. The dialog offers a choice between all the End2End

Analysis Contexts found in the CHESS model (Figure 94)

Figure 94 End2End Analysis Context selection

12. Wait while the analysis is executed (may take some time)

13. Result appears in a pop-up window (Figure 95) where the first section (HW Resources) is described

in 16.2.1). The second one details the result of the End-To-End Scenario analyzed. The last reports

the response time of those operations in the model not involved in the End-To-End Scenario under

analysis (as in 16.2.1)

Figure 95 End2End Analysis Result pop-up window


87

14. The end2end Response Time property in the Activity <<SaEndtoEndFlow>> is updated with the

analysis results (Figure 96)

Figure 96 End2End Analysis results in Activity diagram SaEnd2EndFlow properties

15. Also the Context is updated with the analysis results (Figure 97)

Figure 97 End2End Context updated with results

End2End response time analysis results are automatically saved as a textual file in the CHESS project (in the

End-To-End_analysis_results folder).

Moreover as for the schedulability analysis, analysis results can be retrieved at any time by selecting the

AnalysisContext in the model explorer or diagram and then selecting the AnalysisContext tab in the

Property View (see Figure 80).

16.3 Dependability Analysis The following dependability analyses are supported:

State-based (see module 05 at http://www.chess-project.org/page/training )

FPTC - Fault Propagation and Transformation Calculus (see module 7A at http://www.chess-

project.org/page/training)

FI4FA - Formalism for Incompletion, Inconsistency, Interference and Impermanence Failures (see

module 7B at http://www.chess-project.org/page/training)

http://www.chess-project.org/page/training





88

FTA – Fault Tree Analysis performed in CHESS integrating the xSAP tool (https://es-

static.fbk.eu/tools/xsap/) is currently under development.

16.4 Performing Formal Verification of Contracts

16.4.1.1 Model Verification

A model verification feature for contracts is available as an early version. It can be launched from the

Model Explorer View by right-clicking on the model and selecting “Check Forever model for NuSMV3

analysis tool”.

Figure 98 Model verification for NuSMV3

It checks if the model can be correctly analyzed by the NuSMV3 tool (see below) and it marks errors found

in the model.


89

Figure 99 Model verification for NuSMV3 results

The constraints that are checked are the following:

For each Block/Component, its attributes must have unique identifiers.

Every Composition between two Blocks/Component must be directed from the parent to the

children.

For each Connection, the two linked ports (stereotyped as <<FlowPort>>) must have compatible

directions

For each Constraint stereotyped as <<FormalProperty>>, its specification must be expressed in the

NuSMV3/OCRA syntax.

Every Port, stereotyped as <<FlowPort>>, must be typed.

According to OCRA1.3 specification, allowed types for properties and ports are boolean, integer,

real, event, continuous, range of integers (to be modelled with BoundedSubtype, see 9.3.3.1),

enumeration; this constraint is not currently checked during the model validation. Table 1 below shows

the mapping between OCRA and CHESS types.


90

Table 1 - CHESS to OCRA data types

16.4.1.2 Contract Refinement Analysis

A contract refinement analysis can be launched from the main menu by selecting CHESS -> Analysis ->

Formal Verification -> Check Contract Refinement Analysis.

Figure 100 Contract Refinement Analysis

CHESS Type OCRA Types

PrimitiveType named boolean boolean

PrimitiveType named integer Integer

PrimitiveType named real Real

Signal Event

DataType named Continuous Continuous

BoundedSubType with

baseType=Integer and MinValue

and MaxVAlue set

range of integers

Enumeration (owning

EnumerationLiterals)

list symbolic constants

Enumeration (temp solution) list of integers


91

A dialog window will allow the user to select the root of the system to be analyzed.

Figure 101 System Root Selection

The execution of the command will then create files and folders under the current project according to the

following structure:

Figure 102 Contract Refinement Verification files and results

The folder NuSMV3-OCRA contains two other folders: Files and Results:

The Files folder contains all the files generated by the execution of the command that are used as input to

NuSMV3-Ocra. For the “Check Refinement” analysis only a representation of the model in the .oss format is

needed and is generated by a model to text transformation. Files for the implementation (.smv) will be

generated too (see next section).

The Result folder contains two files: one contains the output of the NuSMV3 analysis, the other is an error

log. If the model didn’t pass the validation checks (see 16.4.1.1) the transformed .oss file won’t be a valid

input to the analysis tool, so the output won’t be correct and the error log will report problems.

17 Ada infrastructural code generation See http://chess-project.org/page/training.

http://chess-project.org/page/training


92

18 Appendix

18.1 Note about the usage of the <<Contract>> ConstraintBlock in the context of

the SysML language The SysML ConstraintBlock is a package for Constraints that can be used to bind the latter to a given block.

One of the main features of the ConstraintBlock construct is that it allows the reuse of constraints in

different blocks; in particular this is possible in SysML:

1. by using the ConstraintBlock parameters to represent the parameters addressed by the packaged

constraints,

2. by using the Parametric diagram which allows to bind the ConstraintBlock parameters to the Block

parameters, so as to specify which are the Block parameters that are interested by the constraints

packaged in the ConstraintBlock.

In FoReVer the aforementioned SysML support for ConstraintBlock can be applied to Contracts also, so the

design and then the reuse of pattern of Contract are available.

However, in case the support of Contract-pattern is not needed, the SysML procedure regarding the

binding of the ConstraintBlock to a given Block can be simplified by allowing the modeler to omit the

parameters of the Contract itself and so to omit the modeling of the Parametric diagram for the given

Contract usage.

So the following semantic regarding the binding of Contract to Block is adopted in the FoReVer profile:

If the Parametric diagram is not provided for the given instantiation of the Contract inside the

Block, then an implicit binding is assumed between the parameters considered in the Assume and

Guarantee of the Contract and the properties (e.g. ports) of the Block where the Contract has been

instantiated. The implicit mapping is performed by comparing the string of the Assume/ Guarantee

parameters with the name of the Block properties.

If instead the Parametric diagram is provided for the given instantiation of the Contract inside the

Block, then the mapping of the Assume/ Guarantee parameters to the Block properties are derived

from the mapping provided through the Parametric diagram itself.

18.2 Tips

Warning: this action should be performed to overcome possible limits/bugs of the implemented

CHESS view support. Please contact the CHESS development team to notify the existing problem.

Click the CHESS SuperUser button located in the CHESS toolbar to skip all the checks concerning

working with views.


93

18.3 Tutorial: the CHESS process - protected operation example

18.3.1 Create data types

Go to the Component View, then right click on Component View and select New Child->Package to create a

package called “DataTypes”.

Right click on the newly created package and select New Diagram->Class Diagram to create a new Class

Diagram, then use the palette to create the needed types.

Figure 103 Creating data types

18.3.2 Create interfaces

Go to the Component View, then right click on Component View and select New Child->Package to create a

package called “Interface”.

Create the Interfaces: right click on the Interfaces Package and select New Diagram->Class Diagram to

create a new Class Diagram, then use the palette to create the Interfaces (e.g. Producer_IF, Consumer_IF

and Store_IF), as depicted in Figure 104.

Figure 104 Creating interfaces

Create the operations for the Interfaces that you have just created using “ Operation” from the palette.


94

Figure 105 Creating operations

Use the UML tab in the Properties below to define the (in/out) parameters for the operations you have just

created.

Figure 106 Defining operation's parameters

Assign the type to the parameters from the Type field clicking on “…” and selecting the needed type, as

depicted below.


95

Figure 107 Assigning a type to operation parameters

So now you have created your interfaces and operations, as illustrated below.

Figure 108 Modeling interfaces and operations

18.3.3 Create component types

Go to the Component View (Functional). Right click on the package and select New Diagram-> Class

Diagram.

Create component types using the palette, as depicted in Figure 109.


96

Figure 109 Creating component types

Create the needed Provided and Required Ports for each Component Type:

Select the ComponentType from the Model Explorer

Create its Composite Structure Diagram (right-click->Create new Diagram->Composite Structure

Diagram)

Select Provided Port or Required Port icon from the CHESS FunctView palette

Click on the border of the ComponentType

<TBC>


97

19 References

[1] I. Sljivo, B. Gallina, J. Carlson and H. Hansson, "Strong and Weak Contract Formalism for Third-Party Component Reuse," 3rd International Workshop on Software Certification, November 4-7, 2013.

[2] CONCERTO, "D2.8 – Multi-concern Component Methodology and Toolset – Final Version," www.concerto-project.org/, 2015.

chess toolset user guide - eclipse · chess toolset user guide 1 chess toolset user guide 18 june...

Documents