Post on 17-Feb-2019
transcript
Public
FP7-ICT-2009- 4 (247999) COMPLEX
COdesign and power Management in PLatform-
based design space EXploration
Project Duration 2009-12-01 – 2012-11-30 Type IP
WP no. Deliverable no. Lead participant
WP2 D2.1.1 GMV
System specification methodology
using MARTE and Stateflow
Prepared by F. Ferrero (GMV), R. Valencia (GMV),
F. Herrera (UC), E. Villar (UC)
L. Lavagno (PoliTo), D. Quaglia (EDALab)
Issued by OFFIS
Document Number/Rev. COMPLEX/GMV/P/D2.1.1/1.1
Classification COMPLEX Public
Submission Date 2010-12-10
Due Date 2010-11-30
Project co-funded by the European Commission within the Seventh Framework Programme (2007-2013)
© Copyright 2010 OFFIS e.V., STMicroelectronics srl., STMicroelectronics Beijing
R&D Inc, Thales Communications SA, GMV Aerospace and Defence SA, SNPS Belgium
NV, ChipVision Design Systems AG, EDALab srl, Magillem Design Services SAS,
Politecnico di Milano, Universidad de Cantabria, Politecnico di Torino, Interuniversitair
Micro-Electronica Centrum vzw, European Electronic Chips & Systems design Initiative.
This document may be copied freely for use in the public domain. Sections of it may
be copied provided that acknowledgement is given of this original work. No responsibility is
assumed by COMPLEX or its members for any aplication or design, nor for any
infringements of patents or rights of others which may result from the use of this document.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 2
History of Changes
ED. REV. DATE PAGES REASON FOR CHANGES
GMV 1.0 2010-12-10 120 Complete version of the Deliverable.
PAH 1.1 2011-01-24 120 Dissemination changed to “Public”
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 3
Contents
1 Introduction ........................................................................................................................ 4
1.1 Scope ........................................................................................................................... 4
1.2 Acronym list ................................................................................................................ 4
1.3 Glossary ....................................................................................................................... 6
2 General objectives .............................................................................................................. 8
3 State of Art on System-level Modelling ............................................................................. 9
3.1 UML/MARTE ............................................................................................................. 9
3.2 Stateflow .................................................................................................................... 15
4 UML/MARTE and Stateflow in COMPLEX ................................................................... 20
4.1 UML/MARTE in COMPLEX ................................................................................... 20
4.2 Stateflow in COMPLEX ............................................................................................ 25
5 System design methodology ............................................................................................. 29
5.1 COMPLEX design process ........................................................................................ 29
5.2 UML/MARTE design methodology .......................................................................... 43
5.3 Stateflow design methodology .................................................................................. 83
6 Design process tools ......................................................................................................... 86
6.1 Introduction ............................................................................................................... 86
6.2 Modelling tools .......................................................................................................... 88
6.3 Model transformation engines ................................................................................. 102
6.4 Model transformation tools ..................................................................................... 104
6.5 Model simulation tools ............................................................................................ 111
7 Limitations ..................................................................................................................... 115
8 Conclusions .................................................................................................................... 117
9 References ...................................................................................................................... 119
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 4
1 Introduction
1.1 Scope
This document corresponds to the output deliverable of the task 2.1 “Model-driven design
front-end” for the work package 2 within the COMPLEX project (see the Description of
Work, DoW [1]). It depends of the deliverable D1.2.1 “Definition of application, stimuli and
platform specification, and definition of tool interfaces” (see [2]) in terms of goals and
requirements for the design front-end, as well as the requirements on the interfaces with other
tasks of the COMPLEX design flow.
Task 2.1 aims to define a system-level specification methodology by means of two different
modelling languages, UML/MARTE and Stateflow, identifying all those features of the
system-level modelling language relevant for the characterization of the system functional and
non-functional properties and the estimation of system performance.
In order to develop an executable model of the system, it is necessary to transform the high-
level models into an executable, SystemC specification, which enables fast functional
validation, and performance estimations. This way, such SystemC specification will make
feasible in the COMPLEX design flow, the optimization of the system architecture after a
design space exploration (DSE) phase with a reasonable bound in time. This document
addresses this transformation and provides a first insight on the implementation of the tools
required for carrying out the task.
This is a public document that describes the system-level specification and the transformation
from the system-level model to the SystemC and IP-XACT models. This document is not
intended for evolving along the COMPLEX project, but must serve as a basis for the
development of the transformation tools in task 2.2 (see DoW, [1]).
1.2 Acronym list
The following table lists all the acronyms used along this document:
Table 1-1: Acronym list
Acronym Definition
AEM Application Executable Model
AML Abstract Modelling Language
API Application Programming Interface
ASIC Application-Specific Integrated Circuit
CFAM Concurrent Functional Application Model
CSP Communicating Sequential Processes
DML Detailed Modelling Language
DoW Description of Work
DRM Detailed Resource Modelling
DSE Design Space Exploration
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 5
Acronym Definition
DSL Design Specific Language
EDA Electronic Design Architecture
EML Execution Modelling Language
FPGA Field Programmable Gate Array
GCM Generic Component Model
GQAM Generic Quantitative Analysis Modelling
GRM Generic Resource Modelling
HDL Hardware Description Language
HLAM High-Level Application Modelling
HRM Hardware Resource Modelling
LT Loosely Timed
M2T Model to Text
MARTE Modelling and Analysis for Real-time and Embedded Systems
MDA Model Driven Architecture
MDD Model Driven Development
MoC Model of Computation
MOF MetaObject Facility
MOST Multi-Objective System Tune
MPSoC Multiprocessor System-on-Chip
MSoC Multi System on Chip
MTL Model to Text Langue
MTL MOF to Text Transformation Language
NA Not Applicable
NFP Non-Functional Properties
NoC Net on Chip
OCL Object Constraint Language
OMG Object Management Group
OSCI Open SystemC Initiative
PAM Performance Analysis Modelling
PC Personal Computer
PDM Platform Description Model
PIM Platform Independent Model
POSIX Portable Operating System Interface
PSM Platform Specific Model
QoS Quality of Service
QVT Query View Transformation
RTEA Real-Time and Embedded Analysis
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 6
Acronym Definition
RTES Real-Time and Embedded Systems
RTL Register Transfer Level
RTOS Real-Time Operating System
SAM Schedulability Analysis Modelling
SoC System on Chip
SRM Software Resource Modelling
SysML System Modelling Language
TBC To Be Completed
TBD To Be Defined
TLM Transaction Level Modelling
TPV Timed Programmer View
UML Unified Modelling Language
VHDL VHSIC Hardware Description Language
VHSIC Very High Speed Integrated Circuits
VSL Value Specificaiton modeLing
XML eXtensible Markup Language
1.3 Glossary
The following table summarizes the most important concepts provided along this document:
Table 1-2: Definition list
Definition Description
Platform Independence Platform independence is a quality, which a model may exhibit.
This is the quality that the model is independent of the features
of a platform of any particular type (see [3]).
Platform Model A set of technical concepts, representing the different kinds of
parts that make up a platform and the services provided by the
platform.
Platform-Independent
Model (PIM)
The MDA model that defines an application independent of a
specific platform. The PIM is applied to a more detailed model
using a transformation mechanism (see [3]).
Platform-Specific Model
(PSM)
The MDA model that refers to or includes elements from the
implementation platform, often made more precise through the
use of relevant stereotypes (see [3]).
Specification The set of information which serves as an input for an
implementation flow. It may include a model or a set of models,
functional and non-functional constraints.
Transformation A model operation that takes one or more models as input and
returns one or more models as output. The operation maps
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 7
Definition Description
elements from the source model elements to the target model
elements.
Transformation Chain If a sequence of more than one transformation is applied to an
input model, the configuration of these transformations –
including their sequence, possible branches and other
information – is called transformation chain.
View A viewpoint model or view of a system is a representation of
that system from the perspective of a chosen viewpoint.
Viewpoint A viewpoint on a system is a technique for abstraction using a
selected set of architectural concepts and structuring rules, in
order to focus on particular concerns within that system. Here
„abstraction‟ is used to mean the process of suppressing selected
detail to establish a simplified model.
The concepts and rules may be considered to form a viewpoint
language.
CFAM Concurrent Functional Application Model
CFAM API API for accessing real-time and communication and
synchronization services from CFAM code
CFAM code Sources (User code) of the CFAM
CFAM Component
Structure
Sources reflecting the Component-based structure of the
application and generated from the UML/MARTE model.
CFAM Generator Code Generation Engine which extracts from the COMPLEX
UML/MARTE specification the Component Structure and other
information (concurrency structure, etc) and generate the code
which reflects (by means of a set of macros and facilities
common to different implementation possibilities).
CFAM Infrastructure Set of implementations available for the CFAM Component
Structures produced by the CFAM Generator, and grouped for
each Simulation and Analysis Infrastructure supported.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 8
2 General objectives
The COMPLEX system-level specification methodology aims to define methods, tools and
techniques to support the modelling of real-time embedded systems, paying special attention
to those system aspects related to performance and power estimation.
Two different but complementary design entries will be defined corresponding to two
different MDA (see [3]) design entries described in the DoW [1]:
The UML/MARTE branch, based on the UML modelling language extended with the
MARTE profile.
The Stateflow branch, based on the Matlab© modelling framework.
Both design entries will specify the behavioural model of the system with independence of the
underlying execution platform (i.e. PIM according to [3]). This entry will also provide the
use-case scenario, which will model the validation environment of the system and specify the
stimuli necessary for its validation.
However, the UML MARTE design entry will specify the execution platform, both hardware
and software resources (i.e. PDM according to [3]). This model will provide enough
information about the platform (i.e. connections between devices, physical properties, etc.) so
that it enables the estimation of the system performance and power consumption when the
system functions are allocated to the platform. Once that allocation is performed the model of
the whole system is achieved (i.e. PSM according to [3]).
The two PIM (derived from both design entries) will be simulated either directly using the
MathWorks tools (in the case of the Stateflow design entry) or transforming the system model
into a SystemC specification (in the case of the UML/MARTE design entry). In both cases,
the stimuli will be derived from the stimuli description in the PIM model.
Additional transformations will be performed from the UML/MARTE PDM to IP-XACT and
SystemC. From the IP-XACT platform specification a structural top-level view of the
platform architecture is assembled. It will consist of processing elements, dedicated hardware,
memories and interconnections between these elements.
Finally, the system architecture will be optimized during the design space exploration (DSE)
process. In order to enable this process, it will be necessary to derive information about the
objective functions and parameters from the PSM. With this information, the exploration and
optimization tool will iterate to efficiently tune the objective parameters and find the optimal
architecture (if possible).
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 9
3 State of Art on System-level Modelling
3.1 UML/MARTE
3.1.1 Overview
MARTE (Modelling and Analysis of Real-Time and Embedded systems) is a specification of
the Object Management Group (OMG), consisting of a UML™ profile that aims to replace
UML capabilities for model-driven development of Real-Time and Embedded Systems
(RTES), and for analyzing schedulability and performance of UML specifications. It provides
valuable capabilities that are of interest in COMPLEX such as the support for specification,
design, and verification/validation stages, the definition of non-functional properties, time and
time related concepts and analysis frameworks.
MARTE is mainly formed of two main parts, a design model package to model hardware and
software aspects and an analysis model package to annotate application models so that it
permits a quantitative analysis of a range of properties of the system. Those two parts follow
common and consistent approach to describe time and use of concurrent resources, which are
contained in a shared foundation package.
Next image depicts the MARTE design packages and their structure:
Marte Annexes
Marte Foundations
<<profile>>
Time
<<profile>>
NFP
<<profile>>
GRM
<<profile>>
Alloc
Marte Design Model
<<profile>>
DRM
<<profile>>
GCM
<<profile>>
HLAM
<<profile>>
SRM
<<profile>>
HRM
Real-Time & Embedded
Analysis
<<profile>>
SAM
<<profile>>
PAM
<<profile>>
CQAM
<<profile>>
MARTE_library
<<profile>>
RSM
<<profile>>
VSL
Figure 3-1: MARTE design packages
Application modelling is based on interacting component blocks for structural aspects; for
behaviour, block-diagrams are amenable to activity charts, or finite-state machines. This level
of modelling is further decorated with timing and other non-functional attributes.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 10
Execution platform modelling comprises the description of the hardware and (middleware)
software layers and interconnects that compose the platform. Platform components can be
described at the same level of abstraction as the application, and they may thus contain also
timing information along with structural and behavioural aspects.
The allocation model describes the association matching applicative functions onto execution
platform resources.
UML-MARTE is inline with the UML profile for Quality of Service (QoS) and Fault
Tolerance to allow the specification of real-time constraints and other embedded systems
characteristics (e.g. memory capacity, power consumption, etc). It also requires to support
modelling and analysis of component-based architectures (either hardware or software), and
different computational paradigms.
UML-MARTE is structured as a hierarchy of sub-profiles whose foundations are:
Non-Functional Properties (NFP) modelling (e.g. performance, memory usage, power
consumption, deadlines, scheduling policies, etc). They represent a key factor in the
context of MDD for real time and embedded systems providing information related to
delays, scheduling policies, deadlines, memory usage, etc. Additionally, the Value
Specification Language (VSL) allows the specification of textual algebraic expressions.
Timing Modelling (Time) describes concepts for modelling time and timing
mechanisms (clocks, timers). MARTE relies on models of time that are based on partial
ordering of instants.
Generic Resource Modelling (GRM). It comprises the description of both dedicated
hardware and software resources and interconnects composing the platform. It also
provides timing information along with structural and behavioural aspects.
Allocation Modelling (Alloc). It models the allocation of functional application
elements onto the available platform resources. The allocation could be time or space
related. Application and execution platform models are built separately, before their
pairing through the allocation process.
As previously introduced, UML-MARTE includes two differentiated packages, the design
model and the analysis model packages. The first is devoted to describe the activities related
to the model-based design, whereas the second one aims to verify real time applications.
MARTE design model for RTES comprises the following packages:
Generic Component Model (GCM). This is a general model package that is not tied to
any particular execution semantics. It includes interaction ports, flow ports, and
message ports. GCM separates the definition of structural properties and the definition
of behavioural properties.
High-Level Application Modelling (HLAM). It provides high-level modelling concepts
to deal with real-time concerns in RTES (e.g. concurrency or synchronization).
Detailed Resource Modelling (DRM). It includes software and hardware resource
modelling. The Software Resource Modelling (SRM) intends to describe application-
programming interfaces of software multi-tasking execution supports. Hardware
Resource Modelling (HRM) intends to describe hardware execution supports, through
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 11
different views and detail levels. At the end, the hardware modelled resources are
combined with the software ones to support the whole application execution.
Finally, the MARTE analysis model package:
Generic Quantitative Analysis Modelling (GQAM). This package aims to annotate
application models to support analysis of system properties. It includes schedulability
analysis, performance analysis and worst-case execution time (WCET) analysis
modelling. The following sub-packages are included:
Schedulability Analysis Modelling (SAM). Devoted to the analysis of timing constraints
and verification of the temporal correctness.
Performance Analysis Modelling (PAM). Devoted to the analysis of temporal properties
of best-effort systems and soft-real-time embedded systems. Performance measures
(analysis outputs) are statistical.
Like UML, MARTE was developed to be as general as possible. Therefore it covers a broader
range of use cases than what are needed for COMPLEX project. Section 4.1 narrows the
scope of MARTE to focus on the elements that we need in COMPLEX to enable the design
space exploration in RTES.
3.1.2 UML/MARTE-based methodologies
Despite the relative recent development of the UML/MARTE profile, several works have
proposed MARTE-based methodologies or just showed the applicability of the profile.
The development of a methodology based on MARTE has been leveraged by the need to
focus the UML facilities to be used, to fix their semantics and find rules for an actual design
flow.
In [17], CEA, LIFL&INRIA propose a methodology for modelling hardware with MARTE.
Specifically, [17] proposes a methodology for applying the HRM MARTE profile during the
hardware design process. It also explains how the HRM profile can interface the simulation
tools. More specifically, this paper proposes a bottom-up methodology, making use of
Composite Structure Diagrams, as well as Class Diagrams. Then a class diagram can be used
to declare a new hardware concept class, while the composite structure diagram is used to
define the internal parts of the current hardware entity. Papyrus [11], a tool initially
developed by CEA, was used as development tool.
At the same time, LIFL&INSRIA propose in [19] an approach for repetitive allocation
modelling in MARTE is presented. The idea is to facilitate the modelling of the mapping of a
parallel application into parallel hardware architecture. For it, this approach first proposed a
UML component-based framework to specify both, hardware and software parts of the
system. The approach of [19] relies on composite structure diagrams to capture the
application and hardware architecture. In [19] several types of allocation are distinguished:
structural, behavioural and hybrid. It is also noticed that an allocation can mean either a
spatial placement or a temporal placement. In [19], the synthetic capture of the regularity of
the system structure is done through the Repetitive Structure Modelling annex of MARTE,
which supports shaped multiplicities of modelling elements, and repetitive connectors. Then,
the <<allocate>> MARTE stereotype is extended through the <<Distribute>> stereotype to
express regular distributions from an array of elements to another array of elements.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 12
In [20] and [21] a design environment for data-intensive applications called Gaspard2, which
enables a MARTE description of both, the application and the hardware platform, including
MPSoC and regular structures. Gaspard2 uses MARTE for capturing both, the application
and the platform. However, Gaspard2 introduces additional concepts and semantics to
provide the needed information required for the implementation, which is not expressible only
with the concepts provided by MARTE. These concepts are introduced by means of two new
specific UML profiles. One is used to precise the semantics of the concepts used for the
application model, which are under a specific Model of Computation (MoC) called ArrayOL.
The second profile concerns the description of the type of implementation of the elementary
elements, that is, the ones that are used to build up the rest of the components. Specifically,
this profile enables to define that a basic block has an abstract implementation (either as HW
or as SW), containing one or several implementation levels (e.g., cycle bus accurate and
programmers view).
MoPCoM [22] is a UML/MDA co-design methodology oriented to the design of high quality
real-time embedded systems. MoPCoM uses MARTE profile as an UML extension to
describe real-time properties and to perform platform modelling. MoPCoM defines three
abstraction levels. A first Abstract Modelling Level (AML) serves to model system
behaviour. It is based on SysML profiled, enhanced with some MARTE elements. A second
and intermediate Execution Modelling Level (EML) serves for performance analysis. The
Detailed Modelling Level (DML) allows the automatic generation of implementation code.
MoPCoM defines three models to be specified to each of the previous levels: an application
model, a platform model and an allocation model. For instance, in the NFP MARTE profile is
employed for the application model. The platform model employs the HRM MARTE profile,
and the allocation model the Alloc MARTE profile. Rhapsody1 was used in [22] for the
development of MoPCoM models.
In [24], a UML/MARTE based methodology that utilizes activity threads to reduce the effort
to build the set of architectural alternatives for design space exploration. The methodology
only requires one architectural model and one function model in combination with an activity
thread to automatically generate a group of system models, each representing one design
alternative. Relating on this work, in [25] a visual feedback of the performance simulation
results into the UML model, which allows the user to interactively improve the design at the
behavioural level.
In a similar line, in [26] a methodology which focuses on finding a way to help designers in
evaluating the HW/SW partitioning solutions, specifically, to identify design points fulfilling
the timing constraints. For it, it uses SysML and MARTE profiles. Particularly, SysML is
used to include information useful for the construction of the Design Space. By means of
MARTE non-functional properties annotation and schedulability analysis, the Design Space is
restricted to the design points fulfilling timing requirements.
In [27], a code-centric and UML/MARTE-based approach for modelling real-time systems is
presented. The particularity of this approach was its semi-automated support for synchronous
evolution of the generated code and of the model, while enabling the inclusion of legacy code
or code tied to certain regulations or developer preferences.
In [28] a methodology for system-level specification in UML/MARTE is presented. The main
goal of this methodology is to enable a methodology with a sound formal basis able to capture
a system-level model of the system capturing basic features such as the concurrency and
1 Rhapsody is, currently available as Rational Rhapsody, after IBM acquired Telelogic.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 13
synchronization and communication structure of the system. Such a system-level model can
be either interpreted as a PIM, or, actually, as a PSM in case that the introduction of
concurrency is considered in the methodology as a first and high level of addition of
implementation details. Indeed, the methodology uses structure diagrams with components
with basic stereotypes of the GRM MARTE profile. The methodology employs also activity
diagrams to reflect the inner structure of concurrent activities, thus to enable an enough
accurate description of when functionality and when interaction with the remaining
concurrent activities takes place. The formal sound of the methodology is enabled through the
relation, and more specifically, the abstraction, of the UML/MARTE concepts with the
ForSyDe metamodel [34]. In [30], the UML/MARTE methodology was extended in order to
support the capture of a heterogeneous system-level specification. In this context, an
heterogeneous specification is understood as a specification integrating parts under different
models of computation and/or communication. Thus for instance, the specification can
integrate a network of fifo-based communicating process (Kahn process network) and a
network of rendezvous based communicating processes (CSP), which in turn, are
communicated.
3.1.3 Code Generation from UML/MARTE
Several works have tackled code generation from UML/MARTE, among them some of the
methodologies overviewed in the previous sections.
For instance, in [17], Acceleo [14] is used to generate an architectural description which
serves as input for a tool called Simics, which is able to simulate a full system, via two basic
ways of creating a platform: through parameterization or pre-configured machines; or through
definition of configuration scripts based on existing modules. The latter one is what is
targeted in the aforementioned generation.
In Gaspard2 [20] is an executable TLM SystemC platform at the Timed Programmer View
(PVT) level is generated from the UML/MARTE description. As well as the use of
UML/MARTE, another distinguishing contribution of Gaspard with regard to previous work
is its aim for obtaining implementations beyond the proper SystemC executable model. For it,
the Gaspard2 environment relies on model transformations in order to implement the MPSoC
compilation flow. Moreover, such model transformations are chained, enabling the production
of intermediate models under a predefined metamodel. The first transformation produces a
domain specific Gaspard model from the UML/MARTE model. The model transformations
approach enables in Gaspard2 the generation of other codes, such as VHDL, OPenMP, etc.
As mentioned, MoPCoM [22] and [23] enables from the DML model the automatic
generation of implementation code. MoPCoM relies in a subset of C/C++ as action language,
which, after an additional parsing, enables the generation of synthesizable VHDL. [22]
MoPCoM claims its capability to target any implementation language. For instance, by
extending the action code to support syntax constructs supported for C/C++ based high level
synthesis tools. In [22], MDWorkbench [33] platform was used for code generation from
MoPCoM models.
In [31] the fundaments to formally link the UML/MARTE methodology depicted in [28] with
SystemC are provided. The clear separation between concurrency and communication in the
UML/MARTE methodology depicted in [28], facilitates the separation of the generation of
structural and behavioural code. In [31], the formal relation that justifies the mapping between
UML/MARTE concepts and SystemC facilities (e.g. a CocurrencyResource with a SystemC
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 14
thread) is presented. Moreover, the formal framework also enables the identification of the
degrees of the flexibility for such mapping (e.g., in terms of modular structure), which
provides a formal sound for mode flexible and smart generation tools.
The work in [31] gets deep into untimed models, and provides the basic fundaments for a
further extension to provide formal foundation to the mapping proposed in [30] for the
generation of executable heterogeneous specifications in SystemC.
Finally, some of the currently available infrastructure for code generation from models should
be mentioned in this section, specially focusing on the tooling susceptible to be used in the
COMPLEX project.
To this respect it is interesting to mention the MOF Model 2 Text transformation language
(shortly Mof2Text or MTL) ([35]). MTL is a template based language which enables a textual
description of the transformations producing code (text) from a model under a specific
metamodel.
A main benefit of MTL is that it is an available specification of the OMG , and, as such, it is
aligned with other OMG standards, such as UML, MOF and OCL. Thus UML is a supported
and valid input metamodel (although not the only one).
It is also worthy to mention the availability of a set of free code generators, such as Xpand,
JET, and Acceleo, available as Eclipse plug-ins. Within this context, Acceleo provides a
framework supporting MTL, and other interesting features, such as syntax highlighting, meta-
model and scripts based completion, real time error detection, etc.
3.1.4 UML/MARTE Methodology and Code Generation in COMPLEX
In this context, what it is still missing is a holistic UML/MARTE specification methodology,
with the following features:
Possibility to model the different relevant parts of a system (application and platform
components, application and platform architectures, mapping of application components
onto platform components), supporting views as a means for unambiguous separation of
concerns, beyond the clear graphical separation enabled by diagrams.
A Component-based approach. Thus, the application can be separated into clearly
separable and reusable blocks.
Suitability for a SW-centric design approach.
Support of the specification of the use cases and input stimuli which enable system
verification
Supported by a set of generators that feed the DSE flow of complex.
Suitable to feed a real-time design flow, where formal real-time analysis, such as
schedulability analysis. This way, the methodology has the potential to combine real-
time analysis with the dynamic (simulation-based) analysis enabled by the COMPLEX
DSE flow.
Suitable for further development and automation of the implementation flow, based on
the optimum system configuration found after COMPLEX DSE.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 15
3.2 Stateflow
3.2.1 Overview
Matlab, Simulink and Stateflow are widely used model-based design tools provided by
MathWorks. They find applications in areas such as automotive controls, avionics, and digital
signal processing for telecommunications. They provide the designer with a platform-
independent model, which can take the form of algorithmic description (by using the M
language), or block diagrams (by using Simulink blocks), or finite state machines represented
in Stateflow. All these descriptions can work together, via defined interfaces, for both
simulation and target code generation. Simulation can use both continuous and discrete time
semantics. Code generation is performed by language translators, such as Embedded Coder,
Real Time Workshop, HDL Coder or Stateflow Coder, which generate either ANSI C code, or
synthesizable HDL code, for HW or SW implementation.
In COMPLEX design flow we also want to support the use of Stateflow as platform-
independent specification language [37], since it is often used to model control-dominated
applications. A demonstration of the Stateflow entry point will be provided for the Wireless
Sensor Network domain that is the target of the Use Case 1 of the project.
A Stateflow chart is a representation of a finite state machine. A finite state machine is a
representation of an event-driven (reactive) system. In an event-driven system, the system
makes a transition from one state (mode) to another, if the condition defining the change is
true. A finite state machine can be modelled through either a truth table to relate the inputs,
outputs, and states or state-transition charts (bubble charts).
A Stateflow chart uses a variant of the finite state machine notation established by Harel [38].
A chart is a graphical representation of a finite state machine, where states and transitions
form the basic building blocks of the system. You can also represent stateless charts (flow
graphs). You can include Stateflow charts as blocks in a Simulink model. The collection of
Stateflow charts in a Simulink model is the Stateflow machine. A Stateflow chart enables the
representation of hierarchy, parallelism, and history. You can organize complex systems by
defining a parent and offspring object structure [39]. For example, you can organize states
within other higher-level states. A system with parallelism can have two or more orthogonal
states active at the same time. You can specify the destination state of a transition based on
historical information. These characteristics go beyond what state-transition charts and bubble
charts provide.
Notation defines a set of objects and the rules that govern the relationships between those
objects. Stateflow chart notation provides a way to communicate the design information in a
Stateflow chart. Stateflow chart notation consists of these elements:
A set of graphical objects
A set of non-graphical text-based objects
Defined relationships between those objects
As depicted in Figure 3-2 a Stateflow chart consists of graphical objects (states, boxes,
functions, notes, transitions, connective junctions, and history junctions) and non-graphical
objects (events, data, and targets). A detailed description of all these elements is reported in
[37].
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 16
Figure 3-2: Elements of a Stateflow chart
Semantics describe how to interpret chart notation. A typical Stateflow chart contains actions
associated with transitions and states. The semantics describe the sequence of these actions
during chart execution.
The Stateflow chart interfaces to its Simulink model and to code sources external to the
Simulink model (data, events, custom code).
Stateflow charts are event-driven. Events can be local to the Stateflow block or can propagate
to and from the Simulink model. Data can be local to the Stateflow block or can pass to and
from the Simulink model and external code sources.
As shown in Figure 3-3 Stateflow machines arrange Stateflow objects in a hierarchy based on
containment. That is, one Stateflow object can contain other Stateflow objects. The highest
object in Stateflow hierarchy is the Stateflow machine. This object contains all other
Stateflow objects in a Simulink model. The Stateflow machine contains all the charts in a
model. In addition, the Stateflow machine for a model can contain its own data and target
objects.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 17
Similarly, charts can contain state, box, function, data, event, transition, junction, and note
objects. Continuing with the Stateflow hierarchy, states can contain all these objects as well,
including other states. You can represent state hierarchy with superstates and substates.
A transition out of a superstate implies transitions out of any of its active substates.
Transitions can cross superstate boundaries to specify a substate destination. If a substate
becomes active, its parent superstate also becomes active.
You can organize complex charts by defining a containment structure. A hierarchical design
usually reduces the number of transitions and produces neat, manageable charts.
Figure 3-3: Stateflow hierarchy
Every state (and chart) has a decomposition that dictates what kind of substates it can contain.
All substates of a superstate must be of the same type as the superstate‟s decomposition.
Decomposition for a state can be exclusive (OR) or parallel (AND). These types of
decomposition are described in the following topics.
Exclusive (OR) state decomposition for a superstate (or chart) is graphically indicated when
its substates have solid borders. Exclusive (OR) decomposition is used to describe system
modes that are mutually exclusive. When a state has exclusive (OR) decomposition, only one
substate can be active at a time. The children of exclusive (OR) decomposition parents are OR
states.
The children of parallel (AND) decomposition parents are parallel (AND) states. Parallel
(AND) state decomposition for a superstate (or chart) is graphically indicated when its
substates have dashed borders. This representation is appropriate if all states at that same level
in the hierarchy are always active at the same time. The activity within parallel states is
essentially independent.
3.2.2 Code Generation from Stateflow
MathWorks provides different tools which generate either ANSI C code, or synthesizable
HDL code, for HW or SW implementation. They are: Real Time Workshop Embedded Coder,
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 18
HDL Coder, EDA Simulator Link and Stateflow Coder [40]. Figure 3-4 shows a roadmap of
MathWorks‟ solutions for code generation.
Simulink
model
Stateflow
model
VHDL,
Verilog
code
C
code
SystemC
TLM
code
Stateflow
CoderRealtime
Workshop
Embedded
Coder
Simulink HDL
Coder
Realtime
Workshop
Embedded
Coder
+
EDA
Simulator
Link
ASIC
FPGA
PROCESSOR
SYSTEMC
VIRTUAL
PLATFORM
Figure 3-4: MathWorks code generation roadmap
The Real-Time Workshop Embedded Coder generates C code from Simulink and Stateflow
models that has the clarity and efficiency of professional handwritten code. The generated
code is exceptionally compact and fast, essential requirements for embedded systems, on-
target rapid prototyping boards, microprocessors used in mass production, and real-time
simulators. Full support is provided for the integration of legacy applications, functions, and
data.
The Simulink HDL Coder generates bit-true and cycle-accurate, synthesizable Verilog and
VHDL code from Simulink models, MATLAB code, and Stateflow charts. The generated
HDL code can be simulated and synthesized using industry-standard tools and then
implemented on FPGAs and ASICs. With Simulink HDL Coder you can control HDL
architecture and implementation, highlight critical paths in the model, and generate hardware
resource utilization estimates.
EDA Simulator Link allows transforming a Simulink block into TLM-2.0-compliant SystemC
Transaction Level Model (TLM) that can be executed in any OSCI-compatible TLM 2.0
environment, e.g., a commercial virtual platform.
The Stateflow Coder generates portable integer, floating-point, or fixed-point C code for
Stateflow charts. It supports all Stateflow objects and semantics, helping you develop and test
algorithms that can be deployed as stand-alone applications or inserted as sub routines into
your existing code [37]. Figure 3-5 shows an example of statechart and the corresponding C
code.
From the perspective of COMPLEX design flow, the main limitations of MathWorks‟ code
generation tools are:
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 19
they do not generate parallel code from a single Simulink block even if it contains
parallel states;
they do not generate SystemC RTL code;
they do not provide advanced analysis functionality such as state equivalence,
reachability analysis, deadlock analysis, dependability analysis, model verification; as
far as we know, Stateflow Coder can only perform a simple code-coverage checking;
they do not provide automatic mechanisms to perform manipulations on the state charts
(e.g., state reduction, chart abstraction).
Figure 3-5: Example of code generation from Stateflow specification
A tool to generate VHDL code from Stateflow charts has been developed at Berkeley
University [41]. SF2VHD itself is written in a hybrid of C and C++, and works by first
parsing in the text file containing the Stateflow description into an internal object model,
followed by generation of VHDL code for an equivalent state machine. The internal object
model closely resembles the raw functionality of the state machine, and theoretically could be
used to drive other target file formats. The generation of VHDL code is composed primarily
of two processes. First, Stateflow data types are converted to bit-accurate VHDL data types,
both at declaration and “automatically” within every expression operation. Second, the
Stateflow expression syntax and operators are converted to their VHDL equivalents on a line-
by-line basis to implement the functional behaviour of the state machine. Functional
equivalence to the software model of Stateflow is also provided by an extended synchronous
reset and persistent output latches to preserve values across clock cycles. These features are
added intrinsically by SF2VHD. The VHDL code generated by SF2VHD achieves a
satisfying level of efficiency in hardware after synthesis. As main drawbacks, the tool does
not support AND states and history junctions.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 20
4 UML/MARTE and Stateflow in COMPLEX
According to the goals and requirements included in the document [2], UML/MARTE and
Stateflow provide wide concepts that need to be narrowed for the scope of COMPLEX. This
section introduces these two high-level modelling languages and analyzes which
characteristics are for the interest of COMPLEX.
4.1 UML/MARTE in COMPLEX
MARTE introduces enhancements on the UML structure to support the modelling of the real
time characteristics of the system at PIM-level, but also extends UML to deal with the
definition of the platform specification at PDM-level and the architectural mapping of PIM
components and hardware resources. This section provides an analysis of MARTE profiles
that are of the interest for COMPLEX.
4.1.1 Application Modelling
This section provides a discussion of the design packages of the MARTE profile and their
relevance to the COMPLEX project from the point of view of application modelling and
analysis, especially in the light of the principal user requirements described in [2]. We
consider the following packages to be “design” packages:
Generic Component Model (GCM);
High Level Application Modelling (HLAM);
The MARTE profile does not impose a specific component meta-model, but provides an
extension to the standard UML2 component meta-model by means of the GCM package. The
GCM separates the definition of structural and behavioural properties, and provides a
complete set of behavioural concepts.
The behaviour aspects are defined in the High Level Application Model (HLAM). The core
concept for behaviour definition is the RtUnit. An RtUnit behaves as an autonomously
executing component, similar to the UML Active Object concept. The main features of an
RtUnit are:
a choice of policy for message queue management;
a set of behaviour elements;
at least one schedulable resource;
a set of real time services (RtService) implemented by the RtUnit.
Protected passive unit (PpUnit) model resource describes concurrent access policies for
shared resources. The predefined concurrency policies are:
sequential (mutual exclusion must be enforced externally by accessing objects),
guarded (mutual exclusion is enforced internally), and,
concurrent (no mutual exclusion required).
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 21
The UML profile for MARTE is also designed to provide a model-based description of real-
time and embedded systems and an analysis framework of the non-functional properties of
those systems. The packages of interest for these purposes are:
Time, which provides the means to represent time and time-related concerns, such as
time events and clocks, to effectively modelling embedded and real time systems;
GQAM, which provides basic concepts to be used in the software behaviour analysis
such as performance and schedulability analysis;
The package GQAM is part of the RTEA (Real Time and Embedded Analysis), whereas Time
is part of the MARTE foundations. Figure 4-1 below shows the overall structure of MARTE
and highlights the two packages which are the main focus of this section, Time and RTEA.
Marte Annexes
Marte Foundations
Time AnalysisNon-functional properties
<<profile>>
Time
<<profile>>
NFP
<<profile>>
GRM
<<profile>>
Alloc
Marte Design Model
System Design <<profile>>
DRM
<<profile>>
GCM
<<profile>>
HLAM
<<profile>>
SRM
<<profile>>
HRM
Real-Time & Embedded
Analysis
Timming and Analysis
<<profile>>
SAM
<<profile>>
PAM
<<profile>>
CQAM
<<profile>>
MARTE_library
<<profile>>
RSM
<<profile>>
VSL
Figure 4-1: MARTE packages for application design in COMPLEX
Time package offers a large variety of time-related concepts and semantics that are
appropriate for modelling real-time and embedded systems. There are three main classes of
time abstraction used to represent behavioural flows:
Causal/temporal (precedence/dependency)
Clocked/synchronous (simultaneity, discrete succession of instants)
Physical/real-time (accurate modelling of real-time duration values)
The Generic Quantitative Analysis Package proposes generic concepts for types of analysis
based on system execution behaviour, which may be represented at different levels of detail.
Quantitative analysis techniques determine the values of “output NFPs” (such as response
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 22
times, deadline failures, resource utilizations and queue sizes) based on data provided as input
NFPs (request or trigger rates, execution demands, deadlines, QoS targets).
The RTEA package as a whole gives ways to analyze time-related NFPs, i.e. to estimate the
capability of a system to provide timely responses to requests for specified operations, as well
as other NFPs such as memory and power usage, reliability and security.
In summary, the following packages could form part of the COMPLEX design front-end:
Time and related annexes (TimeLibrary, TimeTypesLibrary and CHF) since they
provide a well structured and solid way to describe time entities and values;
NFP and related annexes (BasicNFP_Types, MARTE_DataTypes and VSL) since they
form the basic annotation mechanism to describe non-functional properties and to
define data types. They should be extended to better characterise whether a property is
the result of an analysis and to specify other necessary non-functional properties and
data types;
4.1.2 Platform Modelling
The performance yield of the application strongly depends on the platform, which in general,
contains both software and hardware resources. The Detailed Resource Modelling (DRM)
profile of MARTE provides concepts for considering both the SW and HW components of the
platform. Moreover, MARTE clearly separates SW and HW platform concepts by packaging
them into two different sub-profiles: the Software Resource Modelling (SRM) profile, and the
Hardware Resource Modelling (HRM).
Marte Foundations
Marte Design Model
Marte Annexes
<<profile>>
Time
<<profile>>
NFP
<<profile>>
GRM
<<profile>>
Alloc
<<profile>>
DRM
<<profile>>
GCM
<<profile>>
HLAM
<<profile>>
SRM
<<profile>>
HRM
Real-Time & Embedded
Analysis
<<profile>>
SAM
<<profile>>
PAM
<<profile>>
CQAM
<<profile>>
MARTE_library
<<profile>>
RSM
<<profile>>
VSL
Figure 4-2: MARTE packages for platform modelling in COMPLEX
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 23
Moreover, it will be of interest the possibility of capturing non-functional properties tied to
either specific components of the platform (e.g., a cache memory size), or the overall platform
(e.g. a working frequency). Therefore, the NFP profile of MARTE is again of interest for this
purpose.
4.1.2.1 SW platform
The SRM profile provides infrastructure for modelling of the Application Programming
Interfaces of software multi-tasking platform. Literally, the SRM profile “is not a new multi-
tasking API standard”, but “it provides modelling artifacts to describe such API” [7].
Therefore, the SRM profile could be used to document at a MARTE level the elements of the
application modelling API (CFAM) introduced in [32].
However, the COMPLEX/MARTE methodology will not aim to enable a user specification of
the modelling API (since it will be provided and fix). The goal in the COMPLEX
UML/MARTE methodology is to enable a synthetic description of the main components
instance of a SW architecture (e.g., RTOS kernel instances) and, by extension, how the
application on top maps onto such SW components; and how such SW components are
mapped over the HW resources of the platform.
A modelling example could be the modelling of a heterogeneous system mapped over a
heterogeneous NoC, where its heterogeneity does not come from having different nodes, but
from employing different RTOS instances for the nodes, e.g. ELinux and Embedded
Windows. In such a case, the representation of the platform requires an infrastructure to
represent:
A RTOS instance as a system component.
The allocation of the different RTOS instances to the specific nodes of the HW
resources of the platform.
Application
Component
1
Application
Component
3
RTOS 1
(ELinux)
RTOS 2
(EWindows)
Node 1 Node 2
Application
Component
2
SW part
Platform Model
Figure 4-3: System example with two RTOS instances.
This suggests the usage of:
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 24
The Generic Component Model (GCM) profile, for enabling a component-base
approach.
Generic stereotypes of the GRM or, more specifically, the DRM:SRM profile can be
selected, for the representation of the RTOS instances and other “large grain”
components (drivers, middleware) of the SW platform.
The Allocation profile for the allocations between SW and HW platform components.
The allocation of the application components to the different RTOS instances suggests again
the usage of the Allocation profile.
4.1.2.2 HW platform
A former requirement for enabling the platform description is the component-based approach,
which points to the GCM profile again.
Moreover, the description of the HW platform for the generation of an executable model for
performance analysis requires the consideration of at least two types of information:
The architectural description.
The performance data associated to the implementation of each component of the
architecture.
The MARTE DRM::HRM::Logical profile provides stereotypes for capturing both typical
components of a platform architecture (processor, bus, memories, etc). Moreover, some
stereotypes are able to reflect the underlying implementation technology, as will be discussed
in section 5.2.4 suggests that the capture of the HW part of the platform can be separated into
two levels through the allocation of architectural components to the components representing
an implementation technology. In any case, the MARTE DRM::HRM::Logical profile
provides the MARTE elements to be used for such a description.
4.1.3 Architecture Modelling
This section provides a discussion of the design packages of the MARTE profile and their
relevance to the COMPLEX project from the point of view of the architecture modelling. The
allocation of functional application elements onto the available resources (the execution
platform) is main concern of real-time embedded system design. A MARTE allocation is an
association between a MARTE application (whose components were modelled in sections
5.2.2.1 and 5.2.2.2) and a MARTE execution platform (modelled in section 5.2.3.1).
While in previous views the system engineer is focused on defining the types of system
components (see section 4.1.1 ) and the platform resources (see section 4.1.2), in this view the
system engineer will:
Instantiate the components that compose the application;
Instantiate the components that model the HW and SW resources of the platform.
Allocate application components to platform components (resources).
Therefore, the packages of interest for these purposes are:
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 25
Allocation Modelling (Allocation);
Application and execution platform models are modelled separately and in parallel, before
they are paired through the allocation process. The allocation can then be viewed as an
abstraction relying on constructs introduced in the more refined model.
4.2 Stateflow in COMPLEX
As shown in Figure 4-4 Stateflow is supported by the COMPLEX project as a possible way to
enter the design flow with a platform-independent description of the system to be designed
[2]; Stateflow has been chosen (together with UML/MARTE) since it is widely used to model
complex control-dominated applications as the one described in Use Case 1 [1].
Figure 4-4 Role of Stateflow-to-C/SystemC conversion in the COMPLEX design flow
In Use Case 1 we will provide abstract, platform-independent Application Programme
Interfaces (APIs) to access the underlying sensors (e.g. accelerometers) and the radio to
send/receive packets. These APIs will be implemented using the Mathworks-provided
languages (e.g. Simulink, Matlab and Stateflow) in the functional simulation phase, and will
be translated into appropriate SystemC code or RTOS-dependent code when the final target
will be generated.
For example, consider a simple WSN application whose basic purpose is to transmit and
receive packets randomly. When a node receives six packets it will stop all communications
and turn on all LEDs on the WSN node. The Stateflow model of the application is shown in
Figure 4-5. The application is triggered by a periodic event, called CLK, which in practice
will need to be generated by a periodic interrupt (assumed to be set every 10 milliseconds in
this case).
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 26
It starts with the initialization of the next transmitting (tNextTX) and receiving (tNextRX)
timestamps. To set these timestamp, in each case it calls a platform API function
getRandTimeStamp which is implemented in SystemC or by the underlying RTOS. After
initialization of timestamps, it sets the received packet count to zero. At the next CLK event,
it moves to the Sleep state from the Init state. In the Sleep State, the receiving and
transmitting timestamps will be decremented by one at every occurrence of CLK. On the
expiration of transmit timestamp, the algorithm will make a transition to the Transmit_pkt
state and also toggle LED 1. In the Transmit state, it sets the first byte of the payload to 1 and
sends the packet by calling a platform API function, sendPacket. After transmitting the
packet, the application makes a transition to the Sleep State, sets the next transmission
timestamp and toggles LED 1. In the same way, when the receiving timestamp expires, the
algorithm makes a transition from the Sleep state to the Receive_pkt state and in the transition
it calls the receivePacket function to configure the radio in receiving mode and also specifies
the duration in milliseconds (here 40 milliseconds).
In the Receive_pkt state, the algorithm waits for the PKT and for the CLK event. The PKT
event is generated after receiving a packet and the CLK event is generated when the periodic
timer expires. After receiving a PKT event, it calls function getPktData to copy the packet
data field into a local variable (payload). Now the algorithm calls a local function processData
where it checks the first byte of the packet data and if it is equal to 1, then it increases the
receiving packet counter and also toggles LED 2 to provide a visual indication of successful
reception of a packet. After expiration of receiving time slot, the algorithm makes a transition
to the Sleep state from Receive_pkt state. While making the transition, it sets the next
receiving timestamp and toggles LED 0.
After receiving 6 packets, it makes the final transition to the Done state where it turns on all
LEDs and stop all communications.
Figure 4-5 Stateflow algorithm modelling a very simple WSN application
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 27
Figure 4-6 shows how the COMPLEX design flow can be applied to the described example.
The design flow starts with the Stateflow platform-independent model described in Figure
4-5. Since this model is platform-independent, it represents the application to be developed.
The initial model is simulated directly by using Stateflow for functional evaluation. Also
external system stimuli are derived from the environment model in Stateflow/Simulink. Then
HIFSuite is used to translate Stateflow description of the application either to a SystemC
model (Scenario A) or to native C/C++ code (Scenario B). As described in section 6.3.3,
HIFSuite performs code generation after having imported Stateflow representation into an
abstract language named HIF. This way, HIF descriptions can be analysed and manipulated
by some tools already present in the HIFSuite. In Scenario A, a pure SystemC model can be
created by merging the model of the application with the model of the other components of
the embedded system (virtual platform). For instance, in Use Case 1, the whole SystemC
model represents a set of wireless sensor nodes interacting through the radio channel. In
Scenario B, HIFSuite generates native code for a target processor which is executed by an
instruction-set simulator (ISS) contained in the SystemC model of the embedded system
(virtual platform).
HIF
description
SystemC
node description
(Virtual Platform)
SystemC
application
description
(A) (B)
Stateflow
application
description
Convertion
through
HIFSuite
Statechart
analysis
&
manipulation
SystemC
node description
(Virtual Platform)
ISS
C/C++
application
code
Figure 4-6 Stateflow-based COMPLEX design flow applied on the example of embedded system
The advantages of this approach with respect to the use of MathWorks code generation tools
are:
generation of SystemC code both at RTL and TLM;
support for parallel state charts to generate multi-threaded models (in SystemC and
C/C++);
presence of advanced analysis functionality, e.g., state reachability, state equivalence,
dependability analysis, model verification;
availability of automated mechanisms to perform transformations on the state charts
(e.g., state reduction, chart abstraction).
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 28
Figure 4-7 depicts the HIFSuite code generation roadmap for a comparison with MathWorks‟
approach shown in Figure 3-4. The proposed roadmap is simpler, new targets are supported,
and new functionalities are added, i.e., analysis and manipulation of statecharts.
Stateflow
model
VHDL,
Verilog
code
(Note 1)
C/C++
code
(Note 1)
SystemC
TLM
code
(Note 1)
ASIC
FPGA
PROCESSOR
SYSTEMC
VIRTUAL
PLATFORM
HIFSuite
SystemC
RTL
code
(Note 1)
Statechart
analysis &
manipulation
NEW
NEW
Note 1:
Generation of both
single-threaded and
multi-threaded
modelsNEW
Figure 4-7 HIFSuite’s roadmap to code generation from Matlab Stateflow
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 29
5 System design methodology
5.1 COMPLEX design process
The COMPLEX design process is subdivided into several high-level activities associated to
each design branch, which again may be split up in two or more sub-level activities. If high-
level activity has not been assigned to any high-level or sub-level activities, only an overall
activity will be listed.
Next Figure 5-1 depicts the whole COMPLEX design process, including both the
UML/MARTE and the Stateflow design branches. As shown in that picture, UML/MARTE
and Stateflow design branches are independent and only have one activity in common. In
order to select which design branch is more appropriate for your project the following criteria
may be applied:
Complexity of the design: Stateflow does not support object oriented concepts,
therefore is not suitable for complex designs.
Platform modelling: Stateflow does not support the modelling of HW and SW resources
at the system platform.
Company policies and experience.
The COMPLEX design process is composed of the following high-level activities are
identified:
In the UML/MARTE design branch:
o UML/MARTE System Design: produces the UML/MARTE model for all the
PIM, PDM and PSM.
o UML/MARTE Model Transformations: in this activity the UML/MARTE is
read and analyzed, and all the output artefacts that feed the simulation and
performance estimation analysis are produced.
o System Coding: in this activity the CFAM code (i.e. user code) is
coded/integrated with the CFAM containers produced in previous activity.
In the Stateflow design branch:
o Stateflow Model Design;
o Transformation to SystemC;
o Transformation to target processor;
Common to both design branches, Simulation and performance analysis;
At the end of the Simulation and performance estimation analysis, system metrics are
compared with the performance requirements derived from the System Specification. If the
system metrics does not fulfil those requirements, it is necessary to modify system models
and regenerate the executable models.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 30
COMPLEX System Modelling
UML/MARTE
System Design
StateFlow Model Design
UML/MARTE
model transformations
Transformation to
SystemC
System simulation
and performance
estimation analysis
System specification
(REQ)StateFlow design
MARTE
PIM, PDM, PSM
StateFlow
SystemC model
Application
Executable Model
Platform
IP-XACT model
XML System
Description Model
Metrics
Metrics (prev.)
MARTE PDM
SystemC model
Do metrics fulfil system specifications?No
Functional codingMARTE CFAM
code
After Design Space Exploration (DSE)
After Virtual Platform simulation
Input Stimuli Model
XML Design Space
Model
Input Stimuli
System
Yes
Transformation to
target processor
StateFlow Target
Processor Model
Legacy Code
Coding Standards
IP Core library
Stimuli Specifications
Figure 5-1: COMPLEX design process
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 31
5.1.1 UML/MARTE System Design
The UML/MARTE System Design activity is in charge of all engineering and modelling tasks
for defining:
The system application, both its functional and non-functional properties (see section
5.1.1.1);
The system platform, both at HW and SW resource level (see section 5.1.1.2);
The stimuli environment that will excite the system during the simulation and
performance analysis activity (see section 5.1.1.4);
The system architecture, instantiating application and platform components, including
the allocation of the application onto the platform sources and the specification of the
DSE parameters, rules and constraints that will drive the DSE cycle (see section
5.1.1.3);
The inputs are mainly the System Specification (e.g. system requirements) and the system
metrics from earlier iterations in the design process.
The outputs consist of UML/MARTE model including the following model viewpoints:
The Platform Independent Model (PIM), which describes the functional and non-
functional aspects of the system functions (e.g. application).
The Platform Description Model (PDM), which describes the different HW and SW
resources that form part of the system platform,
The Stimuli Environment Model, which describes the subsystems that interact with the
system, describes their functional behaviour and model interaction of the system and the
external sub-subsystems by means of stimuli environments.
Finally, the Platform Specific Model, which describes the system architecture, the
allocation of platform resources and the DSE parameters, rules and constraints.
It is intended that this activity receives feedback from previous iterations of the life cycle by
means of the system metrics. At early iterations of the design process, the system metrics will
guide the modelling engineer to modify the system model whenever they do not satisfy the
system requirements.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 32
UML/MARTE System Design
Application Modelling
Platform Modelling
Architecture Modelling
System
specification (Req.)
MARTE PDM
MARTE PSM
Metrics (prev.)
MARTE PIM
Data ModellingDefinition of the external ICD
Use Case modellingStimuli Environment
Model
Figure 5-2: UML/MARTE system modelling
5.1.1.1 Application Modelling
The Application Modelling activity is in charge of all engineering and modelling tasks for
providing a Platform Independent Model (PIM) of the system describing the whole structure
and behaviour of the system abstracting it from any specific platform.
The Platform Independent modelling consists of describing the whole structure and behaviour
of the system abstracting it from a specific platform. The inputs of this activity are the System
Specification and the metrics generated by a previous execution of the DSE loop (see section
5.1.6), in case it was produced. The output consists of the Platform Independent Model (PIM)
of the system, composed by the Data Model, the Functional view and the Communications &
Concurrency views.
The first steps of the Platform Independent modelling are to identify the use cases (in case
that they were not already provided by the System Specification) and define the system‟s
interfaces and classes based on those use cases and the System Specification. These interfaces
and classes compose the Functional view of the PIM (refer to section 5.2.2.1 ) and are the
ones responsible of implementing the functional part of the system. In parallel, the data model
is refined using the information and necessities extracted from the System Specification and
the Functional view to generate the Data Model of the PIM.
Once defined the Data Model and Functional views, the system components and their internal
structure are identified and modelled. These components are the basic logical units of the
system. Each one may identify an independent concurrent element of the system (a real-time
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 33
unit, refer to section 5.2.2.2 ) or a unit of communication and synchronization between other
components (a protected passive unit, refer to section 5.2.2.2). The internal structure of a
component is composed by instances of the classes identified in the Functional view, which
are in charge of executing the functional behaviour of the component. The definition of the
system components and their internal structure are the bases of the Communications &
Concurrency view of the PIM (refer to section 5.2.2.2). This view also includes the
description of the internal interactions between the elements of a component needed to carry
out a specific component‟s provided service as well as the external interactions between
components needed to execute the system operations. These interactions are specified by
means of sequence diagrams.
The last step in the Platform Independent modelling is to identify the non-functional aspects
of the system (as for example time related constraints) and annotate consequently the
diagrams of the Communications & Concurrency with them, using the elements and tools
provided by UML MARTE.
As shown in Figure 5-3, the description of the Communications & Concurrency view of the
system may be affected by the metrics provided by a previous execution of the DSE loop.
These metrics must be taken into account when developing this view, as they could imply
changes in the concurrency structure of the system or in its non-functional properties.
The inputs are mainly the System Specification (e.g. system requirements) and the system
metrics from earlier iterations in the design process.
The outputs consist of UML/MARTE model including the following model viewpoints:
The Platform Independent Model (PIM), including its three specific model views: the
Data model, the Functional view and the Communications & Concurrency view.
The following image depicts the different steps of the Application Modelling activity.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 34
Platform independent modelling
Define
component interactions
Define internal
component interactions
System Specification
(REQ)
Metrics (prev.)
MARTE PIM
Refine data model
Identify use cases
Define interfaces and classes
Identify system components
Define component internal structure
Define non-functional aspects
Figure 5-3: MARTE platform independent modelling
5.1.1.2 Platform Modelling
The Architecture Modelling activity is in charge of all engineering and modelling tasks for
providing a Platform Description Model (PDM) of the system describing the whole structure
of the system platform, in a sufficiently abstract way to prevent the designer for a
cumbersome data input; and in a sufficiently detailed way to enable the performances
estimation, for the DSE flow, and even to feed further implementation activities.
The Platform Description modelling consists of describing which the components of the
platform are. Each component specification requires providing its identifier and its type, and
the parameter values which define it, e.g., number of processors for a processor cluster.
Parameters can be required and optional. Their values can be fixed or tuned by the DSE
exploration tool.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 35
The user defines the platform following any requirement regarding it. The metrics generated
by a previous execution of the DSE loop (see section 5.1.6), in case at least one DSE
interation was already produced, can be used by the user to change platform components,
fixed and default values, and to add/remove values of optional parameters. The exploration
tool can automatically change the input values of parameters which can be tunned.
Platform
Initial
Requirements
Metrics (prev)
Platform Description Modelling
PDM Defne Primitive HW Components
Define HW Hierarchical Components
Instantiate Components
Define Interconnections Fill Attribute Values
Define SW platform components
Figure 5-4: MARTE platform description modelling.
The output consists of the Platform Description Model (PIM) of the system, composed by the
Platform Description view.
The first step of the designer is to create a platform description view. Then, once the user has
identified the HW primitive components, they are captured in UML/MARTE providing the
corresponding identifiers and using UML/MARTE stereotypes for its typing. Then user
provides the values for the component attributes. Later on, the user describes hierarchical HW
components. For it, the user must make instantiations of previously defined components and
define their interconnections. This process is iterative. Following, the user defines the SW
components (RTOS, device drivers), providing their identifiers and types.
The inputs are mainly the System Specification (e.g. system requirements) and the system
metrics from earlier iterations in the design process.
The outputs consist of UML/MARTE model including the following model viewpoints:
The Platform Description Model (PIM), including a description of all platform
components, either HW or SW, that form part of the system platform.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 36
5.1.1.3 Architecture Modelling
The Architecture Modelling activity is in charge of all engineering and modelling tasks for
defining:
The system architecture, instantiating the application components defined in activity
Application Modelling, and the platform components modelled in activity Platform
Modelling.
The allocation of the application components to the platform resources.
The DSE parameters associated to both application and platform components, and the
different DSE rules and constraints that will drive the DSE cycle;
The following steps are recognized in this activity to achieve the previous objectives:
1. Instantiation of the application components defined in the activity Application
Modelling.
2. Component binding , in which the application components are assembled together to
form the system application. See section 5.2.4.1 regarding how to assemble the
application components.
3. Instantiation of the platform components defined in the activity Platform Modelling.
4. Component binding , in which the platform components are assembled together to
form the system application. See section 5.2.4.1 regarding how to assemble the system
platform.
5. Allocation of individual application components to platform components by means of
the MARTE stereotypes described in section 5.2.4.1.
6. Finally, and maybe in parallel to previous steps, define the DSE parameters, rules and
constraints that will guide the DSE cycle. There should not be orphan DSE parameters
not referenced by DSE rules and/or DSE constraints. For further information about
how to describe them in the UML model, refer to section 5.2.4.1.
The inputs are mainly the System Specification (e.g. system requirements) and the system
metrics from earlier iterations in the design process. It is implicit that the PIM and PDM
model viewpoints are imported to define the architecture.
The outputs consist of UML/MARTE model including the following model viewpoints:
The Platform Specific Model (PSM), which describes the system architecture, the
allocation of platform resources and the DSE parameters, rules and constraints that will
drive the DSE cycle.
The following image depicts the different steps of the Architecture Modelling activity.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 37
Architecture Modelling
System Specification
(REQ)
MARTE PSM
Instantiate application
components
Declare DSE
parameters
Declare DSE Rules
and DSE constraints
Assemble
the system application
Instantiate platform
components
Assemble
the system platform
Allocate platform
Resources
Metrics (prev.)
Figure 5-5: Architecture Modelling
5.1.1.4 Use Case Modelling
The Use Case Modelling activity is in charge of all engineering and modelling tasks for
defining:
The stimuli environment responsible for exciting the system during the simulation and
performance estimation analysis.
The use cases which model the external stimuli to be injected to the system described in
the Architecture Modelling activity.
The following steps are recognized in this activity to achieve the previous objectives:
1. Identify the different external sub-systems interacting with the system and analyze
how they interact with the system. Those subsystems must be already identified in
activity Application Modelling like UML actors.
2. Model the behaviour of the external sub-system entities using the information
provided in the Use Case diagrams developed in activity Application Modelling. Refer
to section 5.2.5.1 for a more detailed description of how this modelling can be done.
3. Instantiate the system and the external sub-systems in order to define the stimuli
environment. Refer to section 5.2.5.1 for a more detailed description of how this
modelling can be done.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 38
4. Finally, create the stimuli scenarios which will model the interaction between the
system and the external sub-systems. Refer to section 5.2.5.1 for a more detailed
description of how this modelling can be done.
The inputs are mainly the System Specification (e.g. system requirements) and the system
metrics from earlier iterations in the design process. It is implicit that the PIM and the PSM
viewpoints are imported to define the architecture.
The outputs consist of UML/MARTE model including the following model viewpoints:
The Input Stimuli Model, which describes the stimuli environment and the stimuli
scenarios that will drive the system excitation during the simulation and performance
estimation analysis.
It is intended that this activity will start only when the activity Application Modelling has
provided the UML use cases and identified correctly the different interacting sub-systems.
It is also mandatory for this activity to start that the data model developed in the activity
Application Modelling has been already provided defining the data structures exchanged
between the system and the external sub-system.
Finally, this activity might be developed in parallel with other activities but wait for the
activity Architecture Modelling to define the system interfaces with the external world. For
additional details about this issue, refer to section 5.2.5.1.
The following image depicts the different steps of the Use Case Modelling activity.
Input stimuli modelling
Analyze interactions
with external subsystems
Model the stimuli
environment
System Specification
(REQ)
Input Stimuli Model
Model the behaviour
of the external subsystems
Create stimuli scenarios
Figure 5-6: Input stimuli modelling
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 39
5.1.2 Stateflow System Design
A Stateflow chart is a representation of a finite state machine, in which the system makes a
transition from one state (mode) to another, if the condition defining the change is true.
Stateflow uses the finite state machine notation established by Harel [38], where states and
transitions form the basic building blocks of the system, and you can also represent stateless
charts (flow graphs). A Stateflow chart enables the representation of hierarchy, parallelism,
and history. You can organize complex systems by defining a parent and offspring object
structure [39]. A system with parallelism can have two or more orthogonal states active at the
same time. You can specify the destination state of a transition based on historical
information.
In Wireless Sensor Networks, which are the application domain for Use Case 1 in Complex,
Stateflow is used to model both the protocol and the application, since both are generally
simple and require making simple decision and computations, which can be easily modelled
as statecharts.
Simulation uses a time-driven model, in which executions of the statechart are triggered e.g.
by level crossings of input signals (e.g. any time an input goes above or below a threshold) or
periodically.
Multi-threaded SystemC code can be generated from a Stateflow chart, following the
generation semantics that is outlined in Section 5.3.2, in order to interface with the rest of the
Complex design flow. Single-threaded ANSI C code can also be generated, to be executed on
the processor ISS or on the actual hardware, as described in Section 5.3.3.
5.1.3 MARTE Model Transformations
The MARTE Model Transformations activity is in charge of all engineering and code
generation tasks for producing the following artefacts:
The application containers (i.e. CFAM, Native SW and SystemC, see section 5.2.6), and
the CFAM code skeletons (e.g. the functional code skeletons).
The IP-XACT model of the system platform.
The executable model of the system platform, required by the Virtual Platform in case
of selecting simulation technique (see section 5.1.6 for further details).
The Input Stimuli System executable model and the associated interfaces to interact
with the application executable model.
The XML System Description document, which is input to the tool SCoPE+ (see
section 6.5.1) describing the system architecture (application, platform and allocations).
The XML Design Space document, which is input to the tool MOST (see section 6.5.3)
proving the DSE parameters and rules that will drive the DSE cycle.
The following steps are recognized in this activity to achieve the previous objectives:
1. Generation the application containers and the CFAM code (e.g. the functional code of
the application) taking as input the MARTE PIM produced in the activity Application
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 40
Modelling. This activity is supported by the tool COMPLEX CFAM generator
described in section 6.4.2.
2. After previous step, generation the XML System Description and XML Design Space
artefacts, which are input to the simulation and performance analysis performed by
SCoPE+. This activity is supported by the tools COMPLEX XML System Description
generator and COMPLEX XML Design Space generator described in sections 6.4.3
and 6.4.4, respectively.
3. In parallel to previous steps, the IP-XACT and the SystemC executable models of the
system platform could be generated. First, the IP-XACT model is produced using the
tool COMPLEX IPXACT generator described in section 6.4.1. Afterwards, the
SystemC executable model is produced transforming this IP-XACT specification to
SystemC using the tool described in section 6.3.2.
4. Again, in parallel to all previous steps, the stimuli system can be produced using the
tool COMPLEX Stimuli Input generator described in section 6.4.5.
The input is mainly the IP Core Library necessary to create the IP-XACT model. It is implicit
that the PIM, PDM and the PSM viewpoints are input for this activity.
The outputs of this activity consist of following documents and source code:
The application containers, and the CFAM code skeletons.
The IP-XACT model of the system platform.
The SystemC executable model of the system platform.
The Input Stimuli System executable model.
The XML System Description document.
The XML Design Space document.
The following image depicts the different steps of the MARTE Model Transformations
activity.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 41
MARTE Model Transformations
Generate
Application Executable Model
Generate
IPXACT Model
Generate
SystemC Platform ModelMARTE PDM
SystemC model
CFAM code
(skeletons)
Platform IP-XACT
model
XML System
DescriptionGenerate
System Description
Input Stimuli
SystemGenerate
Input Stimuli System
XML Design SpaceGenerate
Design Space Description
Application
containers
Figure 5-7: MARTE Model Transformations
5.1.4 Stateflow Transformation to SystemC
The functional behaviour of the Stateflow model can be translated into concurrent multi-
threaded SystemC code for functional verification, e.g. at virtual platform level, by translating
each semantic object (e.g. states, junctions, transitions, hierarchy) to an appropriate SystemC
construct, as described more in detail in section 5.3.2.
The user can choose to generate either multi-thread or single-thread code depending on the
modelling needs. Multi-thread behaviour is obtained by using SystemC sc_thread. Single-
thread code is generated by serializing AND states according to the execution order specified
in the original Stateflow model.
The input of the activity is the MDL file generated by the Stateflow tool for each block, and
the output of the activity is a SystemC module which has the same interface as the Stateflow
block.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 42
5.1.5 Stateflow Transformation to the Target Processor
The functional behaviour of the Stateflow model can also be translated into ANSI C for
execution on an Instruction Set Simulator, embedded within a Complex platform model, or on
the actual target processor.
This is done by translating each semantic object (e.g. states, junctions, transitions, hierarchy)
to ANSI C code corresponding to the behaviour of the statechart, implemented as a set of
nested switch and if statements representing the behaviour of the various states and super-
states, depending on and affecting the value of external and internal signals, as well as
depending on timeouts and on entering and leaving other states of the statechart, as described
in Section 5.3.3.
The input of the activity is the MDL file generated by the Stateflow tool for each block, and
the output of the activity is a C file which has the same interface as the Stateflow block,
implemented using functions (e.g. pktEvent() to notify the generated code that input event
pkt has arrived) that allow the generated code to access the block inputs and update the block
outputs.
5.1.6 Model Simulation and Performance Analysis
The Model Simulation and Performance Analysis activity is in charge of all engineering tasks
for verifying the system behaviour and producing the performance metrics.
Two different approaches might be taken for obtaining the performance metrics:
Performing a design space exploration for trying to reach an optimal architecture, which
will output the metrics of the optimal architecture.
Performing a simulation on a virtual platform.
In current version of the COMPLEX design process, the former is only available on the
UML/MARTE design branch. Derived from the UML model, DSE parameters and rules are
transformed into the XML Design Space artefact, which drives the DSE cycle performed by
the SCoPE+ (see section 6.5.1) and MOST (see section 6.5.3) tools.
The later can be performed for both UML/MARTE and Stateflow design branches.
For performing the DSE cycle the following inputs derived from previous activities are
necessary:
The application executable model for SCoPE+, i.e. CFAM model.
The XML System Description artefact.
The XML Design Space artefact.
The Input Stimuli System.
For evaluating the system performance in the virtual platform, the following artefacts are
required:
In the UML/MARTE design branch:
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 43
o The application executable model, i.e. Native Software PIM. It might be
required to adapt this model to the virtual platform it is intended to.
o The SystemC executable model of the system platform.
In the Stateflow design branch:
o The application executable model targeted to a particular processor. In this
case the virtual platform should support the targeted processor.
The outputs of this activity consist of the system performance metrics.
The following image depicts the different steps of the Model Simulation and Performance
Analysis activity.
Model Simulation and Performance
Analysis
Perform
Design Space Exploration
Estimate performace
Virtual Platform
simulation
Design Space
Exploration
Metrics
Figure 5-8: Model Simulation and Performance Analysis
5.2 UML/MARTE design methodology
The following section introduces UML/MARTE specification methodology of COMPLEX.
The main concepts sustaining the methodology, as well as the modelling elements, procedures
and flows to be traversed by the user will be explained in the following sub-paragraphs.
5.2.1 Definition of model views
The increasing complexity of embedded systems requires an additional effort to deal with the
different system concerns. In particular, the separation of the functional and non-functional
aspects of the system allows mastering this complexity. This is known as separation of
concerns.
Different aspects in a RTES should be taken into account: from concurrency at application
level to functional specification via hardware selection, data modelling, verification and
validation, architecture definition and system configuration. A well-defined separation of
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 44
concern enables to focus the designer‟s attention on specific aspects of the system. Indeed,
without the need of coping with all system aspects at once, it allows designers to gain control
over the development process.
Separation of concerns may be achieved using two different approaches:
designing the system using distinct models, one for each concern;
designing the system using a single model with dedicated views, which are specialized
projection of the system in specific areas of interest.
The first approach is the most complex one from a theoretical point of view. Distinct models
are used to address different concerns. These models may or may not use the same
specification language. The major difficulties lay in assuring that the meta-models of the
different languages do not overlap. Even they use the same specification language,
consistency is another issue to be considered.
In the second approach, the separation of concerns is achieved by providing distinct system
views to the designer, each one for every relevant aspect. There is a single specification
language with a single meta-model. Again, the major problem in this approach is how to
maintain the consistency between different views, so that the combination of all views covers
consistently the whole system description.
Section 5.2 defines the different model views in the COMPLEX project that will address and
manage the separation of concerns at the system-level model. There are four different kinds of
views:
Data model and Functional views, part of the PIM: focused on the data exchanged
within the system and the functional aspects of the system.
Communications and concurrency view, part of the PIM: centred on the non-functional
aspects of the system.
Platform Description view, part of the PDM: provides a description of the platform
resources, either HW or SW.
Architectural view, part of the PSM: provides information about the architectural
mapping of system functions onto platform resources.
Additionally, the Verification view: devoted to the definition of the system stimuli
environment. This view represents the external systems interacting with the system,
defines the stimuli for the verification of the system functions and specifies a set of test
procedures to evaluate the system power and timing characteristics.
5.2.2 Platform Independent Model (PIM)
The development of the Platform Independent Model (PIM) focuses on the environment and
the requirements of the system ([3]). The details of the processing platform are hidden or as
yet undetermined. In order to master the complexity of the PIM two different model views are
defined within the Platform Independent viewpoint:
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 45
The data model and functional view (see section 5.2.2.1), devoted to only system
functional aspects (e.g. the application and the data types involved in all system
functions).
The communications and concurrency view (see section 5.2.2.2), devoted to extra-
functional aspects of the system (e.g. concurrency, real-time properties).
The following sub-paragraphs include a detailed description of the UML2 diagrams and
element associations, and MARTE profiles and stereotypes to be used for the different model
views. The COMPLEX profile will extend UML diagrams with additional semantics that are
not covered by the MARTE profile (see section 6.2.3).
5.2.2.1 Data Model and Functional View
This model view focuses on the definition of the application behaviour. This includes the
modelling of the data types that will be involved in the application operations, and the
behavioural definition of the application itself (i.e. operations, interfaces).
The data model will be defined within an UML package stereotyped with the DataModel
stereotype of the COMPLEX profile (see section 6.2.3.1 for further details).
The functional view will be defined within an UML package stereotyped with the Functional
View stereotype of the COMPLEX profile (see section 6.2.3.1 for further details).
The following UML2 diagrams will be used for this view:
Use case diagrams.
It represents the general capabilities provided by the system and the actors that
interact with it.
The next table summarizes the diagram specific elements allowed in the
context of the COMPLEX project, as well as the applicable MARTE profiles
and stereotypes for each element:
UML2 Diagram elements MARTE profiles MARTE stereotypes
Actor N/A N/A
Use case
Association
Class diagram.
On the one hand, the class diagram is used to describe the system‟s data model,
within the UML package stereotyped with DataModel. It will include classes
stereotyped as “signal”, “dataType” or “enumeration”. Only dependency
relationships are allowed: a “dataType” element depends on another
“dataType” or on an “enumeration” element when the former is a complex data
type that contains elements of the latter types.
The next table summarizes the diagram specific elements allowed in the
context of the COMPLEX project, as well as the applicable MARTE profiles
and stereotypes for each element:
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 46
UML2 Diagram
elements
MARTE profiles MARTE
stereotypes
Signal N/A N/A
DataType VSL::DataTypes CollectionType
Enumeration N/A N/A
Dependency
relationship
N/A N/A
Data types might specify the size of its representation in memory. The system
modelling engineer can specify this including a property in the type using the
MARTE data type NFP_DataSize. The notation of this MARTE type consists
of a tuple of three values:
o size: NFP_DataSize[1] = (value=260, unit=KB)
where unit might be bit, Byte, KB, MB or GB.
It is assumed that only one NFP_DataSize property was created by UML data
type. If this property is not specified, The size of the data type will be set by
default by the simulation and performance analysis tool.
On the other hand, the class diagram will be also used to model the interfaces
and classes that implement the functionality of the system, created within the
UML package stereotyped with FunctionalView. Two kinds of relationships
are allowed between the elements of the class diagram in the context of the
COMPLEX project:
o Realization relationships: Between a class and an interface. A class
“realizes” an interface when that class implement the interface‟s
operations.
o Use relationships: Between a class and an interface or between classes.
A class “uses” an interface or another class when the former invokes an
operation provided by the latter.
Some of the interfaces may be required/provided by the components of the
system, i.e., they are associated to a port of the component.
Component‟s ports are stereotyped with the MARTE ClientServerPort.
Interfaces associated to those ports are then stereotyped with the MARTE
ClientServerSpecification.
Other interfaces are stereotyped with the stereotype ExternalInterface from the
COMPLEX profile (see section 6.2.3.3). These interfaces define a logical
dependency of an external entity out of the system. For example, an specific
function requires to access data from a camera device connected to the system.
Component‟s ports are typed with these interfaces to highlight the dependency
of the external source/sink of data.
The classes implement the functionality of the system and will belong to one
of the components of the system.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 47
The next table summarizes the diagram specific elements allowed in the
context of the COMPLEX project, as well as the applicable MARTE profiles
and stereotypes for each element:
UML2 Diagram elements MARTE profiles MARTE stereotypes
Interface GCM ClientServerSpecification
Class N/A N/A
Realization relationship N/A N/A
Use relationship N/A N/A
The next table describes the specific UML elements listed in previous table
where the COMPLEX profiles and stereotypes are applicable:
UML2 Diagram elements COMPLEX profiles COMPLEX
stereotypes
Interface Verification ExternalInterface
Please, refer to section 6.2.3.3 for more details about the semantics of the
previous COMPLEX stereotypes.
MARTE Stereotype’s attributes
For each corresponding MARTE stereotype, the attributes that will be used in
the COMPLEX project are described below.
For each attribute, its meaning, possible values to be assigned and character in
the context of the COMPLEX project are specified.
When some MARTE stereotype‟s attribute (or some its possible values) is not
being used or its original meaning in MARTE is lightly specialized in the
COMPLEX project, it will be explicitly indicated and the reasons will be
explained.
The character of a specific attribute may take one of these values:
Mandatory: The attribute must be used and a valid value must be
given to it for each model element to which the corresponding
stereotype applies.
Optional: The attribute may be used or not in the model elements
to which the corresponding stereotype applies. The decision is up to the
system designer.
Not used: The attribute is not used in the MARTE model.
In some cases, the character of some attribute may take more than one of the
previous values, depending on certain condition (for example, the value taken
by another attribute of the stereotype.) In those cases, the corresponding
condition is identified.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 48
Note that ClientServerSpecification is not considered below as MARTE does
not define any attribute for them.
CollectionType
o collectionAttrib: Property [1]
This attribute identifies the element type, size, uniqueness and order
kind of this composite data type.
In the context of the COMPLEX project, whenever an UML data type
is stereotyped with this CollectionType stereotype indicates that the
selected data type consist of list of data types constrained to those
defined in the UML::DataType package or one of the children meta-
classes only.
This property is constrained, within COMPLEX project, to the
following possible property values: MARTE_DataType::IntegerMatrix
or MARTE_DataType::RealMatrix.
Character: Mandatory.
5.2.2.2 Communications and Concurrency View
This model view focuses on the definition of the application components (i.e. definition of
components types) at extra-functional level, i.e. defining the non-functional properties of the
application components (i.e. deadlines, worst execution times for component services).
The communications and concurrency view will be defined within an UML package
stereotyped with the CommsConcurrencyView stereotype of the COMPLEX profile (see
section 6.2.3.1 for further details).
The following UML2 diagrams will be used for this view:
Composite structure diagrams.
This diagram will be used to show the components of the system and their
internal structure.
A component represents a modular part of the system that encapsulates its
contents and whose behaviour is defined in terms of provided and required
interfaces. Two kinds of components are foreseen in the context of the
COMPLEX project:
o Components with their own execution thread, providing/requiring
services to/from others components by means of provided and required
interfaces. These components are stereotyped with the MARTE RtUnit.
o Components that represent information shared by several components
and whose concurrent access must be protected by some
synchronization mechanism. These components are stereotyped with
the MARTE PpUnit.
Component‟s ports are stereotyped with the MARTE ClientServerPort, and
maybe by a MARTE RtFeature with its corresponding associated
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 49
RtSpecification (defined within a comment), which details real-time
characteristics related to the port.
The composite structure diagram also shows the internal structure of the
mentioned components. Components‟ parts will consist of instances of the
classes that appear in the class diagram. Those classes implement the
functionality of the component. The internal instances will have ports that can
be connected between them through assembly connectors, indicating the
collaboration to carry out some operation provided by some component‟s
interface. A port of an internal instance may be also associated to a port of the
component by means of a delegation connector, indicating that the provided
interfaces of the component are realized by the instance.
The next table summarizes the diagram specific elements allowed in the
context of the COMPLEX project, as well as the applicable MARTE profiles
and stereotypes for each element:
UML2 Diagram elements MARTE profiles MARTE stereotypes
Component HLAM RtUnit
PpUnit
Port (component) GCM ClientServerPort
HLAM RtFeature
Provided interface GCM ClientServerSpecification
Required interface GCM ClientServerSpecification
Comment HLAM RtSpecification
Instance specification N/A N/A
Port (instance specification) N/A N/A
Assembly connector
(between instances)
N/A N/A
Delegation connector
(between a instance‟s port
and a component‟s port)
N/A N/A
Sequence diagram.
Sequences diagrams will be used to model both the interaction between
component instances and the interactions between class instances belonging to
a given component.
o Component instances sequence diagrams.
There will be one diagram of this kind for each system operation
identified.
The diagram will consist of several lifelines representing the instances
of the components that participate in the execution of the corresponding
system operation.
Each message interchanged by two component instances will
correspond to one of the services provided by some of the provided
interfaces of the component instance that receives the message.
Those messages may be stereotyped by the MARTE RtService,
indicating its real-time behaviour.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 50
The execution specifications associated to the lifelines of the
component instances may be annotated with some of the stereotypes
included in the MARTE Time profile.
The next table summarizes the diagram specific elements allowed in
the context of the COMPLEX project, as well as the applicable
MARTE profiles and stereotypes for each element:
UML2 Diagram elements MARTE profiles MARTE stereotypes
Lifeline
(associated to a component
instance)
HLAM RtUnit
PpUnit
Execution specification Time
Message HLAM RtService
o Class instances sequence diagrams.
This kind of diagram is similar to the previous one, with the difference
that in this case it represents the interaction between internal class
instances of a component. The diagram shows the interaction between
class instances of a component when some of the services provided by
the component must be executed.
The next table summarizes the diagram specific elements allowed in
the context of the COMPLEX project, as well as the applicable
MARTE profiles and stereotypes for each element:
UML2 Diagram elements MARTE profiles MARTE stereotypes
Lifeline
(associated to a class
instance)
N/A N/A
Execution specification Time
Message HLAM RtService
MARTE Stereotype’s attributes
For each corresponding MARTE stereotype, the attributes that will be used in
the COMPLEX project are described below.
For each attribute, its meaning, possible values to be assigned and character in
the context of the COMPLEX project are specified.
When some MARTE stereotype‟s attribute (or some its possible values) is not
being used or its original meaning in MARTE is lightly specialized in the
COMPLEX project, it will be explicitly indicated and the reasons will be
explained.
The character of a specific attribute may take one of these values:
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 51
Mandatory: The attribute must be used and a valid value must be
given to it for each model element to which the corresponding
stereotype applies.
Optional: The attribute may be used or not in the model elements
to which the corresponding stereotype applies. The decision is up to the
system designer.
Not used: The attribute is not used in the MARTE model.
In some cases, the character of some attribute may take more than one of the
previous values, depending on certain condition (for example, the value taken
by another attribute of the stereotype.) In those cases, the corresponding
condition is identified.
Note that ClientServerSpecification and RtFeature stereotypes are not
considered below as MARTE does not define any attribute for them.
RtUnit
o isDynamic: Boolean
This attribute specifies whether the creation of the tasks in charge of
executing the services of the RtUnit is dynamic or not. In the context of
the COMPLEX project the dynamic creation of tasks is not allowed, so
this attribute will be always set to False. There will be a predefined
pool of tasks to execute the services of the RtUnit.
Character: Mandatory (and always set to False)
o isMain: Boolean
It may be True or False. If True, the RtUnit will have a main function.
Character: Mandatory
o srPoolSize: Integer
As the tasks will not be created dynamically in COMPLEX (the
attribute isDynamic will be always set to False), the size of the pool of
tasks must be defined. This attribute takes an Integer value.
Character: Mandatory
o srPoolPolicy: PoolMgtPolicyKind
Defines the pool management policy. It can take one of the three
following values:
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 52
infiniteWait: If none of the tasks in the pool is available to
execute the service, the RtUnit will wait indefinitely until one
of them is released.
timedWait: If none of the tasks in the pool is available to
execute the service, the RtUnit will wait a specific time until
one of them is released. If the waiting time expires, an
exception is raised.
exception: If none of the tasks in the pool is available to
execute the service, an exception is directly raised.
The pool management policies dynamic and other defined by MARTE
are not taken into account. The first one would imply dynamic creation
of tasks, which is not allowed in COMPLEX. The second one is
discarded as in the context of the COMPLEX project it is not foreseen
other policy different from those specified above.
Character: Mandatory
o srPoolWaitingTime: NFP_Duration
It defines the maximum time a RtUnit waits for a task of the pool to be
released, in case that the srPoolPolicy is set to timedWait.
Character: Mandatory(when the srPoolPolicy is set to timedWait)/ Not
used (otherwise)
o queueSchedPolicy: SchedPolicyKind
It may take any of the values defined by UML MARTE.
Character: Mandatory
o queueSize: Integer
Size of the message queue of the RtUnit. It may take any Integer value.
Character: Mandatory (the amount of memory to be used by the
application defined using MARTE must be specified)
o msgMaxSize: NFP_DataSize
It represents the maximum size of the messages acceptable in the
queue.
Character: Mandatory
o operationalMode: Behaviour
This attribute consists of a behaviour associated to the RtUnit
representing its operational modes.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 53
Character: Optional
o main: Operation
The name of the main operation of the RtUnit in case that the isMain
attribute is set to True.
Character: Mandatory(when the isMain attribute is set to True)/Not
used(otherwise)
o memorySize: NFP_DataSize
It specifies the amount of static memory necessary to place each
instance of the RtUnit in an application.
Character: Mandatory (the amount of memory to be used by the
application defined using MARTE must be specified)
PpUnit
o concPolicy: CallConcurrencyKind
This attribute establishes the default policy applied to the services
provided by PpUnit. When a service provides its own policy, the latter
is used instead of the default one. It may take the following values:
sequential: No concurrency mechanism is associated so the
system designer must assure that no concurrent invocations are
produced.
guarded: Several invocations may occur concurrently, but
only one is attended at a time. The rest are blocked until the
execution of the invocation being attended finishes.
concurrent: Several invocations may occur and be attended at
the same time.
Character: Mandatory(when some service doesn‟t define its own
policy)/Not used(otherwise.)
o memorySize: NFP_DataSize
It specifies the amount of static memory necessary to place each
instance of the PpUnit in an application.
Character: Mandatory (the amount of memory to be used by the
application defined using MARTE must be specified.)
ClientServerPort
o specificationKind: PortSpecificationKind
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 54
It describes how the provided or required functionalities associated to
the port have been defined.
In the context of the COMPLEX project the ports always define its
associated functionalities by means of interfaces. So this attribute will
always be set to interfaceBased.
So, featureBased and atomic values defined by MARTE for this
attribute will not be used in COMPLEX.
Character: Mandatory (always set to interfaceBased)
o isConjugated: Boolean
As defined by MARTE, this attribute only applies to featureBased
ports, so it will not be use in COMPLEX, where only interfaceBased
are allowed.
Character: Not used
o kind: ClienServerKind
It defines the kind of the functionalities associated to the port (in this
case, the kind of the interfaces, as ports are always interfaceBased in
COMPLEX). It may take the following values:
required: If the associated interfaces are only required
interfaces.
provided: If the associated interfaces are only provided
interfaces.
proreq: If there are both required interfaces and provided
interfaces associated to the port.
Character: Mandatory
RtSpecification
o utlility: UtilityType
The type of this parameter is user-defined, so the designer may decide
if it is needed or not.
Character: Optional
o occKind: ArrivalPattern
This attribute specifies the arrival pattern of the invocations to the
corresponding RtFeature. It may take any of the values defined by
MARTE.
Character: Mandatory
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 55
o tRef: TimedInstantObservation
This attribute is used to specify a time reference associated to the
execution of the corresponding RtFeature. The corresponding time
reference will be identified by its name.
Character: Optional
o relDl: NFP_Duration
This attribute is used to specify a deadline relative to the time reference
specified by the tRef attribute.
Character: Optional
o absDl: NFP_DateTime
This attribute is used to specify an absolute deadline associated to the
execution of the corresponding RtFeature.
Character: Optional
o bounDl: NFP_Duration
It specifies a relative deadline. MARTE does not give the precise
semantics of this attribute, so its use depends on the designer.
Character: Optional
o rdTime: NFP_Duration
It is used to specify the minimum ready time of the corresponding
RtFeature.
Character: Optional
o miss: NFP_Percentage
It specifies the percentage of acceptance for missing the deadlines. It
must be specified if any deadline has been defined.
Character: Mandatory (when some deadline has been defined)/Not
used(otherwise)
o priority: NFP_Integer
It is used to specify the priority of the corresponding RtFeature.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 56
Character: Optional
o context: BehavioralFeature
This attribute is used to specify the BehavioralFeature to which the
RtSpecification attributes apply, in case that the corresponding
RtFeature is a Port. That BehavioralFeature will be identified by its
name.
Character: Mandatory(when the associated RtFeature is a Port)/Not
used(otherwise)
The proposed modelling tool does not support this property so it is
necessary to apply the RtSpecification stereotype to a comment with the
same body content than the interface method. The syntax would be
[interface_name.method].
RtService
o concPolicy: ConcurrencyKind
This attribute is used to identify the kind of concurrency associated to
the service. It may take one of the following values:
reader: The execution of the RtService does not modify
the state of the object (for example, the value of its attributes.)
writer: The execution of the RtService modifies the state
of the object (for example, the value of its attributes.)
parallel: The execution of the RtService may be done in
parallel with another service.
Character: Optional (Although it could be very useful for the designer
to establish other properties of the service to which the RtService
stereotype applies, or the properties of the objects that call the service.)
o exeKind: ExecutionKind
This attribute identifies the execution nature of the service. It may take
one of the following values:
deferred: The execution of the service is carried out
by the object that owns it.
remoteImmediate: The execution of the service is carried out
by the calling object immediately after the calling event.
localImmediate: The execution of the service is carried out
by the object that owns it immediately after the calling event.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 57
Character: Mandatory
o isAtomic: Boolean
This attribute may be True or False. When True, the RtService is
executed atomically, non-interleaved with another RtService (although
not explicitly specified in MARTE, in the context of the COMPLEX
project this constraint will be considered either they are executed in the
same or different computing resources.) When False, the execution of
the RtService may be interleaved with the execution of another non-
atomic RtService.
Character: Mandatory
o synchKind: SynchronizationKind
It determines the synchronization mechanism of the service.
synchronous: The calling object waits for the end of the
execution of the RtService before it continues its own execution.
asynchronous: The calling object does not wait for the
end of the execution of the RtService before it continues its own
execution (so they may execute in parallel).
delayedSynchronous: The calling object continues its own
execution and does not synchronize with the RtService until the
latter returns some value.
rendezVous: The RtService and the calling object
synchronize using a Rendez-vous mechanism.
The synchronization kind other defined by MARTE is not taken into
account, as the synchronization kinds mentioned above are considered
enough for the COMPLEX project.
Character: Optional
5.2.3 Platform Description Model (PDM)
The development of the Platform Description Model (PDM) focuses on the software and
hardware features of the system platform. It provides a set of technical concepts about the
parts and services provided by the system platform, as well as the different kind of
computational resources to be used by application ([3]).
The platform is not considered as a model viewpoint itself in [3]. However due to the fact it
provides lots of information to the transformation of the PIM to the Platform Specific Model,
it is sensible to consider the platform modelling as a separate view within the COMPLEX
design process. Section 5.2.3.1 includes a detailed description of the UML2 diagrams and
element associations, and MARTE profiles and stereotypes to be used for modelling both the
SW and the HW aspects of the system platform.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 58
5.2.3.1 Platform Description View
This model view focuses on the definition of the system platform at both HW and SW levels.
This view enables the description of the SW and HW resources of the platform. Moreover, the
PDM will support configurability in order to enable the representation of a set of PDMs, and
thus define a platform exploration space. Such a platform exploration space is enabled by
means of two mechanisms:
Enabling the configurability of the multiplicity of a certain platform component (either
through a property or through a template parameter).
Enabling the description of an allocation space between SW and HW components of the
platform.
As introduced in section 4.1.2.1, the COMPLEX UML/MARTE methodology aims a
synthetic description of the main components of the SW platform, e.g. RTOS instances.
The description of the HW platform will cover the structural description of the platform,
including a portfolio of usual components (processor, bus, memory, bridge, etc), plus the
possibility to reflect the presence of devices enabling the custom implementation of part (or
the whole) of the system functionality.
All the platform components and diagrams, except for the diagram for the top platform
architecture, which is part of the architecture platform view (see section 5.2.4.1), will be
enclosed in an UML package stereotyped through the PlatformDescriptionView stereotype of
the specific COMPLEX profile (section 6.2.3).
As a result, the following UML2 diagrams are proposed for this view:
Component diagram for declaring HW platform components
This diagram will be used to declare the HW components of the system,
including both, elementary and hierarchical components which will be
instanced for building the top architecture of the platform. This diagram can be
used also for settling the attributes of the components.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 59
UML2 Diagram elements MARTE
profiles
MARTE stereotypes
Component HRM:Logical HwResource
HwComputingResource,
HwProcessor,
HwPLD,
HwASIC
HwCommunicationResource
HwMedia
HwBus
HwBridge
HWBus
HwMemory
HwCache
HwRAM
HwROM
HwDevide
HwIO
Port N/A N/A
Interface N/A N/A
A minimum set of rules will apply to the diagram built up of these elements.
Such restrictions are reflected in the following table:
Rule Rationale
At least one component with processing
capabilities will be declared. That is, at least a
component with HwComputingResource or
derived stereotype.
At least one element to
compute application is
required.
At least one component with communication
capabilities among processing components will
be declared. That is, at least a component with
HwCommunicationResource or derived
stereotype.
To define a “computation
node/cluster” (required by
SCoPE).
A Component must have at least an
interconnection port.
The interconnection
interfaces are clearly
declared and indentified
for a component.
An interface can be optionally associated to a
port
To enable the declaration
of HW interconnection
interfaces and later let
inter-connection
consistency checks
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 60
Composite structure diagram for the internal HW architecture of a
hierarchical HW platform component
This diagram will be used to describe the internal structure (that is, the internal
architecture) of a component of the HW architecture composed of other
components which, in turn, has an internal structure. Such a component will be
instanced in the architectural mapping view as a single instance. Thus,
actually, the internal architecture of this component is reflected. However, an
instance of this component in the architectural mapping view (section 5.2.4.1)
will be handled as a whole to allocation effects.
The new component will be a UML component, admitting a MARTE
stereotyping. For reflecting this internal architecture, HW component instances
of the other components and its interconnection will be used. The next table
summarizes the diagram specific elements allowed in the context of the
COMPLEX project, as well as the minimum set of applicable MARTE profiles
and stereotypes for each element:
UML2 Diagram
elements
MARTE profiles MARTE stereotypes
Component N/A or
DRM:HRM:Logical
HwResource
HwComputingResource,
HwCommunicationResource
HwMemory
HwDevide
Port N/A N/A
Interface N/A N/A
Component Instance N/A N/A
Assembly connector
(between Component
instance ports)
N/A or
HRM:Logical
N/A or
HwCommunicationResource
HwMedia
HwBus
HwBridge
Delegation connector
(between a components
instance‟s port and a
component‟s port)
N/A N/A
A minimum set of rules will apply to the diagram built up of these elements.
Such restrictions are reflected in the following table:
Rule Rationale
An UML component will reflect the new
declared hierarchical component, whose
internal structure is being reflected by the
diagram.
To define the boundary of
the new component and the
connection of the internal
elements with the outside
world
The top component will declare through ports
all the I/O interfaces of the system.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 61
Rule Rationale
Internal components (parts of the diagram) will
be Component Instances.
To use one object in the
diagram for it real
component of the platform.
If the hierarchical component contains at least
an instance of a Component stereotyped as a
HwComputingResource (or derived), the
hierarchical Component will be stereotyped as
HwComputingResource.
To facilitate the allocation
of functionality to the
instance of a hierarchical
component.
A connection between two Instances of
Components stereotyped as a
HwComputingResource (or derived) must be
done through their ports, and either:
through an assembly connector
stereotyped with any of the following
stereotypes
HwCommunicationResource, HBus or
HwMdia;
or through an Instance of
Components stereotyped with one of the
the 3 aforementioned stereotypes, and
two non-stereotyped assembly
connectors.
Flexibility in the diagram to
conceive the bus either as a
component itself (“box”) or
as a simple connector
(“line”).
The ports involved in the aforementioned
connection must be “compatible” (the same
interfaces or with an inheritance relationship).
To ensure compatible
interconnections.
Interfaces associated to the I/O ports of the
hierarchical component will be compatible with
the interfaces of the ports of the inner
instances.
To ensure compatible
interconnections.
Component diagram for declaring SW platform components (optional)
This diagram will be used to declare the SW components of the system, of the
SW architectural diagram.
UML2 Diagram elements MARTE profiles MARTE stereotypes
Component DRM:SRM SwResource
The SwResource stereotype is used to reflect in a generic way the use of a
RTOS component as part of the platform.
This component will enable the allocation of application components onto it,
and the allocation of a RTOS component into the HW platform resources.
The RTOS usually comprises a scheduler and many other services, for which
the MARTE profile provides enough elements to model them. However, high-
level estimation tools such as SCoPE+, will require a synthetic information.
Specifically, a name attribute to distinguish between RTOS types (Linux,
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 62
Win32, etc) will be sufficient to consider the different performance costs
associated to each RTOS implementation.
This diagram is optional since the user could omit the specification of the SW
components in order to:
o Reflect an application component is to be executed without relying over
an RTOS .
o Enable a more synthetic description, by assuming a default association
of SW resources to platform resources (e.g. one generic RTOS instance
could be immediately associated to a processing device or a processing
cluster). Actually, this is the option assumed by SCoPE+ (see section
6.5.1)
This diagram is understood as optional since the user could omit the
specification of the SW components in order to:
o Reflect an application component is to be executed without employing
an RTOS or any other SW component ascribed to the platform.
o Enable a more synthetic description, by assuming a default association
of SW resources to platform resources (e.g. one generic RTOS instance
could be immediately associated to a processing device or a processing
cluster).
Single Level Approach for the HW platform description:
The MARTE DRM::HRM::Logical sub-profile includes stereotypes which reflect both
architectural and implementation technology concepts. For instance, let‟s consider the
HwProcessor, the HwASIC and the HwPLD stereotypes. Strictly speaking, a processor (which
can be represented by the HwProcessor MARTE stereotype) is an architectural component.
As a matter of fact, nowadays many processors can be implemented either as a hard IP, thus
as an ASIC, which can be directly reflected through the HwASIC stereotype, or as a soft IP,
e.g., synthesized and implemented within a programmable device (e.g., a FPGA), which can
be reflected through the HwPLD stereotype.
The COMPLEX UML/MARTE specification methodology will ensure the support of a single
level approach for the specification of the HW part of the platform. In such an approach, the
methodology will associate to each component both architectural and implementation
semantics. This way, components with stereotypes such as HwProcessor, HwASIC and
HwPLD stereotypes can be used in the same HW platform architectural diagram without
ambiguity.
<<HwProcessor>>
ARM9_PLD
<<HwProcessor>>
ARM9_ASIC<<HwPLD>> <<HwASIC>> HW platform
Figure 5-9: Single level approach for HW platform specification.
This approach facilitates the development of the generation tools and the faster availability of
a first version of the COMPLEX UML/MARTE specification methodology and its related
generation tools.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 63
Figure 5-9 provides an example which sketches (without using a specific UML capture tool)
the declaration of 4 components of the HW platform. Two ARM9 processors are declared. As
can be seen two component declarations are used to reflect the same architectural element (an
ARM9 processor) implemented with two different technologies. Then, while the
ARM9_ASIC component reflects an ARM9 processors implemented as an IC, the other
ARM9_PLD component can reflect an ARM9 soft core implementation in a FPGA. Each
component declaration can assign the corresponding performance values to its attributes.
In the “single level” approach, a HW component with the “HwASIC” or with the “HwPLD”
stereotype will be considered just as a processing element, which an application component
can be assigned to. This is actually consistent with the MARTE description, since, indeed,
stereotypes such as HwASIC and HwPLD inherit, as HwProcessor, from the same stereotype:
HwComputingResource. Anyway, it has to be taken into account to later define the allocation
rules.
Double Level Approach for the HW platform description:
A result of the preliminary research on the MARTE profile for the definition of the
COMPLEX UML/MARTE specification methodology is the devising of a double-level
approach for the description of the HW platform.
<<HwProcessor>>
ARM9
<<HwProcessor>>
ARM9
<<HwPLD>> <<HwASIC>>
Architectural
Level
Implementation
Level
Figure 5-10: Double Level HW platform specification.
In this approach, there would be a first level for UML elements (e.g. components) reflecting
architectural components (e.g. using HwProcessor or HwMemory stereotypes), and a second
level for UML elements (e.g., again components) reflecting an implementation technology
(e.g., using HwASIC or HwPLD stereotypes).
An advantage of such a “two-level approach” could be the automatic assignation of specific
values to the attributes of architectural components as a function of the allocation to the
implementation technology component. It is reflected in REFIG.
For instance, different operation frequencies (op_Frequencies) of a processor component
could be determined depending on its allocation to either, a HwASIC component instance, or
to a HwPLD component instance. Moreover, the own attributes of the implementation
component instances could be taken into account.
As far as we know, no UML edition tool enables this feature. Its implementation can turn out
complicated and/or time consuming. Moreover, the double level approach can mean more
detail in the model than necessary or convenient for a fast capture in most of the cases.
Because of this, support of double-level specification of the HW platform is considered as an
advanced future, whose implementation is beyond the goals of COMPLEX.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 64
5.2.4 Platform Specific Model (PSM)
The development of the Platform Specific Model (PSM) combines both the platform
independent view and the information provided by the platform description model focusing
on the detail of the use of the platform resources by the system application ([3]). The
following image suggests the PIM is transformed into the PSM with the information about the
system platform provided by the PDM, including additional information about how platform
resources (both SW and HW) are used by the application.
PSM
PIM PDM
Model Merge
Mapping
Information
Figure 5-11: Model transformation
Section 5.2.4.1 includes a detailed description of the UML2 diagrams and element
associations, and MARTE profiles and stereotypes to be used for architectural views.
5.2.4.1 Architectural View
This model view focuses on the architectural aspects of the system related to the instantiation
and assembling of application and platform components, and the allocation of platform
resources.
This view enables the allocation of components of the application components (defined in the
PIM, see section 5.2.2) to the components of the platform model (defined in the PDM, see
section 5.2.3). Additionally, this view allows the user to define the system design space by
means of the insertion of DSE parameters and the insertion of constraints and rules which
drive the DSE cycle.
This view is expressive enough to support the definition of different allocation schemes, that
is, different combination possibilities about how resources may be used. Therefore, an
allocation scheme is one of the possibilities of the whole set. The combination of all
allocation schemes is so called the allocation space.
But it also enables the definition of parameters and rules that will compose the space of
possible platforms where the application may run on. The combination of all possible
platforms is so called the platform space.
The sum of the space of application allocations with the space of platforms yields in system
design space.
The architectural mapping view includes four well distinguishable parts:
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 65
A set of instances of the application components previously defined in the PIM.
A set of instances of the platform components previously defined in the PDM.
A set of abstract relationships between application components and platform
components, representing the default allocation scheme.
A set of DSE parameters, rules and constraints that will drive the DSE cycle.
All these four parts will be combined in the same composite structure within a UML package
stereotyped with the ArchitecturalView stereotype of the COMPLEX profile (see section
6.2.3.1 for further details).
However before describing in detail this view it is necessary to distinguish the difference
between component types and component instances. While the former only represents the
instance template, providing the information about their functional and non-functional
properties, the latter will expose those functional and non-functional properties. Therefore, if
the component type declares “providing” and “requiring” services, then the component
instance will actually expose those services. Components types are defined in the PIM (e.g.
application component types) and the PDM (e.g. platform component types) while component
instances are created in the PSM and related each other by means of allocation relationships.
All these four parts will be combined in the same composite structure within a UML package
stereotyped with the Architectural View stereotype of the COMPLEX profile (see section
6.2.3.1 for further details).
The following UML2 diagrams will be used for this view:
Composite structure diagrams.
This diagram will be used to describe the system interfaces with other external sub-
systems and its internal structure: instances of application components defined in the
PIM, instances of platform components, their assembling to define the system
application and platform, respectively, and the allocation of resources.
The system will be modelled as a component type defined within the package
stereotyped with ArchitecturalView from the COMPLEX profile. Moreover, this
component shall be stereotyped with System stereotype from the COMPLEX profile
(see section 6.2.3.3 related to the verification profile).
It is important to highlight that there must be just one System component defined within
the ArchitecturalView package.
The system will have an internal structure depicted by a composite structure diagram
which will show the application and platform assembling, and the allocation of
application components to platform processing nodes.
Two kinds of components instances are foreseen as properties of the system:
o Application component instances, which component types are stereotyped
either with RtUnit or PpUnit MARTE stereotypes (see section 5.2.2.2).
The assembling of the application components forms the application.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 66
o Platform component instances, which component types are stereotyped with
those stereotypes listed in section 5.2.3.1.
The assembling of the platform components forms the system platform. This
platform architecture will reflect:
Instances of SW components, i.e. RTOS, drivers.
Instances of HW components, i.e. buses, microprocessors, bridges, etc.
The allocation of instances of SW platform components to instances of
HW component.
The system may have interfaces with external subsystems which it exchanges data with.
These interfaces are modelled by means of typed UML ports attached to the System
component(see Figure 5-12 and the external port typed ICamera). Refer to sub-
paragraph Definition of system interfaces for further details about the modelling of
system interfaces.
The next table summarizes the diagram specific elements allowed in the context of the
COMPLEX project, as well as the applicable COMPLEX profiles and stereotypes for
each element:
UML2 Diagram elements COMPLEX
profiles
COMPLEX stereotypes
Component Verification System
Port (component) N/A N/A
Comment DSE DseScalarParameter
DseVectorParameter
Constraint DSE DseRule
DseConstraint
Instance specification N/A N/A
Port (instance specification) N/A N/A
Assembly connector
(between instances)
N/A N/A
Delegation connector
(between a instance‟s port
and a component‟s port)
N/A N/A
Abstraction dependency N/A N/A
The next table describes the specific UML elements listed in previous table where the
MARTE profiles and stereotypes are applicable:
UML2 Diagram elements MARTE profiles MARTE stereotypes
Component Allocation Allocated
Abstraction dependency Allocation Allocate
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 67
A minimum set of restrictions will apply to the system composite diagram:
Rule Rational
Instances of application components shall not be
connected to instances of platform components
(by means of assembly connectors through their
ports).
It makes no sense to
connect the port of an
instance of an application
component to a port of an
instance of a platform
component.
Only the ports of instances of application
components associated to periodic interfaces
may remain unconnected to any other port.
Periodic interfaces are
automatically executed by
the system platform.
There will be at least one component instance
which component type is stereotyped as a
HwComputingResource (or derived).
This rule also relies on the rule that obliges to
stereotype with HwComputingResource a
component which encloses in turn further
computation resources.
At least one element to
compute application is
required.
There will be at least one component instance of
an elementary component stereotyped as a
HwCommunicationResource (or derived).
To define a “computation
node/cluster” (required by
SCoPE+).
A connection between two instances of
components stereotyped as a
HwComputingResource (or derived) must be
done through an instance of component
stereotyped with one of the following MARTE
stereotypes: HwCommunicationResource,
HwBus or HwMedia.
In this view the system
architect should not be
aware of the lower level
implementation of the
system platform. Including
MARTE stereotypes
regarded the HW
components would add an
additional concern to this
model view.
No composition of hardware components will
appear in the HW part of the diagram.
On this way the system
architect can have full view
of the different processing
elements
(HwComputingResource
and derived) that form part
of the system platform).
All instances of application components must be
“allocated” by default to instances of platform
components.
Transformation tools
requires to define a default
configuration of the system
design space.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 68
Rule Rational
All DSE parameters defined must be associated
to an component instance.
The transformation tools
might require additional
information about the
component type (i.e.
MARTE stereotype fields,
units).
All DSE parameters must be reference by at least
one DSE rule or DSE constraint.
According to document
[16], it is necessary to
define rules to avoid an
undefined behaviour of the
simulator.
Regarding the definition of DSE parameters, rules and constraints in the architectural
view, refer to the sub-paragraph “design space definition” within this paragraph.
MARTE Stereotype’s attributes
For each corresponding MARTE stereotype, the attributes that will be used in the
COMPLEX project are described below.
For each attribute, its meaning, possible values to be assigned and character in the
context of the COMPLEX project are specified.
When some MARTE stereotype‟s attribute (or some its possible values) is not being
used or its original meaning in MARTE is lightly specialized in the COMPLEX project,
it will be explicitly indicated and the reasons will be explained.
The character of a specific attribute may take one of these values:
o Mandatory: the attribute must be used and a valid value must be given to it for
each model element to which the corresponding stereotype applies.
o Optional: the attribute may be used or not in the model elements to which the
corresponding stereotype applies. The decision is up to the system designer.
o Not used: the attribute is not used in the MARTE model.
In some cases, the character of some attribute may take more than one of the previous
values, depending on certain condition (for example, the value taken by another
attribute of the stereotype.) In those cases, the corresponding condition is identified.
Allocate
o kind: AllocationKind
This attribute specifies whether the allocation is structural, behavioural or both
(hybrid).
In the context of the COMPLEX project, the allocation dependencies will be
always structural, it means, both ends of the allocation will be instances of
components.
Character: Not used.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 69
o nature: AllocationNature
This attribute specifies whether the nature of the allocation is spatial, timed.
In the context of the COMPLEX project, both kinds of allocation will be
considered, spatialDistribution or timeScheduling. The first one will take place
whenever a SW component instance (application or software resource) is
allocated to a HW component instance. The second one will be given when an
application instance is allocated to a SW component instance which
component type is stereotyped with SwResource (see section 5.2.3.1 regarding
the modelling of SW resources in the system platform).
Although it is explicit in the MARTE standard [7] that the clients must be
stereotyped Time::TimedElement, in the context of COMPLEX this constraint
will not be considered.
Character: Mandatory.
Allocated
o allocatedTo: Allocated
This attribute specifies the platform component(s) that the application
component is mapped to.
In the context of the COMPLEX project, this property must have one element
representing the default allocation of the component in the system design
space.
Allocated named elements must be designated by the “to” end of an “allocate”
dependency.
Character: Optional (only applicable to instances of application components).
o allocatedFrom: Allocated
This attribute specifies the application component(s) that the platform
component is linked to.
In the context of the COMPLEX project, this property must have at least one
application component. It represents the default allocation of the resource in
the system design space.
Allocated named elements must be designated by the “from” end of an
“allocate” dependency.
Character: Optional (only applicable to instances of platform components).
o kind: AllocationEndKind
This attribute specifies the kind of the allocation end: undef, application,
executionPlatform or both.
In the context of the COMPLEX project, this property is not used.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 70
Character: Not used.
COMPLEX stereotypes
The COMPLEX profile is fully described in section 6.2.3. All attributes and their
restrictions are fully explained in that section.
The following image depicts an example of the composite diagram of the system internal
structure including its external interfaces, DSE parameters, rules and constraints.
Figure 5-12: Example of composite diagram for system description
Definition of system interfaces
As already mentioned, the system described in the architectural view may exchange data with
other external subsystems. Normally embedded systems require data from external devices for
performing their functions.
In order to model these communications we need to create an external port in the System
component and to type it with any of the interfaces stereotyped with ExternalInterface of the
COMPLEX profile.
The aforementioned interfaces were identified in the functional view (see section 5.2.2.1) as a
required interface a system function (i.e. it needs to read data from a camera device or send
commands to an electronic control unit). At the functional view they just represent a logical
dependency between the application components and the external subsystems. At the
architectural level, these interfaces represent a communication port with external sub-systems
and this has implications when creating the necessary interfaces with the stimuli environment
(described in section 5.2.5).
Then, the communication with the external sub-system will be modelled at two different
levels:
At application level: the application components represented by the CFAM containers
are connected to this port by means of assembly connectors. This connection provides
the following information in the model:
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 71
o The application component requires specific services from the platform to
read/write data to a specific interface. During the transformation it would be
necessary to provide access to those services to the functional components of
the CFAM container.
o It is necessary to generate the appropriate interfaces to connect the system to
the external sub-systems when producing the stimuli environment.
It is important to note that the UML ports of the application component port and the
system port must be of the same type.
At platform level: the external port is connected to an instance of platform component
stereotyped with HwIO stereotype the MARTE profile by means of a delegation
connector. This implies that the communication will be managed by that specific
component at platform level. Moreover, this will have influence in the simulation phase.
It is important to note that the delegation connector must only be associated to a
component instance which component type is stereotyped with MARTE HwIO
stereotype.
The following image depicts previous concepts and provides an example of the definition of
the modelling of external interfaces in the system.
<<System>>
Platform
Processing
Element
<<allo
cate
>>
ExtInterface
<<ExternalSubsystem>>
external::ExtSysExtInterface ExtInterface
CFAM
container
Bus com. instance
IO device com.
instance
Figure 5-13: Modelling of external interfaces of the system
System design space definition
In order to define the system design space so that the MOST tool may find the optimal
architecture, it is necessary to describe the space to explore by means of a set of parameters
and rules that will guide the tool in the process (see document [16]).
From that document it is inferred a set of steps to define the system design space within the
UML model. The architectural view will support the description of DSE parameters, rules and
constraints that will guide the DSE cycle. This sub-paragraph describes these steps and
identifies the restrictions on the modelling of these concepts.
Identification of the DSE parameters
This step assumes that the system architecture has been completed, that is:
Delegation connector: the
communications are delegated
to the HwIO device.
Typed port:
external system
interface
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 72
The instances of the application components assemble the application.
The instances of the platform components assemble the system platform.
The default allocations of application components to platform components are defined.
Finally, the external interfaces are already defined as described in previous sub-
paragraph.
In order to create DSE parameters, first it is necessary to create UML comments and
stereotype them with either DseScalarType or DseVectorType (see section 6.2.3.2 for a
detailed description of these attributes). According to document [16], there are two types of
system parameters, scalar or vector types:
Scalar types, which specify a sequential progression associated that specific parameter
of the system.
Among the different scalar types there are integer, boolean, exp2 and string:
o Integer type specifies an integer simple progression bounded by a min and max
value.
o Boolean scalar type specifies a progression from 0 to 1.
o Exp2 scalar type specifies a power of two progression, also bounded by a min
and maximum value.
o String scalar type specifies an enumeration of items that the parameter might
be assigned to.
Vector types, which represent variable vector of combination of components of the
system. There are two kinds of vector types: on_off_mask and permutation.
DSE parameters are then associated to instances of platform components, due to the fact that
these parameters are likely to be attached to platform parameters. If a component is applicable
to more than one instance (i.e. frequency of the microprocessors), the comment must be
attached to all of them.
It is important to note that the name of the parameter (an attribute of the stereotype
DseScalarParameter or DseVectorParameter) must be the same one than the attribute name
of MARTE stereotype applied to the component type of the platform instance.
Due to the fact that the DSE parameter name must be unique, whenever two parameters refers
to the same MARTE attribute of different component instances, the name of the DSE
parameter shall follow this naming convention:
[name_MARTE_atribute]_[1-9]
It is noted that those DSE parameters pointing to MARTE attributes inherit the units and
magnitudes of the platform parameters that point to them.
Definition of the DSE rules
The second step consists of defining the DSE rules that will evaluate to true those architecture
configurations that are feasible. This kind of rules are likely applied for defining the different
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 73
platform configurations, instead of the allocation schemes. They must only refer to DSE
parameters of kind DseScalarType.
In order to create DSE rules in the model it is necessary to add UML constraints to the System
component and stereotype them with DseRule from the COMPLEX profile (see section
6.2.3.2 for a detailed description of these attributes).
The DSE rule references the list of DSE parameters that are involved in the evaluation of the
architecture configuration. The notation shall be:
$[dse_parameter_name].
It also provides an OCL expression to define a rule with the DSE parameters included in
previous attribute. This OCL rule has a limited syntax that consists of:
Algebraic operands: *,+,-,/, =;
Logic operands: >, >=, <, <=, ==, !=, and, or;
Decision structures: if-then-else;
All logic or numerical expressions must be in parenthesis. The following OCL expressions are
examples of possible DSE rules:
($frequency_1 <= 4000) and (($frequency_2 + 1000) <= 2000).
if ($parameter >= $cacheSize) then $configuration = 0 OCL expression.
Definition of the DSE constraints
The third step consists of defining the DSE constraints that will guide the different allocation
schemes. This kind of rules are likely applied DSE parameters of kind DseVectorType,
permutation kind.
In order to create DSE constraints in the model it is necessary to add UML constraints to the
System component and stereotype them with DseConstraint from the COMPLEX profile (see
section 6.2.3.2 for a detailed description of these attributes).
The DSE constraint references a DSE parameter (type DseVectorType, permutation kind).
The notation shall be exactly the one used for DSE rules:
$[dse_parameter_name].
Then, it is mandatory to specify the kind of partitioning scheme selected for that instance: SW
or HW.
This constraint will inform the MOST tool to prevent any architecture configuration where the
selected component instance is mapped onto the SW or HW parts.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 74
5.2.5 Input stimuli definition
5.2.5.1 Verification View
The objective of the Stimuli Scenarios Definition process is to define a set of scenarios which
describe concrete behaviours of the external actors interfacing with the system. The behaviour
include the stimuli provided to the system represented as messages sent to it (either they are
signals, calls, asynchronous messages or replies to messages received from the system.) These
stimuli are used to exercise the system in the phase of system simulation of the DSE loop.
The stimuli scenarios are not intended to be a set of test procedures, but allow the DSE loop
to simulate some significant execution scenarios to obtain representative metrics. Therefore,
the behaviour of the system should be completely predictable under the conditions imposed
by the behaviour of the external actors described in the scenarios.
The Stimuli Scenarios Definition process may be carried out in parallel with most of the
system design process, as the only inputs needed are the system requirements, the use cases
and the system operations identified in the first steps of the system design. However, in order
to define more significant stimuli scenarios (e.g. scenarios that imply reaching the longest task
execution path, the maximum processing load of the whole system, etc.), it would be better to
define those scenarios whenever a deeper knowledge of the internal behaviour of the system
is achieved.
The next sections describe the diagrams and elements used in the context of the stimuli
scenarios definition as well as the specific process followed.
There are three types of UML diagrams used for the input stimuli definition process:
Use case diagrams, used to describe the specific functionalities provided by the system
and the external actors interfacing with it. They are modelled in the functional view (see
section 5.2.2.1);
Class diagram, used to define the external sub-systems as UML components and their
interfaces with the system. In this class diagram the behavioural aspects of the external
sub-systems is also modelled, derived from the UML use cases modelled in the
functional view (see section 5.2.2.1).
Composite structure diagram, used to define the stimuli environment where the system
itself and the different sub-systems are properties of the stimuli environment
component. In this diagram the sub-system ports are connected to the system ports
assembling the stimuli environment itself.
Sequence diagrams, used to represent the stimuli scenarios.
The following tables show which specific elements from those provided by the UML2
specification will be used for the UML use case and sequence diagrams in the context of the
Stimuli Scenarios Definition for the COMPLEX project. The tables also give short
description of each element, whose semantics are in some cases specialized for that context
(semantics are adapted to the purpose of the stimuli scenarios specified in the previous
section).
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 75
No MARTE stereotypes are used in this view.
Table 5-1: Use case diagrams for input stimuli definition
Use Case Diagram elements Description
Actor Represents the external actors that interface with the
system.
Use Case Represents specific functionality provided by the
system to the external actors.
Association Specifies which specific functionality is requested by
each actor from the system.
Table 5-2: Class diagrams for input stimuli definition
Class Diagram elements Description
Component Represents the different sub-systems interfacing with
the system modelled in the Architectural View in
section 5.2.4.1.
Component operations describes the behaviour of the
subsystem inferred from the UML use cases.
Interface Represents the different interfaces with the system.
Realization relationship Identifies the contract offered by a component in
terms of its provided and required interfaces.
In this case, the sub-systems will require an interface
that the system provides.
Table 5-3: Class diagrams for input stimuli definition
Composite Diagram
elements
Description
Component Represents the stimuli environment system itself.
Only one
Port (component) Defines an interaction point between the component
and its environment. This port must be typed with the
interface it requires, and represents a contract of the
component specified by a interface.
Comment If necessary.
Instance specification Represents the system and the sub-systems within the
stimuli environment. They are actually properties of
the component modelling the stimuli environment.
Connector
(between instances)
Represents a communication between two instances
through their typed ports. The connector should link
two ports typed with the same interface.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 76
Table 5-4: Sequence diagrams for input stimuli definition
Sequence Diagram elements Description
Interaction Represents a specific stimuli scenario (see Figure
5-14).
InteractionUse Represents the usage of a specific stimuli scenario
by another one. It is shorthand for copying the
contents of the referred Interaction where the
InteractionUse is (see Figure 5-15).
Lifeline It represents the behaviour of a participant of an
interaction along the time.
The participants of the interactions may be the
system and the external actors interfacing with it
(see Figure 5-14).
ActionExecutionSpecification
BehaviorExecutionSpecifiaction
Represents, within a lifeline, the execution of a
specific action or behaviour by the corresponding
participant of the interaction (see Figure 5-14).
StateInvariant Represents a runtime constraint on a participant of
the interaction at a concrete point of the lifeline.
More specifically, in the context of the stimuli
scenarios definition, these StateInvariants represent
the internal states (values of variables, operational
states, etc.) a participant of the interaction must
have at a concrete point of that interaction. Those
constraints must not be seen as conditions to be
evaluated in the simulations. They actually represent
conditions that must be forced to evaluate to True at
specific points of the simulations, so the necessary
actions must be implemented during them (see
Figure 5-16).
CombinedFragment It represents a fragment of a given interaction
composed by several other fragments whose
relationships depend on the interaction operator
associated to the CombinedFragment. Those several
other fragments are called the interaction operands
of the CombinedFragment.
Interaction operators to be used in the context of the
stimuli scenario definition for the COMPLEX
project are shown in Table 5-5 (see Figure 5-17 and
Figure 5-18).
InteractionOperand Represents a fragment of a given interaction
enclosed by a CombinedFragment (see Figure 5-17
and Figure 5-18).
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 77
Sequence Diagram elements Description
Message It is a particular communication between two
participants of the interaction.
Only UML2 complete messages are allowed, either
they are signals, replies, synchronous calls or
asynchronous calls.
Create and destroy messages make no sense in the
context of the stimuli scenarios definition of a
system (see Figure 5-14).
Table 5-5: Combined fragment for input stimuli definition
Interaction operator Description
par (Parallel) The CombinedFragment is composed by several
interaction fragments (the interaction operands)
which may be executed in parallel.
No guards are used for this operator in the context
of the stimuli scenario definition.
seq (Weak Sequencing) The CombinedFragment is composed by several
interaction fragments (the interaction operands)
whose behaviour may be executed in parallel with
one constraint: the event occurrences of the
interaction operands within the same lifeline are
ordered, i.e., the first occurrence in the first operand
is executed before the first one in the second
operand, the second occurrence in the first operand
is executed before the second one in the second
operand, and so on.
An event occurrence in a lifeline may be the sending
or reception of any kind of message by the
corresponding participant in the interaction.
No guards are used for this operator in the context
of the stimuli scenario definition.
strict (Strict Sequencing) Similar to the weak sequencing, but now the
restriction applies not only to the occurrences within
the same lifeline but also in different lifelines.
No guards are used for this operator in the context
of the stimuli scenario definition.
critical (Critical Region) The CombinedFragment represents a critical region,
which is treated atomically, without interleaving its
behaviour with the behaviour out of the critical
region.
No guards are used for this operator in the context
of the stimuli scenario definition.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 78
Interaction operator Description
loop (Loop) The CombinedFragment represents a loop. In this
case, the CombinedFragment only encloses one
interaction operand, whose behaviour is repeated
several times.
For this operator, a guard indicating the number of
times the operand‟s behaviour is executed will be
used. No Boolean expression is used for the guard
in the context of the stimuli scenario definition.
Figure 5-14: Sequence diagram example
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 79
Figure 5-15: Interaction use example based on previous figure
Figure 5-16: StateInvariant example
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 80
Figure 5-17: Parallel CombinedFragment example
Figure 5-18: Loop CombinedFragment example
5.2.6 Transforming UML/MARTE model to CFAM model
COMPLEX targets to bridge the gap between the everyday more and more complex
embedded applications and the growing capabilities of implementation technology.
Specifically, in finding how a complex application with multiple components has to be
mapped in a complex platform, with multiple executive resources.
However, exploring each feasible implementation can be very costly in time terms. For
instance, lets imagine an concurrent application with 10 SW tasks and a platform with a single
processor and a HW resource where there would be room only to accelerate one task. Then
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 81
we can conclude that there would be 10 implementation alternatives where 1 task could be
moved to hardware. If each alternative requires a recoding of one of the SW tasks to HW,
then the exploration time of each alternative is quite costly.
The CFAM API will be useful in order to enable the coding of a concurrent application using
real-time services independently from the infrastructure required for its execution. This way
this code will be implementable and usable in different analysis environments.
An execution infrastructure is a very generic way to name any infrastructure able to execute
an application code. Therefore, it comprises any feasible implementation of the application. In
COMPLEX, the execution infrastructures considered are actually simulation and analysis
(S&A) infrastructures, since one fundamental activity in COMPLEX is to extract a
corresponding executable specification that enables the production of performance results and
their analysis and exploration for deciding the optimum configuration.
Figure 5-19 shows the idea within a sketch of part of the COMPLEX flow. On top of this
flow, the user builds up a UML/MARTE model, supporting the model views (Data,
Functional, Concurrency&Communication, Platform, Architectural and Verification)
presented in this document.
UML/MARTE Model
Native SW
Executable
CFAM Generator (T2.1)
PIM Functional Verification
Specification (T2.1)
SystemC
Executable
PIM Functional Validation
Feeding other COMPLEX methodologies
SCoPE+
Executable
PIM Functional Verification
Performance Exploration (T2.2)
CFAM code
(user code) Data, Functional, C&C, Arch. Views Platform, Arch. Views
XMLD
XMLD Generator (T2.1)
a)
b)
c)
CFAM Component
Structure
Figure 5-19: CFAM in the context of COMPLEX
Additionally, the user provides the inner coding of functions referenced by the UML/MARTE
model (CFAM code in Figure 5-19). While some of these functions can be C/C++ pure
functions, other functions will use the CFAM API for accessing to synchronization services or
real time services such as forcing a time delay.
From the UML/MARTE model, a set of generators will be in charge of extracting the code
necessary to build an executable model, ready for functional validation, and in some cases, for
performance analysis. The type of generation depends on the specific purpose. In any case,
the CFAM code is re-used without modification, thanks to the CFAM API, which will have
an associated implementation for each simulation infrastructure.
For instance, if the user is interested in a simple functional validation, then the generator can
generate an executable Platform Independent Model (PIM) as a SW native application
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 82
(Figure 5-19 (a)) just by extracting the information from the Data, Functional, Concurrency
and Architectural views. For instance, when relying on a Linux host plus the pthread library,
a mutex CFAM API call will be implemented through a POSIX mutex.
In the COMPLEX flow, a main activity will consist in the generation of a PIM in SystemC
(Figure 5-19 (b)). From this SystemC PIM, the remaining steps of the COMPLEX flow will
be in charge of converting this executable model on a Platform Specific Model. Such steps are
described in the COMPLEX flow (see DoW [1]), and include HW/SW separation tasks,
source analysis through cross-compilation and behavioural synthesis, BAC++ generation, etc.
For the generation of the SystemC PIM, the same CFAM code used for the generation of the
Host Native executable can be used. However, in this case, the CFAM API calls, for instance,
implementation of the mutex access, will rely on the SystemC mutex, thus on the SystemC
library. In COMPLEX, the SystemC executable has been explicitly described in the DoW as a
product of the generators developed in the generation tasks (T2.1) of COMPLEX for feeding
the remaining COMPLEX activities. This way, the CFAM will be exported to the rest of
estimation methodologies involved in COMPLEX. The requirements of the SystemC
generation have been specified in Deliverable D1.2.1 of COMPLEX [2].
One of the performance analysis tools involved in COMPLEX is SCoPE+ (Figure 5-19 (c)).
This tool has the particularity that it will directly admit the CFAM code as input front end.
The platform description (PDM) and the mapping will be read from an XML Description file.
This way, SCoPE+ will facilitate the exploration of many different implementations, without
requiring any adaptation of the concurrent applications. This is major benefit of the CFAM
API, since avoiding such adaptations or refinements related to specific mapping, speed ups
the iterations in the Design Space Exploration (DSE) cycle. Such kind of refinements is left
for implementation phases, once the architecture to be implemented has been decided.
Figure 5-19 illustrates also that the three generations can be unified in a single code generator
(CFAM generator). This can be done through the generalization of the generation of the code
related to the CFAM Component structure, which is depicted as a dashed line in Figure 5-19
since the component implementation is defined only once the simulation infrastructure is
defined and an implementation for the CFAM Component structure over the simulation
infrastructure is provided. “macros” and other auxiliary constructs of the CFAM Component
structure are not part of the CFAM API specification, since actually they are code constructs
to be automatically generated, and not directly and explicitly used by the user code, that is, the
CFAM code. Therefore, at least during the life of COMPLEX project, it is interesting to keep
the definition of these macros and auxiliary functions flexible in order to make as simple and
efficient as possible the generation process.
5.2.7 Functional coding
The body, that is, the implementation of the methods which appear in the Functional View are
provided by the user. It is also called CFAM user code since it can make calls to the CFAM
API.
They should admit ANSI-C code without further restrictions than that such code can be
compiled by a compiler supporting the C++ grammar (this is due to implementation reasons).
For instance, if the code can be processed by the GNU g++ compiler, the user code is
admissible.
The code must be consistent with the architectural view. In the CFAM specification [42] an
example shows the type of information which has to be produced by the CFAM generator for
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 83
the user, when a component requiring a service is bound to two service provider components,
in order to enable a coherent writing of the CFAM user code.
5.3 Stateflow design methodology
Stateflow is a model-based statechart editor by MathWorks. It allows the designer to enter an
extended finite state machine, simulate it in the context of other blocks modelled with
Stateflow or Simulink, representing other design components or a test bench, and finally to
generate code for a target micro-controller or for hardware implementation.
In the COMPLEX project, Stateflow is used as a platform-independent design entry tool,
while HIFSuite is used to generate both a SystemC model for design space exploration, and
software to be executed on the target micro-controller.
With respect to the UML/MARTE-based design entry, it provides an alternative specification
style, based on statecharts in both cases, which may be better suited for application domains
where the designers are already used to the Simulink/Stateflow GUI look and feel, and are not
willing to learn the complex set of diagrams that one must master in order to specify a design
with the UML. The Use Case 1, in which Stateflow will be used for application modelling,
focuses on optimizing parameters (such as the memory architecture) of an existent HW/SW
embedded platform used for wireless sensor network applications.
5.3.1 Stateflow model design
A Stateflow chart is a representation of a finite state machine. A finite state machine is a
representation of an event-driven (reactive) system. In an event-driven system, the system
makes a transition from one state (mode) to another, if the condition defining the change is
true. A finite state machine can be modelled through either a truth table to relate the inputs,
outputs, and states or state-transition charts (bubble charts).
A Stateflow chart uses a variant of the finite state machine notation established by Harel [38].
A chart is a graphical representation of a finite state machine, where states and transitions
form the basic building blocks of the system. You can also represent stateless charts (flow
graphs). You can include Stateflow charts as blocks in a Simulink model. The collection of
Stateflow charts in a Simulink model is the Stateflow machine. A Stateflow chart enables the
representation of hierarchy, parallelism, and history. You can organize complex systems by
defining a parent and offspring object structure [39]. For example, you can organize states
within other higher-level states. A system with parallelism can have two or more orthogonal
states active at the same time. You can specify the destination state of a transition based on
historical information. These characteristics go beyond what state-transition charts and bubble
charts provide.
Stateflow has a graphical user interface, which allows one to specify the input/output signals
of the block, as well as its hierarchical extended Finite State Machine. It can be invoked either
to create a new block, or to edit an existing block in the context of a Simulink block diagram.
Stateflow descriptions are written in MDL text files.
In Wireless Sensor Networks, which are the application domain for Use Case 1 in Complex,
Stateflow is used to model both the protocol and the application, since both are generally
simple and require making simple decision and computations, which can be easily modelled
as statecharts.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 84
Simulation uses a time-driven model, in which executions of the statechart are triggered e.g.
by level crossings of input signals (e.g. any time an input goes above or below a threshold) or
periodically.
5.3.2 Transforming Stateflow descriptions to SystemC
The semantic elements of the Stateflow model (e.g., states, junctions, transitions) are
extracted from the MDL file and represented by the HIF language by using an appropriate
front-end tool named SF2HIF.
The HIF format preserves the functional behaviour of the statecharts obtained from Stateflow;
the parallel behaviour of AND states is also preserved. In the HIF domain different tools can
be used to verify and manipulate the statecharts. For instance, state coverage can be analysed
and abstraction can be performed by grouping together equivalent states and low-level states.
State manipulation and abstraction could be useful to optimize some properties of the system
(e.g., power consumption) or to speed up simulation of SystemC models.
A back-end tool named HIF2SC generates a SystemC model of the original statechart. The
SystemC model can be both at RTL and TLM depending on the detail level of the Stateflow
model and on the abstraction process eventually performed on the HIF representation.
The user can choose to generate either multi-thread or single-thread code depending on the
modelling needs. Multi-thread behaviour is obtained by using SystemC sc_thread. Single-
thread code is generated by serializing AND states according to the execution order specified
in the original Stateflow model.
5.3.3 Transforming Stateflow descriptions to target processor code
The semantic elements of the Stateflow model (e.g., states, junctions, transitions) are
extracted from the MDL file and represented by the HIF language by using an appropriate
front-end tool named SF2HIF.
The HIF format preserves the functional behaviour of the statecharts obtained from Stateflow;
the parallel behaviour of AND states is also preserved. In the HIF domain different tools can
be used to verify and manipulate the statecharts. For instance, state coverage can be analysed
and abstraction can be performed by grouping together equivalent states and low-level states.
State manipulation and abstraction could be useful to optimize some properties of the system
(e.g., power consumption) or to speed up simulation of SystemC models.
A back-end tool named HIF2OS generates ANSI C/C++ code corresponding to the behaviour
of the statechart, implemented as a set of nested switch and if statements representing the
behaviour of the various states and super-states, depending on and affecting the value of
external and internal signals, as well as depending on timeouts and on entering and leaving
other states of the statechart.
The user can choose to generate either multi-threaded or single-threaded code depending on
the target architecture. Multi-threaded code is generated by following the standard of POSIX
threads. Single-threaded code is generated by serializing AND states according to the
execution order specified in the original Stateflow model.
The code generator can be customized by using a textual proprietary language called TLC
(Target Language Compiler), which allows the maintainer of a target micro-controller
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 85
platform to support the target hardware and OS, e.g. by encapsulating a periodically activated
block into a timer interrupt service routine, or by modifying the syntax of the generated code.
In the context of Use Case 1, we will develop a set of TLC scripts that generate code for the
FreeRTOS and the ZigBee protocol stack that will run on the ST-I embedded platform. This
will involve translating the platform-independent API calls described in Section 3.2.1 into the
appropriate FreeRTOS calls, for example, to start or reset a timer, and to the protocol stack
calls to send or receive a packet, turn on or off the radio, or check the length of the packet
queue.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 86
6 Design process tools
6.1 Introduction
This paragraph introduces the list of tools that will be used in the system design process, for
both MDA design entries: the UML/MARTE design entry, and the Stateflow and HIFSuite
design entry to handle Stateflow representations. The proposed tools cover the three main
design phases the COMPLEX MDA entry, which are:
System modelling: it describes the modelling framework and the modelling tool;
Model transformation: it comprises the transformation engine and tools to transform
models;
System simulation; it encompasses the different tools used to obtain metrics to guide the
engineering roundtrip and perform the design space exploration.
The proposed tools are mostly based on existing, open-source and standard-based tools,
especially in the case of the UML/MARTE design entry. In such way, the COMPLEX design
flow is made open to the whole industry. Indeed, avoiding the dependence of proprietary
solutions enhances the integration the interaction of the COMPLEX tools with other external
tools due to the well-known definition of their interfaces.
The proposed tools can be also categorized into three different groups according to their role
in the COMPLEX project:
Basic tools, which correspond to those tools that represent the tooling framework to
enable the system modelling for the two different design entries, UML/MARTE or
Stateflow.
Standard-based tools and/or profiles, which correspond to those tools or profiles that
were developed following an open standard (like UML2, MARTE, IPXACT or
SystemC).
State-of-the-art tools and/or profiles, which represent the innovative part of the
COMPLEX project in terms of the proposed technical solution.
The following table summarizes the different frameworks, tools and profiles necessary to use
the COMPLEX design entry provided by the COMPLEX framework.
Table 6-1: Design process tools
Design Branch
Type UML/MARTE Stateflow Category
Modelling
Framework Eclipse [13] version 3.5
Matlab®,
Simulink®/StateFlow
® 2007 and 2010
Basic
Modelling
Tool Papyrus [11] version 1.12.3
StateFlow® 2007 and
2010
Basic
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 87
Design Branch
Type UML/MARTE Stateflow Category
UML2 meta-model NA Standard (UML2,
[4] and [5])
MARTE profile [12] NA Standard
(MARTE, [7])
COMPLEX profile NA State of the art
Model
transformati
on engine
Acceleo [14] version 3.0.0 HIFSuite
Basic
Standard (MTL,
[6])
Model
transformati
on tool2
Complex IPXACT Generator
SF2HIF front-end for
HIFSuite
HIF2SC back-end for
HIFSuite
HIF2OS back-end for
HIFSuite
State of the art
Standard
(IPXACT, [10])
Complex SystemC Generator State of the art
Complex DSE Enabler State of the art
Model
Simulation
tool3
M3P+ StateFlow® 2007 and
2010
State of the art
SCoPE+ SystemC v2.2
State of the art
Standard
(SystemC, [8])
MOST MOST State of the art
2 To be developed within the COMPLEX Project. 3 To be developed wtihin the COMPLEX Project.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 88
The following table summarizes the host environment configuration where the COMPLEX
design entry was tested in
Table 6-2: Host environment configuration
Design Branch
Type UML/MARTE Stateflow Category
Host
architecture
PC PC Basic
Operative
System
Linux Fedora Core 7 Linux Debian, Microsoft
Windows
Basic
Compiler
version
GNU C/C++ v4.x
Pref.: g++ v4.1
NA Basic
Additional
libraries
SystemC v2.2 SystemC v2.2 Basic
qt4 and qt4 devel NA Basic
qwt and qwt devel NA Basic
zlib-devel NA Basic
Utilities
make make Basic
bison NA Basic
flex NA Basic
6.2 Modelling tools
This section introduces the modelling framework for COMPLEX. The following sub-
paragraphs describe the different tools whilst proving a brief view of the capabilities that
might be interesting for the project.
6.2.1 Papyrus MDT
Papyrus [11] is a dedicated tool for modelling within UML2.2 (see [4] and [5]) , and supports
UML/MARTE profile (beta 3 for the version pointed in previous figure, see [12]). This open
source tool is based on the Eclipse environment (version 3.6) and allows UML profile
extensions the following ways:
UML Stereotypes.
This is the most common approach for the construction of a UML profiles. The
stereotypes extend and complement UML modelling elements for the representation of
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 89
domain concepts. The limitation of stereotypes is that they must be applicable to UML
modelling elements available in UML meta-model.
UML Constraints.
UML constraints (optionally annotated with stereotypes) can be used for the
representation of specific constraints that complement the modelling elements that
annotate the constraint. The language for the representation of the constraint (e.g. OCL
[8]) extends the description of the modelling element. For example, UML constraints
can be used for the specification of domain-specific types of non-functional constraints.
Model Libraries.
UML model libraries can be used to represent domain specific concepts represented as
UML reusable modelling structures that are not modified in different UML projects. An
example of this kind of extensions is domain specific patterns, to be reused in different
UML projects. Another example is platform specific APIs that represents operating
system and middleware interfaces. Sometimes model libraries are used in combination
with stereotypes.
Direct reuse of UML modelling elements.
In this approach UML modelling elements or modelling compositions can be used to
represent domain specific concepts. For example, we can use UML behaviour
specifications (e.g. interaction diagrams and state machines) for the representation of
specific types of behaviour of domain structures (e.g. classes and components)
annotated with stereotype extensions. Because these behaviours are associated to
extended elements, they are interpreted in a specific way. But UML behaviour
modelling elements are not directly extended with stereotypes. For example, it could be
possible to associate Petri Nets represented with restricted UML state-charts for the
description of this specific type of behaviours. In this case UML state machine language
is restricted and interpreted with a specific semantic.
Papyrus provides also facilities to write OCL [8] constraints with a content assistant (code
completion). OCL constraints declared in the profile stereotypes may be evaluated on user
models.
The Object Constraint Language (OCL, [8]) is a declarative language for describing rules that
apply to Unified Modelling Language (UML, [4] and [5]) models developed at IBM and now
part of the UML standard. Initially, OCL was only a formal specification language extension
to UML. OCL may now be used with any Meta-Object Facility (MOF) Object Management
Group (OMG) meta-model, including UML. The Object Constraint Language is a precise text
language that provides constraint and object query expressions on any MOF model or meta-
model that cannot otherwise be expressed by diagrammatic notation. OCL is a key component
of the new OMG standard recommendation for transforming models, the
Queries/Views/Transformations (QVT) specification.
OCL language statements are constructed in four parts:
a context that defines the limited situation in which the statement is valid;
a property that represents some characteristics of the context (e.g., if the context is a
class, a property might be an attribute);
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 90
an operation (e.g., arithmetic, set-oriented) that manipulates or qualifies a property, and;
Keywords (e.g., if, then, else, and, or, not, implies) that are used to specify conditional
expressions.
6.2.2 Stateflow
A Stateflow chart is a representation of a finite state machine [37]. A finite state machine is a
representation of an event-driven (reactive) system. In an event-driven system, the system
makes a transition from one state (mode) to another, if the condition defining the change is
true. A finite state machine can be modelled through either a truth table to relate the inputs,
outputs, or states or state-transition charts (bubble charts).
A Stateflow chart uses a variant of the finite state machine notation established by Harel [38].
A chart is a graphical representation of a finite state machine, where states and transitions
form the basic building blocks of the system. You can also represent stateless charts (flow
graphs). You can include Stateflow charts as blocks in a Simulink model. The collection of
Stateflow charts in a Simulink model is the Stateflow machine. A Stateflow chart enables the
representation of hierarchy, parallelism, and history. You can organize complex systems by
defining a parent and offspring object structure [39]. For example, you can organize states
within other higher-level states. A system with parallelism can have two or more orthogonal
states active at the same time. You can specify the destination state of a transition based on
historical information. These characteristics go beyond what state-transition charts and bubble
charts provide.
Notation defines a set of objects and the rules that govern the relationships between those
objects. Stateflow chart notation provides a way to communicate the design information in a
Stateflow chart. Stateflow chart notation consists of these elements:
A set of graphical objects
A set of non-graphical text-based objects
Defined relationships between those objects
As depicted in Figure 6-1 a Stateflow chart consists of graphical objects (states, boxes,
functions, notes, transitions, connective junctions, and history junctions) and non-graphical
objects (events, data, and targets). A detailed description of all these elements is reported in
[37].
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 91
Figure 6-1: Elements of a Stateflow chart
Semantics describe how to interpret chart notation. A typical Stateflow chart contains actions
associated with transitions and states. The semantics describe the sequence of these actions
during chart execution.
The Stateflow chart interfaces to its Simulink model and to code sources external to the
Simulink model (data, events, custom code).
Stateflow charts are event-driven. Events can be local to the Stateflow block or can propagate
to and from the Simulink model. Data can be local to the Stateflow block or can pass to and
from the Simulink model and external code sources.As shown in Figure 6-2 Stateflow
machines arrange Stateflow objects in a hierarchy based on containment. That is, one
Stateflow object can contain other Stateflow objects. The highest object in Stateflow
hierarchy is the Stateflow machine. This object contains all other Stateflow objects in a
Simulink model. The Stateflow machine contains all the charts in a model. In addition, the
Stateflow machine for a model can contain its own data and target objects.
Similarly, charts can contain state, box, function, data, event, transition, junction, and note
objects. Continuing with the Stateflow hierarchy, states can contain all these objects as well,
including other states. You can represent state hierarchy with superstates and substates.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 92
A transition out of a superstate implies transitions out of any of its active substates.
Transitions can cross superstate boundaries to specify a substate destination. If a substate
becomes active, its parent superstate also becomes active.
You can organize complex charts by defining a containment structure. A hierarchical design
usually reduces the number of transitions and produces neat, manageable charts.
Figure 6-2: Stateflow hierarchy
Every state (and chart) has a decomposition that dictates what kind of substates it can contain.
All substates of a superstate must be of the same type as the superstate‟s decomposition.
Decomposition for a state can be exclusive (OR) or parallel (AND). These types of
decomposition are described in the following topics.
Exclusive (OR) state decomposition for a superstate (or chart) is graphically indicated when
its substates have solid borders. Exclusive (OR) decomposition is used to describe system
modes that are mutually exclusive. When a state has exclusive (OR) decomposition, only one
substate can be active at a time. The children of exclusive (OR) decomposition parents are OR
states.
The children of parallel (AND) decomposition parents are parallel (AND) states. Parallel
(AND) state decomposition for a superstate (or chart) is graphically indicated when its
substates have dashed borders. This representation is appropriate if all states at that same level
in the hierarchy are always active at the same time. The activity within parallel states is
essentially independent.
6.2.3 COMPLEX profile
The COMPLEX project aims to provide an MDA design entry using MARTE UML profile
for modelling all the application, the platform and the architecture of the system. The
MARTE profile introduces lots of enhancements on the UML structure to support the
modelling of the real time characteristics of the system and the HW and SW platform.
However it does not provide any support to the DSE loop and the definition of the stimuli
environment.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 93
Although the use of Design Specific Languages (DSL) has been kept to a minimum, the
MARTE profile does not cover all the necessities for dealing with all aspects related with the
model viewpoints, design space exploration and stimuli environment. Therefore, this profile
aims to cover those concepts not supported by MARTE profile.
The following image depicts the structure of the COMPLEX profile. The Core profile
provides support to the model viewpoint support, while the Verification and Dse supports
concepts related to the verification environment and the design space exploration.
Figure 6-3: COMPLEX profile package diagram
The COMPLEX profile is distributed by means of an Eclipse plug-in to be installed within
Papyrus MDT. Indeed, this profile is developed using Papyrus facilities to develop UML
profiles, and relays on Papyrus libraries to be installed correctly.
6.2.3.1 Core
Current implementation of the Papyrus MDT tool does not provide support to views as
described in section 5.2.1. It is necessary therefore to identify the different model views that
form part of the UML/MARTE design entry (see section 5.2.1).
The following image depicts the structure of the Core profile.
Figure 6-4: Core profile for COMPLEX project
The COMPLEX Core profile consists of six different stereotypes with no properties that
extends the UML meta-class Package. The semantics added by these stereotypes allow the
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 94
system engineers to focus their attention on specific aspects of the system, but also allow the
transformation engines to identify the different model views and process them correctly.
Stereotype Description
DataModel Description:
This stereotype identifies the UML package that contains
the description of the system data model.
For additional information about the UML elements that
are expected to be found there refer to section 5.2.2.1.
Extensions:
UML Package.
Generalizations:
None.
Attributes:
None.
Constraints:
This stereotype must only appear once in the UML
model.
FunctionalView Description:
This stereotype identifies the UML package that contains
the functional description of the system by means of the
system components which implement system functions
and the interfaces they expose to other components.
For additional information about the UML elements that
are expected to be found there refer to section 5.2.2.1.
Extensions:
UML Package.
Generalizations:
None.
Attributes:
None.
Constraints:
This stereotype must only appear once in the UML
model.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 95
Stereotype Description
CommsConcurrencyView Description:
This stereotype identifies the UML package that contains
the system components which define the non-functional
proprieties of the system functions (i.e. service deadlines,
interface types, etc.)
For additional information about the UML elements that
are expected to be found there refer to section 5.2.2.2.
Extensions:
UML Package.
Generalizations:
None.
Attributes:
None.
Constraints:
This stereotype must only appear once in the UML
model.
PlatformView Description:
This stereotype identifies the UML package that contains
the system components which model the system
platform, both HW and SW.
For additional information about the UML elements that
are expected to be found there refer to section 5.2.3.1.
Extensions:
UML Package.
Generalizations:
None.
Attributes:
None.
Constraints:
This stereotype must only appear once in the UML
model.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 96
Stereotype Description
ArchitecturalView Description:
This stereotype identifies the UML package that contains
the description of the system architecture, instantiating
the system components and the platform components,
and allocating the system components to the platform
resources.
It also defines the different DSE parameters and DSE
rules and constraints that will guide the DSE loop.
For additional information about the UML elements that
are expected to be found there refer to section 5.2.4.1.
Extensions:
UML Package.
Generalizations:
None.
Attributes:
None.
Constraints:
This stereotype must only appear once in the UML
model.
VerificationView Description:
This stereotype identifies the UML package that contains
the description of the stimuli environment that will excite
the system during the simulation and performance
analysis.
For additional information about the UML elements that
are expected to be found there refer to section 5.2.5.1.
Extensions:
UML Package.
Generalizations:
None.
Attributes:
None.
Constraints:
This stereotype must only appear once in the UML
model.
Table 6-3: COMPLEX Core profile stereotypes
6.2.3.2 Design Space Exploration
In order to cope with the design space exploration already from the MDA design entry, it is
necessary to add new concepts to the UML model which provide information about the DSE
parameters, rules and constraints that will guide the DSE tool (i.e. MOST, see section 6.5.3).
This profile represents all the information necessary for providing the XML Design Space
file, generated by the transformation tool described in section 6.4.4. The following image
shows the profile structure and the UML meta-classes that are extended with new semantics.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 97
Figure 6-5: DSE profile for COMPLEX project
The DSE profile is mainly composed by four basic stereotypes. They are fully described in the
following table.
Stereotype Description
DseParameter Description:
A DSE parameter is used to specify the names, types and
ranges of the parameters that can be explored by the MOST
tool.
Extensions:
None.
Generalizations:
None.
Attributes:
name: String[1]; identifies the name of the parameter.
description: String[0..1]; provides a brief description of
the parameter.
Constraints:
Each parameter name must be unique within the UML
model.
Feasible parameter names are identified by the following
regular expression: [A-Za-z_][A-Za-z0-9_]*
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 98
Stereotype Description
DseScalarParameter Description:
A DSE parameter of scalar type.
Extensions:
UML Comment.
Generalizations:
COMPLEX_profile::Dse::DseParameter.
Attributes:
scalar_type: ScalarType[1]; identifies the type (see Table
6-5).
items: String[*]; lists the possible string values when the
scalar type is string (see Table 6-5).
min: Integer[0..1]; minimum boundary.
max: Integer [0..1]; maximum boundary.
step: Integer[0..1]; defines the increment in non-unitary
progressions.
Constraints:
min and max are mandatory when the scalar type is integer
or exp2 (see Table 6-5).
min and max are 0 and 1 when the scalar type is boolean
by default (see Table 6-5).
DseVectorParameter Description:
A DSE parameter of vector type, which identifies specific
constraints on the possible combination of components.
Extensions:
UML Comment.
Generalizations:
COMPLEX_profile::Dse::DseParameter.
Attributes:
vector_type: VectorType[1]; identifies the type (see Table
6-5).
dimension: Integer [0..1]; dimension of the vector.
dimensionRef: String [0..1]; reference to another DSE
parameter defined in the UML model using
@parameter_name notation.
on_set_size : Integer [0..1]; specifies the amount of
elements that should be on the resulting vector.
on_set_sizeRef: String[0..1]; reference to another DSE
parameter defined in the UML model using
@parameter_name notation.
Constraints:
dimensionRef and on_set_sizeRef references to DSE
parameter which type is integer (see Table 6-5). The
notation must be @parameter_name if the step is not 1,
and @_parameter_name_ if step is equal to 1.
dimension and on_set_size must not be defined if
dimensionRef and on_set_sizeRef are defined,
respectively (and vice versa).
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 99
Stereotype Description
DseRule Description:
A DSE rule consists of a boolean expression which should
evaluate to true for a feasible configuration of the design space.
Extensions:
UML Constraint.
Generalizations:
None.
Attributes:
parameter: String[1..*]; references the DSE parameters
where the boolean expression will act on. The notation
shall be $dse_parameter.
expression: String[1]; defines an OCL expression to define
a rule with the DSE parameters included in previous
attribute.
Constraints:
None.
DseConstraint Description:
A DSE constraint consists of an allocation constraint for a
system component.
Extensions:
UML Constraint.
Generalizations:
None.
Attributes:
partition: PartitioningType[1]; identifies that the constraint
instance of a system component must be either SW or
HW.
parameter: String[1]; references the name of the vector
parameter of type permutation that defines the possible
combination of allocations between the component and the
platform resources. The notation shall be $dse_parameter.
Constraints:
The referenced DSE parameter must be a vector type
permutation.
Table 6-4: COMPLEX DSE profile stereotypes
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 100
Additionally this profile defines three enumerations which have the following meaning:
Table 6-5: COMPLEX DSE profile data types and enumerations
Enumeration Description
ScalarType Description:
Identifies a DSE parameter with a sequential progression.
Values:
integer: a simple sequential progression.
boolean: integer sequential progression with two possible
values, 0 and 1.
exp2: integer power of two progression.
string: list of possible string values.
VectorType Description:
Identifies a DSE parameter that specifies constraints on the
possible combinations of the components and the platform
resources.
Values:
on_off_mask: vector combination of boolean values with
an specific dimension.
permutation: vector combination of permutations used in
the case of component mapping to platform resources.
PartitioningType Description:
Identifies the type of allocation constraint.
Values:
SW: the component must be allocated to the SW part.
HW: the component must be allocation to the HW part.
6.2.3.3 Stimuli Environment Definition
The MDA design entry is also used to model the stimuli environment that will excite the
system during the simulation and performance analysis process. However it is necessary to
add new concepts to the UML model which provide information the different sub-systems
interacting with the system and the different scenarios that will be considered.
This profile provides the information necessary producing the stimuli environment using the
transformation tool described in section 6.4.5. The following image depicts the profile
structure and the UML meta-classes that are extended with the new semantics.
Figure 6-6: Verification profile for COMPLEX project
The following table describes the different stereotypes and their attributes in detail.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 101
Table 6-6: COMPLEX Verification profile stereotypes
Stereotype Description
ExternalSubsystem Description:
Identifies a subsystem that interacts with the system.
Extensions:
None.
Generalizations:
None.
Attributes:
None.
Constraints:
None.
ExternalInterface Description:
Identifies an interface with an external subsystem. It just
represents a logical dependency of an external source of data.
Extensions:
None.
Generalizations:
None.
Attributes:
None.
Constraints:
None.
System Description:
Identifies the component that will be excited during the
simulation and performance analysis.
Extensions:
None.
Generalizations:
None.
Attributes:
None.
Constraints:
None.
Scenario Description:
A DSE parameter is used to specify the names, types and
ranges of the parameters that can be explored by the MOST
tool.
Extensions:
None.
Generalizations:
None.
Attributes:
name: String[1]; identifies the name of the scenario.
Constraints:
The name of the scenario must be unique in the UML
model.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 102
6.3 Model transformation engines
6.3.1 Acceleo
This tool consists of an implementation of the OMG MOF Model-to-text (M2T) specification
(see reference [35]). It supports the developer on tasks like syntax error highlighting, content
assistant, smart completion optimized code generation, and other advanced tooling features
like plug-in generation.
The Acceleo Project (previously named MTL) is an open source component under the Eclipse
Modelling / Model To Text (M2T) project [36], integrated with Eclipse Helios in its version
3.0.0.
Among its main characteristics, it is remarkable its high ability to customization,
interoperability, easy kick off and traceability management.
This transformation engine support the development of Eclipse plug-ins that are able to
generate text files from an UML model, which could be source code files, XML files or plain
text files.
Tool developers write Acceleo modules for code generation. A module is made of several
templates that describe the information required to generate source code from the UML meta-
model. Within each template, several scripts enable the user to customize the generator
accurately.
This tool is intended to be used for generating the following source code and text generators:
The CFAM generator, producing the CFAM containers and CFAM code (see section
5.2.6 for further information), SystemC containers and the SW Native source code to be
executed in the virtual platform.
The IP-XACT generator, providing the IP-XACT specification derived from the
MARTE platform model.
The XML System Description and XML Design Space generators (sections 6.4.3 and
6.4.4), which produces two XML documents
For further information about Acceleo, refer to [14].
6.3.2 Magillem Generator Studio
Magillem Generator Studio is an Eclipse-based user-friendly and powerful environment to
help designers implement, launch and debug their own executables (“generators”) in order to
extend the capabilities of their IP based design environment.
Particularly in this methodology, it helps designers implement, launch and debug their own
generators in order to transform the IP-XACT specification into a SystemC model of the HW
platform.
For further information about Generator Studio, refer to [17].
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 103
6.3.3 HIFSuite
HIFSuite is a set of tools and application programming interfaces (APIs) that provides support
for modelling and verification of HW/SW systems. The core of HIFSuite is the HDL
Intermediate Format (HIF) language upon which a set of front-end and back-end tools have
been developed to allow the conversion of HDL code into HIF code and vice-versa. HIFSuite
allows designers to manipulate and integrate heterogeneous components implemented by
using different hardware description languages (HDLs). Moreover, HIFSuite includes tools,
which rely on HIF APIs, for manipulating HIF descriptions in order to support code
abstraction and post-refinement verification.
Figure 6-7 shows an overview of the HIFSuite features and components. HIFSuite is
composed of:
The HIF core-language and APIs: a set of HIF objects corresponding to traditional HDL
constructs as, for example, processes variable/signal declarations, sequential and
concurrent statements, etc.
A set of front/back-end conversion tools:
o HDL2HIF. Front-end tools that parse VHDL, Verilog and SystemC (RTL and
TLM) descriptions and generate the corresponding HIF representations; in the
COMPLEX project a new front-end tool named SF2HIF has been introduced
to parse Stateflow descriptions.
o HIF2HDL. Back-end tools that convert HIF models into VHDL, Verilog,
SystemC (RTL and TLM) and NuSMV code; in particular, two back-end tools
are relevant, i.e., HIF2SC to generate SystemC descriptions, and HIF2OS
which has been introduced in COMPLEX to generate C/C++ code.
A set of APIs in C++ that allow designers to develop HIF-based tools to explore,
manipulate and extract information from HIF descriptions. The HIF code manipulated
by such APIs can be converted back to the target HDLs by means of HIF2HDL.
A set of tools developed upon the HIF APIs that manipulate HIF code to support
modelling and verification of HW/SW systems. In particular:
o A2T: a tool that automatically abstracts statecharts by grouping together
several states.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 104
Figure 6-7: HIFSuite architecture
6.4 Model transformation tools
6.4.1 COMPLEX IPXACT generator
The COMPLEX IPXACT generator is in charge of producing an IP/XACT description of the
HW platform. Its main function will be to feed the virtual platform generation, to serve to the
rest of the DSE flow of complex, below the system-level DSE enabled by SCoPE+, the
generation of a virtual platform model. This IP/XACT code will be readable by Magillem
Generator Studio tool.
The COMPLEX IPXACT generator will support multi-level generation. That is, it will be
able to feed again SCoPE+, which, through an IP/XACT plug-in, is able to read the HW
platform IP/XACT description. The IP/XACT description of the HW platform read by
SCoPE+ is abstract in the sense that it does not require as much information as Magillem
Generator Studio. This is because high-level estimation enabled by SCoPE+ requires less
platform details.
The COMPLEX IPXACT generator takes as input an .uml file, generated with Papyrus MDT,
and produced an .xml file, under the IP/XACT standard.
Specifically, the generator takes the information from the Platform View, and from the
Architectural View (since the latter is the only view with the top interconnection of the
platform). Because of that, the two first thinks the generator has to recognize are two UML
packages with the COMPLEX specific stereotypes for the afore mentioned views, namely
COMPLEX::PlatformView and COMPLEX::ArchitecturalView.
An additional set of transformation rules dictates how the UML/MARTE elements are
translated into IP/XACT constructs. For instance, a UML class instance in the architectural
view of a component stereotyped with the MARTE HwProcessor stereotype in the Platform
view is translated into a IPXACT spirit::componentInstance entry.
The tool is being deployed as a set of templates, under the Model To Text (M2T) [36]
language. This way, M2T templates reflect in an standard language the transformation rules.
These templates are being checked on AcceleoMTL, a tool fully integrated in Eclipse Helios
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 105
(see reference [13]), which enables the transformation of the UML/MARTE model (it
supports the identification of MARTE stereotypes), through the transformation rules
implemented by the M2T templates into the XML code. AcceleoMTL enables the
deployment of the IP/XACT generator as an installable plug-in for Eclipse Helios.
Currently, an early version of the tool has been implemented, working on simple examples
(with one or several processors, bus and memory).
The following information is being introduced by the tool:
IP/XACT code of the platform (currently abiding the information required by SCoPE).
XML comments for tracking generation information, and the source the IP/XACT code
has been inferred from.
Header informing version of the tool, authors, and the automated character of the
IP/XACT code.
Immediate activity is focused on extending the generator to produce IP/XACT code with the
information necessary to make it readable by Magillem Generator Studio, and on the
implementation of consistency checks and their associated warnings. For instance, that there
is no a direct connection (without a bridge) between two incompatible buses.
6.4.2 COMPLEX CFAM generator
The COMPLEX CFAM generator is responsible for producing the source code necessary to
build an application executable model, ready for functional verification, and in some cases,
for performance analysis. This model transformation tool is based in the transformation
engine Acceleo (see section 6.3.1) and is developed in Java and a proprietary scripting
language.
The type of generation depends on the specific purpose of the executable model and the
simulation and analysis infrastructure (see section 5.2.6 for further details).
In any case, the CFAM code (user code) is never modified thanks to the abstraction level
provided by the CFAM API, which will have an associated implementation for each
simulation and analysis infrastructure.
According to section 5.2.6 there are executable models to be produced by this tool:
Native SW Executable Model (executes on POSIX based platforms);
SystemC Executable Model (feeding other COMPLEX tools);
SCoPE+ Executable Model (feeding the SCoPE+ tool);
The Application Executable Model generator reads, analyzes and processes the
UML/MARTE model to generate the source codes files that conform the application
executable model. There are mainly three sources where the generator takes the information
to generate this model:
Both Data View and Functional View (see section 5.2.2.1), which models the system
functions and their data types and structures.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 106
The Concurrency and Communication View (see section 5.2.2.2), which defines the
system components and their functional and non-functional properties.
The Architectural View (see section 5.2.4.1), which defines the instances of system
components and their allocation to the platform HW and SW resources.
An executable component is formed of both the CFAM code (pure functional code), and the
container code (see section 5.2.6). As mentioned, the CFAM code is user provided, and
independent from the simulation and analysis infrastructure.
The container code depends on the simulation and analysis infrastructure and will be
automatically generated by the CFAM generator derived from the PIM view (see section
5.2.2). Thus, this would require a generator for each targeted simulation and analysis
infrastructure.
In order to overcome this pitfall, the CFAM generator will generate all the different
executable models by means of a common set of “C” macros and support facilities for all
different simulation and analysis infrastructures. The set of all those implementations for the
set of Simulation and Analysis infrastructures supported constitute the CFAM infrastructure.
The following image depicts the transformation process at a glance:
Functional View
Data View
CFAM code
Generate CFAM code
Analyze System Architecture
Generate CFAM Containers
Communications and
Concurrency View
Architectural ViewSCOPE containers
code
SystemC containers
code
SW_PIM containers
code
Data Types
Makefile
Dump errors
Dump warnings Warning Report
Error Report
Consistency of the data model
with classes
Consistency between
classes and interfaces
Consistency between the functional
and the component interfaces
Consistency between component
interfaces
Errors?
Errors?
Figure 6-8: Transformation flow for the CFAM generator
Each of the two first steps (e.g Generate CFAM code, Generate CFAM containers ) is split
into several activities to analyze, check the consistency and produce the output source code.
These activities are:
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 107
Analysis activities: loads the UML/MARTE model into memory so that further analysis
might be performed on them. During the loading process, information derived from
MARTE (if exist) is retrieved and stored for further analysis.
Consistency checks: for example, verification that the CFAM code interfaces
corresponds with the CFAM container interfaces.
Generation of source code: the source code is generated by means of the Acceleo
scripting language and the analysis data base generated in previous activities. If there
are errors during the analysis and consistency checks, this activity will not be performed
and the user will be notified accordingly.
This tool will be deployed as an installable plug-in for Eclipse, integrated with the XML
System Description Generator (see section 6.4.3) and the XML Design Space Generator (see
section 6.4.4).
The resultant plug-in will be then integrated in Eclipse Helios (see reference [13]).
6.4.3 COMPLEX XML System Description generator
The COMPLEX XML System Description generator is responsible for producing the XML
file required by SCoPE+ for performing the performance analysis. As well as the CFAM
generator, it is based on the transformation engine described in section 6.3.1 and developed in
Java and the proprietary scripting language provided by the Acceleo.
The XML System Description generator reads, analyzes and processes the UML
UML/MARTE model to generate an XML file that contains the system description:
Description of the HW platform, identifying all the HW components that can be
instantiated to create the HW platform, their instantiation to create a particular HW
architecture and possible computing groups that support as a whole a SW system (i.e.
multi-core SoC providing computing resources to the same operating system).
Description of the SW platform, mainly the operating system and other components like
drivers or middleware. Again, it describes the SW components available to be
instantiated later to create a SW architecture.
Description of the CFAM containers (e.g. the application components): it describes the
CFAM containers that can be instantiated to create the application, and defines the
allocation of CFAM container instantiations to instances of the platform, either HW or
SW instances.
Finally, it generates a set of description parameters that are required by SCoPE+ to
perform the simulation, like init and end simulation time and back trace information.
To extract this information the generator must have access to the UML/MARTE. There are
mainly four sources where the generator takes the information to generate this model:
The Concurrency and Communication View (see section 5.2.2.2), which defines the
system components and their functional and non-functional properties.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 108
The Platform Description View (see section 5.2.3.1), which describes the platform in
terms of HW (processors, buses, etc.) and SW components (operating system,
middleware, drivers, etc.)
The Architectural View (see section 5.2.4.1), which defines the instances of system
components and their allocation to the platform HW and SW resources.
The Verification View (see section 5.2.5.1), which defines the simulation parameters.
Due to the fact that this tool requires the analysis capabilities implemented in the IP-XACT
generator (see section 6.4.1) and CFAM generator (see section 6.4.2), they will be integrated
in order to minimize the duplication of functionality. However some additional steps are
necessary to generate the XML document. The following image depicts the transformation
process at a glance:
Analyze CFAM Containers
Analyze
System Architecture
Communications and
Concurrency View
Architectural View
Generate XML
document
XML System
Description
I.e. consistency
between the funcitonal
and the component
interfaces
Consistency between
component interfaces
Errors?
Errors?
Reused from
CFAM generator
Platfrom Description
ViewAnalyze Platform Components
Errors?
Reused from
IP-XACT generator
Reused from
CFAM generator
Figure 6-9: Transformation flow for the XML System Description generator
The resultant plug-in will be then integrated in Eclipse Helios (see reference [13]).
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 109
6.4.4 COMPLEX XML Design Space generator
The COMPLEX XML Design Space generator is responsible for producing the XML file
required by SCoPE+ and MOST for configuring the Design Space Exploration (DSE) loop .
As well as the CFAM generator, it is based on the transformation engine described in section
6.3.1 and developed in Java and the proprietary scripting language provided by the Acceleo
tool.
The XML Design Space generator reads, analyzes and processes the UML/MARTE model to
generate an XML file that defines the design space to explore:
Initially, this XML file will describe the complete path name of the executable of the
simulator and performance analyzer (e.g. SCoPE+).
It defines the different parameters that define the names, types and ranges of the system
parameters that can be explored by the DSE tool. The names will be used for generating
configurations at the input of the analyzer.
Then, it identifies the names, types and units of the system metrics that will be provided
by the analyzer. The DSE tool would expect to find this system metrics in the output file
name of the simulator and performance analyzer.
Finally, it describes the different rules used by the DSE tool in order to not generate
invalid or unfeasible solutions during the automated exploration process. Each rule
consists of a boolean expression acting on system parameters, constants or other
boolean expressions. These expressions should evaluate to true for a feasible
configurations of the design space.
For further information about the different rules that can be formulated in the
UML/MARTE model, please refer to section 5.2.4.1.
For further information about the design space definition, refer to document [16].
To extract this information the generator must have access to the UML/MARTE. There are
one sources where the generator takes the information:
The Architectural View (see section 5.2.4.1), which defines the allocation schemes,
DSE parameters and the DSE rules for defining the different configurations.
Due to the fact that this tool requires the analysis capabilities implemented in CFAM
generator (see section 6.4.2), they will be integrated in order to minimize the duplication of
functionality. However some additional steps are necessary to generate the XML document.
The following image depicts the transformation process at a glance:
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 110
Analyze
System ArchitectureArchitectural View
Generate XML
documentXML Design Space
Consistency between
component interfacesErrors?
Reused from
CFAM generator
Figure 6-10: Transformation flow for the XML Design Space generator
This tool will be deployed as an installable plug-in for Eclipse, integrated with the CFAM
generator (see section 6.4.2). The resultant plug-in will be then integrated in Eclipse Helios
(see reference [13]).
6.4.5 COMPLEX Stimuli Input generator
The COMPLEX Stimuli Input generator is responsible for producing the infrastructure of the
stimuli environment that will excite the system during the simulation and/or performance
analysis.
The Stimuli Input generator reads, analyzes and processes the UML/MARTE model to
generate the necessary infrastructure to excite the system during the simulation and
performance analysis, and producing the skeletons of the stimuli scenarios so that the
verification engineer can insert the necessary behaviour.
CFAM API enables the writing of input stimuli as a functional test bench, in a way
independent from the Simulation and Analysis infrastructure. Thus a functional test bench can
be written again as C code with calls to the CFAM API. This code is associated to instances
of CFAM component declared in the verification view.
Therefore, the stimuli generation can be easily integrated within code generation
infrastructure used for the system (CFAM and XMLD generators). A main distinction that has
to be done is that the functionality associated to the environment will be wrapped by CFAM
components associated to the Verification view. The only relevance in the case of application
of the SystemC S&A structure, is to delimit the border between system and environment. In
the case of the application to the SCoPE+ S&A infrastructure, it is more relevant since
functionality associated to generation of input stimuli, that is, environment components, will
not consume system resources.
This tool will be deployed as an installable plug-in for Eclipse, integrated with the CFAM
generator (see section 6.4.2) due to some common analysis functions that are implemented in
the mentioned tool. The resultant plug-in will be then integrated in Eclipse Helios (see
reference [13]).
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 111
6.4.6 SF2HIF
The semantic elements of the Stateflow model (e.g., states, junctions, transitions) are
extracted from the MDL file and represented by the HIF language by using an appropriate
front-end tool named SF2HIF.
The HIF format preserves the functional behaviour of the statecharts obtained from Stateflow;
the parallel behaviour of AND states is also preserved. In the HIF domain different tools can
be used to verify and manipulate the statecharts. For instance, state coverage can be analysed
and abstraction can be performed by grouping together equivalent states and low-level states.
State manipulation and abstraction could be useful to optimize some properties of the system
(e.g., power consumption) or to speed up simulation of SystemC models.
6.4.7 HIF2SC
A back-end tool named HIF2SC generates a SystemC model of the original statechart. The
SystemC model can be both at RTL and TLM depending on the detail level of the Stateflow
model and on the abstraction process eventually performed on the HIF representation.
The user can choose to generate either multi-thread or single-thread code depending on the
modelling needs. Multi-thread behaviour is obtained by using SystemC sc_thread. Single-
thread code is generated by serializing AND states according to the execution order specified
in the original Stateflow model.
6.4.8 HIF2OS
A back-end tool named HIF2OS generates ANSI C/C++ code corresponding to the behaviour
of the statechart, implemented as a set of nested switch and if statements representing the
behaviour of the various states and super-states, depending on and affecting the value of
external and internal signals, as well as depending on timeouts and on entering and leaving
other states of the statechart.
The user can choose to generate either multi-thread or single-thread code depending on the
target architecture. Multi-thread code is generated by following the standard of POSIX thread.
Single-thread code is generated by serializing AND states according to the execution order
specified in the original Stateflow model.
6.5 Model simulation tools
6.5.1 SCoPE+
The integration of SCoPE+ in the COMPLEX flow supports the system-level DSE cycle in
COMPLEX design process. The goal is to provide a fast estimation of time and power
consumption figures at a sufficient accuracy to enable early design decisions, such as finding
the the optimum mapping of application components onto platform resources. On this way,
the system-level DSE will enable a first level of decisions in the overall COMPLEX flow,
which can be later refined.
In order to get such a fast estimation of performance metrics, SCoPE+ stresses on the
following points:
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 112
1. Native simulation: it enables handing as input for the estimation the source code of the
application, actually, a non-refined implementation independent version of the code.
2. An implementation independent API for the description of the Application, which will
allow the user to get rid of the manual refinement or adaptation of the functional code
no matter of the simulation and performance analysis infrastructure.
3. Configurable executable specification and input formats supporting the definition of a
Design Space parameters and rules. A configurable executable specification makes
unnecessary the recompilation of a new executable specification for exploring a new
specification.
For a full description of the tool, please refer to document [2].
6.5.2 M3P+
M3P+ recalls for a possible extension of the M3P plug-in. the M3P plug in enables the XML
interface of SCoPE, and will do so also for SCoPE+. Figure 6-11 shows the scheme of input
and output XML files of SCoPE enabled by M3P:
(Input) System Description File: It enables the declaration of the HW and SW
components, of the platform architecture, of the allocation of application tasks into the
HW platform. It supports parameterization.
(Input) System Configuration File: It enables giving specific values to the parameters
defined and used in the System Description.
(Input) Metric Definition File: It enables specifying the desired set of metrics which the
exploration tool, i.e., SCoPE, must report.
(Output) Metric Report File: It containts the metrics reported by SCoPE after the
simulation.
Through this XML interface, SCoPE will communicate with the exploration tool (MOST in
COMPLEX).
Figure 6-11: M3P inputs and output diagram.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 113
More detailed information about M3P plug-in can be found in tool, please refer to document
[15].
M3P+ will consider any required extension which can be required, for instance, to take into
account the component-based allocation (that is, application components, instead of tasks,
will be allocated to a hardware resource). This extension is in the framework of T3.1 of
COMPLEX.
6.5.3 MOST
The Multi-Objective System Tune (MOST) tool is a proprietary tool for discrete optimization
specifically designed for enabling design space exploration of hardware/software
architectures. MOST helps driving the designer towards near-optimal solutions to the
architectural exploration problem. The final product of the framework is a Pareto set of
configurations within the design evaluation space of the given architecture and analysis on the
effects of design space parameters on to the objective functions.
MOST will use the XML-based interfaces to communicate with performance estimation tools.
SCoPE+ is one of them, working at system-level DSE.
One of the goals of MOST is to provide a command line interface to construct automated
exploration strategies. Those strategies are implemented by means of command scripts
interpreted by the tool without the need of manual intervention. This structure can easily
support the batch execution of complex strategies
For a full description of the tool, please refer to document [2].
6.5.4 Virtual Platform
The Virtual Platform tools are a simulation environment that allows multiple design tasks
ranging from early development of embedded software for multi core systems to the
evaluation of the system performance in terms of software execution time, memory
bottlenecks or power consumption for various architectural variants or software mappings.
A Virtual Platform simulator is a software model of a complete system that provides software
engineers a development environment enabling the concurrent development of SoC hardware
and software. The virtual platform tool, Innovator, provides an integrated SystemC
development environment for assembling virtual prototypes from transaction-level models
(TLMs) from various sources, and creating new ones.
The Virtual Platform simulator will be a SystemC model for the HW architecture presented
above. For each of the different components of the architecture, a SystemC LT model will be
used in order to provide with an efficient environment for SW development.
The virtual platform simulator will provide with support for SW debugging of the application
code and also provide with platform debugging information (register visibility, pin tracing) as
well as HW analysis features in order to be able to do a high-level evaluation of the SW
performance.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 114
Figure 6-12: Virtual Platform simulator
A main role of Virtual Platform in COMPLEX, specifically in use case 3, is to serve as
reference platform to contrast the performance figures obtained by the system-level
performance estimation technologies developed in COMPLEX. Since Virtual platform is able
to consider HW models at RTL level and ISS for processor modelling, it should serve to
check that system-level performance estimations techniques developed in COMPLEX serve
to obtain an speed-up in the estimation time, while preserving an accuracy enough to lead to
similar Pareto optimum solutions.
For further details about the Virtual Platform simulator, refer to document [2], Synopsys
Platform Architect tool.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 115
7 Limitations
The following paragraph lists the limitations of the methodology, both at tool and method
levels, which are to be considered during the use case exercising in the COMPLEX project.
Coherence between model views.
According to the document [2], there is an explicit requirement regarding the use of
Open Source tools to support the design process whenever possible. Moreover, it is
sensible to consider this kind of requirements in a research and development project.
The selection of the modelling tool Papyrus MDT (see section 6.2.1) represents a good
choice due to its stability and the full compatibility with the UML2 meta-model.
Besides, it supports the MARTE and SysML profiles, widely spread all over the
industry. However it does not support the model views.
Whenever a model view is active, the editor may or may not allow users to see and/or
modify other aspects of the system different from they are working in. For example, the
definition of the functional concerns is treated in a different view from the description
of the concurrency of system functions. However, while editing the later the user is able
to modify the interfaces in the former, likely to provoke inconsistencies within the
model
In order to overcome this pitfall, the methodology has separated at maximum the
different concerns in order to avoid the appearance of inconsistencies between different
model views.. Besides, the transformation tools described in section 6.4 will implement
analysis methods and report any possible inconsistency found in the model during the
analysis.
Tool limitations regarding the generation of SystemC code from the UML/MARTE
design flow.
The SystemC code generated regards only to component structure, and not to
functionality, which is captured through the CFAM user code. Capturing such
functionality could be introduced through behavioural diagrams. However it is not an
aim of the methodology proposed.
The CFAM user code needs to be ANSI-C code (plus CFAM API calls) which can be
processed by a compiler abiding the C++ grammar. This is actually no limitation of a
generator, since the CFAM user code is not generated indeed, but of the SCoPE+
estimation methodology.
Tool limitations regarding the generation of SystemC/C/C++ code from MathWorks
Stateflow.
The generation of C/C++/ from MathWorks Stateflow descriptions is limited by the
following issues are not under control of COMPLEX consortium:
o Concurrency not clearly addressed by Stateflow; concurrent statecharts can be
described by Stateflow through the use of AND states; however, in Stateflow
both simulation and code generation assume a defined execution order between
AND states; furthermore, the execution order can be implicitly defined through
the graphical position of the states; if code generated by COMPLEX tool
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 116
preserves the semantic of concurrent states, the target execution scheduler may
choose a different (even random) execution order leading to a different
functional behaviour with respect to Stateflow execution; this issue can be
solved by adopting the same execution order but in this case the concept of
parallel states is useless.
o Changes of the syntax of Stateflow descriptions; Stateflow descriptions are
contained into text files (with .mdl extension) generated by the Stateflow
graphical user interface; the grammar of this description is managed by
MathWorks as a private format; if this grammar will change in future versions
of Stateflow, the parser of the COMPLEX tool must be modified accordingly.
o Misunderstanding of the semantic of Stateflow descriptions; in this project the
semantic of the Stateflow items has been obtained from the user manual and
the empirical investigation through the writing of several examples; the
functional behaviour of the code generated by the COMPLEX tool has been
compared with the behaviour of the code generated by Stateflow but no official
validation from MathWorks is available.
o Changes of the semantic of Stateflow description items; the semantic of
Stateflow textual descriptions is managed internally by MathWorks; if this
semantic will changes in future versions of Stateflow, the COMPLEX
generation tool must be modified accordingly.
Integration of the models UML/MARTE and Simulink/Stateflow
Although the COMPLEX design methodology integrates both the UML/MARTE and
Stateflow design branches, there is no integration of the two models. Their meta-models
are incompatible and require a considerable effort to adapt the Stateflow generators to
the CFAM code format defined by SCoPE+ (see section 5.2.7).
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 117
8 Conclusions
This deliverable has provided a first version of a system-level specification methodology (e.g.
methods, techniques and tools) based on two different MDA design entries using different
modelling languages, UML with MARTE profile and Matlab Stateflow, and suitable for
feeding the COMPLEX DSE flow.
The presented specification methodology accomplishes two important requirements for
nowadays development of embedded systems:
Managing the complexity of the development of real-time embedded systems,
separating the different concerns in model views. In this way, system designers focus
their attention in one design aspect instead of trying to master the whole system design.
Enabling an early assessment of the optimal implementation solution within a design
space, before tackling the implementation flow. The implementation solution is
expressed as a set of values for the parameters that describe the system (number of
processors, memory sizes), and also comprises the platform architecture, and the
allocation of application components to platform resources. The implementation
solution is within the bounds of the parameter ranges and allocations constraints defined
in the design space.
Regarding the UML/MARTE design entry, this methodology allows the system engineer to
perform the following activities:
Modelling the functional and non-functional properties of the application software by
means of the UML2 constructs and MARTE stereotypes. A component model has been
defined to describe the application as an assembling of components requiring and
providing services from/to other components.
Describing the system platform by means of MARTE stereotypes following a
component-based approach, which allows the system user to create libraries of
components and reuse them in other system models. The platform model includes both
HW and SW resources.
Modelling the system architecture as an assembly of instances of application and
platform components connected each other through UML ports.
Describing the allocation of system functions onto the platform resources by means of
MARTE stereotypes.
Adding design space parameters and rules in the system architecture so that the Design
Space Exploration (DSE) is enabled from the design entry.
Describing the stimuli environment so that the system can be excited during the
simulation and performance estimation analysis.
In order to decrease the complexity of designing embedded system, the methodology takes
into account the separation of the functional and non-functional aspects of the system. The
proposed separation of concerns is achieved by providing distinct system views to the
designer, each one for every relevant aspect:
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 118
Data model and Functional Views, centred on the data model and the functional aspects
of the system.
Communications and Concurrency View, centred on the non-functional aspects of the
system related to the application (i.e. concurrency, service deadlines).
Platform Description View, focused on the description of the platform resources, either
HW or SW.
Architectural View, describing both the application and platform architectures, and
providing the information about the architectural mapping of system functions onto
platform resources, as well as the DSE parameters and rules that will enable the DSE
cycle.
Verification View: devoted to the definition of the system stimuli environment. This
view represents the external systems interacting with the system, defines the stimuli for
the verification of the system functions and specifies a set of test procedures to evaluate
the system power and timing characteristics.
The methodology has been developed for its suitability for the code generation steps,
necessary for the fed design process; specifically, for the generation of code feeding the
COMPLEX DSE flow (CFAM and XMLD generators). Moreover, the methodology has also
considered the generation of the IP-XACT specification by means of including specific
activities in the design process, and identifying the necessary tools to produce it.
Regarding the Stateflow design entry, the methodology allows the system engineer to perform
the following activities:
Model the functional aspects of the application by means of the Stateflow charts that
represent state finite machines.
Transforming the Stateflow charts into an executable SystemC model.
Transforming the Stateflow charts into a ANSI C/C++ code customized to the target
microcontroller (HW platform and RTOS) by means of an scripting language.
Besides, the methodology has identified the toolset required for the design process, including
both UML/MARTE and Stateflow design entries.
Therefore, this methodology accomplishes with all the objectives described in the DoW (see
reference [1]), but also contributes with innovative solutions on the development of real-time
embedded systems, like the component model approach for both the application and system
platform, the separation of concerns, and the inclusion of the design exploration loop at very
early stages of the COMPLEX design entry.
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 119
9 References
[1] "Description of Work". COMPLEX – COdesign and power Management in Platform-
based design-space EXploration, FP7-ICT-2009- 4 (247999), 2009.
[2] “Definition of application, stimuli and platform specification, and definition of tool
interfaces”. COMPLEX – COdesign and power Management in Platform-based design-
space EXploration, D1.2.1, version 1.1.1
[3] “MDA Guide”. (OMG/2003-06-12), version 1.0.1.
[4] “UML2 infrastructure”. (OMG/2009-02-04), version 2.3.
[5] “UML2 superstructure”. (OMG/2009-02-02), version 2.3.
[6] “MOF Model to Text Transformation Language (MOFM2T)”. (OMG/2008-01),
version 1.0.
[7] “MARTE specification”. (OMG/2009-11-02), version 1.0.
[8] “OCL Specification). (OMG/ 2006-05-01), version 2.0.
[9] “SystemC Core Language”. (OSCI/2007-03-14), version 2.2.
[10] Schema WG of The SPIRIT Consortium. “IP-XACT v1.4: A specification for XML
meta-data and tool interfaces”. March, 12th
. 2008.
[11] Papyrus MDT tool (http://www.eclipse.org/modeling/mdt/papyrus/ ), version 0.7.0
[12] MARTE profile for Papyrus (http://www.papyrusuml.org/), version 1.0
[13] Eclipse framework (http://www.eclipse.org/), version 3.6 (Helios)
[14] Acceleo (http://www.acceleo.org/), version 3.0.0
[15] User Manual for M3P ScoPE Plug-in: XML Management for DSE
(http://www.teisa.unican.es/gim/en/scope/source.html ), version 1.0.5
[16] Multicube Explorer User Manual
(http://home.dei.polimi.it/zaccaria/multicube_explorer_v1/Documentation.html ), version
1.1
[17] Magillem Generator Studio, http://www.magillem.com/eda/
[18] S. Taha, A. Radermacher, S. Gerard Jean-Luc Dekeeyser. MARTE: UML-based
Hardware Design from Modeling to Simulation. FDL‟2007, Barcelona, Spain, September
2007.
[19] P. Boulet, P. Marquet, E. Piel, J. Taillard. “Repetitive Allocation Modelling with
MARTE”. In Proceedings of FDL‟07. Barcelona, Sept. 2007.
[20] E. Piel, R.B.Atitallah, P.Marquet, S.Meftali, S. Niar, A. Etien, J.L.Dekeyser, P.
Boulet. “Gaspard2: from MARTE to SystemC Simulation. In Design, Automation and
Test in Europe (DATE 08), Munich, Germany, March 2008.
[21] J.L.Dekeyser, A. Gamatié, A. Etien, R.B.Atitallah, P. Boulet. "Using the UML Profile
for MARTE to MPSoC Co-Design". In First International Conference on Embedded
Systems & Critical Applications (ICESCA'08), Tunis, Tunisia, May 2008.
[22] J. Vidal, F. de Lamotte, G. Gogniat, P. Soulard, J.P. Diguet. “A Code-Design
Approach for Embedded System Modeling and Code Generation with UML and
MARTE”. In Design, Automation & Test in Europe Conference, DATE‟09. Dresden.
March, 2009.
[23] D. Aulagier, A. Koudri, S. Lecomte, P. Soulard, J.Champeau, J.Vidal, G.Perrouin,
P.Leray. “SoC/SoPC development using MDD and MARTE profile”. In Model Driven
Engineering for Distributed Real-time Embedded Systems ISTE (Ed.) (2009).
COMPLEX/GMV/P/D2.1.1/1.1 Public
System specification methodology using MARTE and Stateflow
Page 120
[24] A. W. Liehr, H. S. Rolfs, K. J. Buchenrieder, and U. Nageldinger. “Generating
MARTE Allocation Models from Activity Threads” in “Languages for Embedded
Systems and their Applications”. Lecture Notes in Electrical Engineering, 2009, Volume
36, Part I, 43-56.
[25] A. W. Liehr, H. S. Rolfs, K. J. Buchenrieder, and U. Nageldinger. “Visual Feedback
for Design-Space Exploration with UML MARTE“.International Conference on
Innovations in Information Technology, 2008. IIT 2008. Dec., 2009.
[26] M.Mura, L.G.Murillo, M.Prevostini. “Model-based Design Space Exploration for
RTES with SysML and MARTE”. In proceedings of the Forum of Specification and
Design Languages 2008, FDL‟08. Stuttgart, Germany. 2008.
[27] P. Ulbrich, C. Elsner†, M. Hoffmann, R. Schmid, W. Schröder-Preikschat ”Using
MARTE in Code-centric Real-time Projects Providing Evolution Support”. In
Proceedings of DATE, 2010. March, 2010. Dresden, Germany. Available online in Aug.
2010 in http://www4.informatik.uni-
erlangen.de/Publications/2010/ulbrich_etal_date2010_mbed.pdf.
[28] P. Peñil, H. Posadas, E.Villar. “Formal Modeling for UML-MARTE Concurrency
Resources”. UML&AADL. 15th IEEE Int. Conf. on Engineering of Complex Computer
Systems. Oxford. March, 2010.
[29] P. Andersson, M. Host. “UML and SystemC- A comparison and Mapping Rules for
Automatic Code Generation”. In Embedded Systems Specification and Design Languages.
Lecture Notes in electrical Engineering, 2008, V10, III, pags. 199-209.
[30] P. Peñil, J. Medina, H. Posadas, E. Villar. “Generating heterogeneous executable
specifications in SystemC from UML/MARTE models”. Innovations in System Software
Engineering (2010) 6:65–71. DOI 10.1007/s11334-009-0105-4.
[31] P.Peñil, F.Herrera, and E.Villar. “Formal Foundations for MARTE-SystemC
Interoperability”. In Proc. of FDL‟2010. Southampton, U.K, Sept. 2010.
[32] IBM. “Rational Rhapsody”. http://www-01.ibm.com/software/awdtools/rhapsody/
[33] SODIUS, “MDWorkbench platform”. http://www.mdworkbench.com
[34] A. Jantsch and I. Sander. Models of computation and languages for embedded system
design. IEE Proceedings on Computers and Digital Techniques, 152(2):114-129, March
2005. Special issue on Embedded Microelectronic Systems.
[35] MOF Model to Text Transformation Language (MOFM2T)
(http://www.omg.org/spec/MOFM2T/1.0/ ), version1.0
[36] “Model 2 Text project of Eclipse”. http://www.eclipse.org/modeling/m2t/
[37] MathWorks, “Stateflow® and Stateflow® CoderTM 7 User‟s Guide”, 2010.
[38] Harel, D. “Statecharts: A Visual Formalism for Complex Systems.” Science of
Computer Programming. Vol. 8, 1987, pp. 231–274.
[39] Hatley, D. J. and I. A. Pirbhai. Strategies for Real-Time System Specification. New
York, NY: Dorset House Publishing, 1988.
[40] MathWorks, “Code generation tools”, http://www.mathworks.com
[41] Kevin Camera, “SF2VHD: A Stateflow to VHDL Translator”, M.Sc. Thesis,
University of California, Berkeley, 2001
[42] F. Herrera, H.Posadas, F.Ferrero. Concurrent Functional Application Modelling
(CFAM) API. Dec., 2010. Internal Document of the COMPLEX project.