codesign and power management in platform- based design ... d2.1.1... · l. lavagno (polito), d....

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

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”



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



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



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



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



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.



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



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.



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



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.



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.



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



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.



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



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.



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,



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:



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.



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



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


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



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


Analysis

<<profile>>

SAM

<<profile>>

PAM

<<profile>>

CQAM

<<profile>>

MARTE_library

<<profile>>

RSM

<<profile>>

VSL

Figure 4-2: MARTE packages for platform modelling in COMPLEX



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:



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:



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



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



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



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



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



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.



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



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



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.



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 Platform Description Model (PIM), including a description of all platform

components, either HW or SW, that form part of the system platform.



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.


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



Architecture Modelling


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


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.



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.


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


(REQ)

Input Stimuli Model

Model the behaviour

of the external subsystems

Create stimuli scenarios

Figure 5-6: Input stimuli modelling



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.


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



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.



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.



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:



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



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:



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.






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.







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.



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


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



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.





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.



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:


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:


Lifeline

(associated to a class

instance)

N/A N/A

Execution specification Time

Message HLAM RtService


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.




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.


o srPoolPolicy: PoolMgtPolicyKind

Defines the pool management policy. It can take one of the three

following values:



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.


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.


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.


o operationalMode: Behaviour

This attribute consists of a behaviour associated to the RtUnit

representing its operational modes.



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.


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.


application defined using MARTE must be specified.)

ClientServerPort

o specificationKind: PortSpecificationKind



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.


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.




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.



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.




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.


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.



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.



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



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


UML2 Diagram

elements

MARTE profiles MARTE stereotypes

Component N/A or

DRM:HRM:Logical

HwResource

HwComputingResource,


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


HwMedia

HwBus

HwBridge


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



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.


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,



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.



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.



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:



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


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.



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


(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:


Component Allocation Allocated

Abstraction dependency Allocation Allocate



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.



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.


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.


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.



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.



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:



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



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



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.



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



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.



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



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.



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.



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.





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



Figure 5-15: Interaction use example based on previous figure

Figure 5-16: StateInvariant example



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



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



(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



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




outputs, and states or state-transition charts (bubble charts).











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.



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.





5.3.3 Transforming Stateflow descriptions to target processor code










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



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.



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



Design Branch


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.



The following table summarizes the host environment configuration where the COMPLEX

design entry was tested in

Table 6-2: Host environment configuration

Design Branch


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



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);



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




outputs, or states or state-transition charts (bubble charts).











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



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.



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.



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



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:


the functional description of the system by means of the

system components which implement system functions

and the interfaces they expose to other components.



Extensions:

UML Package.

Generalizations:

None.

Attributes:

None.

Constraints:


model.




CommsConcurrencyView Description:


the system components which define the non-functional

proprieties of the system functions (i.e. service deadlines,

interface types, etc.)



Extensions:

UML Package.

Generalizations:

None.

Attributes:

None.

Constraints:


model.

PlatformView Description:


the system components which model the system

platform, both HW and SW.



Extensions:

UML Package.

Generalizations:

None.

Attributes:

None.

Constraints:


model.




ArchitecturalView Description:


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.



Extensions:

UML Package.

Generalizations:

None.

Attributes:

None.

Constraints:


model.

VerificationView Description:


the description of the stimuli environment that will excite

the system during the simulation and performance

analysis.



Extensions:

UML Package.

Generalizations:

None.

Attributes:

None.

Constraints:


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.



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.


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_]*




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




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



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.



Table 6-6: COMPLEX Verification profile stereotypes


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.



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



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.



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



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



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:



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.



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



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:



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



6.4.6 SF2HIF










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.





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.


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:



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.



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.



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.



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



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



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:



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.



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

http://www.papyrusuml.org/

http://www.eclipse.org/

http://www.acceleo.org/

http://www.teisa.unican.es/gim/en/scope/source.html

http://home.dei.polimi.it/zaccaria/multicube_explorer_v1/Documentation.html

http://www.magillem.com/eda/



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

http://www4.informatik.uni-erlangen.de/Publications/2010/ulbrich_etal_date2010_mbed.pdf

http://www4.informatik.uni-erlangen.de/Publications/2010/ulbrich_etal_date2010_mbed.pdf

http://www.mdworkbench.com/

http://www.omg.org/spec/MOFM2T/1.0/

http://www.eclipse.org/modeling/m2t/

http://www.mathworks.com/

codesign and power management in platform- based design ... d2.1.1... · l. lavagno (polito), d....

Documents