D2.3 Analysis and back-propagation of properties for...

Guaranteed Compone nt 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.

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

Project Number 333053

D2.3 – Analysis and back-propagation of properties for multicore systems - Initial Version

Version 1.0

3 November 2014 Final

Public Distribution

MDH, INT, UNIFI, UPD


Page ii Version 1.0 3 November 2014

Confidentiality: Public Distribution

DOCUMENT CONTROL

Version Status Date

0.0 Initial coarse-grained document structure 08 Aug 2014

0.1

Added contributions regarding CHESS review and proposal for

changes

29 Sept 2014

0.2 Added contribution about dependability profile, modelling of parti-

tions, modelling of socio technical system. Overall check performed.

Version issued for internal review.

20 Oct 2014

1.0 Final issue with comments from internal reviews (made by BME and

Atego) addressed.

03 Nov 2014


3 November 2014 Version 1.0 Page iii


TABLE OF CONTENTS

List of Figures .................................................................................................................................................................. iv

List of Tables .................................................................................................................................................................... iv

List of Abbreviations ........................................................................................................................................................ v

Executive Summary ......................................................................................................................................................... vi

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

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

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

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

2.3 Modelling the dependability ............................................................................................................................... 3

3 CHESSML modification – cross domain ................................................................................................................ 4

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

3.2 Component Model ............................................................................................................................................... 5 3.2.1 Data flow .................................................................................................................................................... 5 3.2.2 Inter-components bindings scenarios .......................................................................................................... 5 3.2.3 Hierarchical Components ............................................................................................................................ 6 3.2.4 Events ......................................................................................................................................................... 7

3.3 Operational Modes ............................................................................................................................................. 8

3.4 Dependability\Safety Model ................................................................................................................................ 9 3.4.1 The new CHESS dependability profile ....................................................................................................... 9

3.5 Instance-level modelling of extra-functional properties ................................................................................... 10

3.6 Platform and Allocation Models (Deployment Model) ..................................................................................... 12 3.6.1 Modelling allocations for each operational mode ..................................................................................... 12

3.7 Modelling extra functional properties for operational modes .......................................................................... 12

3.8 Modelling Partitions ......................................................................................................................................... 13

3.9 Analysis model .................................................................................................................................................. 13

4 CHESSML modification –domain specific ........................................................................................................... 14

4.1 Petroleum .......................................................................................................................................................... 14 The extension planned to support socio-technical systems modelling are currently applied to the petroleum domain

(see D3.2). No further extensions are currently formalized in the CHESSML for the petroleum domain. .............. 14

4.2 Automotive ........................................................................................................................................................ 14 4.2.1 Safety Integrity level ................................................................................................................................. 14

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

6 Conclusion ............................................................................................................................................................... 21

7 References ................................................................................................................................................................ 21

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

B. CONCERTO Dependability Profile .................................................................................................................. 28


Page iv Version 1.0 3 November 2014


LIST OF FIGURES

Figure 1: Sequence diagram representing inter-component bindings ................................................................................. 6 Figure 2: Modelling Signals ............................................................................................................................................... 7 Figure 3: Modelling Operational Modes (source MARTE spec.) ....................................................................................... 8 Figure 4: CSD and its corresponding “composite instance model” .................................................................................. 11 Figure 5: modelling Allocations constrained to OperationalModes ................................................................................. 12 Figure 6: Initial extension for safety integrity level modelling support ............................................................................ 14 Figure 7: CHESS model and views predefined structure .................................................................................................. 22 Figure 8: Interfaces ........................................................................................................................................................... 22 Figure 9: ComponentTypes .............................................................................................................................................. 22 Figure 10: ComponentType’s provided and required ports .............................................................................................. 23 Figure 11: CHESS CompoentImplementation .................................................................................................................. 23 Figure 12: Intra-component binding ................................................................................................................................. 24 Figure 13: CHESS ComponentImplementation instances ................................................................................................ 24 Figure 14: CHESS timing annotation ............................................................................................................................... 25 Figure 15: CHESS Instance Model ................................................................................................................................... 25 Figure 16: CHESS deployment model .............................................................................................................................. 26 Figure 17: Timing properties resulting from the analysis ................................................................................................. 26 Figure 18: Dependability information annotated HW components .................................................................................. 26 Figure 19: SBA analysis context ...................................................................................................................................... 27 Figure 20: FPTC specification .......................................................................................................................................... 27 Figure 21: Results of the FPTC analysis........................................................................................................................... 28 Figure 22. Proposal for the CONCERTO dependability conceptual model. .................................................................... 29

