D2.7 Analysis and back-propagation of properties for ...api.ning.com/files/HrJMLaNSVNiLLW3cp6PqlCkfWXH3lRkF6LyqHo*M0f-7... · D2.7 – Analysis and back-propagation of properties

Guaranteed Component Assembly w i th Round Tr ip Ana lys is

fo r Energy E f f i c ien t H igh - in tegr i ty Mu l t i - core Sys tems

Project Partners: AENSys, Aicas, Atego, Budapest University of Technology and Economics,

Critical Software, EADS, Intecs, ISEP, Maelardalens University, OTG Solutions,

SINTEF, Thales Communications & Security, The Open Group, University of Florence,

University of Padova

Every effort has been made to ensure that all statements and information contained herein are accurate, however the

Partners accept no liability for any error or omission in the same.

© 2015 Copyright in this document remains vested in the CONCERTO Project Partners.

Project Number 333053

D2.7 – Analysis and back-propagation of properties for multicore systems - Final Version

Version 1.0

3 November 2015

Final

Public Distribution

Airbus Group (EADS), INT, MDH, UNIFI, UPD

D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version

Page ii Version 1.0 3 November 2015

Confidentiality: Public Distribution

DOCUMENT CONTROL

Version Status Date

0.1 Initial document structure taken from the Y2 first release of the deliv-

erable, to be reviewed and extended. First set of possible revi-

sions\extensions added.

15 Sep 2015

0.2 All sections filled. Ready for internal review 22 Oct 2015

0.3 Review by Airbus Group (EADS) and TCS 26 Oct 2015

1.0 Final version with comments addressed. New Appendix C about

MARTE usage.

03 Nov 2015


3 November 2015 Version 1.0 Page iii


TABLE OF CONTENTS

List of Figures ................................................................................................................................................................... v

List of Tables ..................................................................................................................................................................... v

List of Abbreviations ....................................................................................................................................................... vi

Executive Summary ........................................................................................................................................................ vii

1 Introduction .............................................................................................................................................................. 1

1.1 Main changes with respect to D2.3 ..................................................................................................................... 1

2 Review of the CHESS modelling language ............................................................................................................. 1

2.1 Support for View Definition ................................................................................................................................ 2

2.2 Modelling the real time ....................................................................................................................................... 3 2.2.1 Timing annotation ....................................................................................................................................... 3 2.2.2 Real time analysis ....................................................................................................................................... 4

2.3 Modelling the dependability ............................................................................................................................... 5

2.4 Instance-level modelling ..................................................................................................................................... 6

3 CHESSML extensions – cross domain .................................................................................................................... 8

3.1 System Model ...................................................................................................................................................... 8 3.1.1 Data flow .................................................................................................................................................... 8 3.1.2 Socio-technical systems .............................................................................................................................. 8

3.2 Component Model ............................................................................................................................................... 9 3.2.1 Data flow .................................................................................................................................................... 9 3.2.2 Inter-components bindings scenarios .......................................................................................................... 9 3.2.3 Hierarchical Components .......................................................................................................................... 10 3.2.4 Events ....................................................................................................................................................... 11 3.2.5 HW Abstraction Component ..................................................................................................................... 12

3.3 Operational Modes ........................................................................................................................................... 12

3.4 Dependability\Safety Model .............................................................................................................................. 13 3.4.1 The new CHESS dependability profile ..................................................................................................... 13 3.4.2 Modelling Criticality ................................................................................................................................. 14

3.5 Platform and Allocation Models (Deployment Model) ..................................................................................... 16 3.5.1 Modelling allocations for each operational mode ..................................................................................... 16

3.6 Extra functional properties for operational modes ........................................................................................... 17

3.7 Multi-cores processors ..................................................................................................................................... 17

3.8 Run-time Monitoring and Verification .............................................................................................................. 18

3.9 Partition Modelling ........................................................................................................................................... 19

3.10 Analysis model .................................................................................................................................................. 21

3.11 Advanced support for Sporadic operation ........................................................................................................ 21

4 CHESSML modification –domain specific ........................................................................................................... 22

4.1 Petroleum .......................................................................................................................................................... 22

4.2 Automotive ........................................................................................................................................................ 22

4.3 Avionics............................................................................................................................................................. 24 4.3.1 Functional Partitions ................................................................................................................................. 24 4.3.2 ARINC Processes ..................................................................................................................................... 24 4.3.3 Restriction on the deployment .................................................................................................................. 28

5 Coverage of CONCERTO metamodel derived requirements ............................................................................. 28


Page iv Version 1.0 3 November 2015


6 Conclusion ............................................................................................................................................................... 34

7 References ................................................................................................................................................................ 35

A. An introduction to the CHESSML profile ........................................................................................................ 35

B. CONCERTO Dependability Profile .................................................................................................................. 40

B.1 Stereotypes ............................................................................................................................................................. 41

B.2 Notes about the current implementation ................................................................................................................ 53 B.2.1 Deprecated stereotypes .................................................................................................................................... 53 B.2.2 Renamed Stereotypes ...................................................................................................................................... 53 B.2.3 About the FPTCSpecification ......................................................................................................................... 54

C. About MARTE usage in the CHESSML .......................................................................................................... 55


3 November 2015 Version 1.0 Page v


LIST OF FIGURES

Figure 1: MARTE RtSpecification CHESS extensions ...................................................................................................... 4 Figure 2: CSD and its corresponding “composite instance model”, source UML specification ......................................... 7 Figure 3: Sequence diagram representing inter-component bindings ............................................................................... 10 Figure 4: Modelling Signals ............................................................................................................................................. 11 Figure 5: Modelling Operational Modes (source MARTE spec.) ..................................................................................... 13 Figure 6: Extension for criticality level modelling support .............................................................................................. 15 Figure 7: Criticalities specification ................................................................................................................................... 16 Figure 8: Criticalities Interface Specification ................................................................................................................... 16 Figure 9: modelling Allocations constrained to OperationalModes ................................................................................. 17 Figure 10: MARTE HWProcessor stereotype .................................................................................................................. 18 Figure 11- RunTimeSupport stereotype ............................................................................................................................ 19 Figure 12: Using MARTE MemoryPartition .................................................................................................................... 20 Figure 13: CHRtSpecification extension for sporadic operations ..................................................................................... 22 Figure 14: CHESS stereotypes for modelling redundant ASIL decomposition ................................................................ 23 Figure 15: Modelling Redundant Decomposition in CHESS ........................................................................................... 24 Figure 16: CHESS profile for ARINC processes .............................................................................................................. 25 Figure 17: CHESS model and views predefined structure ................................................................................................ 35 Figure 18: Interfaces ......................................................................................................................................................... 35 Figure 19: ComponentTypes ............................................................................................................................................ 35 Figure 20: ComponentType‟s provided and required ports .............................................................................................. 36 Figure 21: CHESS ComponentImplementation ................................................................................................................ 36 Figure 22: Intra-component binding ................................................................................................................................. 37 Figure 23: CHESS ComponentImplementation instances ................................................................................................ 37 Figure 24: CHESS timing annotation ............................................................................................................................... 38 Figure 25: CHESS Instance Model ................................................................................................................................... 38 Figure 26: CHESS deployment model .............................................................................................................................. 39 Figure 27: Dependability information annotated HW components .................................................................................. 39 Figure 28: SBA analysis context ...................................................................................................................................... 39 Figure 29: FPTC specification .......................................................................................................................................... 40 Figure 30: Results of the FPTC analysis........................................................................................................................... 40 Figure 31: Proposal for the CONCERTO dependability conceptual model. .................................................................... 41 Figure 32: MARTE HLAM::RtSpecification and HLAM::RTFeature CHESSML extensions........................................ 57

LIST OF TABLES

Table 1 - WP4, WP3 cross domain “metamodel” reqs and their coverage at M30 .......................................................... 28 Table 2 - WP4, WP3 domain specific “metamodel” reqs and their coverage at M18 ...................................................... 33


Page vi Version 1.0 3 November 2015


LIST OF ABBREVIATIONS

ARINC Aeronautical Radio INCorporated

ASIL Automotive Safety Integrity Level

CHESSML CHESS Modelling Language

CSD Composite Structure Diagram

DSL Domain Specific Language

FLA Failure Logic Analysis

FPTC Failure Propagation and Transformation Calculus

IMA Integrated Modular Avionics

PIM Platform Independent Model

PSM Platform Specific Model

QoS Quality of Service

SBA State-Based Analysis


3 November 2015 Version 1.0 Page vii


EXECUTIVE SUMMARY

This deliverable is the M30 update of its D2.3 predecessor and reports on the work

conducted in WP2 as final definition of the modelling language capable to express

system, software and hardware multi-core architectures, together with non-functional

properties for analysis and back-annotation.

The findings discussed in this document rely upon the understanding of industrial

requirements captured in WP1 and in particular upon the corresponding elaborations

performed in WP2, WP3 and WP4.

This document considers the results of the CHESS project as baseline and then

elaborates upon the extensions that have been defined to satisfy the CONCERTO

project requirements.


3 November 2015 Version 1.0 Page 1


1 INTRODUCTION

This deliverable is the M30 update of its D2.3 predecessor and describes the

modifications required for the CHESS modelling language to support the CONCERTO

needs for what regards the modelling, analysis and back propagation of the analysis

results. In particular, results coming from WP3 and WP4 have been taken into account.

The structure of the document is the following: first the review of the CHESS modelling

language, as resulting from the CHESS project, is addressed in section 2; then in

sections 3 and 4 the extensions of the CHESS modelling language for the cross and

specific domain needs respectively are discussed. The coverage of the CONCERTO

requirements with respect to the updated CHESS modelling language (as presented in

this document) is provided in section 5.

1.1 MAIN CHANGES WITH RESPECT TO D2.3

With respect to D2.3, the following sections\topics have been created or significantly

updated\reviewed:

