D2.1 Multiview-based design of industrial multicore ...api.ning.com/files/oj4MhhoM4fTPkB5E0sgB7HBWSDSKfFcZMu5ZonlVeyZdJ... · D2.1 – Multiview-based design of industrial multicore

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, BME, ISEP, Critical Software, EADS, Intecs, 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.1 – Multiview-based design of industrial multicore systems – Initial Version

Version 1.1

9 May 2014 Final

Public Distribution

UPD, Atego, INT, BME, ISEP, SINTEF, MDH, UNIFI

D2.1 – Multiview-based design of industrial multicore systems – initial version

Page ii Version 1.1 9 May 2014

Confidentiality: Public Distribution

DOCUMENT CONTROL

Version Status Date

0.0 Initial coarse-grained document structure 10 Nov 2013

0.1

First elaboration of user, WP3 and WP4 requirements and definition

of CONCERTO views requirements

4 March 2014

0.2 Added contribution from partners. Synchronization with D3.1, D4.1

and D4.4 concerning derived requirements.

14 March 2014

0.3 Added further contributions, addressed comments from partners

(UNIFI, BME, MDH, ISEP, UPD)

14 April 2014

1.0 Added further contributions, addressed comments from partners

(UPD, ATEGO).Version ready for internal review

15 April 2014

1.1 Reviewer’s comments addressed 9 May 2014


9 May 2014 Version 1.1 Page iii


TABLE OF CONTENTS

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

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

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

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

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

2 Project Background .................................................................................................................................................. 1

2.1 CHESS methodology and multi-view based design............................................................................................. 1 2.1.1 System Level Views ................................................................................................................................... 2 2.1.2 Requirement View ...................................................................................................................................... 2 2.1.3 PIM Views .................................................................................................................................................. 3 2.1.4 PSM Views ................................................................................................................................................. 5

2.2 The CHESS Toolset for Multiview-based design ................................................................................................ 6

2.3 Modelling at Instance Level ................................................................................................................................ 7

3 Constraints ................................................................................................................................................................ 9

3.1.1 Overview ..................................................................................................................................................... 9 3.1.2 Breakdown analysis .................................................................................................................................. 10

3.2 Requirements from WP3 and WP4.................................................................................................................... 12 3.2.1 About the Deployment View .................................................................................................................... 12 3.2.2 WP4.1 requirements .................................................................................................................................. 12 3.2.3 Wp4.4 Requirements................................................................................................................................. 17 3.2.4 WP3.1 Requirements ................................................................................................................................ 20

4 Plan for Realization ................................................................................................................................................ 24

4.1 Cross-Domain\Core Views ............................................................................................................................... 24

4.2 Domain-Specific Views ..................................................................................................................................... 31

4.3 Partners Involvement ........................................................................................................................................ 33

5 Conclusion ............................................................................................................................................................... 34

6 References ................................................................................................................................................................ 35


Page iv Version 1.1 9 May 2014


LIST OF FIGURES

Figure 1: CHESS editor ...................................................................................................................................................... 6 Figure 2: example of CSD, part 1 ....................................................................................................................................... 7 Figure 3: example of CSD, part 2 ....................................................................................................................................... 8 Figure 4: example of UML model derived from CSDs as used in CHESS ........................................................................ 8 Figure 5: example of UML instance model as it will be investigated in CONCERTO ...................................................... 9 Figure 6: example of Object Diagram ................................................................................................................................ 9

LIST OF TABLES

Table 1: D4.1 derived requirements.................................................................................................................................. 12 Table 2: D4.4 derived requirements.................................................................................................................................. 17 Table 3: D3.1 derived requirements.................................................................................................................................. 20 Table 4 – CHESS views vs WP4, WP3 cross domain “metamodel” reqs ........................................................................ 24 Table 5 – Cross-domain CONCERTO Views reqs ........................................................................................................... 28 Table 6 – CHESS views vs WP4, WP3 domain specific “metamodel” reqs .................................................................... 32 Table 7 - Domain-specific CONCERTO Views reqs ....................................................................................................... 33


9 May 2014 Version 1.1 Page v


LIST OF ABBREVIATIONS

ADL Activity of Daily Living

CHESS ML CHESS Modelling Language

CSD Composite Structure Diagram

EMF Eclipse Modelling Framework

PIM Platform Independent Model

PSM Platform Specific Model

SMP Symmetric MultiProcessing


Page vi Version 1.1 9 May 2014


EXECUTIVE SUMMARY

This document reports on the work conducted in Task 2.1 in Year 1 of the project, as

first iteration of the definition of the multi-view and cross-domain solutions for the

modelling structures and elements that have been identified at M12.

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

requirements captured in WP1 and the corresponding elaborations performed in WP3

and WP4.

The ultimate goal of the work in WP2 is the definition of a multi-view support for the

modelling of functional and extra functional properties.

This document covers the initial steps in the accomplishment of the above goal by

considering the results of the CHESS methodology as baseline and then by identifying

the extensions that are needed to satisfy the project requirements.


9 May 2014 Version 1.1 Page 1


1 INTRODUCTION

This report describes the multi-view requirements for the modelling structures and

elements required according to the user requirements and the corresponding

requirements elaboration performed in WP3 and WP4.

The main goal of the initial activities of WP2, to be carried out in Task 2.1, is to identify

the preliminary definition of the set of views needed in CONCERTO.

The CHESS methodology, with its dedicated modelling language and multi-view based

design, is considered as a baseline for the definition of the CONCERTO methodology.

In particular the CHESS language extensions needed in CONCERTO have been derived

in the other WPs by analysing and elaborating the end-user requirements and so by

identifying new required meta-model entities.

This report takes into account all of the aforementioned information and identifies how

CHESS views need to be extended to take into account the new meta-model entities

which have been identified of interest in CONCERTO.

An updated version of this deliverable documenting the multi-view requirements

implementation will be released at M24.

This report first introduces the CHESS views background while also highlighting some

known limitation (section 2), and then provides an impact analysis of the CONCERTO

requirements with respect to the views support (section 3). Finally, a plan for the

realization of the views is provided (section 4).

2 PROJECT BACKGROUND

The current section provides a high-level overview on the views available in the CHESS

framework [CHESSD232].

In this deliverable we will refer to the CONCERTO views as the CHESS reviewed and

extended ones, and vice versa.

2.1 CHESS METHODOLOGY AND MULTI-VIEW BASED DESIGN

The current CHESS methodology identifies two different levels of the software system

design: the user design level, called Platform Independent Model (PIM), and a lower

level design corresponding to the final implementation called Platform Specific Model

(PSM).

Taking into account the approach above, CHESS provides different views to be used at

different levels for the specification of the different concerns of the system under

development. In particular CHESS basically includes three different levels of main

design views:

1. System Level Views,


Page 2 Version 1.1 9 May 2014


2. Platform Independent Model (PIM) Views,

3. Platform Specific Model (PSM) Views.

All these views defined above are domain independent.

An additional view is the Requirement View which can be considered orthogonal to the

previous ones.

An elaboration of the views as currently defined in CHESS is given in the next sub-

sections.

2.1.1 System Level Views

The modelling language of reference to be used for system models in CHESS, and then

CONCERTO, is SysML [SysML]. No specific SysML restrictions\extensions or

