D2.7 Analysis and back-propagation of properties for ...api.ning.com/files/HrJMLaNSVNiLLW3cp6PqlCkfWXH3lRkF6LyqHo*M0f-7... · D2.7 – Analysis and back-propagation of properties
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
Project Partners: AENSys, Aicas, Atego, Budapest University of Technology and Economics,
D2.7 – Analysis and back-propagation of properties for multicore systems - Final Version
Version 1.0
3 November 2015
Final
Public Distribution
Airbus Group (EADS), INT, MDH, UNIFI, UPD
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
Page ii Version 1.0 3 November 2015
Confidentiality: Public Distribution
DOCUMENT CONTROL
Version Status Date
0.1 Initial document structure taken from the Y2 first release of the deliv-
erable, to be reviewed and extended. First set of possible revi-
sions\extensions added.
15 Sep 2015
0.2 All sections filled. Ready for internal review 22 Oct 2015
0.3 Review by Airbus Group (EADS) and TCS 26 Oct 2015
1.0 Final version with comments addressed. New Appendix C about
MARTE usage.
03 Nov 2015
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
3 November 2015 Version 1.0 Page iii
Confidentiality: Public Distribution
TABLE OF CONTENTS
List of Figures ................................................................................................................................................................... v
List of Tables ..................................................................................................................................................................... v
List of Abbreviations ....................................................................................................................................................... vi
Executive Summary ........................................................................................................................................................ vii
1.1 Main changes with respect to D2.3 ..................................................................................................................... 1
2 Review of the CHESS modelling language ............................................................................................................. 1
2.1 Support for View Definition ................................................................................................................................ 2
2.2 Modelling the real time ....................................................................................................................................... 3 2.2.1 Timing annotation ....................................................................................................................................... 3 2.2.2 Real time analysis ....................................................................................................................................... 4
2.3 Modelling the dependability ............................................................................................................................... 5
3.1 System Model ...................................................................................................................................................... 8 3.1.1 Data flow .................................................................................................................................................... 8 3.1.2 Socio-technical systems .............................................................................................................................. 8
3.10 Analysis model .................................................................................................................................................. 21
3.11 Advanced support for Sporadic operation ........................................................................................................ 21
4 CHESSML modification –domain specific ........................................................................................................... 22
B.2 Notes about the current implementation ................................................................................................................ 53 B.2.1 Deprecated stereotypes .................................................................................................................................... 53 B.2.2 Renamed Stereotypes ...................................................................................................................................... 53 B.2.3 About the FPTCSpecification ......................................................................................................................... 54
C. About MARTE usage in the CHESSML .......................................................................................................... 55
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
Table 1 - WP4, WP3 cross domain “metamodel” reqs and their coverage at M30 .......................................................... 28 Table 2 - WP4, WP3 domain specific “metamodel” reqs and their coverage at M18 ...................................................... 33
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
Page vi Version 1.0 3 November 2015
Confidentiality: Public Distribution
LIST OF ABBREVIATIONS
ARINC Aeronautical Radio INCorporated
ASIL Automotive Safety Integrity Level
CHESSML CHESS Modelling Language
CSD Composite Structure Diagram
DSL Domain Specific Language
FLA Failure Logic Analysis
FPTC Failure Propagation and Transformation Calculus
IMA Integrated Modular Avionics
PIM Platform Independent Model
PSM Platform Specific Model
QoS Quality of Service
SBA State-Based Analysis
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
3 November 2015 Version 1.0 Page vii
Confidentiality: Public Distribution
EXECUTIVE SUMMARY
This deliverable is the M30 update of its D2.3 predecessor and reports on the work
conducted in WP2 as final definition of the modelling language capable to express
system, software and hardware multi-core architectures, together with non-functional
properties for analysis and back-annotation.
The findings discussed in this document rely upon the understanding of industrial
requirements captured in WP1 and in particular upon the corresponding elaborations
performed in WP2, WP3 and WP4.
This document considers the results of the CHESS project as baseline and then
elaborates upon the extensions that have been defined to satisfy the CONCERTO
project requirements.
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
3 November 2015 Version 1.0 Page 1
Confidentiality: Public Distribution
1 INTRODUCTION
This deliverable is the M30 update of its D2.3 predecessor and describes the
modifications required for the CHESS modelling language to support the CONCERTO
needs for what regards the modelling, analysis and back propagation of the analysis
results. In particular, results coming from WP3 and WP4 have been taken into account.
The structure of the document is the following: first the review of the CHESS modelling
language, as resulting from the CHESS project, is addressed in section 2; then in
sections 3 and 4 the extensions of the CHESS modelling language for the cross and
specific domain needs respectively are discussed. The coverage of the CONCERTO
requirements with respect to the updated CHESS modelling language (as presented in
this document) is provided in section 5.
1.1 MAIN CHANGES WITH RESPECT TO D2.3
With respect to D2.3, the following sections\topics have been created or significantly
updated\reviewed:
2 Review of the CHESS modelling language (updated)
3.2.5 HW Abstraction Component (new)
3.4.2 Modelling Criticality (new)
3.7 Multi-cores processors (new)
3.8 Run-time Monitoring and Verification (new)
3.9 Partition Modelling (updated) (section 3.8 in D2.3)
3.11 Advanced support for Sporadic operation (new)
4.2 Automotive (updated)
4.3 Avionics (new)
5 Coverage of CONCERTO metamodel derived requirements (updated)
B CONCERTO Dependability Profile (updated)
C About MARTE usage in the CHESSML (new)
2 REVIEW OF THE CHESS MODELLING LANGUAGE
The CHESS modelling language (CHESSML) is considered as the baseline for the
CONCERTO needs. This section reviews the current version of the CHESSML, i.e. the
one resulting from the CHESS project, in order to better identify a more stable and
suitable baseline to be adopted in CONCERTO.
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
Page 2 Version 1.0 3 November 2015
Confidentiality: Public Distribution
The CHESSML specification, as metamodel\UML profile, is described in the CHESS
deliverable D2.3.2 [CHESSD232].
Basically the CHESSML restricts and extends the SysML, UML and MARTE OMG
standards to support:
view definition,
modelling of PIM entities,
modelling of the hardware platform,
modelling of timing related information (at PIM and PSM level),
modelling of dependability information (at PIM and platform level),
modelling of analysis scenario,
modelling of PSM entities,
back propagation of analysis results (at PSM and PIM level).
The reader can refer to annex A for a quick introduction to the CHESSML illustrating
the aforementioned support.
In the remainder of this document the term component type is used to refer to a
classifier of a set of component instances, in the sense of the object-oriented paradigm,
while the terms ComponentType and ComponentImplementation are used to refer the
corresponding entities (i.e. stereotypes of the UML Component) defined in the CHESS
component model (see CONCERTO D2.2).
2.1 SUPPORT FOR VIEW DEFINITION
In CHESSML a view corresponds to a stereotyped package, i.e. a UML container
allowed to own all the entities that belong to the given view. It is worth remembering
that a view-package can be defined as the sum of distinct sub-views, the latter acting
upon the same package of the parent view; e.g. this is the case for the CHESS
component view-package which is actually the overlapping of two distinct sub-views:
the functional and extra functional views.
Regarding the support for views definition in CHESSML, no extension has been done
in CONCERTO regarding UML support.
One possible solution identified in CONCERTO regards the definition of a dedicated
meta-model for views specification1; in particular, for each view, the meta-model
should allow to formalize the permission rules (e.g. read-only, read-write) to be applied 1 View specification is also known in literature as viewpoint. E.g. from the SysML: “A Viewpoint is a specification of
the conventions and rules for constructing and using a view for the purpose of addressing a set of stakeholder con-
cerns…”
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
3 November 2015 Version 1.0 Page 3
Confidentiality: Public Distribution
at modelling-time on the UML entities and, more in general, on the entities of a given
domain specific language (DSL, e.g. implemented as UML profile), as defined by the
view specification itself. The meta-model should be implemented in Eclipse and a
framework should be developed on top of it to offer a DSL-independent support for
views definition and usage; the framework should be designed to be integrated with the
Eclipse Papyrus UML editor. Due to project priorities, derived according to the end-
user requirements, and resources, the development of the aforementioned support has
not been planned yet.
2.2 MODELLING THE REAL TIME
2.2.1 Timing annotation
Regarding real time modelling and back-propagation support, CHESSML basically
relies on the usage of a subset of the MARTE language which allows the timing
decoration of component‟s ports at PIM level. MARTE, in particular the
RtSpecification2 stereotype, has been extended in CHESS (Figure 1) to support real-
time annotation of operations exposed through provided ports at component instance
level. In fact MARTE allows to attach real time information like thread activation
pattern (e.g. sporadic, periodic), deadline to a given operation of a component type,
while timing information is proper of (and as to be differentiated for) each single
component instance. The aforementioned limitation of MARTE was reported to the
MARTE OMG team3 and it will be fixed in the next version of the MARTE OMG
release.
See Annex C for a more detailed explanation about usage of the MARTE entities in
CHESS.
2 Defined in the MARTE High-Level Application Modeling (HLAM) sub-profile
3 OMG Issue 15166
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
Page 4 Version 1.0 3 November 2015
Confidentiality: Public Distribution
Figure 1: MARTE RtSpecification CHESS extensions
In CHESSML the decoration of component‟s operations exposed through provided
ports makes it possible to address operations having public visibility only; in fact only
public operations are visible through a provided port.
In CONCERTO, in order to support some specific request from domains like avionics
(see 4.3.2), the CHESSML CHRtSpecification has been extended to allow the
decoration of private operations for a given component instance; in particular according
to the CONCERTO component model definition (see CONCERTO D2.6)
CHRtSpecification can only be used to decorate private operations as protected or
unprotected.
2.2.2 Real time analysis
Another MARTE customization available in CHESS regards the way analysis results
are available in the model (by back-propagation). The MARTE profile makes a clear
distinction about how HW, SW resources and the information related to a given analysis
are modelled, and uses different stereotypes for these different aspects4. In CHESS
4 MARTE stereotypes for modeling of application programming interfaces of software multi-tasking platforma are
available in the Software Resource Modeling (SRM) sub-profile. Stereotypes focused on modeling hardware platform
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
3 November 2015 Version 1.0 Page 5
Confidentiality: Public Distribution
some parts of this information have been collapsed into the extended RtSpecification
stereotype; in fact the latter is used to provide timing properties of the SW operations-
resources (e.g. their activation kind, like periodic, sporadic, and its deadline) and to
attach data coming from the analysis (e.g. the worst case response time and blocking
time for the given operation) (see Annex A); this was done in CHESS because MARTE
does not allow to have information about a given analysis directly attached to port-
operation (i.e. where the RtSpecification applies).
In order to provide a better compliance with the MARTE standard, CONCERTO has
changed the way real time information resulting from the analysis are back propagated
in CHESS. In CHESS, in order to perform timing analysis, a PSM model is
automatically generated starting from the PIM user-level model; basically the PSM
represents the PIM model bounded to a given computational model. In the PSM,
MARTE stereotypes (from the Software Resourece Modeling sub-profile) are used to
provide the definition of tasks and shared resources; moreover the MARTE stereotypes
concerning schedulability analysis (from the Schedulability Analysis Modeling sub-
profile) are used as well.
In CONCERTO the back propagation of the analysis results is applied to the PSM level
entities only; at the same time traceability information between the PSM and the PIM
related entities are generated and stored in the model. Then the back propagation of the
analysis results to the PIM model is derived on demand by querying the model, in
particular by using the stored traceability links.
With the solution depicted above the analysis contexts and results can be modelled
separately from the SW\HW resources; concerning the CHESSML profile, it has been
possible to remove the attributes resulting from the analysis from the CHRtSpecification
(in particular the response time and the blocking time), allowing to have a strict
compliance with the MARTE standard.
To allow the user to easily retrieve and navigate the information related to the analysis
results, a dedicated tab view has been developed in CONCERTO; the analysis results
view shows all the analysis results associated to the selected analysis context, allowing
to navigate the provided information (e.g. the given sporadic\periodic operation) from
the view and the model explorer and diagram with hyperlinks (see CONCERTO D2.6
deliverable, section 3.1.5.1.1).
2.3 MODELLING THE DEPENDABILITY
Regarding dependability, CHESSML comes with a dedicated dependability profile
[CHESSD232]; the parts of the dependability profile useful to represent error models,
state-based and failure propagation information has been reviewed and extended in
CONCERTO according to the results coming from the WP3 and documented in the
CONCERTO D3.3 deliverable. The other constructs available in the CHESS
dependability profile have not been considered in CONCERTO given that they are out
of scope.
are available in the Hardware Resource Modeling (HRM) MARTE sub-profile. Stereotyped intended specifically for
schedulability analysis are available in the Schedulability Analysis Modeling (SAM) MARTE sub-profile.
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
Page 6 Version 1.0 3 November 2015
Confidentiality: Public Distribution
The elaboration about the extensions of the dependability profile is provided in section
3.4.
2.4 INSTANCE-LEVEL MODELLING
The CHESSML resulting from the CHESS project makes use of the UML composite
structure diagram (CSD) to model instances and extra functional information for them;
there can be some limitation while using CSDs to model instances, especially if
hierarchies of instances, i.e. instances owning sub-instances, have to be considered,
together with its ports and extra functional decoration5. This limitation is even more
relevant in CONCERTO where decomposition of components and hierarchical
instances and their extra functional annotation are considered.
The proposal in CONCERTO is to be able to rely much more on the usage of the UML
instance model. In UML there is not a specific view\diagram for the instances, they are
modelled through the class diagram with a very basic notation; a kind of composite
object diagram is available in the UML standard itself (see Figure 2) but just as
example, it is not formalized (and so UML tools do not support it); as counterpart,
instance models are particularly of interest for the kind of systems addressed in
CONCERTO where e.g. decoration of extra functional properties naturally apply at
instance level.
5 Composite structure diagram allows to model instances in the context of a classifier, i.e. given a classifier, like a com-
ponent, it is possible to model the instance that are created when an instance of the component itself is created. So only
one level of decomposition; clearly composite structure diagram can be composed together, so if an instance A inside a
composite diagram is typed by a component B with in turn has a composite diagram, then it is possible to see A as de-
composed by the instances owned by B. However there can be some limitation: imagine to have two instances of com-
ponent B: then it is not possible to differentiate parameters of the instances owned by B for the different instances of B.
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
3 November 2015 Version 1.0 Page 7
Confidentiality: Public Distribution
Figure 2: CSD and its corresponding “composite instance model”, source UML specification
CONCERTO allows decoration of the UML instance model with extra functional
properties. A specific InstanceView has been implemented on top the CHESS editor by
using a query driven approach; in this way it is possible to render the instances in a
hierarchical representation, allowing the modeller to easily navigate the instance model
and provide properties for the instances, as alternative to the usage of the CSDs.
So the modelling steps to be performed in order to complete the design in the extra
functional dimension are:
1. Create components (first ComponentType and then ComponentImplementation).
2. Create components CSDs for ComponentImplementation.
3. For the extra functional properties that can be expressed at this level, e.g., the
dependability error model: attach extra functional information to the components
and internals (the latter modelled in the CSDs)
4. Create the instance model starting from what has been modelled with the
component diagrams and their CSD‟s, which can be done automatically in
CHESS by using a dedicated command.
5. Use the instance model view to attach extra functional information for the
instances or to override the extra functional properties eventually modelled in
the step 3, if needed.
In order to support step 5, the modelling language constructs used in CHESSML to
model extra functional annotations at component level or in the CSD have to be made
available in the instance model view.
Note that this support is particularly useful to complete the modelling of software
component for what regards extra functional annotations, but it can also be adopted in
the system view and platform specification view if useful to model blocks and hardware
components properties at instance level.
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
Page 8 Version 1.0 3 November 2015
Confidentiality: Public Distribution
3 CHESSML EXTENSIONS – CROSS DOMAIN
This section addresses the cross-domain model-level support added to the CHESSML to
support the CONCERTO needs.
3.1 SYSTEM MODEL
The modelling support discussed in this section is offered through the System View,
which basically reuses and tailors the SysML standard.
3.1.1 Data flow
SysML support to the modelling of data flow is introduced in CHESSML. This is to
allow modelling of data-flow at system level, e.g. useful to enable expression of
dependability properties and to allow dependability analysis at system level.
3.1.2 Socio-technical systems
Extensions to the CHESSML are introduced to address the modelling of socio-technical
systems, the latter discussed in CONCERTO deliverable D3.2.
To enable the modelling of socio-entities, two additional kinds of composite
components are introduced in the CHESSML: human and organizational. According to
the CONCERTO FLA:
human beings are modelled as composite components comprising their sensor-
like and actuator-like functionalities (as atomic components); human failures can
be represented as an internal component, named accordingly to the category.
Input ports of the human composite component should be connected to
appropriate input port of the logical (or sensor-like) component, and the output
of the action-related component should be connected to the output port of the
human component. Several logical components can be connected to action-
related component, and only one action-related component should be allowed
for one human component.
Organizational composite components should be connected to human composite
components using appropriate ports to capture organizational influences on
human behaviour. Human composite components are then connected to
technical (composite) component.
So the following stereotypes are added in the CHESSML in the system view (as
specialization of the SysML Block entity):
Human
Organizational
Technical.
As documented in D3.2, CONCERTO FLA is based upon the CHESS Failure
Propagation and Transformation Calculus (FPTC) formalisms and analysis.
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
3 November 2015 Version 1.0 Page 9
Confidentiality: Public Distribution
To allow failure logic analysis to be applied to socio-technical systems, the CHESS
language constructs already available to support FPTC expressions for software and
hardware components become also applicable to the socio-technical systems entities. In
detail, FPTC can be used to assign a FPTC expression to humans, organizational and
technical blocks and related sub-blocks, while FPTCSpecification can be used to model
a given failure (late, early, omission, etc.) in input or output to a given block‟s port.
Furthermore, as required by the CONCERTO FLA, the application of FPTC is extended
to connectors, to allow modelling of failure of blocks interactions, and to block and
connector instances, to allow the refinement of FPTC specification at block instance
level.
3.2 COMPONENT MODEL
This section addresses the new modelling features introduced in CHESS regarding the
CHESS component model (see CONCERTO D2.6 deliverable).
3.2.1 Data flow
Data flow is introduced in the ComponentView as supported by MARTE through the
FlowPort entity6 (similar to the SysML support available in the SystemView). In
CHESSML FlowPorts are not allowed to be decorated with timing information. Data
flow in the component model is introduced to enrich the support for functional and
dependability modelling. For example, in a preliminary phase of the software design -
where typically dependability analysis applies - only the data flow can be available for
the entities under design, while the provided and required interfaces and service ports
(i.e. ports providing and requiring operations) are still to be defined. In this case the
usage of flow ports can be used to allow preliminary dependability\safety analysis, like
failure propagation, without the need to introduce and consider provided and required
interfaces\ports for the components.
3.2.2 Inter-components bindings scenarios
Inter-components bindings are functional collaboration scenarios, i.e. call operations
flows between interacting component instances.
UML sequence diagrams are introduced in CHESSML to support the modelling of
inter-components bindings; see Figure 3 for an example, where component instances are
represented together with the sequence of the operations calls between them.
6 Available in the MARTE Generic Component Model (GCM) sub-profile
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
The modelling support discussed in this section is offered through the different
dependability views available in the system, component and deployment views (see
CONCERTO D2.5 deliverable about views).
3.4.1 The new CHESS dependability profile
According to result of WP3, the needs for modifications of the CHESS dependability
profile have been identified in order to:
improve the support for dependability modelling and analysis needs,
improve the integration between the two analysis techniques of interest in
CONCERTO, namely “State-Based Analysis” (SBA in the following) and
“Failure Logic Analysis” techniques (FLA in the following).
The proposed extensions are based on the following requirements coming from
CONCERTO D3.2 (see D3.2 for a deeper elaboration):
In CHESSML it shall be possible to define different (custom) failure
classifications, to be used in different models, or for different components.
In the current CHESSML failure classifications are associated with component
ports, i.e., the failures that are assumed to occur on that port can be specified.
Ports connected together by a connector should use the same classification with
respect to failures.
In CHESSML, it should be possible to use annotations for state-based and for
failure logic analysis together
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
Page 14 Version 1.0 3 November 2015
Confidentiality: Public Distribution
More in general, in CONCERTO ML, it should be possible to define the failure
behaviour of a component at different levels of details:
o No annotations
The component does never fail spontaneously (i.e., no internal
faults). If an incoming failure is received from another
component, then it is “transmitted” as it is.
o FLA annotations only
The component does never fail spontaneously (i.e., no internal
faults). If an incoming failure is received from another
component, then it is “transmitted” according to FLA rules.
o SBA annotations (failure rate/repair rate)
o SBA annotations + FLA annotations
o Error Model
In the error model it shall be possible to define several ErrorStates, which define
the behaviour of the component different from the nominal Healthy state (the
InitialState).
In the error model the distinction between Error and FailureMode as in the
current CHESSML is no more needed. For any ErrorState it shall be possible to
define which failure mode affects the ports owned by the component.
The reader can refer to Annex B for an elaboration of the implementation of the
aforementioned requirements, included in the CHESSML as replacement\enhancement
of the previous CHESS dependability profile.
3.4.2 Modelling Criticality
The new dependability profile allows to model criticality (e.g. as ASIL9) decoration for:
Requirements
System level components (i.e. SysML Blocks)
Software component operations
Hardware Components
The modelling of criticalities has been particularly useful in CONCERTO to provide
support for validation of criticalities constraints (see CONCERTO D4.11 deliverable);
e.g. support at model level for ASIL inheritance, propagation and decomposition check, 9 Automotive Safety Integrity Level (ASIL) is a risk classification scheme defined by the ISO 26262 - Functional Safety
for Road Vehicles standard.
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
3 November 2015 Version 1.0 Page 15
Confidentiality: Public Distribution
e.g. the latter as defined by the functional safety ISO 26262 automotive standard has
been implemented (analogous support can be provided for other domain).
Picture below provides a sketch of the extensions introduced in the CHESSML as part
of the dependability profile for what concerns criticalities.
Figure 6: Extension for criticality level modelling support
CriticalityLevel has to be defined first, e.g. according to the standard\domain of interest;
then criticality can be assigned to entities, e.g. SW components, using the
CriticalitySpecification stereotype (Figure 7).
CriticalityInterfaceSpecification stereotype can be used to constraint a given provided
port\interface (Figure 8), in particular to constraint the criticalities that clients must have
in order to be able to access the given provided port\interface.
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
Page 16 Version 1.0 3 November 2015
Confidentiality: Public Distribution
Figure 7: Criticalities specification
Figure 8: Criticalities Interface Specification
3.5 PLATFORM AND ALLOCATION MODELS (DEPLOYMENT MODEL)
3.5.1 Modelling allocations for each operational mode
In case of a system with different operational modes it is possible to define different
software to hardware allocations scenarios, one for each operational mode. In this case
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
3 November 2015 Version 1.0 Page 17
Confidentiality: Public Distribution
the MARTE Assign10
, already used to model allocations, can be constrained by the
MARTE NFPConstraint11
construct, where the latter allows specifying the mode on
which the given Assign has to apply. For example, in Figure 9 the allocation of the
component instances to the processing resource CPU0 for only the NormalMode
operational mode is modelled.
Figure 9: modelling Allocations constrained to OperationalModes
3.6 EXTRA FUNCTIONAL PROPERTIES FOR OPERATIONAL MODES
In case of a system with different operational modes, through CHESSML it has to be
possible to specify extra-functional properties of the system elements under design for
each declared mode. Regarding temporal properties, MARTE defines a complex type12
to allow the modelling of non-functional properties; in particular any property value
(e.g., the period duration) can be expressed in MARTE by using a complex type which,
in addition to the value, has a “mode” attribute which allows specifying the operational
mode(s) in which the provided value is valid.
3.7 MULTI-CORES PROCESSORS
In CHESS the MARTE support to model the number of cores for a given
HWProcessor13
is imported. In particular MARTE allows modelling the number of
cores through the nbCores integer attribute of the HWProcessor stereotype, where the
latter is already used in CHESS in the deployment view to represent a computing
resource where software entities can be executed.
10
From the MARTE Allocation Modelling sub-profile 11
From the MARTE Non-functional Properties Modeling (NFPs) sub-profile 12
The NFP_ CommonType, from the normative MARTE Model Libraries (MARTE_Library). Any property value (e.g.
regarding real time, like period duration) can be expressed in MARTE by using a type which inherits from
NFP_CommonType. 13
From the MARTE Hardware Resource Modeling (HRM) sub-profile.
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
Page 18 Version 1.0 3 November 2015
Confidentiality: Public Distribution
Figure 10: MARTE HWProcessor stereotype
3.8 RUN-TIME MONITORING AND VERIFICATION
CONCERTO extends CHESS to support the run-time monitoring and verification of
properties (see CONCERTO D4.10 deliverable for more details on the provided
support).
Concerning the modelling language, CHESS is extended to allow the specification of
the properties that need to be monitored and\or verified. It is worth noting that it is
important to make this kind of information available at model level. In fact, in safety
systems, the rationale regarding the need for the monitoring\verification of a given set
of properties typically originates from safety analysis and it is typically stated in safety
requirements (available in the requirements view). The possibility to prove in the model
that the requirements about monitoring\verification have been addressed in the design,
together with the model driven support offered by the CONCERTO toolset, allows to
provide a valid argumentation of the coverage of the given safety requirements.
According to D4.10 the properties that can be monitored\verified are the following:
Period: minimum, maximum, jitter
Execution time: Minimum, Maximum
Blocking time: Maximum
Response time: Maximum, jitter
CONCERTO extends CHESSML by adding specific the RunTimeSupport, as showed
in Figure 11.
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
3 November 2015 Version 1.0 Page 19
Confidentiality: Public Distribution
Figure 11- RunTimeSupport stereotype
RunTimeSupport stereotype is intended to be used together with the CHRtSpecification,
which is used in CHESS to provide timing decoration for components instances
operations.
3.9 PARTITION MODELLING
The CHESSML is extended in CONCERTO to allow the modelling of partitions.
Two kinds of partitions are allowed:
the one defined in MARTE, i.e. MemoryPartition14
; to be used in the
DeploymentView,
FunctionalPartition as domain specific notion of partition, coming from the
avionics domain; see section 4.3.1.
MARTE MemoryPartition represents a virtual address space which insures that each
concurrent resource associated to a specific memory partition can only access and
change its own memory space.
Figure 12 below provides an example of usage of the MARTE MemoryPartition in the
DeploymentView.
14
From the MARTE Software Resource Modeling (SRM) sub-profile.
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
Page 20 Version 1.0 3 November 2015
Confidentiality: Public Distribution
MemoryPartition instances are bound to the given HW memory through the Allocate
MARTE relationships.
The MemoryPartition stereotype comes with the MemorySizeFootprint property which
can be used to set the size of the partition, in particular the percentage of the HW
memory which is reserved. The MemorySizeFootprint property can be specified by
creating an OpaqueExpression (e.g. named size) and then using natural language to
provide its value (see bottom part of Figure 12).
Figure 12: Using MARTE MemoryPartition
MemoryPartition instances can be decorated with criticality level (e.g. ASIL)
specification by using the CriticalitySpecification entity (see 3.4.2); this is particular
useful in case of mixed criticality system and to validate criticalities constraints, e.g. wrt
to criticalities of the software components allocated to the computing resource
connected to the HW memory and partitions.
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
3 November 2015 Version 1.0 Page 21
Confidentiality: Public Distribution
3.10 ANALYSIS MODEL
MARTE supports the modelling of the analysis context15
, where analysis context
means:
the system, SW, HW architectural entities to be taken into account by the
analysis, with optionally their behaviour,
the extra functional information attached to them,
any other information to be given in input to the analysis, like for instance the
property to be measured.
CHESSML already adopts the MARTE analysis context for what regards
StateBasedAnalysis, FPTC and FI4FA Analysis.
CONCERTO extends CHESS by applying analysis context usage to timing analysis; in
particular MARTE analysis contexts are used to specify the platform and workload
needed for the schedulability and end-to-end analysis. The platform must comprises the
instance models of the software and hardware components while the workload is
represented by the extra functional information attached to the component instances; in
case of the end-to-end analysis, the workload must also comprise the sequence diagram
acting as the end-to-end scenario to be taken into account by the analysis (see section
3.2.2 about inter-components bindings scenarios).
3.11 ADVANCED SUPPORT FOR SPORADIC OPERATION
In CONCERTO the CHESS CHRtSpecification stereotype is extended to allow the
modelling of “composed” sporadic operations, as required by WP3, in particular by the
work concerning the integration of the synchronous approach within CHESS (see
CONCERTO deliverable D2.8 section 4.1.1 and CONCERTO deliverable D4.8 section
6.4). The goal is to be able to model that a given sporadic operation is actually activated
just after a well-defined set of operations, the latter defined in the context of the same
component, have been invoked.
The goal cited above has been reached by introducing a new property for the
CHRtSpecification named operationReqForSporadicOcc typed with a list of
Operations.
15
From the Generic Quantitative Analysis Modeling (GQAM) and Schedulability Analysis Modeling (SAM) MARTE
sub-profiles.
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
Page 22 Version 1.0 3 November 2015
Confidentiality: Public Distribution
Figure 13: CHRtSpecification extension for sporadic operations
4 CHESSML MODIFICATION –DOMAIN SPECIFIC
This section addresses the cross-domain model-level support added to CHESSML.
4.1 PETROLEUM
The extension planned to support socio-technical systems modelling are currently
applied to the petroleum domain (see D3.2). No further extensions have been
formalized in the CHESSML for the petroleum domain.
4.2 AUTOMOTIVE
One goal of the CHESSML in CONCERTO is to support automatic verification of
ASIL decomposition in the safety ISO 26262 automotive standard meaning.
Figure 14 shows the stereotypes which have been introduced for the aforementioned
goal: Decomposition must be used to represent the set of requirements which
decompose a given parent requirements. The Independency requirement must be used to
model that the requirements which decompose a parent requirement are actually
independent, as required by the ISO 26262 standard. The rationale for the independence
can be provided by filling in the justification property of the Independency stereotype;
moreover, if it exists, a link to the Evidence e.g. a document that states why these
elements are to be considered independent, can be provided through the linkToEvidence
property.
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
3 November 2015 Version 1.0 Page 23
Confidentiality: Public Distribution
Figure 14: CHESS stereotypes for modelling redundant ASIL decomposition
For the modelling of redundant decomposition (in the 26262 automotive standard
meaning), the CHESS toolset enforces the following modelling conventions.
In order to model ASIL decomposition (as illustrated in Figure 17) the CHESS user
must:
1. In the CHESS Requirement View: decompose the original safety requirement into
redundant requirements by creating two new SysML deriveReqt relationships
stereotyped as Decomposition, that share the same origin;
2. Assign ASILs (through CriticalitySpecification stereotype) to the decomposed safety
Requirements;
3. In the Requirement View: create an independence safety Requirement (to state that
the original safety requirement has been decomposed into two redundant ones, add
rationale to this by filling in the justification property and, if exists, a link to the
Evidence e.g. a document that states why these elements are to be considered
independent) and create the Independency relationship linking the independence
requirement to original requirement that has been redundantly decomposed;
4. In the Requirement View: create the SysML Satisfy relationships, for instance by
dragging the component\block that satisfy the decomposed safety Requirements
from the model explorer into the diagram and then creating the Satisfy relationships;
5. In the System View: Associate ASILs (through CriticalitySpecification stereotype)
to components\blocks.
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
Page 24 Version 1.0 3 November 2015
Confidentiality: Public Distribution
Figure 15: Modelling Redundant Decomposition in CHESS
4.3 AVIONICS
4.3.1 Functional Partitions
According to the results coming from WP4 presented in CONCERTO D4.6 about
partitions support for IMA, a partition is defined in CHESSML as a UML Component
stereotyped as FunctionalPartition. The stereotype contains extra-functional properties
of the partitions (see section 3.1.3 of D4.6) about budget, scheduling ordering and
utilization.
4.3.2 ARINC Processes
Initial version of the demonstrator has revealed some limitations with respect to the
modelling of the avionics use case, i.e. the modelling of the IMA application. In order to
satisfy the requirements elaborated in the previous deliverables, new domain specific
stereotypes are introduced in the CONCERTO profile during the third year of the
project. On top of existing component features already present, they capture ARINC-
653 process definition with a single provided operation decorated with a periodic/cyclic
attribute, and a number of provided operations. These are private to the component, that
is to say not callable by other components. The periodic/cyclic operation may have an
offset. The private ones must be able to have priorities and precedence relations which
will be expressed between groups of function. This information will be used to compute
some offsets, as presented in the detailed description from below:
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
3 November 2015 Version 1.0 Page 25
Confidentiality: Public Distribution
Figure 16: CHESS profile for ARINC processes
<<ARINCComponentImpl>>: it extends the CHESS
<<ComponentImplementation>> in order to add ARINC process semantic. It is
available in the extra functional view.
ARINCComponentImpl comes with the following constraints:
o The extended Component must be stereotyped as
CHESS::ComponentImplementation
o An <<ARINCComponentImpl >> must define one public operation
stereotyped with <<ARINC_Process>> (see below in the text)
o An <<ARINCComponentImpl >> must define a set (>=1) of
<<ARINCFunction>> operations (see below in the text)
<<ARINCProcess>>: it extends UML::Operation, UML::Comment, and is used
to map to the concept of ARINC Process, as collection of operations. It is
available in the extra functional view.
ARINCProcess comes with the following properties:
D2.7 – Analysis and back-propagation of properties for multicore systems – Final Version
Page 26 Version 1.0 3 November 2015
Confidentiality: Public Distribution
o operationsGroups: it defines how the operations which need to be
executed when the <<ARINC_Process>> operation is scheduled are
grouped; i.e. it defines which operation can run with which other. If an
operation is not mentioned in any group than it may be added to any of
them during the schedule generation. The string has to be compliant