2 Review of the CHESS modelling language (updated)

3.2.5 HW Abstraction Component (new)

3.4.2 Modelling Criticality (new)

3.7 Multi-cores processors (new)

3.8 Run-time Monitoring and Verification (new)

3.9 Partition Modelling (updated) (section 3.8 in D2.3)

3.11 Advanced support for Sporadic operation (new)

4.2 Automotive (updated)

4.3 Avionics (new)

5 Coverage of CONCERTO metamodel derived requirements (updated)

B CONCERTO Dependability Profile (updated)

C About MARTE usage in the CHESSML (new)

2 REVIEW OF THE CHESS MODELLING LANGUAGE

The CHESS modelling language (CHESSML) is considered as the baseline for the

CONCERTO needs. This section reviews the current version of the CHESSML, i.e. the

one resulting from the CHESS project, in order to better identify a more stable and

suitable baseline to be adopted in CONCERTO.


Page 2 Version 1.0 3 November 2015


The CHESSML specification, as metamodel\UML profile, is described in the CHESS

deliverable D2.3.2 [CHESSD232].

Basically the CHESSML restricts and extends the SysML, UML and MARTE OMG

standards to support:

view definition,

modelling of PIM entities,

modelling of the hardware platform,

modelling of timing related information (at PIM and PSM level),

modelling of dependability information (at PIM and platform level),

modelling of analysis scenario,

modelling of PSM entities,

back propagation of analysis results (at PSM and PIM level).

The reader can refer to annex A for a quick introduction to the CHESSML illustrating

the aforementioned support.

In the remainder of this document the term component type is used to refer to a

classifier of a set of component instances, in the sense of the object-oriented paradigm,

while the terms ComponentType and ComponentImplementation are used to refer the

corresponding entities (i.e. stereotypes of the UML Component) defined in the CHESS

component model (see CONCERTO D2.2).

2.1 SUPPORT FOR VIEW DEFINITION

In CHESSML a view corresponds to a stereotyped package, i.e. a UML container

allowed to own all the entities that belong to the given view. It is worth remembering

that a view-package can be defined as the sum of distinct sub-views, the latter acting

upon the same package of the parent view; e.g. this is the case for the CHESS

component view-package which is actually the overlapping of two distinct sub-views:

the functional and extra functional views.

Regarding the support for views definition in CHESSML, no extension has been done

in CONCERTO regarding UML support.

One possible solution identified in CONCERTO regards the definition of a dedicated

meta-model for views specification1; in particular, for each view, the meta-model

should allow to formalize the permission rules (e.g. read-only, read-write) to be applied 1 View specification is also known in literature as viewpoint. E.g. from the SysML: “A Viewpoint is a specification of

the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder con-

cerns…”




at modelling-time on the UML entities and, more in general, on the entities of a given

domain specific language (DSL, e.g. implemented as UML profile), as defined by the

view specification itself. The meta-model should be implemented in Eclipse and a

framework should be developed on top of it to offer a DSL-independent support for

views definition and usage; the framework should be designed to be integrated with the

Eclipse Papyrus UML editor. Due to project priorities, derived according to the end-

user requirements, and resources, the development of the aforementioned support has

not been planned yet.

2.2 MODELLING THE REAL TIME

2.2.1 Timing annotation

Regarding real time modelling and back-propagation support, CHESSML basically

relies on the usage of a subset of the MARTE language which allows the timing

decoration of component‟s ports at PIM level. MARTE, in particular the

RtSpecification2 stereotype, has been extended in CHESS (Figure 1) to support real-

time annotation of operations exposed through provided ports at component instance

level. In fact MARTE allows to attach real time information like thread activation

pattern (e.g. sporadic, periodic), deadline to a given operation of a component type,

while timing information is proper of (and as to be differentiated for) each single

component instance. The aforementioned limitation of MARTE was reported to the

MARTE OMG team3 and it will be fixed in the next version of the MARTE OMG

release.

See Annex C for a more detailed explanation about usage of the MARTE entities in

CHESS.

2 Defined in the MARTE High-Level Application Modeling (HLAM) sub-profile

3 OMG Issue 15166




Figure 1: MARTE RtSpecification CHESS extensions

In CHESSML the decoration of component‟s operations exposed through provided

ports makes it possible to address operations having public visibility only; in fact only

public operations are visible through a provided port.

In CONCERTO, in order to support some specific request from domains like avionics

(see 4.3.2), the CHESSML CHRtSpecification has been extended to allow the

decoration of private operations for a given component instance; in particular according

to the CONCERTO component model definition (see CONCERTO D2.6)

CHRtSpecification can only be used to decorate private operations as protected or

unprotected.

2.2.2 Real time analysis

Another MARTE customization available in CHESS regards the way analysis results

are available in the model (by back-propagation). The MARTE profile makes a clear

distinction about how HW, SW resources and the information related to a given analysis

are modelled, and uses different stereotypes for these different aspects4. In CHESS

4 MARTE stereotypes for modeling of application programming interfaces of software multi-tasking platforma are

available in the Software Resource Modeling (SRM) sub-profile. Stereotypes focused on modeling hardware platform




some parts of this information have been collapsed into the extended RtSpecification

stereotype; in fact the latter is used to provide timing properties of the SW operations-

resources (e.g. their activation kind, like periodic, sporadic, and its deadline) and to

attach data coming from the analysis (e.g. the worst case response time and blocking

time for the given operation) (see Annex A); this was done in CHESS because MARTE

does not allow to have information about a given analysis directly attached to port-

operation (i.e. where the RtSpecification applies).

In order to provide a better compliance with the MARTE standard, CONCERTO has

changed the way real time information resulting from the analysis are back propagated

in CHESS. In CHESS, in order to perform timing analysis, a PSM model is

automatically generated starting from the PIM user-level model; basically the PSM

represents the PIM model bounded to a given computational model. In the PSM,

MARTE stereotypes (from the Software Resourece Modeling sub-profile) are used to

provide the definition of tasks and shared resources; moreover the MARTE stereotypes

concerning schedulability analysis (from the Schedulability Analysis Modeling sub-

profile) are used as well.

In CONCERTO the back propagation of the analysis results is applied to the PSM level

entities only; at the same time traceability information between the PSM and the PIM

related entities are generated and stored in the model. Then the back propagation of the

analysis results to the PIM model is derived on demand by querying the model, in

particular by using the stored traceability links.

With the solution depicted above the analysis contexts and results can be modelled

separately from the SW\HW resources; concerning the CHESSML profile, it has been

possible to remove the attributes resulting from the analysis from the CHRtSpecification

(in particular the response time and the blocking time), allowing to have a strict

compliance with the MARTE standard.

To allow the user to easily retrieve and navigate the information related to the analysis

results, a dedicated tab view has been developed in CONCERTO; the analysis results

view shows all the analysis results associated to the selected analysis context, allowing

to navigate the provided information (e.g. the given sporadic\periodic operation) from

the view and the model explorer and diagram with hyperlinks (see CONCERTO D2.6

deliverable, section 3.1.5.1.1).

2.3 MODELLING THE DEPENDABILITY

Regarding dependability, CHESSML comes with a dedicated dependability profile

[CHESSD232]; the parts of the dependability profile useful to represent error models,

state-based and failure propagation information has been reviewed and extended in

CONCERTO according to the results coming from the WP3 and documented in the

CONCERTO D3.3 deliverable. The other constructs available in the CHESS

dependability profile have not been considered in CONCERTO given that they are out

of scope.

are available in the Hardware Resource Modeling (HRM) MARTE sub-profile. Stereotyped intended specifically for

schedulability analysis are available in the Schedulability Analysis Modeling (SAM) MARTE sub-profile.




The elaboration about the extensions of the dependability profile is provided in section

3.4.

2.4 INSTANCE-LEVEL MODELLING

The CHESSML resulting from the CHESS project makes use of the UML composite

structure diagram (CSD) to model instances and extra functional information for them;

there can be some limitation while using CSDs to model instances, especially if

hierarchies of instances, i.e. instances owning sub-instances, have to be considered,

together with its ports and extra functional decoration5. This limitation is even more

relevant in CONCERTO where decomposition of components and hierarchical

instances and their extra functional annotation are considered.

The proposal in CONCERTO is to be able to rely much more on the usage of the UML

instance model. In UML there is not a specific view\diagram for the instances, they are

modelled through the class diagram with a very basic notation; a kind of composite

object diagram is available in the UML standard itself (see Figure 2) but just as

example, it is not formalized (and so UML tools do not support it); as counterpart,

instance models are particularly of interest for the kind of systems addressed in

CONCERTO where e.g. decoration of extra functional properties naturally apply at

instance level.

5 Composite structure diagram allows to model instances in the context of a classifier, i.e. given a classifier, like a com-

ponent, it is possible to model the instance that are created when an instance of the component itself is created. So only

one level of decomposition; clearly composite structure diagram can be composed together, so if an instance A inside a

composite diagram is typed by a component B with in turn has a composite diagram, then it is possible to see A as de-

composed by the instances owned by B. However there can be some limitation: imagine to have two instances of com-

ponent B: then it is not possible to differentiate parameters of the instances owned by B for the different instances of B.




Figure 2: CSD and its corresponding “composite instance model”, source UML specification

CONCERTO allows decoration of the UML instance model with extra functional

properties. A specific InstanceView has been implemented on top the CHESS editor by

using a query driven approach; in this way it is possible to render the instances in a

hierarchical representation, allowing the modeller to easily navigate the instance model

and provide properties for the instances, as alternative to the usage of the CSDs.

So the modelling steps to be performed in order to complete the design in the extra

functional dimension are:

1. Create components (first ComponentType and then ComponentImplementation).

2. Create components CSDs for ComponentImplementation.

3. For the extra functional properties that can be expressed at this level, e.g., the

dependability error model: attach extra functional information to the components

and internals (the latter modelled in the CSDs)