guidelines for usage are currently identified in CHESS.

The SysML FoReVer profile and methodology [FOR] for system blocks and

software\hardware component’s contracts definition as well as the formal verification of

requirements refinement (the latter performed by invoking the OCRA tool1) has been

defined by Intecs in the context of the pSafeCer Artemis JU Grant Agreement nr

269265 project [PSAFE]; the possible usage in CONCERTO will be investigated.

In general system level views may be used by the system engineer to model the user

context, business concepts, use-cases, scenarios, product lines variability, analysis and

of course the overall, top level system design.

System models may consider hardware, software, data, personnel, procedures, and any

kind of facilities; support for this kind of modelling is not currently provided in CHESS,

it supposed to be modelled e.g by adoption of domain specific methodologies and

languages. This part will be extended in CONCERTO, in particular by taking into

account the domain specific requirements for system level modelling.

System level views shall also be used for the import or modelling of system elements

that are relevant to the software inside a specific system view and to enable traceability

between the system and the software design elements of the other views.

2.1.2 Requirement View

The Requirement view is used to collect requirements at model level and the SysML

Requirement Diagrams are used to support it. No specific SysML restrictions\extensions

have been identified in CHESS.

The Requirement view enables the modelling of the requirements at system, software

and hardware level. Software and hardware related requirements may be traced to high

level requirements defined in the system views.

1 https://es-static.fbk.eu/tools/ocra/




According to the SysML specification the relationships that may be used to associate

requirements to other requirements as well as to other model elements are the following:

• derive requirement to associate requirements to other requirements and capture

requirements at the upper level of the decomposition hierarchy.

• refine to associate requirements to a particular system scenario/state/mode; the refine

requirement relationship can be used to describe how a model element or set of

elements can be used to further refine a requirement. For example, a use case or activity

diagram may be used to refine a text-based functional requirement.

• satisfy to capture the fact that a model element satisfies a particular requirement.

• trace to describe a generic relation between a requirement and an arbitrary model

element for traceability reasons.

2.1.3 PIM Views

Platform Independent Model (PIM) Views are software level multi-concern design

views that are a proper part of the CHESS language definition.

The CHESS PIM views represent a platform independent space that users from the

different domains apply for the development of the multi-concern component-based

architectures.

Each view addresses a specific concern of the CHESS methodology; and at the same

time each view is allowed to refer other views to relate entities of different concerns.

PIM Views are described in the following sections, where for each view we also discuss

the UML diagrams to be used to model the information of the view itself.

2.1.3.1 Component View

In CHESS the ComponentView allows the modelling of components2 according to the

CHESS component model (see CONCERTO D2.2). The ComponentView is actually

the sum of two separate sub-views, the functional and the extra functional one: they are

introduced in the following sub-sections.

2.1.3.1.1 Functional View

The CHESS Functional view enables modelling of the functional specification of the

software components. According to the component-based design principles also

supported by UML [UML], each component comes with the definition of the owned

ports which in turn come with provided and required interfaces specification.

UML support for component-based design is imported in this view with some

limitation; in particular the limitations are applied to avoid UML-way of modelling of

real-time information, the latter being better supported by the UML profile for 2 In this document, according to the UML, with the term ‘component’ we refer to a software entity, if not diversely stat-

ed.




Modelling and Analysis of Real-Time Embedded Systems (MARTE) [MARTE], which

has been adopted in CHESS.

The following diagrams are used to work with the functional view:

Class diagram: to model components with their specific ports and

provided\required interfaces.

Composite Structure diagrams: to model composite functional components with

their specific ports. Moreover composite structure diagram is used in CHESS to

model the instantiation of the components and their bindings through provided

and required interface ports.

Activity diagram: to model the functional behaviour of a component’s operation,

in particular to model the operations (internal to the component or required)

called by a given provided operation.

State machine diagram: to model behaviour of a specific functional component or

its operation.

The usage of data flow ports were not addressed in the CHESS project.

2.1.3.1.2 Extra Functional View

The Extra Functional view enables the modelling of real-time and dependability

concerns. According to the separation of concerns principle, through this view

information from the functional view is extended with extra-functional information in a

way that the functional specification is not altered.

Entities modeled in this view are real time and dependable components, while entities

from the Functional View are imported in a read-only mode.

The following UML diagrams are used within this view:

Class diagram: to model dependability properties for the designed components.

Composite Structure diagrams: to model dependability and real time concerns for

the given components instances.

State Machine: to model the error model for a given software or hardware

component, according to the CHESS dependability profile [CHESSD232]

2.1.3.2 Deployment View

The Deployment view provides support for the modelling of the information related to

the deployment of software components on the hardware platform. Using this view the

user is able to represent two set of information:




the hardware entities and their relevant properties, in particular by using the

MARTE specific stereotypes defined in the Hardware Resource Modelling

(HRM)3 sub-profile,

the allocation of the software instances to the hardware entities.

The following diagrams are used within this view:

Class diagram: to model hardware entities, as types.

Composite Structure diagrams: to model hardware instances, their connections

and the allocation of component instances to hardware instances.

2.1.3.3 RealTimeAnalysis View

Not currently used at PIM level; in CHESS it is currently used to store the PSM entities

derived by model transformations which are needed to perform schedulability analysis

(see also section 2.1.4).

2.1.3.4 DependabilityAnalysis View

The DependabilityAnalysis View models the dependability analysis contexts. Several

different dependability analysis contexts are supported [CHESSD322]:

FTA, FMECA, FMEA, State-Based, Wide Data-flow, Call-graph, FPTC (Failure

Propagation Transformation Calculus) and its extension FI4FA4.

The DependabilityAnalysis View refers to the ExtraFunctional View for what concerns

the software and the Deployment View for what concern the hardware resources,

together with their extra-functional attributes, to be considered in the analysis.

The following diagram is used within this view:

Class diagram: to be used to define dependability analysis context.

2.1.4 PSM Views

According to the CHESS methodology the PSM owns the entities (i.e. container and

connectors) related to the target computational model; the aforementioned entities

implement the component’s extra functional constraints defined in the PIM view

[CHESSD232] and according to the CHESS methodology are automatically generated

through model transformation.

3 “MARTE-HRM is intended to serve for description of existing and conception of new hardware platforms, through

different views and detail levels. In a few words, the Hardware Resource Model is grouping most hardware concepts

under a hierarchical taxonomy with several categories depending on their nature, functionality, technology, and form”

(from MARTE specification). 4 FI4FA extends FPTC by enabling the analysis of I4 (incompletion, inconsistency, interference and impermanence)

failures as well as the analysis of the mitigations, needed to guarantee completion, consistency, isolation and durability




In CHESS no specific automatically generated diagram is currently available to allow

the modeller to graphically navigate the PSM model. The PSM model can be navigated

in the current CHESS editor by using a model tree-like explorer.

2.2 THE CHESS TOOLSET FOR MULTIVIEW-BASED DESIGN

During the CHESS project an implementation of the CHESS views was provided to the

modeller as an extension of the Eclipse Papyrus5 UML editor [CHESSASE12] (see in

Figure 1).

Figure 1: CHESS editor

In particular the CHESS views, i.e. their constraints definition regarding which