LIST OF TABLES

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


3 November 2014 Version 1.0 Page v


LIST OF ABBREVIATIONS

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


Page vi Version 1.0 3 November 2014


EXECUTIVE SUMMARY

This document reports on the work conducted in WP2 as first iteration of the 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 starts

identifying the modifications and the extensions that are needed in the CHESS

modelling language to satisfy the CONCERTO project requirements.


3 November 2014 Version 1.0 Page 1


1 INTRODUCTION

This report 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, current results coming from WP3 and

WP4 have been taken into account.

The structure of the document is the following: first the reviews of the CHESS

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

then in sections 3 and 4 initial proposals for the extensions of the CHESS modelling

language for the cross and specific domain needs respectively are discussed. The current

coverage of the CONCERTO requirements with respect to the updated CHESS

modelling language (as presented in this document) is discussed in section 5.

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.

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


Page 2 Version 1.0 3 November 2014


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. an UML container

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

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 is currently

planned in CONCERTO.

The approach selected in CONCERTO is to build a dedicated meta-model for views

specification1 definition; in particular, for each view, the meta-model will allow to

formalize the permission rules (e.g. read-only, read-write) to be applied at modelling-

time on the entities of a given domain specific language (DSL), as defined by the view

specification itself. The meta-model will be implemented in Eclipse and a framework

will be developed on top of it to offer a DSL-independent support for views definition

and usage to be integrated with the Eclipse Papyrus UML editor. Then the framework

will be instantiated to implement the views required by CONCERTO (as documented in

CONCERTO D2.1), together with the editing rules upon the CHESSML entities.

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 to support real-time

annotation of operations exposes through provided ports at component instance level; in

fact MARTE allows to attach real time information like WCET, thread activation

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

information is proper of (and as to be differentiate 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.

An open question in CHESSML is the following: 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. E.g. in this way cyclic operations have to be defined public in order to be

decorated, while a cyclic operation does not need to be visible from the external 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…” 2 Defined in the MARTE::HLAM sub-profile

3 OMG Issue 15166




components. To overcome this limitation, it should be possible to extend the decoration

of real-time information to private operations of a given component instance (see

section 3.5 for a further elaboration).

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 how HW, SW resources and the information resulting from a particular

analysis are modelled, and uses different stereotypes for these different aspects. In

CHESS 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 resulting from the analysis

attached to port-operation. In order to provide a better compliance with the MARTE

standard, one of the goals in CONCERTO is to review its analysis result storage

approach so that the analysis context and results can be modelled separately from the

system resources, as in MARTE. Finally, in order to continue representing the real time

analysis results associated to the port-operation a new dedicated analysis view will be

developed and evaluated.

More in detail, the proposed CHESSML modification is to leverage the role and use of

the instance specification entities of UML, and so of the instance model. In UML the

instance model allows to represent the entities which are available in a given running

system; it is typically derived starting from the static part of the model comprising the

component and composites structure diagrams; the CHESS toolset already supports the

automatic derivation of the instance model. The idea is to use (and extend if needed) the

UML instance model to allow representing instances of components with their

operations, so to be able to model real time properties and analysis results at instance-

operation level by using MARTE stereotypes. It is worth noting that the availability of

instance-operations in the instance model, also the ones with private visibility, would

allow the decoration of them; this would overcome the limitation expressed in section

2.2.1 about cyclic operations having public visibility.

The reader can refer to section 3.5 for a further elaboration of the intended usage of the

instance model in CONCERTO.

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 is reviewed and extended in

CONCERTO according to the results coming from the WP3. The other constructs

available in the CHESS dependability profile will not be considered here given that they

are out of scope for CONCERTO.

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

3.4.




3 CHESSML MODIFICATION – 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 human, 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 through the

Component View.

3.2.1 Data flow

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

FlowPort entity (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 is 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 (see CONCERTO D2.2).

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

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

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




Figure 1: 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.2)

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 consistent4.

3.2.3 Hierarchical Components

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.

4 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.




So no UML extension are needed in the modelling language to support the current

candidate top-down and bottom-up process for hierarchical components design as

discussed in CONCERTO D2.2 (Solution 3, pag. 17).

3.2.4 Events

Events as elaborated in CONCERTO D2.2 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 D2.2. 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 ComponentImplementation5,

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 2 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 2: Modelling Signals

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




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.

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, and in particular the stereotyped modeBehaviour state machine, together

with mode states and mode transitions (see in Figure 3). 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 3: 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.1).

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 “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, to be included in the CHESSML as