4. Create the instance model starting from what has been modelled with the

component diagrams and their CSD‟s, which can be done automatically in

CHESS by using a dedicated command.

5. Use the instance model view to attach extra functional information for the

instances or to override the extra functional properties eventually modelled in

the step 3, if needed.

In order to support step 5, the modelling language constructs used in CHESSML to

model extra functional annotations at component level or in the CSD have to be made

available in the instance model view.

Note that this support is particularly useful to complete the modelling of software

component for what regards extra functional annotations, but it can also be adopted in

the system view and platform specification view if useful to model blocks and hardware

components properties at instance level.




3 CHESSML EXTENSIONS – CROSS DOMAIN

This section addresses the cross-domain model-level support added to the CHESSML to

support the CONCERTO needs.

3.1 SYSTEM MODEL

The modelling support discussed in this section is offered through the System View,

which basically reuses and tailors the SysML standard.

3.1.1 Data flow

SysML support to the modelling of data flow is introduced in CHESSML. This is to

allow modelling of data-flow at system level, e.g. useful to enable expression of

dependability properties and to allow dependability analysis at system level.

3.1.2 Socio-technical systems

Extensions to the CHESSML are introduced to address the modelling of socio-technical

systems, the latter discussed in CONCERTO deliverable D3.2.

To enable the modelling of socio-entities, two additional kinds of composite

components are introduced in the CHESSML: human and organizational. According to

the CONCERTO FLA:

human beings are modelled as composite components comprising their sensor-

like and actuator-like functionalities (as atomic components); human failures can

be represented as an internal component, named accordingly to the category.

Input ports of the human composite component should be connected to

appropriate input port of the logical (or sensor-like) component, and the output

of the action-related component should be connected to the output port of the

human component. Several logical components can be connected to action-

related component, and only one action-related component should be allowed

for one human component.

Organizational composite components should be connected to human composite

components using appropriate ports to capture organizational influences on

human behaviour. Human composite components are then connected to

technical (composite) component.

So the following stereotypes are added in the CHESSML in the system view (as

specialization of the SysML Block entity):

Human

Organizational

Technical.

As documented in D3.2, CONCERTO FLA is based upon the CHESS Failure

Propagation and Transformation Calculus (FPTC) formalisms and analysis.




To allow failure logic analysis to be applied to socio-technical systems, the CHESS

language constructs already available to support FPTC expressions for software and

hardware components become also applicable to the socio-technical systems entities. In

detail, FPTC can be used to assign a FPTC expression to humans, organizational and

technical blocks and related sub-blocks, while FPTCSpecification can be used to model

a given failure (late, early, omission, etc.) in input or output to a given block‟s port.

Furthermore, as required by the CONCERTO FLA, the application of FPTC is extended

to connectors, to allow modelling of failure of blocks interactions, and to block and

connector instances, to allow the refinement of FPTC specification at block instance

level.

3.2 COMPONENT MODEL

This section addresses the new modelling features introduced in CHESS regarding the

CHESS component model (see CONCERTO D2.6 deliverable).

3.2.1 Data flow

Data flow is introduced in the ComponentView as supported by MARTE through the

FlowPort entity6 (similar to the SysML support available in the SystemView). In

CHESSML FlowPorts are not allowed to be decorated with timing information. Data

flow in the component model is introduced to enrich the support for functional and

dependability modelling. For example, in a preliminary phase of the software design -

where typically dependability analysis applies - only the data flow can be available for

the entities under design, while the provided and required interfaces and service ports

(i.e. ports providing and requiring operations) are still to be defined. In this case the

usage of flow ports can be used to allow preliminary dependability\safety analysis, like

failure propagation, without the need to introduce and consider provided and required

interfaces\ports for the components.

3.2.2 Inter-components bindings scenarios

Inter-components bindings are functional collaboration scenarios, i.e. call operations

flows between interacting component instances.

UML sequence diagrams are introduced in CHESSML to support the modelling of

inter-components bindings; see Figure 3 for an example, where component instances are

represented together with the sequence of the operations calls between them.

6 Available in the MARTE Generic Component Model (GCM) sub-profile




Figure 3: Sequence diagram representing inter-component bindings

For a given system under design, different inter-components bindings can be provided,

one for each particular collaboration scenarios to be represented (for instance, one for

each operational mode, see section 3.3).

The main goal of this extension is to enrich the functional behaviour specification,

available in the functional view, and provide additional analysis techniques, in

particular end-to-end response time analysis.

The inter-components binding scenario complements the intra-component binding

information already available in the CHESS component model (see CONCERTO D2.6)

and represented by using UML activity diagrams. CHESSML intra-component bindings

are represented by activity diagrams attached to component‟s operations (so all the

instances of the same component inherit the same specification of intra-component

binding); the activity diagram models the sequence of internal or external operations

calls, the latter invoked through the required ports of the component itself. So intra-

component bindings are modelled for a component-operation in isolation and do not

consider external components.

In order to avoid inconsistencies in the model, the set of call operations modelled in the

intra-component and inter-components bindings, and so activity and sequence diagrams,

have to be consistent7.

3.2.3 Hierarchical Components

According to the new definition of the CONCERTO component model (see

CONCERTO D2.6 deliverable) Hierarchical components are introduced in the

CHESSML. In particular UML composite structure diagram can be used to model the

decomposition of a given ComponentImplementation into a collaboration of functional

ComponentImplementation instances: each component instance is typed with a

ComponentImplementation which in turn can be decomposed by using a different

composite diagram.

7 In the intra-component binding (sequence diagram), supposed to have a call to an operation Op upon an instance of

component C which in turns calls another operation OpReq; then the call of the operation OpReq must be defined in the

intra-component binding associated to operation Op of component C as well.




3.2.4 Events

Events, as supported by the CONCERTO component model, are introduced in the

CHESS modelling language by using the UML Signal. UML Signals supports

generalization and sub-typing (i.e. it is possible to have hierarchies of events) and they

can either carry parameters or be parameter-less, as required by the CONCERTO

component model. Moreover, UML defines that the sender of a Signal will not block

waiting for a reply but continue execution immediately which is compliant with the

constraint of the CONCERTO component model which does not allows sender-side

operations to be blocking.

The possibility to have MARTE output/input FlowPorts typed by a single Signal is

introduced in the CHESSML for the ComponentType and ComponentImplementation8,

so to model the emission/reception of events, i.e. what is called in the CONCERTO

component model event emitter/receiver ports. In addition, out flow port can be bound

to multiple in flow ports (or even none), as many as the components that are interested

in the notification.

The information about the event that can be emitted by the implementation of a given

operation is modelled in the activity diagram representing the intra-component binding

of the operation itself; in particular the UML SendSignalAction has to be used in the

activity diagram.

To model that a ComponentType or ComponentImplementation can react to a given

event, the UML Reception construct has to be attached to the component; the Reception

allows specifying the behaviour of the component to be processed when the given signal

arrives.

Figure 4 shows the modelling of Signal and Reception in UML; in particular Receptions

is shown in the Component‟s compartment using the same notation as for Operations

with the keyword «signal».

Figure 4: Modelling Signals

As additional constraint from the CONCERTO component model, the operation tagged

with Receipt, can only be marked protected or unprotected in the extra-functional view.

8 The same support can be added in the system view for the block entities if needed.




3.2.5 HW Abstraction Component

In CONCERTO the CHESS notion of ComponentImplementation has been extended

with the concept\stereotype of HWAbstractionComponentImpl.

HWAbstractionComponentImpl allows the representation of a functional component

which encapsulates the dependencies of the application on specific hardware

components, like sensors or actuators.

HWAbstractionComponentImpl stereotype comes with a property typed with the

HWResource of MARTE which can be used to set the hardware resource (e.g.

HWSensor, HWActuator, HWComputingResource) of which the

HWAbstractionComponentImpl represents the abstraction.

In CONCERTO, the HWAbstractionComponent Impl stereotype has been used in

particular to provide a more strict compatibility with the AUTOSAR component model

(see CONCERTO D2.6 deliverable); however it is safe to state that

HWAbstractionComponentImpl is a cross domain stereotype.

3.3 OPERATIONAL MODES

Operational modes are introduced in the CHESSML. As stated in the MARTE

specification:

“An operational mode can represent different things:

An operational system (or subsystem) state that is managed by reconfiguration

mechanisms (e.g., fault-tolerance management middleware) according to fault

conditions.

A state of system operation with a given level of QoS that can be handled by

resource management infrastructures (e.g., middleware that assign resources at

run time according to load demand, timing constraints, or resource usage).

A phase of a system operation (e.g., starting, stopping, launching, in a mission-

critical aerospace system).”

Operational modes can be defined for the given system under design by using MARTE

stereotypes (defined in the CoreElements sub-profile), and in particular the stereotyped

modeBehaviour state machine, together with mode states and mode transitions (see in

Figure 5). Mode transitions can be added in the state machine in response to an Event

(see section 3.2.4) to model how a given change of mode is activated in the system.

The modeBehaviour state machine can be defined at system, component or hardware

level. Currently in CHESSML we assume that only one modeBehaviour can be

provided for a given CHESS model.




Figure 5: Modelling Operational Modes (source MARTE spec.)

3.4 DEPENDABILITY\SAFETY MODEL

The modelling support discussed in this section is offered through the different

dependability views available in the system, component and deployment views (see

CONCERTO D2.5 deliverable about views).

3.4.1 The new CHESS dependability profile

According to result of WP3, the needs for modifications of the CHESS dependability

profile have been identified in order to:

improve the support for dependability modelling and analysis needs,

improve the integration between the two analysis techniques of interest in

CONCERTO, namely “State-Based Analysis” (SBA in the following) and

“Failure Logic Analysis” techniques (FLA in the following).

The proposed extensions are based on the following requirements coming from

CONCERTO D3.2 (see D3.2 for a deeper elaboration):