diagrams and entities are allowed in read\write mode, were mainly implemented

working at Papyrus editor level, i.e. directly interacting with the Papyrus code.

Unfortunately, currently there is no support by UML for any view specification. Only

SysML is offering some support at meta-model level for the specification of viewpoints

and views, but its extension mechanism is very general and provides only a limited and

informal set of definition capabilities (e.g. viewpoints are specified in a textual

language).

One of the main goals of CONCERTO to be addressed in WP2 (in particular task 2.1

and task 2.5) will be to (i) investigate/define a meta-model language for views

specification and (ii) provide a generic extension to a UML editor (most probably the 5 an open-source UML design environment (http://wiki.eclipse.org/MDT/Papyrus),




same Papyrus tool) in a way that the corresponding multi-view support needed for the

user at design level can be realized starting from the views specifications provided with

the aforementioned meta-model.

2.3 MODELLING AT INSTANCE LEVEL

In the CHESS component and deployment views the usage of the UML Composite

Structure Diagram is adopted for the modelling of the software and hardware instances,

respectively.

According to the UML, working at instances level is the proper way to address software

components connections through provided and required ports bindings6; moreover for a

given component the specification of some extra functional properties, like the real-time

ones, e.g. WCET and deadline, depends from the particular instantiation of the

component itself in the current architecture under design; so it has to be possible to edit

this kind of information for a given component at instance level.

Using composite structure diagram in place of object diagram could be a limitation in

case of hierarchies of components, the latter to be addressed in CONCERTO (see

CONCERTO D2.2 about required extension of the CHESS component model regarding

hierarchies of components).

Suppose for instance to have the following composite structure diagram (CSD) for

CompX, decomposed by one instance of CompY, where CompY owns a port portY.

Figure 2: example of CSD, part 1

Now let’s suppose to model a system composed by two instances of CompX (Figure 3)

and also suppose that we want to specify different extra-functional values for the two

ports portY.

6 According to the component based design, components types (in the UML sense) should not have fixed dependencies

between them. A component type specifies a formal contract of the services that it provides to its clients and those that

it requires from other components or services in the system in terms of its provided and required interfaces\ports. The

bindings between provided and required ports can then be modelled at instance level, allowing the reuse of the compo-

nents in different contexts. In other words UML associations should not be modelled between components types.




Figure 3: example of CSD, part 2

What we want to model is not possible at this point, and so having CSD’s only, because

portY is actually only one entity in the model (Figure 4); the CSD shows two entities

portY in the diagram but in the model they are actually a single one; in other words

there is no place in the model to store that one (extra functional) information related to

the portY owned by the Y instance inside x1:CompX and the other one is related to the

portY owned by the Y instance inside x2:CompX.

Figure 4: example of UML model derived from CSDs as used in CHESS

In order to have a full representation of the instances in the model we have to switch to

the UML instance level which can be derived from the information modelled through

the CDS’s; by doing so all the proper hierarchies and containments information can

have the corresponding instance level representation, at any decomposition level. A

simplified UML instance level model derived from the previous model is summarized

in the Figure 5; in this model it is possible to see that now portY have two

representations corresponding to the different CompY instance level occurrences. In this

case, information provided by the modeller about the two different ports instances can

be properly stored in the model.




Figure 5: example of UML instance model as it will be investigated in CONCERTO

A possible additional view to be offered to the modeller to represent this information

and work with it could be an UML object diagram (Figure 6) looking very similar to a

CSD. This kind of diagram is not currently available in CHESS, so an extension will be

investigated in CONCERTO (see elaboration of requirement R54 in section 3.1.2).

Figure 6: example of Object Diagram

3 CONSTRAINTS

The current section summarizes (i) the user requirements for supporting multiview-

based design and (ii) an elaboration of the requirements to derive view support specific

requirements. Please note the CHESS views cited before are taken into account in the

elaboration.

3.1.1 Overview

The following table summarises the user requirements mapped to Task 2.1.

Req.

No.

Overall

Priority

Category Requirement

28 SHALL Methodology CONCERTO shall use UML as the basis for its modelling

language.

64 SHALL Methodology A kind of diagram shall be identified to describe intra-

component flows between component ports within components.




Req.

No.

Overall

Priority

Category Requirement

65 SHALL Methodology At least composite structure diagrams and class diagrams shall

be used.

30 /

31

SHALL Methodology Open source Eclipse tools for capturing UML models and

EMF-compliant model representation and interchange shall be

used.

62 SHALL Methodology

+ Metamodel

+ M2M +

Analysis +

Code

generation

Matlab/Simulink use shall be supported to incorporate

behavioural modelling into CONCERTO functional

components.

36 SHALL Metamodel Some UML diagram / MARTE stereotypes shall be supported

to describe activity/dependencies.

46 SHALL Metamodel CONCERTO component model shall support the

implementation of TLC systems.

45 SHOULD Methodology An hierarchical compositions-components model should be

supported.

3.1.2 Breakdown analysis

R28: CONCERTO shall use UML as the basis for its modelling language.

CONCERTO views shall be based upon UML language and diagrams. This requirement

is already satisfied by the adoption of the CHESS views as baseline of the CONCERTO

views.

R64: A kind of diagram shall be identified to describe intra-component flows

between component ports within components.

UML activity diagrams shall be used to describe the behaviour of a given component

operation. In particular an activity diagram shall be used to describe the operations that

are invoked by the given operation; the invoked operations can be internal of the

component or required by the component itself through owned required ports. This

requirement is already satisfied by the CHESS functional view definition. CONCERTO

may investigate improvements about usage of activity diagram for the specification of

functional behaviour (R64_V1).

R65: At least composite structure diagrams and class diagrams shall be used.

Class diagrams shall be used to model software components in the component view and

hardware components in the deployment view. Composite structure diagrams shall be

used to model how a given component is actually decomposed by collaboration of

component instances. This requirement is already satisfied by the CHESS functional




view definition. An Instance level diagram shall also be used (see section 2.3 and the

elaboration of the R54 below).

Block diagrams, the SysML counterpart of the class diagram at system level, shall be

used in the system views to model system level entities, i.e. blocks, in the SysML

terminology (R65_V1). Internal Block diagram shall be used to model the

decomposition of a given block (R65_V2).

R30/31 - Open source Eclipse tools for capturing UML models and EMF-

compliant model representation and interchange shall be used.

CONCERTO views shall be based upon UML models implemented and serialized by

using the UML2 Eclipse plug-in. This requirement is already satisfied by the current

CHESS views implementation.

R62 - Matlab/Simulink use shall be supported to incorporate behavioural

modelling into CONCERTO functional components.

CHESS Functional View shall be extended to allow the importing of behavioural

Matlab/Simulink blocks (R62_V1). CHESS Functional View shall allow allocating

Matlab/Simulink blocks to software components’ operations (R62_V2).

R36 - Some UML diagram / MARTE stereotypes shall be supported to describe

activity/dependencies.

See the elaboration of R64.

R45 - An hierarchical compositions-components model should be supported.

See the elaboration of R65.

R45 - CONCERTO component model shall support the implementation of TLC

systems.

The modelling of TLC systems requires representing specific HW blocks, like GBE

switch layers, RJ45 Interface, A/D-D/A, and buses like I2C, MII, Ethernet cable,

SGMII. CHESS deployment view shall be extended to allow the modelling of TLC

hardware (MARTE support with respect to the TLC relevant properties shall be

investigated) (R46_V1).

R54 - Execution resources (tasks and mutexes, or others) should be allocated on

component ports.

Extra Functional view shall allow decorating the software component ports, at type and

instance level, with non-functional attributes. This requirement is already satisfied by

the CHESS extra-functional view definition. CONCERTO shall investigate

improvements about usage of some instance views for the specification of extra

functional properties upon port instance, in place of the current composite structure

diagram used as part of the CHESS extra-functional view (R54_V1); see also section

2.3.




3.2 REQUIREMENTS FROM WP3 AND WP4

The elaboration of user requirements undertaken by WP3 and WP4 is taken into account

in this section to analyse impacts upon views support as required by analysis and

platform specific concerns.

For the WP3 and WP4 derived requirements which have been assigned to the

Metamodel category, the CHESS (or new) views through which the metamodel entities

addressed by the requirements themselves can be created, updated, read and deleted are

listed.

3.2.1 About the Deployment View

In CONCERTO we consider the CHESS DeploymentView as composed by two distinct

sub-views:

Platform Specification View, for the modelling of the hardware entities with their

relevant properties (relevant for analysis and code generation purposes)

Allocation View, for the software to hardware allocation; this view reuses the

information made available in the Platform Definition View, as read-only.

The rationale of this decision is that the information regarding hardware design and

software to hardware allocation will be extended in CONCERTO; the two sub-views

mentioned before will make it possible to manage, document (also in the following

sections) and possibly implement this extension in a more effective way.

3.2.2 WP4.1 requirements

In this section the requirements table derived in CONCERTO D4.1 is showed. A

dedicated column has been added to describe impacts upon views specification and\or

about CHESS views to be used\extended for the specific metamodel information.

Table 1: D4.1 derived requirements

Req.

No.

Category Derived Requirement Impact Upon Views/Views where metamodel information

shall be managed

R6.1 Metamodel The modelling language shall support

the definition of different types of

schedulers and their parameters. In

particular there shall be support for

multi-core schedulers for SMP and

heterogeneous systems.

Platform Specification View.

R6.2 Metamodel The modelling language shall define

schedulability attributes for software

and hardware components in order to

provide all the information for the

analysis input at PIM level. In particular

the modelling language shall support

timing parameters such as period,

deadline, WCET, offset and jitter.

Platform Specification View, for what regard HW

entities. Usage of the Component Instance

View+ExtraFunctional View for what regards SW

components. This requirement has an impact upon the

list of the entities allowed to be managed. See R64.1.




R6.3 Metamodel The modelling language shall define a

schedulability analysis model (SAM) at

PSM level (protected resources,

schedulers, transactions, etc.)

A read-only and automatically generated representation

of the PSM entities could be provided to allow an easy

navigation of the latter. R6.3_V1

R6.4 Metamodel The modelling language shall allow to

describe computational hardware

resources (processor, memory, specific

resources) for single and multi-core

systems. For multi-core systems it shall

be possible to define combination of

cache(s), memory access and

communication busses.

Platform Specification View

R6.5 Analysis Analysis tools shall be exploited to

perform analysis for single core and

multi-core systems

R6.6 M2M Model transformations shall map the

PIM to the SAM and then to the

analysis input and produce traces

R6.7 Back-

propagation

Back-propagation transformation shall

map the analysis output to the PIM

using the traces produced by the model

transformations in 6.5. The analysis

output format supported shall be, at

least, that of MAST.

See R6.8_V1.


the specification of analysis results of

interest (metrics) such as CPU usage,

task activity monitoring, task response

delay, concurrency and throughput.

A dedicated view for the representation of real time

analysis results shall be defined (R6.8_V1).

R78.1 Metamodel The modelling language shall subset

MARTE to define hardware specific

concerns

PlatformSpecificationView

R78.2 Model

validation

The CONCERTO design space shall

enforce model constraints (i.e.

constraint the user actions) to ensure the

correctness of the model regarding

deployment concerns

The DeploymentView shall be extended with the

definition of constraints derived for R78.2

implementation (R78.2_V1)

R73.1 Deployment

View

The CONCERTO deployment view

shall allow the user to define several

execution nodes, containing single core

or multi-core processors, and to define

the allocation of the software

components to the execution resources

on these nodes. There shall be no

specific limitation when the user

deploys the components, either on a

single node or on several nodes.

Deployment View:

PlatformSpecificationView+AllocationView




R73.2 Deployment

View


assist the user to handle multi-core

deployment by enabling specific model

constraints for hardware components

The DeploymentView-PlatformSpecificationView shall

allow the user to enable\disable model constraints for

hardware entities (R73.2_V1)

R73.3 Deployment

view


assist the user to handle multi-core

deployment by enabling an automated

or semi-automated assignment process

to assign software components to

hardware components.

DeploymentView-AllocationView shall assist the user

for the (semi)automated support for task-to-CPU

mapping, with feedback on feasibility (R73.3_V1). This

high-level requirement will be elaborated in the next

version of this deliverable.

R1.1 Metamodel CONCERTO language shall support the

definition of modes of operation for

software components. The set of

components that operates under a

specific mode of operation constitutes a

scenario.

Functional View

R1.2 Analysis The analysis tools shall be able to

compute the response time based on the

user provided scenarios.

UML sequence diagrams shall be used to provide

scenarios to feed end-to-end response time analysis.

(R1.2_V1)

R1.3 M2M The model transformations shall

support modes of operation.

R1.4 Code

generation

The code generation shall generate

containers that are able to switch mode

of operation.

R4.1 Metamodel The modelling language shall be able to

define whether a timing constraint is a

hard or soft requirement.

Extra Functional View

R4.2 Analysis The timing analysis tool shall support

hard constraints

R4.3 Platform The programming language shall

understand and support hard real time

constraints

R4.4 Run-time

monitoring

The execution environment shall

enforce hard real time constraints

R4.5 M2M The model transformations shall take

into account hard real time constraints

R4.6 Code

generation

The code generators shall take into

account hard real time constraints

R35.1 Metamodel This requirements extends R6.1. The

modelling language shall support fix

priority scheduler, time-table driven

scheduler and the composition of both

of them (two-level scheduler).





R35.2 Deployment

View


allow to decorate processing nodes and

cores with schedulers


R35.3 Analysis The analysis tool shall support the

schedulers as per R35.1

R35.4 Platform The execution platform shall support

schedulers as per R35.1

R67.1 Metamodel The modelling language shall define a

Component Model which adopts the

Ravenscar Computational Model. In

particular the PSM shall comply with

Ravenscar.

R67.2 Platform The generated source code architecture

shall conform to the Ravenscar profile

R67.3 Platform The execution platform shall support

the Ravenscar profile


the definition of configuration

information for the underlying

platforms.


R23.2 Deployment

view

That CONCERTO design space shall

assign configuration information to the

nodes of the platform architecture.


R23.3 Model

Validation

That assign configuration shall also be

validated prior to the code generation

R23.4 Code

generation

Code generators shall understand the

configuration and generate code

accordingly.

R23.5 M2M Model transformations shall understand

the configuration and transform the

model accordingly.

R34.1 Metamodel The CONCERTO modelling language

shall support the definition of extra-

functional properties compatible with

the timing properties required by the

ASTRIUM computational model

Component-ExtraFunctionalView

R36.1 Metamodel CONCERTO shall extend the support to

describe activity/dependencies offered

by CHESS if necessary.

Covered by R64.1

R3.1 Model

validation

CONCERTO model validation shall

raise precise messages when the model

contains syntactic errors.

See R44.2_V1 in Table 3




R3.2 M2M Model transformations shall issue

precise error messages when a required

property is missing or incorrect

R42.1 Metamodel The modelling language should define

communication attributes for software

and hardware components.

A System Communication-Matrix View should be

provided as part of the Deployment View to allow

specifying the frames running on the networks described

in the topology and the contents and timing of those

frames. The view should allow to assign data exchanged

between software component, modelled in the Functional

View, to precise slots on a given frame (R42.1_V1).

R42.2 Model

validation


enforce model constraints (i.e.

constraint the user actions) to ensure the

correctness of the model regarding

communication concerns

See R 42.1

R71.1 Metamodel The modelling language should allow to

specify core reservation for software

components.

Allocation view

R71.2 M2M Core reservation should be taken into

account in model transformations

Allocation view

R71.3 Deployment

view

Core reservation should be taken into

account in the assignment process

(R73.3)

AllocationView

R72.1 Metamodel The modelling language should allow to

specify processor affinity for (critical)

software components.

AllocationView

R72.2 M2M Processor affinity should be taken into

account in model transformations

R72.3 Deployment

view

Processor affinity should be taken into

account in the assignment process

(R73.3)

AllocationView

R74.1 Deployment

view

The assignment process (R73.3) should

be based on an assignment policy or

heuristic that find the best deployment

configuration for maximum

schedulability.

R26.1 Metamodel The modelling language should define

resources like buffers, semaphores and

their non-functional properties (like,

size, queuing policy) and services to

manipulate these resources (intra and

inter partition). The communication

mechanisms shall then be instantiated to

the specific domain of interest.

Component – Extra Functional view




R26.2 Component

libraries

The modelling language should be able

to represent resources used in

Aerospace like ARINC653 buffers,

semaphores and their non-functional

properties (like size, queuing policy)

and the services to manipulate these

resources.

See R26.1

R54.1 M2M The model transformation (PIM to

PSM) should allocate execution

resources to the component ports.

O1.1 Metamodel The modelling language shall support

the description of parallel tasks.

Component – Extra Functional view

O1.2 M2M Model transformations between the

PIM, the PSM and the analysis tools

inputs should be extended to support

attributes specific to the description of

parallel tasks

O1.3 Analysis The analysis tools shall be able to

analyse the schedulability of parallel

tasks and the performances that can be

expected by these tasks executing on a

multi-core platform.

O1.4 Code

generation

The run-time environment should

provide support for fine-grained parallel

tasks and the code generation

mechanisms should be adapted

accordingly

3.2.3 WP4.4 Requirements


dedicated column has been added to describe impact upon views specification.


Req.

No.

Category Derived Requirement Impact Upon Views/Views where

metamodel information shall be

managed

R5.1 Metamodel The modelling language shall define CPU, system,

and task utilization attributes.

Platform Specification View (CPU

utilization). Component-Extra

Functional View (system, task

utilization attributes)

R5.2 Run-time

monitoring

Mechanisms shall be provided by the run-time

environment to check and potentially enforce that

the system and its tasks do not exceed their

predefined utilization

R5.3 Code

generation

Run-time monitors must be generated to monitor

CPU, system, and task utilization budgets




Req.

No.



managed

R5.4 Code

generation

Handlers must be generated to handle potential

utilization budget violations

R12.1 Platform The runtime environment shall provide support to

detect the occurrence of system events

R12.2 Platform The runtime environment shall be able to capture

system events for runtime verification

R12.3 Platform The runtime environment shall be able to record the

system events in execution traces for further

analysis.

R12.4 Analysis An analysis tool shall be provided to process and

analyse the execution traces in order to detect

violations of functional and extra functional

properties and identify unexpected system behaviour

R12.5 Back-

propagation

Model transformation mechanisms are required to

back propagate the results of the analysis tools to the

user model.

A view showing the results of the

analysis of the execution traces shall be

provided (R12.5_V1).

R70.1 Metamodel The modelling language shall provide attributes to

describe memories.



describe the configurations of the memories by

defining per-task memory budgets.

Allocation View

R70.3 Platform The runtime environment shall provide an API that

enforces memory budgets of components.

R70.4 Run-time

monitoring +

Code

generation

Run-time monitors relying on the API provided by

the runtime environment and responsible for

checking task memory budget compliance, shall be

generated.

R70.5 Back-

propagation

Per-task memory utilisation at run-time shall be back

propagated to the user-model.

A view showing the Per-task memory

utilisation at run-time shall be provided

(R70.5_V1).

R80.1 Metamodel The modelling language shall contain attributes to

specify access policies, as well as to attach these

policies to components.

Component-Extra functional view

R80.2 Platform The runtime environment shall provide an API for

enforcing and checking access policies.




Req.

No.



managed

R80.3 Run-time

monitoring +

Code

generation

Run-time monitors for checking and enforcing

access policies relying on the API provided by the

runtime environment, shall be generated.


define preconditions that must be respected before

performing certain actions.

Functional view

R89.2 Run-time

monitoring +

Code

generation

Run-time monitors shall be generated to check that

defined preconditions are respected before

performing an action.

R90.1 Run-time

monitoring +

Code

generation

Run-time monitors shall be generated to check ADL

samples and raise an alert in case of an unacceptable

deviation.


define unacceptable deviation of ADL samples.

A view shall be provided to allowing

working with the definition of ADL

samples (R90.2_V1).

R91.1 Platform The runtime environment shall provide an API that

allows the inclusion of user-defined events within

execution traces.

R91.2 Platform Events shall be logged with the corresponding

timestamp.

R91.3 Platform Execution traces shall record (1) scheduling based

events, (2) task interactions related events and (3)

user-defined events.


define task deadlines.



register handlers called in case of a deadline miss.



checking task deadlines.


registering handlers called in case of a deadline

miss.

Component Functional and Extra

Functional View (one possibility is that

the handler is defined in the functional

view, then it is associated to the

deadline miss in the extra functional

view).




Req.

No.



managed


define expected flow between inputs and outputs of

components.

Functional view

R95.2 Metamodel Policies that govern valid information flows between

component inputs and outputs shall be defined in the

functional view.

Functional view

R95.3 Run-time

monitoring +

Code

generation

The runtime environment shall implement runtime

monitors that are able to check if the flow between

components respects the prescribed policies.

3.2.4 WP3.1 Requirements


dedicated column has been added to describe impact upon views.


Req.

No.

Category WP 3.1 Derived Requirement Impact Upon Views/Views where metamodel

information shall be managed

R2.1 Metamodel CONCERTO shall allow availability

information to be specified for system

elements

SystemView-DependabilityView. A

DependabilityView shall be added to the

SystemView (R2.1_V1)

R2.2 Metamodel CONCERTO should allow redundancy and fault-

tolerance mechanism to be specified System View, for the system level entities.

R2.3 Metamodel +

Methodology CONCERTO should allow error propagation

information between system entities to be

specified.

SystemView-DependabilityView

R2.4 Metamodel +

Methodology CONCERTO should allow to specify/derive

dependability information at system level

based on information specified on

subcomponents

SystemView-DependabilityView

R2.5 M2M + Analysis CONCERTO shall allow the evaluation of

system-level availability

R14.1 Design space CONCERTO shall define views where

safety analysis results are shown

Dependability Analysis View shall be extended to

provide safety analysis results. (R14.1_V1)

R14.2 Metamodel CONCERTO shall provide modelling

attributes to support the back-annotation of

dependability properties evaluated by the

analysis techniques with particular focus on

availability and safety

See R14.1_V1.

Dependability Analysis View shall be extended to

provide availability analysis results. (R14.1_V2)




Req.

No.



R14.3 Backpropagation CONCERTO shall provide back-annotation

of properties evaluated by dependability

analysis techniques with particular focus on

availability and safety

R23.1 Design space CONCERTO shall capture domain specific

configuration information necessary to generate

code for domain-specific platforms


R23.2 Deployment Domain-specific configuration information

shall be assigned to the nodes of the

platform architecture in the Deployment

View


R23.3 Model Validation Domain-specific configuration information shall

be validated prior any code generation step is

attempted

R17.1 Code generation Telecare domain-specific configuration shall be

taken into account when deriving intermediate

models for code generation

R18.1 Code generation Mobile devices domain-specific configuration

shall be taken into account when deriving

intermediate models for code generation


R25.1

Metamodel + Component libraries

The modelling language shall allow defining

hardware devices like sensors, mobile local hubs


R25.2

Metamodel + Component libraries

The modelling language shall allow defining

network services to represent, for example,

centralized decision support systems.


R25.3 Metamodel + Component libraries

The modelling language should be

extendable in order to provide means to

define vendor specific details.


R25.4 Metamodel +

Component libraries The modelling language should support dynamic

reconfiguration of allocations for the telecare

domain.

Allocation View

R68.1 Methodology +

M2M The transformation chain definition language

shall support: fully automated, semi-automated

and completely user-driven transformation steps.

A Transformation Process View shall be

introduced to support the transformation chain

workflow (R68.1_V1).

R68.2 Methodology +

M2M CONCERTO shall provide a modelling language

to precisely define the PIM-to-PSM

transformation chain as a workflow.

See R68.1_V1

R50.1 Analysis The analysis framework should provide a

notion of safety/risk model encapsulation to

support compositional safety/risk analysis

from which computational models can be

established.

System-DependabilityView




Req.

No.



R50.2 Analysis The analysis framework should allow

analysts to configure/define a concrete

computational model/formula at design time

for aggregation of safety properties

specifically tailored to the particular system

under analysis.


R51.1 Metamodel The modelling language should provide

constructs for associating safety/risk

properties with all types of components,

including components that represent

physical equipment or

human/organizational elements.


R44.1 Metamodel CONCERTO shall support the detailed

specification of dependability attributes

(with particular focus on

safety/reliability/availability), such as

failure rates, failure modes, etc.

System-DependabilityView, Component-Extra

functional View, PlatformSpecificationView

R44.2 Metamodel + Model

Validation CONCERTO should ensure the consistency

between dependability properties (with

particular focus on

safety/reliability/availability) specified at

different levels of detail

A validation view shall be used to highlight

validation problems (R44.2_V1)

R44.3 Metamodel + Back

Propagation CONCERTO should ensure the consistency

between the dependability properties (with

particular focus on

safety/reliability/availability) back-

annotated in the model as a result of the

analysis, and properties which are added by

the modeller.

See R44.2_V1

R39.1 Metamodel CONCERTO shall support the association of

ASILs (Automotive Safety Integrity Levels) on

model elements

Requirement View, SystemView-

DependabilityView, Platform Specification View,


R39.2 Metamodel +

Methodology CONCERTO shall support the derivation of the

ASIL of a model element from already specified

information, when possible

This should be possible in the SystemView-

DependabilityView, Platform Specification View,


R53.1 Metamodel CONCERTO shall allow the dynamic

properties of barriers to be specified through

parameterization in the sense that safety

properties of components can depend on

external data.

System View

R53.2 Execution Platform CONCERTO shall allow the dynamic properties

of barriers to be checked.

R33.1 Metamodel CONCERTO shall support at least two major

types of components according to their

criticality – “critical” components, and

“non-critical” components

See R39.1 above Concerning criticality, ASIL is

considered in the first definition of this

deliverable. Other kind of criticality specification

will be possibly addressed during the project

according to demonstrators needs.




Req.

No.



R33.2 Metamodel The critical components shall be further

subdivided using SIL

See R39.2 above. Concerning criticality, ASIL is

considered in the first definition of this

deliverable. Other kind of criticality specification

will be possibly addressed during the project

according to demonstrators needs

R61.1 Metamodel CONCERTO modelling language shall allow to

represent argumentation of independence for the

redundant elements, e.g., in the form of

independency requirements

SystemView-DependabilityView, Platform

Specification View, Component-Extra functional

view

R61.2 Constraint CONCERTO modelling environment shall be

able to check ISO 26262 compliant ASIL

decomposition rules

See R44.2_V1

R61.4 Code generation Automotive domain-specific configuration shall

be taken into account when deriving intermediate

models for code generation

R60.1 Metamodel Autosar component model shall be mapped to

the CONCERTO component model

Some views could be impacted based upon

additional concepts that could be introduced in

the modelling language. Information about the

impact of this requirement upon the views will be

provided in the next release of this deliverable.

R62.1 Design space/

Metamodel CONCERTO shall be able to map Simulink

functional blocks to components behaviour See R62_V1

R9.1 Metamodel +

Methodology CONCERTO should support the specification of

data flow in the system architecture System view/Functional View

R9.2 Metamodel +

Methodology CONCERTO should support the specification of

control flow in the system architecture System view/Functional View

R9.3 Metamodel CONCERTO should support the specification of

faults for fault propagation analysis. System-Extra functional view, Component-Extra

Functional View, Platform Specification View

R9.4 M2M + Analysis CONCERTO should provide analysis techniques

to perform fault propagation analysis based on

data flow and control flow information

R11.1 Back Propagation Availability analysis results should be

propagated in the user modelling space See R14.1_V1

R20.1 Code generation CONCERTO should support the definition of

M2C transformation chains

R43.1 Metamodel/ Methodology

Autosar specification for diagnostic attributes

specification should be checked and mapped to

CONCERTO.

Component-ExtraFunctionalView


CONCERTO should give the possibility to

specify a Network Communication matrix

in order to detail how functional

communication (e.g. communication

between the Body Computer and the Engine

Control ECUs) and extra functional

communication (e.g. error diagnostic

messages) should be delivered (Autosar

specification should be checked here).

See R42.1_V1 (from WP4.1)




Req.

No.




CONCERTO should support the import of DBC

format specifying the CAN networks and

messages infrastructure.


R52.3 Metamodel The modelling language should allow safety

properties to be associated with (and

retrieved from) components/containers at all

nesting levels.

System-Extra functional view, Component-Extra

Functional View, Platform Specification View.

R75.1 M2M An Autosar compliant Basic Software

should be used in order to demonstrate the

use of CONCERTO in an Autosar project,

as alternative an Autosar model should be

generated starting from the CONCERTO

PSM (the latter in case an Autosar

compliant Basic Software will not be

available in the project)

R86.1 Platform The compatibility of CONCERTO PSM

should be investigated wrt. OSEK

R85.1 Platform CONCERTO PSM should support CAN,

LIN, FlexRay

Platform Specification View (for the modelling of

CAN, LIN and FlexRay network)

4 PLAN FOR REALIZATION

This section provides information about the plan for realization of the requirements

concerning the extensions of the CHESS views elaborated in the previous sections.

4.1 CROSS-DOMAIN\CORE VIEWS

Taking into account the analysis done in section 3.2, the cross-domain meta-model

entities identified in the WP3 and WP4 and the CHESS views where the entities

themselves shall be addressed are mapped in the following table. In other words the

table formalizes the extensions of the CHESS views required by the CONCERTO meta-

model needs.

Table 4 – CHESS views vs WP4, WP3 cross domain “metamodel” reqs

View WP4, WP3

refined

Requirements

with Category

“Metamodel” to

be managed

through the

view

Metamodel information to be managed

through the view

Comments

SystemView

R9.1 (WP3.1) Data flow Usage of SysML block

diagram and internal

block diagram




View WP4, WP3

refined

Requirements

with Category

“Metamodel” to

be managed

through the

view


through the view

Comments

R9.2 (WP3.1) Control flow Usage of UML Activity

diagram

System-

DependabilityView

(new sub-view, see

R2.1_V1)

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

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

components

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

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

analysis).

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