replacement\enhancement of the previous CHESS dependability profile.

3.5 INSTANCE-LEVEL MODELLING OF EXTRA-FUNCTIONAL PROPERTIES

The current section gives an overview on the extensions of the CHESSML on instance-

level modelling support.

The instance-level modelling support is available in the system, component and

deployment views. In other words the instance model applies to all the different

architectural modelling levels: system, software and hardware.

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 decoration6. This limitation would even be

relevant in CONCERTO where decomposition of components and hierarchical

instances and their extra functional annotation are considered.

The proposal in CONCERTO is 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 in Figure 4) but just as example, it

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

are particularly of interest in the kind of systems addressed in CONCERTO where e.g.

decoration of extra functional properties naturally apply at this level.

6 Composite structure diagram allows to model instances but in the context of a classifier, i.e. given a classifier, like a

component, 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 decomposed by the instances owned by B. However there can be some limitation: imagine to have two instances of

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

of B.




Figure 4: CSD and its corresponding “composite instance model”

The proposal in CONCERTO is to allow decoration of the UML instance model with

extra functional properties. What we still have to define is how to render the instance

model. Additionally, only a limited set of features are supported in the Papyrus UML

editor (on which the CHESS editor is built). Within the project we might define an

instance diagram editor equivalent to the CSD either a complete graphical editor

following the concrete syntax defined in Figure 4, or use a simpler tree editor.

Another point in favor of working with extra functional information at instance model

level is that most of the extra functional information depends on the way components

are allocated to hardware platforms, and the allocation is made at instance level, i.e.,

software component instances are the ones that are allocated to the platform (as already

defined in CHESS).

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 ComponentImplementations.

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.

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 CHESSML at instance level, i.e. in the instance model.

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.6 PLATFORM AND ALLOCATION MODELS (DEPLOYMENT MODEL)

3.6.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 Assign, already used to model allocations, can be constrained by the

MARTE NFPConstraint construct, where the latter allow specifying the mode on which

the given Assign has to apply. For example, in Figure 5 the allocation of the component

instances to the processing resource CPU0 for only the NormalMode operational mode

is modelled.

Figure 5: modelling Allocations constrained to OperationalModes

3.7 MODELLING 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 type7

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.8 MODELLING PARTITIONS

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

According to the latest 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. The allocation of component instances to partitions is modelled by using the

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

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

Further support for modelling partitions will be added in CHESSML according to the

upcoming results of WP4 and described in the final version of this deliverable.

3.9 ANALYSIS MODEL

MARTE supports the modelling of the analysis context, 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.

Moreover the analysis context comes with additional properties for the back-

propagation of analysis results, like the response time of a given cyclic operation.

CHESSML already adopts the MARTE analysis context for what regards

StateBasedAnalysis, FPTC and FI4FA Analysis.

We are planning in CONCERTO to adapt the MARTE analysis context for all analysis

techniques used within CHESSML.

E.g. for what regards timing analysis, 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).

7 The NFP_ CommonType. 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..




4 CHESSML MODIFICATION –DOMAIN SPECIFIC

This section addresses the cross-domain model-level support added to the 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 are currently formalized in the

CHESSML for the petroleum domain.

4.2 AUTOMOTIVE

4.2.1 Safety Integrity level

CHESSML is extended to be able to offer ASIL8 decoration for:

Requirements

System level components (i.e. SysML Blocks)

Software component (i.e. ComponentType and ComponentImplementaion)

operations

Hardware Components