In CHESSML it shall be possible to define different (custom) failure

classifications, to be used in different models, or for different components.

In the current CHESSML failure classifications are associated with component

ports, i.e., the failures that are assumed to occur on that port can be specified.

Ports connected together by a connector should use the same classification with

respect to failures.

In CHESSML, it should be possible to use annotations for state-based and for

failure logic analysis together




More in general, in CONCERTO ML, it should be possible to define the failure

behaviour of a component at different levels of details:

o No annotations

The component does never fail spontaneously (i.e., no internal

faults). If an incoming failure is received from another

component, then it is “transmitted” as it is.

o FLA annotations only

The component does never fail spontaneously (i.e., no internal

faults). If an incoming failure is received from another

component, then it is “transmitted” according to FLA rules.

o SBA annotations (failure rate/repair rate)

o SBA annotations + FLA annotations

o Error Model

In the error model it shall be possible to define several ErrorStates, which define

the behaviour of the component different from the nominal Healthy state (the

InitialState).

In the error model the distinction between Error and FailureMode as in the

current CHESSML is no more needed. For any ErrorState it shall be possible to

define which failure mode affects the ports owned by the component.

The reader can refer to Annex B for an elaboration of the implementation of the

aforementioned requirements, included in the CHESSML as replacement\enhancement

of the previous CHESS dependability profile.

3.4.2 Modelling Criticality

The new dependability profile allows to model criticality (e.g. as ASIL9) decoration for:

Requirements

System level components (i.e. SysML Blocks)

Software component operations

Hardware Components

The modelling of criticalities has been particularly useful in CONCERTO to provide

support for validation of criticalities constraints (see CONCERTO D4.11 deliverable);

e.g. support at model level for ASIL inheritance, propagation and decomposition check, 9 Automotive Safety Integrity Level (ASIL) is a risk classification scheme defined by the ISO 26262 - Functional Safety

for Road Vehicles standard.




e.g. the latter as defined by the functional safety ISO 26262 automotive standard has

been implemented (analogous support can be provided for other domain).

Picture below provides a sketch of the extensions introduced in the CHESSML as part

of the dependability profile for what concerns criticalities.

Figure 6: Extension for criticality level modelling support

CriticalityLevel has to be defined first, e.g. according to the standard\domain of interest;

then criticality can be assigned to entities, e.g. SW components, using the

CriticalitySpecification stereotype (Figure 7).

CriticalityInterfaceSpecification stereotype can be used to constraint a given provided

port\interface (Figure 8), in particular to constraint the criticalities that clients must have

in order to be able to access the given provided port\interface.




Figure 7: Criticalities specification

Figure 8: Criticalities Interface Specification

3.5 PLATFORM AND ALLOCATION MODELS (DEPLOYMENT MODEL)

3.5.1 Modelling allocations for each 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 Assign10

, already used to model allocations, can be constrained by the

MARTE NFPConstraint11

construct, where the latter allows specifying the mode on

which the given Assign has to apply. For example, in Figure 9 the allocation of the

component instances to the processing resource CPU0 for only the NormalMode

operational mode is modelled.

Figure 9: modelling Allocations constrained to OperationalModes

3.6 EXTRA FUNCTIONAL PROPERTIES FOR OPERATIONAL MODES

In case of a system with different operational modes, through CHESSML it has to be

possible to specify extra-functional properties of the system elements under design for

each declared mode. Regarding temporal properties, MARTE defines a complex type12

to allow the modelling of non-functional properties; in particular any property value

(e.g., the period duration) can be expressed in MARTE by using a complex type which,

in addition to the value, has a “mode” attribute which allows specifying the operational

mode(s) in which the provided value is valid.

3.7 MULTI-CORES PROCESSORS

In CHESS the MARTE support to model the number of cores for a given

HWProcessor13

is imported. In particular MARTE allows modelling the number of

cores through the nbCores integer attribute of the HWProcessor stereotype, where the

latter is already used in CHESS in the deployment view to represent a computing

resource where software entities can be executed.

10

From the MARTE Allocation Modelling sub-profile 11

From the MARTE Non-functional Properties Modeling (NFPs) sub-profile 12

The NFP_ CommonType, from the normative MARTE Model Libraries (MARTE_Library). Any property value (e.g.

regarding real time, like period duration) can be expressed in MARTE by using a type which inherits from

NFP_CommonType. 13

From the MARTE Hardware Resource Modeling (HRM) sub-profile.




Figure 10: MARTE HWProcessor stereotype

3.8 RUN-TIME MONITORING AND VERIFICATION

CONCERTO extends CHESS to support the run-time monitoring and verification of

properties (see CONCERTO D4.10 deliverable for more details on the provided

support).

Concerning the modelling language, CHESS is extended to allow the specification of

the properties that need to be monitored and\or verified. It is worth noting that it is

important to make this kind of information available at model level. In fact, in safety

systems, the rationale regarding the need for the monitoring\verification of a given set

of properties typically originates from safety analysis and it is typically stated in safety

requirements (available in the requirements view). The possibility to prove in the model

that the requirements about monitoring\verification have been addressed in the design,

together with the model driven support offered by the CONCERTO toolset, allows to

provide a valid argumentation of the coverage of the given safety requirements.

According to D4.10 the properties that can be monitored\verified are the following:

Period: minimum, maximum, jitter

Execution time: Minimum, Maximum

Blocking time: Maximum

Response time: Maximum, jitter

CONCERTO extends CHESSML by adding specific the RunTimeSupport, as showed

in Figure 11.




Figure 11- RunTimeSupport stereotype

RunTimeSupport stereotype is intended to be used together with the CHRtSpecification,

which is used in CHESS to provide timing decoration for components instances

operations.

3.9 PARTITION MODELLING

The CHESSML is extended in CONCERTO to allow the modelling of partitions.

Two kinds of partitions are allowed:

the one defined in MARTE, i.e. MemoryPartition14

; to be used in the

DeploymentView,

FunctionalPartition as domain specific notion of partition, coming from the

avionics domain; see section 4.3.1.

MARTE MemoryPartition 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.

Figure 12 below provides an example of usage of the MARTE MemoryPartition in the

DeploymentView.

14

From the MARTE Software Resource Modeling (SRM) sub-profile.




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 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 12).

Figure 12: Using MARTE MemoryPartition

MemoryPartition instances can be decorated with criticality level (e.g. ASIL)

specification by using the CriticalitySpecification entity (see 3.4.2); this is particular

useful in case of mixed criticality system and to validate criticalities constraints, e.g. wrt

to criticalities of the software components allocated to the computing resource

connected to the HW memory and partitions.




3.10 ANALYSIS MODEL

MARTE supports the modelling of the analysis context15

, where analysis context

means:

the system, SW, HW architectural entities to be taken into account by the

analysis, with optionally their behaviour,

the extra functional information attached to them,

any other information to be given in input to the analysis, like for instance the

property to be measured.

CHESSML already adopts the MARTE analysis context for what regards

StateBasedAnalysis, FPTC and FI4FA Analysis.

CONCERTO extends CHESS by applying analysis context usage to timing analysis; in

particular MARTE analysis contexts are used to specify the platform and workload

needed for the schedulability and end-to-end analysis. The platform must comprises the

instance models of the software and hardware components while the workload is

represented by the extra functional information attached to the component instances; in

case of the end-to-end analysis, the workload must also comprise the sequence diagram

acting as the end-to-end scenario to be taken into account by the analysis (see section

3.2.2 about inter-components bindings scenarios).

3.11 ADVANCED SUPPORT FOR SPORADIC OPERATION

In CONCERTO the CHESS CHRtSpecification stereotype is extended to allow the

modelling of “composed” sporadic operations, as required by WP3, in particular by the

work concerning the integration of the synchronous approach within CHESS (see

CONCERTO deliverable D2.8 section 4.1.1 and CONCERTO deliverable D4.8 section

6.4). The goal is to be able to model that a given sporadic operation is actually activated

just after a well-defined set of operations, the latter defined in the context of the same

component, have been invoked.

The goal cited above has been reached by introducing a new property for the

CHRtSpecification named operationReqForSporadicOcc typed with a list of

Operations.

15

From the Generic Quantitative Analysis Modeling (GQAM) and Schedulability Analysis Modeling (SAM) MARTE

sub-profiles.




Figure 13: CHRtSpecification extension for sporadic operations

4 CHESSML MODIFICATION –DOMAIN SPECIFIC

This section addresses the cross-domain model-level support added to CHESSML.

4.1 PETROLEUM

The extension planned to support socio-technical systems modelling are currently

applied to the petroleum domain (see D3.2). No further extensions have been

formalized in the CHESSML for the petroleum domain.

4.2 AUTOMOTIVE

One goal of the CHESSML in CONCERTO is to support automatic verification of

ASIL decomposition in the safety ISO 26262 automotive standard meaning.

Figure 14 shows the stereotypes which have been introduced for the aforementioned

goal: Decomposition must be used to represent the set of requirements which

decompose a given parent requirements. The Independency requirement must be used to

model that the requirements which decompose a parent requirement are actually

independent, as required by the ISO 26262 standard. The rationale for the independence

can be provided by filling in the justification property of the Independency stereotype;

moreover, if it exists, a link to the Evidence e.g. a document that states why these

elements are to be considered independent, can be provided through the linkToEvidence

property.




Figure 14: CHESS stereotypes for modelling redundant ASIL decomposition

For the modelling of redundant decomposition (in the 26262 automotive standard

meaning), the CHESS toolset enforces the following modelling conventions.

In order to model ASIL decomposition (as illustrated in Figure 17) the CHESS user

must:

1. In the CHESS Requirement View: decompose the original safety requirement into

redundant requirements by creating two new SysML deriveReqt relationships

stereotyped as Decomposition, that share the same origin;

2. Assign ASILs (through CriticalitySpecification stereotype) to the decomposed safety