The management of these

concepts through the

component-extra

functional view and

deployment view will be

evaluated during the

project.project.

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

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

R95.1 (WP4.4)

R9.2 (WP3.1)

Attributes to define expected flow between

inputs and outputs of components

Usage of Activity

diagrams

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

between component inputs and outputs shall be

defined.

Usage of Activity

diagrams

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

respected before performing certain actions.




View WP4, WP3

refined

Requirements

with Category

“Metamodel” to

be managed

through the

view


through the view

Comments

R9.1 (WP3.1) Data Flow

Component-

ExtraFunctionalView

R6.2, R94.1

(WP4.1)

Schedulability attributes for software

components such as period, deadline, WCET,

offset and jitter.

Requires Functional View

(instance level) in read-only

mode.

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.

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)





analysis).

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

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

redundant elements

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.

Deployment-

PlatformSpecification

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

concerns




View WP4, WP3

refined

Requirements

with Category

“Metamodel” to

be managed

through the

view


through the view

Comments

View 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

The information to be

modelled need to be

elaborated.

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.

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

hubs

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

centralized decision support systems

R44.1 (WP3.1)





analysis).




View WP4, WP3

refined

Requirements

with Category

“Metamodel” to

be managed

through the

view


through the view

Comments

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

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

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)

Some kind of hardware