Picture below provides a sketch of the extensions to be introduced in the CHESSML.

Figure 6: Initial extension for safety integrity level modelling support

Basically, new kinds of requirements and blocks (extending the SysML ones) are

introduced to support association of ASIL to requirements and system entities 8 Automotive Safety Integrity Level (ASIL) is a risk classification scheme defined by the ISO 26262 - Functional Safety

for Road Vehicles standard.




respectively; an extension similar to AumotitveBlock will be introduced for the software

component to support ASIL assignment to software entities.

The final goal of the aforementioned extensions is to provide support at model level for

ASIL inheritance, propagation and decomposition modelling automations, e.g. the

latters as defined by the functional safety ISO 26262 automotive standard.

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 M18 for what regards the modelling support, as

discussed in this document.

The uncovered requirements still need to be addressed, and needs inputs resulting from

WP4 or WP3 elaboration.

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

View WP4, WP3 refined

Requirements with

Category

“Metamodel” to be

managed through the

view

Metamodel information to be managed

through the view

Coverage at M18

SystemView

R9.1 (WP3.1) Data flow Covered

R9.2 (WP3.1) Control flow To be clarified the

need at model level.

E.g.: for which

analysis\model

transformation this

information would

be used?

System-

DependabilityView

(new sub-view, see

R2.1_V1)

R2.1 (WP3.1) Availability for system elements Partially covered.

Dependability

profile is now

applicable at system

level.

R2.3 (WP3.1) Propagation information between system

components

Initially covered by

the new

dependability

profile (possibly to

be extended).





Requirements with

Category


managed through the

view


through the view

Coverage at M18

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


the new

dependability

profile (possibly to

be extended).

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

propagation analysis).

Covered.

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

Partially covered.

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

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

redundant elements

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

mechanism

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

under investigation

if further support is

needed here.

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

flows between component inputs and

outputs shall be defined.

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

must be respected before performing

certain actions.

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


through the view

Coverage at M18

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

O1.1 (WP4.1) Parallel tasks. Parallel activities

can be introduced

IN CHESS-ML by

extending the

activity diagram

already used for the

modelling of the

intra-component

binding scenarios.

In particular the

possibility to add

fork and join nodes

would be enough.

What is still under

discussion and

evaluation regard

the clarification of

the PSM support for

what concern the

generation of

parallel tasks.

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

R5.1 (WP4.4) Task utilization

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

well as to attach these policies to

components

R44.1 (WP3.1)




Covered



Covered

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

component

Covered

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

redundant elements





Requirements with

Category


managed through the

view


through the view

Coverage at M18

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

with the timing properties required by the

ASTRIUM computational 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,

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

heterogeneous systems

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

components.

Multi-core schedulers for SMP and

heterogeneous systems

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.

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

scheduler and the composition of both of

them (two-level scheduler).

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

underlying platforms

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

with schedulers

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

the nodes of the platform architecture.

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

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

local hubs

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

example, centralized decision support

systems





Requirements with

Category


managed through the

view


through the view

Coverage at M18

R44.1 (WP3.1)




Covered



Covered

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

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

redundant elements

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

the execution resources on execution

nodes, containing single core or multi-

core processors

Covered

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

components.

R46_V1 TLC specific hardware (MARTE support

with respect to the TLC relevant

properties shall be investigated)

Deployment-

Allocation View

R72.1(WP4.1),

R72.3 (WP4.1)

Processor affinity for (critical) software

components.

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

defining per-task memory budgets.

R71.3 (WP4.1) Core reservation

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

Metamodel information to be

managed through the view

Coverage at M18





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


the socio-technical

system profile

(possibly to be

extended).

SystemView-

ExtraFunctionalView

Petroleum R50.1 Risk

SystemView-

ExtraFunctionalView

Petroleum R50.2 Computational model/formula at

design time for aggregation of safety

properties

Component-

ExtraFunctional

View

Automotive R43.1 Specification of application level

failure code and diagnostic services

provided by the run time environment

Deployment-


View

Telecare R23.1

(WP3.1)

Telecare domain specific

configuration information

Deployment-


View

Telecare R23.2

(WP3.1)

Configuration information assigned to

the nodes of the platform architecture

Deployment-