Requirements;

3. In the Requirement View: create an independence safety Requirement (to state that

the original safety requirement has been decomposed into two redundant ones, add

rationale to this by filling in the justification property and, if exists, a link to the

Evidence e.g. a document that states why these elements are to be considered

independent) and create the Independency relationship linking the independence

requirement to original requirement that has been redundantly decomposed;

4. In the Requirement View: create the SysML Satisfy relationships, for instance by

dragging the component\block that satisfy the decomposed safety Requirements

from the model explorer into the diagram and then creating the Satisfy relationships;

5. In the System View: Associate ASILs (through CriticalitySpecification stereotype)

to components\blocks.




Figure 15: Modelling Redundant Decomposition in CHESS

4.3 AVIONICS

4.3.1 Functional Partitions

According to the results coming from WP4 presented in CONCERTO D4.6 about

partitions support for IMA, a partition is defined in CHESSML as a UML Component

stereotyped as FunctionalPartition. The stereotype contains extra-functional properties

of the partitions (see section 3.1.3 of D4.6) about budget, scheduling ordering and

utilization.

4.3.2 ARINC Processes

Initial version of the demonstrator has revealed some limitations with respect to the

modelling of the avionics use case, i.e. the modelling of the IMA application. In order to

satisfy the requirements elaborated in the previous deliverables, new domain specific

stereotypes are introduced in the CONCERTO profile during the third year of the

project. On top of existing component features already present, they capture ARINC-

653 process definition with a single provided operation decorated with a periodic/cyclic

attribute, and a number of provided operations. These are private to the component, that

is to say not callable by other components. The periodic/cyclic operation may have an

offset. The private ones must be able to have priorities and precedence relations which

will be expressed between groups of function. This information will be used to compute

some offsets, as presented in the detailed description from below:




Figure 16: CHESS profile for ARINC processes

<<ARINCComponentImpl>>: it extends the CHESS

<<ComponentImplementation>> in order to add ARINC process semantic. It is

available in the extra functional view.

ARINCComponentImpl comes with the following constraints:

o The extended Component must be stereotyped as

CHESS::ComponentImplementation

o An <<ARINCComponentImpl >> must define one public operation

stereotyped with <<ARINC_Process>> (see below in the text)

o An <<ARINCComponentImpl >> must define a set (>=1) of

<<ARINCFunction>> operations (see below in the text)

<<ARINCProcess>>: it extends UML::Operation, UML::Comment, and is used

to map to the concept of ARINC Process, as collection of operations. It is


ARINCProcess comes with the following properties:




o operationsGroups: it defines how the operations which need to be

executed when the <<ARINC_Process>> operation is scheduled are

grouped; i.e. it defines which operation can run with which other. If an

operation is not mentioned in any group than it may be added to any of

them during the schedule generation. The string has to be compliant

with the given syntax:

<expr>:: "(" <operation_list> ")" [ "," "(" <operation_list> ")" ]

<operation_list> ::= <operation> [ "," <operation_list> ]

<operation> ::= <string>

e.g. ( op_1, op_4), ( op_3, op_2)

Precedencies between groups of operations can be derived from the prec-

edencies available between the operations themselves (see

<<ARINCFunction>>).

ARINCProcess comes with the following constraints:

o The owner of ARINCProcess must be an ARINCComponentImpl. The

operations listed in the operationsGroups must be ARINCFunction of the

same owning component or external operations (tagged as passive or

protected) available for the owning component through required ports.

o ARINCProcess must not have any implementation specified; the

behaviour is the “composition” of the behaviours of the operations that

can be scheduled during the ARINCProcess activation

o For ARINCComponentImpl instance, an ARINCProcess operation

should have a CHRtSpecification specifying:

The occurrence pattern occKind, i.e. information regarding the arrival

time, eventually with the phase (i.e. offset) (default is zero); Accord-

ing to MARTE specification, the arrival time can be specified as an

expression string making reference to variables, e.g.: "Period-

ic(period=(value= $MAF + 10), (unit=ms))"

The priority

The WCET is derived as the sum of the operations that can be scheduled dur-

ing the ARINCProcess activation.

ARINCFunction extends: UML::Operation, UML::Comment; it represents an

operation of the ARINCComponentImpl which maps to an ARINC function. It

is part of the ARINCProcess defined in the owning ARINCComponentImpl. It is


ARINCFunction comes with the following properties:

o followedBy: Operation[0..*] the operations that must run after




o rateDivider: Integer[0..1] rate divider of the period associated to the

ARINCProcess operation defined in the owning component

o offset: the phase associated will be calculated during model

transformation –from the previous relation- and directly used to set for

MAST++ the “Phase” value of the External_Event of Transaction.

ARINCFunction comes with the following constraints:

o ARINCFunction as extension of Comment must be used together with the

CHESS\MARTE CHRTSpecification stereotype to provide information

for an ARINCComponentImpl component instance.

o The owner of an ARINCFunction as extension of Operation must be an

ARINCComponentImpl.

o An ARINCFunction cannot be invoked by the public periodic operation

of the same owner component, or by other ARINCFunction operations.

o An ARINCFunction cannot appear in a provided interface of the owning

component.

o An ARINCFunction can only call protected or passive operations availa-

ble through required interfaces of the owning component.

o The operations appearing in the followedBy and precededBy lists must be

ARINCFunction of the same owning component or external operations

(tagged as passive or protected) available through required ports.

o For an ARINCComponentImpl instance, an ARINCFunction operation

should have a CHRtSpecification specifying:

the passive access mechanism, i.e. " CHRtSpecification .protection" =

"concurrent"

the WCET

the phase (i.e. offset) (default is zero)

o According to MARTE specification, phase can be specified in

the context of the periodic activation pattern, e.g.:

CHRtSpecification .occKind= "Period-

ic(phase=(value= 10), (unit=ms))"

o The value for phase is automatically derived in CHESS

o The ARINCFunction inherits the information about its periodic activation

from the ARINCProcess periodic operation of the owning component, on

which the rateDivider is applied.

The updated transformation to the analysis tool (i.e. MAST++) input model is in

charge of generating the offsets that permit a well-balanced workload over the dif-

ferent MIFs. Another role is to generate the priorities for its operations. This is a

unique integer that has to take into account both the priority inherited from the own-

ing process and the relationship of precedencies that is given by the “followedBy”

information.




4.3.3 Restriction on the deployment

In case of FunctionalPartition, the software to hardware allocation has to be compliant

with the following rules:

ARINC processes has to be allocated to Functional Partitions by using the

MARTE stereotype <<Assign>> already used in CHESSML for assigning

software components to hardware components (as showed in Annex A)

FunctionalPartitions have to be allocated to cores (by using the MARTE Assign

construct) and eventually to MemoryPartitions (if the latter are available in the

deployment view)

5 COVERAGE OF CONCERTO METAMODEL DERIVED REQUIREMENTS

This section summarizes the current coverage of the CONCERTO derived requirements

concerning the modelling language definition, i.e. the metamodel\profile.

The following tables are taken from CONCERTO D2.1 section 4 “Plan for realization”;

they summarize the requirements about the metamodel as derived by the end user

requirement elaboration made in WP4 and WP3. The column “Coverage” has been

added to trace what can be covered at M30 for what regards the modelling support, as

discussed in this document.

Table 1 - WP4, WP3 cross domain “metamodel” reqs and their coverage at M30

View WP4, WP3 refined

Requirements with

Category

“Metamodel” to be

managed through the

view

Metamodel information to be

managed through the view

Coverage at M30

SystemView

R9.1 (WP3.1) Data flow Covered

R9.2 (WP3.1) Control flow Not covered. Not

requested by the

methodology.

System-

DependabilityView

(new sub-view, see

R2.1_V1)

R2.1 (WP3.1) Availability for system elements Covered.

Dependability profile

is now applicable at

system level.

R2.3 (WP3.1) Propagation information between

system components

Covered by the new

dependability profile.

R44.1 (WP3.1)

R52.3 (WP3.1)

R2.4 (WP3.1)

Dependability attributes (with particular

focus on safety/reliability/availability),

such as failure rates, failure modes

Covered by the new






Requirements with

Category


managed through the

view



Coverage at M30

R9.3 (WP3.1) Specification of faults (for fault

propagation analysis)

Covered by the new


R51.1 (WP3.1) Constructs for associating safety/risk

properties with all types of components,

including components that represent

physical equipment or

human/organizational elements

Covered by the new


R39.1 (WP3.1) ASIL as system block property Covered

R61.1 (WP3.1) Argumentation of independence for the

redundant elements

Covered

R2.2 (WP3.1) Redundancy and fault-tolerance

mechanism

Partially covered by

the new dependability

profile.

Component-

FunctionalView

R1.1 (WP4.1) Modes of operation for software

components

Covered

R95.1 (WP4.4)

R9.2 (WP3.1)

Attributes to define expected flow

between inputs and outputs of

components

Covered (intra-

component bindings).

R95.2 (WP4.4) Policies that govern valid information

flows between component inputs and

outputs shall be defined.

Not covered for the

functional dimension.

Covered for what

regards failure

propagation.

R89.1 (WP4.4) Attributes to define preconditions that

must be respected before performing

certain actions.

Partially covered, see

section 3.11.

R9.1 (WP3.1) Data Flow Covered

Component-

ExtraFunctionalView

R6.2, R94.1 (WP4.1) Schedulability attributes for software

components such as period, deadline,

WCET, offset and jitter.

Covered





Requirements with

Category


managed through the

view



Coverage at M30

R26.1 (WP4.1) Buffers, semaphores and their non-

functional properties (like, size, queuing

policy) and services to manipulate these