could be useful also for

other domains, so for the

moment we keep this

extension as cross-

domain.

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

Finally, the following table lists all the requirements about the definition of new cross-

domain views\diagrams, new features and constraints upon existing cross-domain views

resulting from the elaboration done in section 3; the involvement of the CONCERTO

partners with respect to each requirement is also expressed.

Table 5 – Cross-domain CONCERTO Views reqs

View/Diagram Req. No. Overall

Priority

Derived Requirement Partners

involved

Comments





Priority


involved

Comments

CHESS Views

RV1 SHALL Current CHESS views shall

be extended to manage the

new cross-domain

metamodel entities required

by CONCERTO (see Table

4).

INT, UPD INT and UPD will provide

support for views definition

and implementation (all

views)

SystemView

R2.1_V1 SHALL

An extra functional-

dependability view shall be

added on top of the

SystemView to manipulate

dependability information

at system level.

MDH,

INT,UNIFI

MDH/UNIFI: interested in

contributing to the extra-

functional system view

aimed at supporting domain

independent as well as do-

main-automotive specific

hazards analysis

Deployment-

Allocation

View

R78.2_V1 SHALL

The Allocation View shall

be extended with the

definition of constraints

derived for R78.2

implementation

UPD

Deployment-

PlatformSpeci-

ficationView