View

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

configuration

Deployment-


View

Automotive R40.1

(WP3.1)

Assignment of can data bases (DBC)

to a CAN networks

Deployment-


View

Automotive R85.1

(WP3.1)

CAN, LIN, FlexRay busses/protocols





refined

Requirements

with

Category

“Metamodel”

to be

managed

through the

view



Coverage at M18

Deployment-

Allocation View

Telecare R25.4

(WP3.1)

Dynamic reconfiguration of

allocations

As multiple

allocations can be

defined for

different modes, we

think we might use

this feature to

model the possible

dynamic

reconfiguration

scenarios.

6 CONCLUSION

The current document reports the initial extensions currently foreseen to the original

CHESS modelling language. Several modifications have been identified to start

covering the CONCERTO requirements along with some limitations of the CHESSML,

where proposals for changes have been defined. Additionally, new extensions needed

for CONCERTO have been discussed like: (i) modelling of socio-technical system, (ii)

the new dependability profile, (ii) the modelling concepts of safety integrity levels, (iii)

defining partitions and (iv) operational modes.

The complete definition of the new CHESSML covering the CONCERTO requirements

will be finalized in the next project period, taking into account the progresses made in

WP3 and WP4, and documented in the second and final version of this deliverable.

7 REFERENCES

[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 7: CHESS model and views predefined structure

Following figures shows the definition of Interfaces and ComponentTypes.

Figure 8: Interfaces

Figure 9: ComponentTypes

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

nentType.




Figure 10: ComponentType’s provided and required ports

Figure 11 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 11: CHESS CompoentImplementation

Figure 12 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 11; 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 12 allows to

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




Figure 12: Intra-component binding

Figure 13 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 13: CHESS ComponentImplementation instances

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

stances, by using RtSpecification decorating operations exposed through provided ports:




Figure 14: CHESS timing annotation

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

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

resented under the SwSystem_instSpec package.

Figure 15: CHESS Instance Model

Figure 16 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 16: CHESS deployment model

Figure 17 shows how the MARTE extended RtSpecification stereotype has been en-

riched with properties derived from the analysis (and stored by back propagation), like

response time (respT) and blocking time (blockT).

Figure 17: Timing properties resulting from the analysis

Figure 18 shows hardware entities and ComponentImplementations enriched with de-

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

Figure 18: Dependability information annotated HW components

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




Figure 19: SBA analysis context

Figure 20 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 20: FPTC specification




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

output-port level are back propagated in the model.

Figure 21: Results of the FPTC analysis.

B. CONCERTO Dependability Profile

This section describes the current proposal for the 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 22, as appearing in D3.2, then some further UML profile detail are provided in

the following text.




Figure 22. Proposal for the CONCERTO dependability conceptual model.

FailureType (new entity in CHESSML)

o Description: This element represents a type of failure (i.e., a failure mode) that is

explicitly considered for the involved system. Different failure types may have

different consequences on failure propagation.

o Attributes

Name : String [1]

Description : String [0..1]

o Extends

UML::DataType

FailuresClassification (new entity in CHESSML)

o Description: A failure classification defines a partition of the failure modes

associated with a component or service of the system architecture. Different failure

classifications can be used for different parts/components of the system, in order to

analyze in details their specificities.

o Attributes




FailureTypes : FailureType [1..*]

o Extends

UML::DataType

ElementWithFailures (new entity in CHESSML)

o Description: This concept extends the UML Component and Port concept, by

specifying the failure classification to be used for that specific component\port. If

two ports connected together use different failure classifications, an error should be

raised.

o Extends

UML::Component, UML::Port

o Associations

FailureModes : FailureClassification [1]

FailureWeight (new entity in CHESSML)

o Description: This element is used to specify the weight (i.e., occurrence probability)

of a given FailureType.

o Associations

Failure: FailureType [1]

o Attributes

Probability: Double [1]

o Extends

UML::Constraint

o Constraints

Probability must be a number between 0 and 1.

FailueModesDistribution (new entity in CHESSML)

o Description: This element is used to specify the probability distribution of the

occurrence of different failure modes on a component or component’s port.

o Associations

FailuresProbability : FailureWeight [0..*]

o Extends

UML::Constraint. (constraints a given component or port)

FailureReference (new entity in CHESSML)

o Description: This element is used to univocally identify a failure type occurring a

specific port or component.

o Associations

Failure : FailureType [1]




o Extends

UML::Constraint

o Constraints

If the constrained port is an ElementWithFailures, then Failure must be

included in the FailureType defined in the FailureClassification associated to

the port.

AbstractFailureBehavior (new entity in CHESSML)

o Description: This element is an abstract element that represents the failure behaviour

of a component. In CONCERTO we foresee three ways to specify failure

behaviours, having increasing detail level: i) failure logic analysis annotations, ii)