resources (intra and inter partition

Partially covered:

In avionic use case,

resources are

represented as

components. Size and

Queuing policy are

not taken into account.

Intra- and Inter-

partitions services can

be represented but

only intra-partitions

ones are taken into

account for timing

analysis.

O1.1 (WP4.1) Parallel tasks Not covered. Impacts

on the component

model PIM-PSM

transformation to be

studied. Support from

timing analysis tool

(MAST) already

available.

R94.2 (WP4.4) Handler associated with deadline miss Currently not covered

at model level; code

generation support for

it will be available,

with generation of

placeholder for

handler code.

R5.1 (WP4.4) Task utilization Can be derived from

existing property; in

particular it can be

derived as the ratio of

the maximum

observed

execution time over

the minimum inter-

arrival time\period.

R80.1 (WP4.4) Attributes to specify access policies, as

well as to attach these policies to

components

Covered by

CHRtSpecification

R44.1 (WP3.1)




Covered





Requirements with

Category


managed through the

view



Coverage at M30



Covered

R39.1 (WP3.1) ASIL, as property for software

component

Covered


redundant elements

Covered

R34.1 (WP4.1) Extra-functional properties compatible

with the timing properties required by

the ASTRIUM computational model

Covered:

To our knowledge,

support of WCET and

synchronizations

trigger is compatible

and sufficient with

studidedcomputational

model

R4.1 (WP4.1) Hard or soft timing constraint. Partially covered.

Deployment-

PlatformSpecification

View

R78.1 (WP4.1) Usage of MARTE to define hardware

specific concerns

Partially Covered

R73.1 (WP4.1) Execution nodes, containing single core

or multi-core processors

Covered

R6.1 (WP4.1) Multi-core schedulers for SMP and

heterogeneous systems

Not covered by the

current support.

R6.2 (WP4.1) Schedulability attributes for hardware

components.

Multi-core schedulers for SMP and

heterogeneous systems

Partially covered:

AMP approach has

been chosen for

avionic code reuse

purpose. Multicore

scheduler is perfectly

handled including for

analysis.

R6.4 (WP4.1)

R70.1 (WP4.4)

Computational hardware resources

(processor, memory, specific resources)

for single and multi-core systems.

Combination of cache(s), memory

access and communication busses

Not covered:

Caches cannot be

modelled and their

delays cannot be

assessed.

Communication

busses like 1553

cannot not be

modelled.





Requirements with

Category


managed through the

view



Coverage at M30

R35.1 (WP4.1) Fix priority scheduler, time-table driven

scheduler and the composition of both

of them (two-level scheduler)

Covered.

R23.1 (WP4.1) Configuration information for the

underlying platforms

Configuration

information is not

modelled in UML but

provided through

external configuration

files.

R35.2 (WP4.1) Processing nodes and cores decorated

with schedulers

Partially covered. No

support for

schedulers.

R23.2 (WP4.1) Configuration information assigned to

the nodes of the platform architecture

(Partially) Covered:

Mapping of partition

to cores and ARINC-

653 time-table

schedule are available.

R5.1 (WP4.4) CPU, system utilization attributes Partially covered

R25.1 (WP3) Hardware devices like sensors, mobile

local hubs

Not covered.

R25.2 (WP3) Network services to represent, for

example, centralized decision support

systems

Not covered.

R44.1 (WP3.1)




Covered



Covered

R39.1 (WP3.1) ASIL, as property for hardware element Covered


redundant elements

Covered

R73.1 (WP4.1) allocation of the software components

to the execution resources on execution

nodes, containing single core or multi-

core processors

Covered





Requirements with

Category


managed through the

view



Coverage at M30

R71.1 (WP4.1) Core reservation for software

components

Covered (through

deployment view)

R46_V1 TLC specific hardware (MARTE

support with respect to the TLC relevant

properties shall be investigated)

Not covered.

Deployment-

Allocation View

R72.1(WP4.1),

R72.3 (WP4.1)

Processor affinity for (critical) software

components.

Partially covered by

the criticality

specification.

R70.2 (WP4.4) Configurations of the memories by

defining per-task memory budgets.

Not covered.

R71.3 (WP4.1) Core reservation Covered (through

deployment view)

Table 2 - WP4, WP3 domain specific “metamodel” reqs and their coverage at M18

View Domain WP4, WP3

refined

Requirements

with

Category

“Metamodel”

to be

managed

through the

view



Coverage at M18

RequirementView Automotive R39.1

(WP3.1)

ASIL, as requirement property. Covered

SystemView

Petroleum R53.1 Barriers, Dynamic properties of

barriers

Covered by the

socio-technical

system profile

SystemView-

ExtraFunctionalView

Petroleum R50.1 Risk Covered by the

dependability

profile.

SystemView-

ExtraFunctionalView

Petroleum R50.2 Computational model/formula at

design time for aggregation of safety

properties

Covered by

dependability

analysis.

Component-

ExtraFunctional

View

Automotive R43.1 Specification of application level

failure code and diagnostic services

provided by the run time environment

Not covered.




View Domain WP4, WP3

refined

Requirements

with

Category

“Metamodel”

to be

managed

through the

view



Coverage at M18

Deployment-


View

Telecare R23.1

(WP3.1)

Telecare domain specific

configuration information

Not covered at

UML model level;

to be provided

through external

configuration files.

Deployment-


View

Telecare R23.2

(WP3.1)

Configuration information assigned to

the nodes of the platform architecture

Not covered at

UML model level;

to be provided

through external

configuration files

Deployment-


View

Telecom R18.1(WP3.1) Mobile device domain-specific

configuration

Not covered at

UML model level;

to be provided

through external

configuration files

Deployment-


View

Automotive R40.1

(WP3.1)

Assignment of can data bases (DBC)

to a CAN networks

Not covered

Deployment-


View

Automotive R85.1

(WP3.1)

CAN, LIN, FlexRay busses/protocols Not covered

Deployment-

Allocation View

Telecare R25.4

(WP3.1)

Dynamic reconfiguration of

allocations

Not covered.

6 CONCLUSION

The document reports the extensions which have been made to the original CHESS

modelling language to satisfy the CONCERTO requirements. Several modifications

have been identified by improving some limitations of the CHESSML. Additionally,

new extensions needed for CONCERTO have been proposed like the new dependability

profile, the modelling concepts of criticality levels, partitions and operational modes.

Moreover a domain specific set of extensions have been identified for the Automotive

and Avionics domains.




7 REFERENCES

[AV] A. Avizienis, J.C. Laprie, B. Randell, C. Landwehr. Basic concepts and taxonomy

of dependable and secure computing. In: IEEE Trans. Dependable Sec. Comput.1(1):

11-33, 2004.

[CHESSD232] D2.3.2 – Multi-concern Component Methodology (MCM) and Toolset

Version 1.0, 10 January 2012, CHESS Artemis Project Number 216682 (available at

http://www.chess-project.org/page/results)

A. An introduction to the CHESSML profile

This section provides an introduction to the main parts of the CHESSML, relevant for

CONCERTO, as resulting from the CHESS project (no CONCERTO extensions), by

illustrating some modelling examples. A basic knowledge of the UML standard is

required.

Figure 17: CHESS model and views predefined structure

Following figures shows the definition of Interfaces and ComponentTypes.

Figure 18: Interfaces

Figure 19: ComponentTypes

http://www.chess-project.org/page/results




Figure 20 shows the definition or provided and required ports for a given Compo-

nentType.

Figure 20: ComponentType’s provided and required ports

Figure 21 shows the ComponentImplementations, where each

ComponentImplementation realizes a given ComponentType. The

ComponentImplementation inherits all the specification from the realized

ComponentType, in particular ports with provided\required interfaces and operations;

then ComponentImplementations can be used to provide implementation details, and

then they can be instantiated and connected together.

Figure 21: CHESS ComponentImplementation

Figure 22 shows an example of intra-component binding (as of activity diagram) for the

Produce operation implemented by the Producer_impl ComponentImplementation ap-

pearing in Figure 21; in particular it is modelled that the implementation of the Produce

operation perform a call of Store and then Consume operations through required ports of

Producer_impl (the On port field visible in the property editor in Figure 22 allows to

specify the required port through which the operation call currently selected applies).




Figure 22: Intra-component binding

Figure 23 shows an example of ComponentImplementations instantiation and connec-

tion. The instances (in yellow in the figure) are represented as internal part of a root

component, the latter representing the entire SW system under design. Each instance

comes with the provided and required ports defined for the typing ComponentImple-

mentation.

Figure 23: CHESS ComponentImplementation instances

Figure 24 shows an example of timing annotation for ComponentImplementation in-

stances, by using MARTE RtSpecification stereotype decorating operations exposed

through provided ports:




Figure 24: CHESS timing annotation

Figure 25 shows an example of instance model (tree-like view) derived from the model

represented in Figure 24; in particular the instances of the software component are rep-

resented under the SwSystem_instSpec package.

Figure 25: CHESS Instance Model

Figure 26 shows an example of deployment, so about the platform specification; in this

case only one computational resource is defined (in grey in the figure). Moreover the

software to hardware component instances allocations are modelled using MARTE As-

sign constructs. Each Assign comes with from and to attributes through which the soft-

ware instance (from) which is allocated to the hardware instance (to) can be specified.




Figure 26: CHESS deployment model

Figure 27 shows hardware entities and ComponentImplementations enriched with de-

pendability information (about stateful, stateless) useful for state-based analysis (SBA).

Figure 27: Dependability information annotated HW components

Figure 28 shows the State-Based analysis context used to run the state-based analysis.

Figure 28: SBA analysis context

Figure 29 shows how the information about FPTC rules (on the top of the figure) and

failure types occurring on top level-input ports (on the left of the bottom figure) can be




provided for ComponentImplementations at type and instance level, to allow FPTC

analysis.

Figure 29: FPTC specification

Figure 30 shows how the results of the FPTC analysis about failure types occurring at

output-port level are back propagated in the model.

Figure 30: Results of the FPTC analysis

B. CONCERTO Dependability Profile

This section describes the new CHESS modelling language for dependability. The

profile is based upon the conceptual dependability model presented in CONCERTO

D3.2; the profile is defined here by taken into account the top-level requirements

coming from WP3, which concern the possibility to apply dependability information at




type and instance level and the possibility to use the dependability profile at System,

Component and Deployment level (in particular for the latter for what regards HW

platform entities).

The proposal here is intended as replacement of the previous CHESSML Dependability

Profile [CHESSD232]. The diagram of the dependability conceptual model is shown in

Figure 31, as appearing in D3.2, then some further UML profile detail are provided in

the following text.

Figure 31: Proposal for the CONCERTO dependability conceptual model.

B.1 STEREOTYPES

Here we list the stereotypes that are foreseen in the implementation of the CONCERTO


«FailureMode»

o Extends

UML::Class




o Description

This element represents a failure mode of a component. Failure

modes should be associated to components‟ ports.

o Attributes

name : String [1]

description : String [0..1]

exposure : String [0..1]

controllability : String [0..1]

likelihood : String [0..1]

«FLABehavior»

o Extends

UML::Component, SysML::Block, UML::Connector,

UML::InstanceSpecification

o Description

This stereotype should be similar to the one used in CHESS, where




the failure behavior is described using a FPTC / FI4FA specification.

If a <<FlaSpecification>> Connector or InstanceSpecification (as

instance of Connector) does not have dependability-related

stereotypes, then it is assumed that failures are propagated “as they

are”, e.g., one “omission” on one end is propagated as an “omission”

on the other end. Otherwise dependability annotations can be used to

i) specify a mapping between failure modes on one side, and failure

modes on the other side; or ii) specify failure behavior of the