R73.2_V1 SHALL

The

PlatformSpecificationView

shall allow the user to

enable\disable model

constraints for hardware

components

BME,

ISEP

BME is interested in

contributing the HW specific

parts as it is an integral part

of the telecare system

configuration

Deployment-

PlatformSpeci-

ficationView

R73.3_V1 SHALL

DeploymentView-

AllocationView shall assist

the user for the

(semi)automated support

for task-to-CPU mapping,

with feedback on feasibility

ISEP, UPD

Analysis View

R12.5_V1 SHALL A view showing the results

of the analysis of the

execution traces shall be

provided

ISEP

RealTime

Analysis View

R70.5_V1 SHOULD A view showing the Per-

task memory utilisation at

run-time shall be provided

ISEP

RealTime

Analysis View

R6.8_V1 SHALL

A dedicated view for the

representation of real time

analysis results shall be

defined

ISEP, UPD

Function-

alView\RealTi

me Analysis

View

R1.2_V1 SHALL

UML sequence diagrams

shall be used to provide

scenarios to feed end-to-

end response time analysis

INT, ISEP INT will provide support for

the definition of a profile of

the UML sequence diagram.





Priority


involved

Comments

Dependability

Analysis View

R14.1_V1 SHALL

Dependability Analysis

View shall be extended to