stochastic annotations, and iii) error-model state-machine.

o Abstract

o Extends

UML::Class, UML::Connector, UML::InstanceSpecification (as instance of

class and connector)

o Constraints

The stereotype applies to Component or Class stereotyped with Block.

StochasticFailureBehavior (new entity in CHESSML)

o Description: This concept extends the AbstractFailureBehavior concept, and can be

used to specify a stochastic failure behaviour for a system component or connector.

The failure behaviour is specified by specifying the failure and repair distributions,

and optionally a set of weights for component’s failure modes. The application of the

StochasticFailureBehavior is compatible with the FLABehavior, but it is mutually

exclusive with the ErrorModelBehavior.

o Extends

AbstractFailureBehavior

o Attributes

FailureDistribution : MARTE::NFP_Real [0..1]

RepairDistribution : MARTE::NFP_Real [0..1]

FailuresProbability : FailureWeight [0..*]

o Constraints

StochasticFailureBehavior and ErrorModelBehavior cannot be applied

together on the same element.

FLABehavior (new entity in CHESSML)

o Description: This concept extends the AbstractFailureBehavior concept, and it is

used to attach an FLA specification to components. The application of the

FLABehavior cannot be performed if an ErrorModelBehavior is applied.

o Attributes




Specification : FLASpecification [1..*]

o Constraints

The FLASpecification cannot be applied on the same element where a

ErrorModelBehavior is applied.

FLARule (already available in the previous version of CHESSML as FPTCSpecification,

reviewed in CONCERTO)

o Description: This element matches the FLARule defined in the conceptual model.

FPTCSpecification represents a “line” of a failure logic specification. The

“Incoming” attribute represents the left part of the FPTC specification, and the

“Outgoing” attribute represents the right part.

o Attributes

Incoming: FailureReference [1]

Outgoing: FailureReference [1]

o Extends

UML::Constraint

ErrorModel (already available in the previous version of CHESSML, reviewed in

CONCERTO)

o Description: This element matches the ErrorModelBehavior and ErrorModel defined

in the dependability conceptual model, in particular it merges the latters in a single

entity. This element extends the UML::StateMachine element, with the purpose to

allow users to describe detailed error models for system components and connectors.

o Extends

UML::StateMachine

o Constraints

ErrorModel state machine can have only states stereotyped with ErrorState,

and transitions stereotyped with InternalFault, ExternalFaultReaction,

RecoveryEvent, HardwareFault.

ErrorModel for connector can be provided by specifying the ErrorModel for

a given Class and then typing the Connector to the Class itself.

ErrorState (already available in the previous version of CHESSML, reviewed in

CONCERTO)

o Description: This element represents state of the component with respect to failures.

ErrorState can only appear in ErrorModel StateMachines. With respect to the

previous version of the CHESS dependability profile, the distinction between

“Error” and “FailureMode” states has been removed.

o Extends

UML::State

o Attributes




AffectedPorts : PortFailureRef [*]

FailureLogicSpecification: FLASpecification [0..*]

o Extends

UML::State

ThreatEvent (already available in the previous version of CHESSML, reviewed in

CONCERTO)

o Description: This abstract element represents an event occurring within a component

or connector, and modifying its behaviour with respect to failures.

o Abstract

o Extends

UML::Transition

o Constraints

Must connect two “ErrorState” states, the “InitialState” with an “ErrorState”

state, the “InitialState” with a “Choice” state, or an “ErrorState” with a

“Choice” state.

ProbabilisticChoice (new entity in CHESSML)

o Description: This elements represents a probabilistic choice within the ErrorModel