connector itself (e.g., a network cable may break). In this case, we

should consider (if possible) the failure modes associated to the two

ports between which the connector (instance) is placed (through the

ConnectorEnd elements in case of the Connector or by using the

owned Slots, i.e. the instances of the connected ports, in case of the

InstanceSpecification)

o Attributes

fptc : String [1]

«SimpleStochasticBehavior»

o Extends

UML::Class, UML::Property, UML::Connector,


o Description

This stereotype is meant to replace the Stateless/Stateful

Software/Hardware stereotypes (those were considered difficult to

handle/understand by industrial users in CHESS).

o Attributes

failureOccurrence : MARTE_Library::NFP_Real [1]




repairDelay : MARTE_Library::NFP_Real [0..1]

failureModesDistribution : String [0..1]

«ErrorModelBehavior» (replace «DependableComponent»)

o Extends

UML::Class, UML::Property, UML::Connector,


o Description

This stereotype is used to attach an error model to a system element

(component/block/connector)

o Attributes

errorModel : CHESSML::ErrorModel [1]




«ErrorModel»

o Extends

UML::StateMachine

o Description

An error model state machine (as in CHESSML)

«InternalFault»

o Extends

UML::Transition

o Description

An internal fault transition, i.e., a state transition caused by an internal

fault.

An internal fault can bring the component to a state different from the

initial state, but can also make the component move between two

internal states.

o Attributes

occurrence : MARTE_Library::NFP_Real [0..1]

weight : Double [0..1]




«InternalPropagation»

o Extends

UML::Transition

o Attributes

externalFaults : String [1]

Specification of which external faults (i.e., failures of

connected components trigger this internal propagation

transition). This attribute should be a string complying with

the following grammar:

modeexp ::= Port „.‟ mode | modeexp „AND‟ modeexp |

modeexp „OR‟ modeexp | „NOT‟ modeexp

mode ::= FailureMode | „nofailure‟

As examples, two valid strings are:

“p1.omission”

“(p1.commision AND p2.nofailure) OR p3.late”

o Description

An error propagation occurring within the component. The

propagation is caused by the occurrence of external faults.

o Attributes

delay : MARTE_Library::NFP_Real [0..1]

weight : Double [0..1]

«Failure»

o Extends

UML::Transition

o Attributes

modes : String [1..*]

Specification of which failure modes affect which ports of the

component. This attribute should be an array of strings

complying with the following grammar:

modes ::= Port „.‟ mode | Port „.(‟ modeprob „)‟

mode ::= FailureMode | „nofailure‟

modeprob ::= prob “ : ” FailureMode | modeprob „, ‟ modeprob

prob ::= Double


“p1.omission”

“p2.(0.2 : omission, 0.8 : commission)”


o Description

The occurrence of a failure of the component (i.e., an erroneous

component state reaches the service interface). The modes attribute is




used to specify which failure modes affect the different ports of the

component.

Having failures as events/transitions is in line with the “classical”

definition given by the taxonomy of Avizienis et al [AV]. There

could be for example situations where a component, as a

consequence of a failure moves back to the initial state. For example,

a component may produce a wrong output as a consequence of a

particular input, but then produce correct output in the following.

«NormalState»

o Extends

UML::State

o Description

A state of the component that is considered “normal”, i.e., in which

the component is providing its full functionalities.

«ErrorState»

o Extends

UML::State

o Description

A state of the component that is considered erroneous (i.e., not

complying with the specifications).

«DegradedState»

o Extends




UML::State

o Description

A state of the component in which it is not delivering its complete

functionalities, but which was foreseen in the specifications (e.g.,

reduced services due to maintenance activities).

«ErrorDetection»

o Extends

UML::Transition

o Attributes


successProbability : Double [0..1]

o Description

An error detection transition. Can be used in components‟ error

models.

o Constraint

from “ErrorState” to any State

«ErrorHandling»

o Extends

UML::Transition

o Attributes



o Description

An error handling transition. Can be used in components‟ error

models.

o Constraint

from “ErrorState” to any State

« FaultHandling »

o Extends

UML::Transition

o Attributes






o Description

A fault handling transition. Can be used in components‟ error models.

o Constraint

From any State (except the InitialState) to any State

«Propagation»

o Extends

UML::Connector, UML::InstanceSpecification

o Attributes


probability : Double [0..1]




«M&MActivity»

o Extends

UML::Activity

o Attributes

when : String [1]

Specification of when the activity should be triggered. This

attribute should be a strings complying with the following

grammar:

S ::= T „[‟ EX „]‟ | T „[‟ EX „] {‟ L „}‟

T ::= „Immediately‟ | „AtTime(‟ R „)‟ | „Periodic(‟ D „)‟

EX ::= „(‟ EX „and‟ EX „)‟ | „(‟ EX „or‟ EX „)‟ | „not‟ EX | „true‟ | FD

FD ::= „Failed(‟ FailureMode „)‟ | „Failed(‟ Port „.‟ FailureMode „)‟ |

„Detected(‟ ErrorState „)‟

L := „Before(‟ R „)‟ | „After(‟ R „)‟ | „Interval(‟ R „,‟ R „)‟

R ::= MARTE::NFP_Real


“Immediately [ p1.omission ]”

“Periodic( 720 ) [ true ] { After(8760) }”

o Description

An activity related to maintenance, which may be composed of

multiple actions (M&MAction). The “when” attribute specifies the

conditions that should hold for this activity to be triggered.

«M&MAction» (abstract)

o Extends

UML::Action

o Attributes

duration : MARTE_Library::NFP_Real [0..1]

probSuccess : Double [1]

targets : UML::Property [*]




o Description

An action belonging to an M&MActivity.

«M&MAction»

o Extends

UML::Action

o Attributes

duration : MARTE_Library::NFP_Real [0..1]

probSuccess : Double [1]

o Description

An action belonging to a M&MActivity.

«Repair»

o Extends

CHESSML::M&MAction

o Attributes

targets : UML::Property [*]

o Description

A repair action performed on a component (or set of components).

Repair brings the component back to its initial healthy state.

«Detection»

o Extends

CHESSML::M&MAction

o Attributes

target : UML::Property [1]

detectableStates : CHESSML::ErrorState [1..*]

onDetection : CHESSML::M&MAction [*]

o Description

An error detection activity performed on a component to detect

specific erroneous states defined in its error model.

«Recovery»

o Extends

CHESSML::M&MAction

o Attributes

target : UML::Property [1]

recoveryState : UML::State [1]

o Description

A recovery activity that brings a component in a specific state.

«StateBasedAnalysis»

o Extends

MARTE::GQAM::GaAnalysisContext

o Attributes

measure : String [1]

measureEvaluationResult : String [0..1]

targetInstances : UML::InstanceSpecification [*]




targetPort : UML::Slot (as instance of Port) [*]

targetFailureModes : CHESSML::FailureMode [*]

initialConditions : CHESSML::SBAInitialConditions [*]

o Description

Definition of measures of interest for state-based analysis as in

CHESS. The target may be specified by specifying i) only the

component instances, ii) specific ports of those instances, or iii)

specific failure modes of those ports.

StateBasedAnalysis can have one or more initial conditions to be

applied to the analysis.

«SBAInitialConditions»

o Extends

UML::Component

o Attributes

targetInstance : UML::InstanceSpecification [1]

setup : String [1]

Specification of the probability distribution of initial states of

the component. This attribute should be a strings complying

with the following grammar:

SETUP ::= „{‟ SP „}‟

SP ::= SP „,‟ SP | S „:‟ P

S ::= UML::State | „Healthy‟ | F

F ::= „Failed(‟ FailureMode „)‟ | „Failed(‟ Port „.‟ FailureMode „)‟

P ::= MARTE::NFP_Real


“{ Failed(p1.omission) : 1.0 }”

“{ Healthy : 0.8, Erroneous : 0.2 }”

o Description

This stereotype is used to specify initial conditions for components of

the system (e.g., healthy, failed, etc.).




Other comments

o «FLABehavior» and «SimpleStochasticBehavior» could in principle coexist

on the same component.

B.2 NOTES ABOUT THE CURRENT IMPLEMENTATION

All the stereotypes defined in the previous version of the CHESS dependability profile

are kept in the current implementation to be able to still use the current transformations

