This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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
D2.1 – Multiview-based design of industrial multicore systems – initial version
9 May 2014 Version 1.1 Page iii
Confidentiality: Public Distribution
TABLE OF CONTENTS
List of Figures .................................................................................................................................................................. iv
List of Tables .................................................................................................................................................................... iv
List of Abbreviations ........................................................................................................................................................ v
Executive Summary ......................................................................................................................................................... vi
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
D2.1 – Multiview-based design of industrial multicore systems – initial version
Page iv Version 1.1 9 May 2014
Confidentiality: Public Distribution
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
D2.1 – Multiview-based design of industrial multicore systems – initial version
9 May 2014 Version 1.1 Page v
Confidentiality: Public Distribution
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
D2.1 – Multiview-based design of industrial multicore systems – initial version
Page vi Version 1.1 9 May 2014
Confidentiality: Public Distribution
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.
D2.1 – Multiview-based design of industrial multicore systems – initial version
9 May 2014 Version 1.1 Page 1
Confidentiality: Public Distribution
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,
D2.1 – Multiview-based design of industrial multicore systems – initial version
Page 2 Version 1.1 9 May 2014
Confidentiality: Public Distribution
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/
D2.1 – Multiview-based design of industrial multicore systems – initial version
9 May 2014 Version 1.1 Page 3
Confidentiality: Public Distribution
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.
D2.1 – Multiview-based design of industrial multicore systems – initial version
Page 4 Version 1.1 9 May 2014
Confidentiality: Public Distribution
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:
D2.1 – Multiview-based design of industrial multicore systems – initial version
9 May 2014 Version 1.1 Page 5
Confidentiality: Public Distribution
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]:
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
D2.1 – Multiview-based design of industrial multicore systems – initial version
Page 6 Version 1.1 9 May 2014
Confidentiality: Public Distribution
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),
D2.1 – Multiview-based design of industrial multicore systems – initial version
9 May 2014 Version 1.1 Page 7
Confidentiality: Public Distribution
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.
D2.1 – Multiview-based design of industrial multicore systems – initial version
Page 8 Version 1.1 9 May 2014
Confidentiality: Public Distribution
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.
D2.1 – Multiview-based design of industrial multicore systems – initial version
9 May 2014 Version 1.1 Page 9
Confidentiality: Public Distribution
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.
D2.1 – Multiview-based design of industrial multicore systems – initial version
Page 10 Version 1.1 9 May 2014
Confidentiality: Public Distribution
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
D2.1 – Multiview-based design of industrial multicore systems – initial version
9 May 2014 Version 1.1 Page 11
Confidentiality: Public Distribution
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