statemachine

o Extends

UML::Transition

o Attributes

Weight : double [1]

o Constraints

Can be applied on transitions connecting a “Choice” state to an “ErrorState”

state.

InternalFault (already available in the previous version of CHESSML, reviewed in

CONCERTO)

o Description: This element represents an internal fault occurring within the

component to which the error model is associated.

o Extends

ThreatEvent

o Attributes

Occurrence : MARTE::NFP_Real [1]

ExternalFaultReaction (already available in the previous version of CHESSML, reviewed in

CONCERTO)

o Description: This element represents a reaction of the component to an external fault




occurring on one of its ports. The reaction is modelled by a change of ErrorState

within the ErrorModel. The IncomingFault attribute specifies the condition for this

reaction to trigger, i.e., on which external faults this reaction is related.

o Extends

ThreatEvent

o Attributes

IncomingFault : String [1]

The string must follow the following grammar:

S ::= F AND F | F OR F | NOT F | F

F ::= FailureReference

RecoveryEvent (already available in the previous version of CHESSML, reviewed in

CONCERTO)

o Description: This element represents a recover event, for which the component

changes its ErrorState (within the ErrorModel). The recover requires a certain

amount of time to be performed, given by the RecoverDelay attribute.

o Extends

ThreatEvent

o Attributes

RecoveryDelay : NFP_Real [1]

HardwareFault (new entity in CHESSML)

o Description: This element represents a failure of the hardware on which a software

component is allocated. The purpose of this element is to be able to refer, within the

error model, a failure of the hardware. In fact, since there are no ports connecting

software and hardware, and thus the ExternalFaultReaction element cannot be used

for this purpose.

o Extends

ThreatEvent

o Constraints

The HardwareFault element can be used only in ErrorModel statemachines

owned by components stereotyped by ComponentImplementation.

MaintenanceAction (abstract) (already available in the previous version of CHESSML,

reviewed in CONCERTO)

o Description: This element represents a maintenance action that is performed on a

component or group of components. This corresponds to the analogous element

present in the previous version of the CHESS ML profile. However, due to the

modifications to the language (and in particular to the ErrorModel), maintenance-

related elements are updated as well.

o Extends

UML::Action




o Attributes

When : String [0..1]

Duration : NFP_Duration [1]

ProbSuccess : NFP_Real [1]

Repair (already available in the previous version of CHESSML, reviewed in CONCERTO)

o Description: This element extends the MaintenanceAction element, and represents a

repair action performed on a component

o Extends

MaintenanceAction

o Attributes

Target : Property [1]

UnderRepairState : ErrorState [0..1]

RepairedState : State [0..1]

o Constraints

RepairedState must be a state in a ErrorModel statemachine (i.e., an

ErrorState, or the InitialState).

UnderRepairState and RepairedState must be contained in the ErrorModel

statemachine associated with the Target component.

RepairGroup (already available in the previous version of CHESSML, reviewed in

CONCERTO)

o Description: This element extends the MaintenanceAction element, and represents a

repair action performed on a group of components.

o Extends

MaintenanceAction

o Attributes

Targets : Property [1..*]

ErrorDetection (already available in the previous version of CHESSML, reviewed in

CONCERTO)

o Description: This element extends the “MaintenanceAction” element, and represents

an error detection activity that is performed on a component.

o Extends

MaintenanceAction

o Attributes

Target : Property [1]

CorrectionProbability : NFP_Real [0..1]

DetectableStates : ErrorState [*]




CorrectedState : State [0..1]

o Constraints

DetectableStates must be a state in a ErrorModel statemachine (i.e., an

ErrorState, or the InitialState).

DetectableStates and CorrectedState must be contained in the ErrorModel

statemachine associated with the Target component.

ErrorDetectionGroup (already available in the previous version of CHESSML, reviewed in

CONCERTO)

o Description: This element extends the “MaintenanceAction” element, and represents

an error detection activity that is performed on a group of components.

o Extends

MaintenanceAction

o Attributes

Targets : Property [1..*]

CorrectionProbability : double [0..1]

D2.3 Analysis and back-propagation of properties for...

Documents

Transcript of D2.3 Analysis and back-propagation of properties for...