provide safety analysis

results

MDH,UNI

FI

MDH: focus on

software..allocation of

system requirements to

software components

Dependability

Analysis View

R14.1_V2 SHALL

Dependability Analysis

View shall be extended to

provide availability

analysis results

UNIFI

PSM View

R6.3_V1 SHALL

A read-only and

automatically generated

representation of the PSM

entities could be provided

to allow an easy navigation

of the latter.

INT

Transformation

Process View

R68.1_V1 SHALL A Transformation Process

View shall be introduced to

support the transformation

chain workflow

BME This view would be

responsible to define the

different model based

workflows (required for the

different case-studies)

Validation

View

R44.2_V1

SHALL A validation view shall be

used to highlight validation

problems

INT,UNIFI INT will provide support for

view definition and imple-

mentation.

UNIFI: interested in defining

properties to be checked with

respect to dependability in-

formation and its consistency

Function-

alView\Activity

diagram

R64_V1 SHALL CONCERTO may

investigate improvements

about CHESS usage of

activity diagram for the

specification of functional

behaviour

ISEP ISEP: interested in using the

activity diagrams for the

description of parallel task

System View

R65_V1 SHALL Block diagrams shall be

used in the system view to

model system level entities,

i.e. blocks, in the SysML

terminology

MDH, INT INT will provide support for

view definition and

implementation. The need of

a SysML profile will be

invesigated.

MDH will act as reviewer

and contributor in the case of

support for ISO26262.

SystemView

R65_V2 SHALL Internal Block diagram

shall be used to model the

decomposition of a given

block

INT INT will provide support for

view definition and imple-

mentation. The need of a

SysML profile will be inve-