and analysis; they appear in this document as deprecated (see below).

B.2.1 Deprecated stereotypes

The following entities (stereotypes and\or properties) from the old CHESS

dependability profile are deprecated:

(deprecated NEW(optional))

FPTCSpecification.failure FPTCSpecification.failureMode

FPTC FLABehavior

FPTCPortSlotFailureModes

FailureTypeFailureMode

DependableComponent ErrorModel

ErrorState.type

ErrorState.vanishingTime

B.2.2 Renamed Stereotypes

ErrorErrorState

Propagation.propDelay=Propagation.delay




B.2.3 About the FPTCSpecification

FPTCSpecification, as defined in the old profile, allows storing failures for ports by

using composite structure diagrams, i.e. by using annotated Comments attached to port-

part pairs. I.e. the modeller can use the FPTCSpecifications in the composite diagram to

provide the faults in input (as fault injection); at the same time the tool uses

FPTCSpecifications to back propagate the propagated failures, as resulting from the

analysis.

FPTCSpecification is kept in the current version of the profile to allow an initial smooth

customization of the implementations currently available for the FPTC analysis; for this

goal a dedicated relationship between FailureModes and FPTCSpecification has been

added in place of the one between FPTCPortSlot and FPTCSpecification defined in the

old profile. So, to reuse the current FPTC implementation, FailureModes should be used

in place of the FPTCPortSlot; then FailureModes at Slot level can be linked to the

<<FPTCSpecification>> Comments modelled in the composite diagram.

However the final goal (in CONCERTO or after) should be to avoid the use of the

FPTCSpecification in place of the usage of the FailureModes stereotype. In other words

the user should be able to use the InstanceView to attach failures to ports, in particular

by using FailureModes attached to Slots, the latter as instances of ports, without the

need to create the FPTCSpecification. So the usage of stereotyped comments, needed to

work with the composite diagram for ports decoration, would not be useful anymore.

It is worth noting that the current FPTC analysis already considers the instance level, so

it already considers the InstanceSpecifications and Slots entities, retrieving the

FPTCSpecification starting from them; the resulting failures are currently back

propagated to the FPTCSpecifications just to allow the modeller to see the results by

using the composite diagram. So what we should implement is a new view to allow the

modeller to check the results directly by looking at the InstanceView, without the need

to switch to the composite diagram. The usage of composite diagram also has some

limitation in case of hierarchical systems, with a hierarchy level > 2, and the new view

for FPTC result built on top of the InstanceView would solve these limitations.




C. About MARTE usage in the CHESSML

This section summarizes the set of MARTE entities which are used in CHESSML and

in the views defined by CHESS.

Component model (CHESS SystemView, ComponentView,

PlatformSpecificationView)

Operational modes can be defined for the given system under design by using MARTE

stereotypes (defined in the CoreElements sub-profile), and in particular the stereotyped

ModeBehavior state machine, together with Mode states and ModeTransition

transitions. ModeTransition can be added in the state machine in response to an event to

model how a given change of mode is activated in the system.

The ModeBehavior state machine can be defined at system, component or hardware

level.




Component model (CHESS ComponentView)

MARTE GCM16

::ClientServerPort and FlowPort entities are used in CHESSML to

model services and data ports respectively for software components (i.e.

CHESSML::ComponentImplementation and CHESSML::ComponentType).

The MARTE HLAM17

::RtSpecification is used in CHESSML to model the following

properties for a given operation owned by a software component (i.e.

CHESSML::ComponentImplementation):

Arrival pattern (i.e., periodic, sporadic) (occKind attribute)

Relative deadline (relDl attribute)

Priority (priority attribute).

In addition, HLAM::RtSpecification is extended in CHESSML (as CHRtSpecification

stereotype, see Figure 32) to also allow the specification of the following properties for

components operations:

worst case execution time (WCET),

protected\unprotected access (protection stereotype‟s field),

ceiling priorities (for protected operations only).

the set of operations that need to be invoked to allow the operation invocation

(invokedoperationReqForSporadicOcc stereotype‟s field); for sporadic

operations only.

Regarding the aforementioned timing properties, any property value (e.g., the period

duration) can be expressed in MARTE by using a complex type which, in addition to

the value, has a “mode” attribute which allows specifying the operational mode(s) (as

MARTE::CoreElements::Mode) in which the provided values are valid.

The partWithPort relationship available for CHRtSpecification allows to model timing

annotation for operations which are provided by a given Property, the latter as instance

of component owned by a composite component. The Property and the associated

CHRtSpecification can be modelled\visualzed through the UML composite structure

diagrams.

The MARTE HLAM::RtFeature is extended in CHESSML (as CHRtPortSlot

stereotype, see Figure 32) to allow application of CHRtSpecification to a given instance

of component‟s port (Slot in UML).

16

the MARTE Generic Component Model (GCM) sub-profile. The “::” denotes the namespace where the stereotype is

defined. 17

the MARTE High-Level Application Modeling (HLAM) sub-profile




Figure 32: MARTE HLAM::RtSpecification and HLAM::RTFeature CHESSML extensions

Platform specification (CHESS PlatformView)

The modelling of the platform is allowed in CHESSML by using the stereotypes available in

the MARTE Hardware Resource Modeling (HRM) sub-profile. In particular processors can

be modelled in CHESS by using the MARTE HRM::HwProcessor entity, while busses

connecting processors can be modelled by using the MARTE HRM::HWBus entities.

MARTE HRM::HwProcessor comes with the nbCores attribute (as natural numerical value)

which allows to specify the number of cores within the HwProcessor.

MARTE SRM18

::MemoryPartition is used in CHESSML to 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.

Software to hardware allocation (CHESS AllocationView)

MARTE Alloc19

::Assign is used in CHESSML to model software to hardware component

(i.e. HRM::HWProcessor) instances allocation.

18

MARTE Software Resource Modeling (SRM) sub-profile




MARTE Alloc::Assign can be constrained by the MARTE NFPs20

::NFPConstraint construct,

where the latter allows specifying the operational mode(s) (as

MARTE::CoreElements::Mode) for which the Assign holds.

Alloc::Assign can be constrained with NFPs::NFPConstraint where the latter is used to

specify the core of the target processor (HRM::HWProcessor) on which the allocation is

performed; the target core is provided as numerical value in the NFPs::NFPConstraint

specification, according to the number of cores within the HRM::HwProcessor (nbCores

attribute) .

Analysis context (CHESS AnalysisView)

CHESSML uses the MARTE SAM21

::SaAnalysisContext entity to specify the information

needed to perform a given analysis.

MARTE GQAM22

::GaResourcePlatform is used in CHESSML as logical container for the

resources referred by an analysis context. CHESSML extends the GQAM

::GaResourcePlatform (as CHGaResourcePlatform stereotype) in order to be applied to UML

Packages (MARTE GaResourcePlatform extends the UML Classifier only). In fact in CHESS

the resources referred by an analysis context are component instances which are available in a

dedicated UML package.

MARTE GQAM::GaWorkloadBeahavior and SAM::SaEndtoEndFlow are used in

CHESSML (in the AnalysisView) to refer a sequence diagram modelled in the

ComponentView (in detail, GaWorkloadBeahavior and SaEndtoEndFlow are applied to a

UML activity which has a CallBehaviorAction pointing to the UML Interaction representing

the information modelled in the sequence diagram). GaWorkloadBehavior can then be used

to attach the referred sequence diagram to an analysis context, the latter used to feed end-to-

end response time analysis; SaEndtoEndFlow is used to provide an end-to-end deadline for

the behaviour modelled in the sequence diagram.

PSM (PSMView)

MARTE SAM::SaExecHost is used in CHESSML to represent at PSM level (in the

PSMView) the HRM::HwProcessor modelled in the PlatformView. SAM::SaExecHost allows

to specify the running schedulable resources, the latter generated in the PSM by the PIM to

PSM CHESS transformation.

MARTE SRM23

::SwSchedulableResource is used in CHESSML to represent PSM resources

that execute concurrently to other concurrent resource. SRM::SwSchedulableResource comes

with a priority field associated.

MARTE SRM::SwMutualExclusionResource and SAM::SaSharedResource are used in

CHESSML to model protected resources in the PSMView. 19

MARTE Allocation Modeling sub-profile 20

MARTE Non-functional Properties Modeling (NFPs) sub-profile 21

Schedulability Analysis Modeling (SAM) sub-profile 22

Generic Quantitative Analysis Modeling (GQAM) sub-profile 23

Software Resource Modeling (SRM) sub-profile




SRM::SwMutualExclusionResource allows to specify the type of protection protocol used to

access the resource (e.g. priority ceiling).

MARTE SAM::SaStep is used in CHESSML to represent an operation in the PSM having the

following properties:

Execution time (execTime:NFP_Duration) as specified in the component view

Blocking time (blockT:NFP_Duration) (retrieved by the analysis)

Response time (respT):NFP_Duration (retrieved by the analysis)

The list of called operations (subUsage:ResourceUsage [0..*]), as specified in the

component model intra-component bindings; this information allows to calculate the

blocking time.

The shared resource where the operation‟s behaviour is executed

(sharedResource:SaSharedResource [0..1])

The resource which executes the behaviour (concurRes:SchedulableResource [0..1])

The SAM::SaAnalysisContext modelled in the AnalysisView is mapped to a corresponding

SAM::SaAnalysisContex entity in the PSM. The SAM::SaAnalysisContext in the PSM

refers the entities of the PSM which are relevant for the analysis, in particular the

SAM::SaStep, SRM::SwSchedulableResource and SRM::SwMutualExclusionResource+

SAM::SaSharedResource protected resources.

Documents

D2.7 Analysis and back-propagation of properties for ...api.ning.com/files/HrJMLaNSVNiLLW3cp6PqlCkfWXH3lRkF6LyqHo*M0f-7... · D2.7 – Analysis and back-propagation of properties