sigated.





Priority


involved

Comments

Functional

View

R62_V1 SHALL CHESS Functional View

shall be extended to allow

the importing of

behavioural

Matlab/Simulink blocks

MDH, INT

BME,

UPD

MDH,INT and UPD: we will

investigate to which extent

Matlab/SimulinkSimulink

behaviour can be imported in

CONCERTO

BME has done research in

the area of Matlab/Simulink

model import/export to the

EMF domain. We might be

interested to extend our

importer to support

behaviour descriptions also

(e.g., Stateflow)

Functional

View

R62_V2 SHALL CHESS Functional View

shall allow allocating

Matlab/Simulink blocks to

software components’

operations

INT, UPD INT and UPD will provide

support for definition and

implementation.

Component-

View-

ExtraFunction-

alView

R54_V1 SHALL CONCERTO shall

investigate improvements

about usage of some

instance views for the

specification of extra

functional properties upon

port instance, in place of

the current composite

structure diagram used as

part of the CHESS extra-

functional view

INT,UNIFI INT will provide support for

definition and implementa-

tion.

UNIFI: interest in investigat-

ing instance-level modelling

of dependability properties

4.2 DOMAIN-SPECIFIC VIEWS

Taking into account the analysis done in section 3.2, the domain-specific meta-model

entities identified in the WP3 and WP4 and the CHESS views where the entities

themselves shall be addressed (in a dedicated domain sub-view) are addressed in the

following table. The goal here is to define domain specific extensions to be

implemented on top of the current CHESS views.




Table 6 – CHESS views vs WP4, WP3 domain specific “metamodel” reqs

View Domain WP4, WP3

refined

Requirements

with

Category

“Metamodel”

to be

managed

through the

view

Metamodel information to be

managed through the view

Comments

RequirementView

Automotive R39.1

(WP3.1)

ASIL, as requirement property. A cross-domain

view will be also

considered in case

support regarding

‘generic’ SIL

properties will be

provided in WP3.

SystemView Petroleum R53.1 Barriers, Dynamic properties of

barriers

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

The information to

be modelled need to

be elaborated.

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

Deployment-

Allocation View

Telecare R25.4

(WP3.1)

Dynamic reconfiguration of allocations




Finally, the following table lists all the requirements about definition of new domain-

specific views\diagrams and constraints upon existing domain-specific views resulting

from the elaboration done in section 3; the involvement of the CONCERTO partners

with respect to each requirement is also expressed.

Table 7 - Domain-specific CONCERTO Views reqs

View/Diagra

m

Req. No. Overall

Priority


involved

Comments

CHESS

Views

RV2 SHALL CHESS Views shall be

extended to support

domain-specific views to

manage the new domain-

specific metamodel

entities as required by

CONCERTO (see Table

3).

INT,

SINTEF,

BME,

UPD

INT and UPD: support for views

definition and implementation

(all views)

SINTEF: support for Petroleum

views definition

BME: support for Telecare views

definition.

Automotive -

System

Communica-

tion Matrix

R42.1_V1 SHALL

A System

Communication-Matrix

View should be provided

as part of the Deployment

View to allow specifying

the frames running on the

networks described in the

topology and the contents

and timing of those

frames. The view should

allow to assign data

exchanged between

software component,

modelled in the Functional

View, to precise slots on a

given frame

INT Automotive domain

INT: support for views definition

and implementation

Telecare -

ADL view

R90.2_V1 SHOULD A view should be

provided to allowing

working with the

definition of ADL samples

(R90.2_V1).

BME Telecare domain.

ADL is not connected so close to

the medical and telecare system

modelling rules only. It could be

useful to represent the

functionality of the systems in the

other domains. So extension of

this view to other domain will be

investigated.

4.3 PARTNERS INVOLVEMENT

The information about partner’s involvement reported in the tables above can be

summarized and elaborated in the following:

MDH will contribute to the development/enhancement of separation of concerns

techniques based on design views. These include the investigation of new views

needs and their specification.




BME will give support to the definition of the cross-domain views and the

evaluation of their applicability to the telecare domain. BME will provide

support for telecare domain specific views definition.

SINTEF will provide support for the description of the petroleum domain view

answering questions around views like involved stakeholders, goal, concerns

addressed, input required from other views.

INT will provide general support to views definition and implementation. INT

will provide contribution for the development of the automotive specific views.

UNIFI will provide support for the definition of the properties to be checked

with respect to dependability information and its consistency.

ISEP will provide support for the definition of the properties to be checked with

respect to temporal analysis.

UPD will provide general support for views definition and implementation and

will focus upon the deployment view for software to hardware allocation and

upon the integration with Matlab\Simulink.

Moreover ATEGO will participate to the future definition of the additional views of

CONCERTO to implement in parallel and realize some intermediate decisions in a

prototype of Artisan Studio, according to the WP5 needs.

5 CONCLUSION

This deliverable elaborates requirements about the CONCERTO needs for multi-view

based design.

Requirements directly coming from WP1 and requirements elaborated in WP3 and WP4

have been considered. In particular CHESS views extensions have been identified to

address new meta-model entities of interest in CONCERTO. Also new views not

currently available in CHESS have been identified.

The list of all the requirements about domain-specific and cross-domain views\diagrams

have been derived (Table 5 and Table 7) and it will be used to feed the implementation

phase.

For each CHESS view planned extension and new view definition, the involvement of

the CONCERTO partners has been specified.




6 REFERENCES

[CHESSASE12] A.Ciccehti, F.Ciccozzi, S.Mazzini, S.Puri, M.Pannuzio, A.Zovi,

T.Vardanega, “CHESS: a Model-Driven Engineering Tool Environment for

Aiding the Development of Complex Industrial Systems”, 2012 Proceedings of the 27th

IEEE/ACM International Conference on Automated Software Engineering.

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

Version 1.0, 10 January 2012, Public Distribution, available at http://www.chess-

project.org/page/results

[CHESSD322] D3.2.2 - Transformations and analysis support to dependability -

Final Version (v2.0) 27 December 2011, Public Distribution, available at

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

[FOR] http://www.intecs.it/CSC2013/presentations/CSC13_FBK.pdf

[MARTE] http://www.omg.org/spec/MARTE/1.1/

[PSAFE] D3.2.1/D3.2.2, “Design and implementation of the support to the design of

components architectures with the specification of certification properties and safety

contracts” “Design and implementation of the support to the validation and verification

of the components and their composition”, Public Distribution, v1.0, 2013-1-14,

pSafeCer, JU Grant Agreement nr 269265, available at

http://www.safecer.eu/text/view/50/

[SysML] http://www.omg.org/spec/SysML/1.3/

[UML] Object Management Group, (August 2011). OMG Unified Modelling Language,

Superstructure, Version 2.4.1, Revision Task Force, OMG document number ptc/2010-

11-13




http://www.omg.org/spec/MARTE/1.1/

http://www.safecer.eu/text/view/50/

http://www.omg.org/spec/SysML/1.3/

Documents

D2.1 Multiview-based design of industrial multicore ...api.ning.com/files/oj4MhhoM4fTPkB5E0sgB7HBWSDSKfFcZMu5ZonlVeyZdJ... · D2.1 – Multiview-based design of industrial multicore