See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/221249824

First experiments using the UML profile for MARTE

Conference Paper · May 2008

DOI: 10.1109/ISORC.2008.36 · Source: DBLP

CITATIONS READS
80 1,110

5 authors, including:

Charles André Sébastien Gérard

National Institute for Research in Computer Science and Control Atomic Energy and Alternative Energies Commission
43 PUBLICATIONS   700 CITATIONS    242 PUBLICATIONS   2,887 CITATIONS   

SEE PROFILE SEE PROFILE

François Terrier
Atomic Energy and Alternative Energies Commission
117 PUBLICATIONS   1,109 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Modelling and analysis of real-time and embedded systems. View project

IP Protection For Models View project

All content following this page was uploaded by Sébastien Gérard on 13 March 2014.

The user has requested enhancement of the downloaded file.

 11th IEEE Symposium on Object Oriented Real-Time Distributed Computing (ISORC)
First experiments using the UML profile for MARTE
Sébastien Demathieu (1), Frédéric Thomas (2), Charles André (3) , Sébastien Gérard (2),
François Terrier (2)
(1) Thales Research & Technology, RD 128, 91767 Palaiseau Cedex
sebastien.demathieu@thalesgroup.com
(2) CEA LIST – Boîte 94 – Gif sur Yvette 91191 – France
{frederic.thomas, sebastien.gerard, francois.terrier} @ cea.fr
(3) I3S, Université de Nice Sophia Antipolis, CNRS/INRIA
charles.andre@unice.fr
Abstract
A UML profile for Modeling and Analysis of Real-
Time and Embedded systems (MARTE) has been
recently standardized by the OMG. This initiative
meets the needs of several Thales divisions (e.g.,
aerospace, land and joint and air systems), which
develop real-time and embedded systems. CEA LIST,
INRIA and Thales have been the main contributors to
the MARTE standard through the ProMARTE
consortium. To foster the deployment of MARTE in
Thales divisions, we have launched the development of
a case study related to a real-time and embedded
system using the MARTE adopted specification. As a
first step of this study, we make use of a fictive
system—the Josefil challenge—to evaluate whether the
profile is applicable to the Thales current systems and
software engineering practices. The purpose of this
paper is to report on this first stage and outline the
next scheduled activities.
1.Introduction
Thales is already using Model-Driven Engineering
(MDE) to support its systems and software engineering
processes. This approach has proven its benefits in
term of cost reduction and quality improvement. MDE-
related techniques are currently deployed in several
Thales divisions to support developments of large-
scale distributed and safety-critical systems. As Real-
Time and Embedded Systems (RTES) have a
significant position in Thales business, there is a strong
interest in deploying model-based techniques in this
segment as well. However, only a few attempts have
been made so far. The main reason is the lack of a
modeling language that can capture the essential
concepts of the real-time and embedded domain.
978-0-7695-3132-8/08 $25.00 © 2008 IEEE 50
DOI 10.1109/ISORC.2008.36
Authorized licensed use limited to: Baylor University. Downloaded on December 23, 2008 at 15:23 from IEEE Xplore. Restrictions apply.
The Object Management Group (OMG) promotes,
among other technologies, a general-purpose modeling
language named the Unified Modeling Language [1].
Its latest release, UML 2, is getting a large audience in
the software engineering community. Nowadays, UML
is also emerging as a possible solution for providing
benefits to embedded systems developers. While UML
can be used with all major object and component based
modeling methods, it appears that the language lacks
quantifiable notions of time, as well as the ability to
express non-functional properties and execution
platforms. All these aspects are particular concerns to
real-time and embedded system designers and
developers.
The issue of how to add such capabilities to UML
has been addressed in different research and industrial
contexts, mostly by the definition of specific dedicated
UML profiles, such as [2][3][4][5]. A profile is a
powerful extension mechanism for UML; however,
most of these extensions, which cover a wide range of
applications, are proprietary and suffer a lack of
standardization. This misalignment onto the idea of a
standard language is very problematic since it
discourages and limits their industrial exploitation.
Standardization ensures definition of a common
framework for both notation and semantics related
concerns, while allowing dissemination of the best
modeling practices. Standards are also a cost effective
solution, since they foster tool interoperability and
lower overall training costs. Additionally, this helps to
manage the risks on tool evolution and maintenance,
reducing the dependency on one single tool.
In that context, the Object Management Group
(OMG) has encouraged proposals for standard UML
extensions dealing with real-time concerns such as
timing properties, as well as non-functional and
platforms aspects.
 SysML [6] has been recently adopted by the OMG conclusions on this experiment and drafts remaining
as a language to model complex systems, including ongoing work related to MARTE.
software, hardware, facilities, and process aspects.
Although SysML native capabilities to model RTES 2.The MARTE UML Profile
are far better than UML ones, some required features
such as strict timing modeling and real-time resource The MARTE specification consists of three main
management are poorly supported by SysML or are packages. The first package defines the foundational
completely missing. concepts used in the real-time and embedded domain.
Another OMG specification, targeting the real-time It provides basic model constructs for non-functional
and embedded domain, is the UML profile for properties, time and time-related concepts, allocation
Schedulability, Performance and Time (SPT) mechanisms and generic resources, including
specification [7]. It provides a straightforward concurrent resources. These foundational concepts are
annotation mechanism with a limited set of common then refined in two other packages to respectively
annotations to perform either schedulability analysis support modeling and analysis concerns of real-time
(e.g., rate monotonic analysis), or performance analysis embedded systems.
(e.g., queuing theory based analyses). Past experiences The second package addresses model-based design.
of the SPT profile have led to a number of significant It provides high-level model constructs to depict real-
suggestions for its improvement and consolidation. time embedded features of applications, but also for
Both synthesis documents [8] and [9] gather all raised enabling the description of detailed software and
issues. This includes new requirements for specifying hardware execution platforms.
both software and hardware aspects, alignment on The third package addresses model-based analysis.
UML 2, compliance with the Model Driven It provides a generic basis for quantitative analysis
Architecture (MDA) [10] for defining separately the sub-domains. This basis has been refined for both
platform the application and allocation models, or also schedulability and performance analysis.
modeling of additional non-functional aspects such as
power consumption or memory size. Part of these
issues was deemed too disruptive for a simple revision
of the current SPT profile of the OMG. Hence, the
OMG requested for a proposal of a new UML profile
for the Modeling and Analysis of Real-Time and
Embedded systems (MARTE) [11].
The submission work to the MARTE request for
proposal has been carried out by the ProMARTE
consortium. CEA-LIST, INRIA and Thales have been
the main contributors to this OMG consortium which
has federated tool vendors (e.g., ARTiSAN, IBM, No
Magic, Telelogic), industrials (e.g., Alcatel, France
Telecom, Lockheed Martin) and academic partners
(e.g., Carleton University, CMU SEI) interested in the Figure 1. Overview of the UML MARTE Profile
definition of a modeling standard to support the real-
time and embedded domain.
In that context, we have started a robotics case
3.Experimenting MARTE on a case study
study related to the development of real-time software
The MARTE specification is a language extension
systems using MARTE. We have used the Papyrus
to UML, hence it does not provide any methodology-
UML tool [12], which implements the OMG adopted
related hints for developing RTES. The next sections
specification, to create MARTE models of the robotics
do not then refer to a specific methodology, but are
system. The goal is to evaluate whether the profile is intended to illustrate the UML profile for MARTE
applicable to our current systems and software capabilities. This experiment report copes with: time
engineering practices. constraint modeling in a logical system decomposition,
The paper is then structured as follows: Section 2
hardware resources modeling and software resources
presents an overview of the MARTE profile; Section 3
modeling. We demonstrate those key features of the
discusses the experiment on a robotics case study
UML profile for MARTE considering the Josefil case
Josefil [12]; this section illustrates how key features of
as the system to design. Using a selected subset of
the MARTE profile have been used to specify real- diagrams, we illustrate how MARTE helped capturing
time behavior and to model hardware and software those essentials concepts of the real-time and
execution platforms; finally, this paper draws some embedded domain.

51

Authorized licensed use limited to: Baylor University. Downloaded on December 23, 2008 at 15:23 from IEEE Xplore. Restrictions apply.
 All the packages introduced in the MARTE 3.2.Logical system decomposition
specification have not been used in the context of this
case study. We focused on the design of the system In this section, we present a first logical
during this first stage. As a consequence, we have not decomposition of the case study, and demonstrate how
used the GQAM, SAM or PAM packages for analysis MARTE can be used to support system-level design.
purposes (either scheduling, performance or other kind We focus here on the specification of the robot, leaving
of quantitative analysis). In the design of our system, apart the control station. Taking into account the key
we realized that dealing with specific component requirements of the case study, we identify the system
models introduced in the real-time and embedded use cases then model use-case realizations as a series
domain was not a key concern and we did not need to of sequence diagrams and activity diagrams. Based on
use the extensions that are provided by the GCM these use case realizations, we identify consistent
package. Additionally, we preferred to use the group of functions, represented as UML classes in
modeling constructs of HRM and SRM for resource Figure 2. We define attributes, operations and
modeling rather than the more abstract GRM package. associations for these classes, thus providing a first
Finally, we did not use the RTEMoCC package. The definition of internal interfaces of the system. As
later provides interesting some features to model a depicted in the Figure 2, the robot architecture consists
real-time application at a high level of abstraction but it of five logical entities respectively dedicated to: the
brings in a novel approach to RTES design that we management of communications with the control
would like to study separately before introducing it in station (CommunicationLink), the LED control
our case study. (DisplayController), the control of the engine (Engine-
Controller), the computation of trajectories
3.1.The Josefil case study (TrajectoryController) and the system supervision
(Supervisor). The last logical entity manages the global
The Josefil case study consists in developing a state and behavior of the system. This structural model
robotics system following model-driven engineering is used in the rest of this paper to illustrate the key
practices. This application has been defined in the features of MARTE.
context of an academic challenge [12], the goal of
which was to provide a case study framework for
benchmarking different kinds of design approaches to
distributed real-time and embedded systems. We chose
this case study because it is fairly representative of
many problems encountered by systems and software
engineers when designing such systems.
The case study introduces a control system for an
exploration robot that carries out temperature
measurements in a hostile environment. It consists of a
robot—equipped with sensors—which communicates
Figure 2. Logical decomposition of the robot
with a remote control station through an Ethernet
subsystem
wireless link. During a mission, the robot has to follow
At this stage of the development, it is usual to
a route transmitted by the control station. The
identify end-to-end performance scenarios. They are
environment is made up of stationary objects that shall
often directly extracted from customer requirements
be avoided by the robot.
and may be used later on to assess the response times
The robot is also equipped with an engine and
of the system. In this context, engineers may need to
driving wheels. A microcontroller controls the speed
specify either the duration of a single processing or the
and calculates the absolute position of the robot. It also
duration related to the execution of an end-to-end flow.
manages the different sensors and activators.
Description of such information within the model may
Additionally, an embedded PC supervises the robot
be achieved by annotating UML 2 interaction
behavior and provides connection to the
diagrams.
microcontroller. In order to follow the execution of a
UML 2 defines constructs to express time-related
mission in real-time, the robot has a movie camera,
notions in a package called CommonBehaviors::
which returns frames displayed on a remote control
Communications::SimpleTime. These concepts
station used by a human operator. Finally, the control
provide a good basis to support the representation of
station provides the ability to transmit various
time events, instants and durations in UML 2.
instructions (e.g., to set the current speed or to indicate
However, it misses a more formal definition of the
alternative routes), which may be required for the
concept of time. Depending on the system to model
progression of the mission.
(whether it is distributed or not), the design approach

52

Authorized licensed use limited to: Baylor University. Downloaded on December 23, 2008 at 15:23 from IEEE Xplore. Restrictions apply.
and the abstraction level, one may deal with physical
time or logical time (discrete or continuous).
Moreover, the system may rely on one or several
clocks. All this information has a strong impact on the
diagram semantics and needs to be explicitly stated.
Another important point is the lack of constructs to
express complex time constraints in the UML2
SimpleTime package.
To overcome these issues, MARTE extends the
UML 2 SimpleTime package introducing stereotypes
that refine UML time events, time observations and
duration observations with explicit references to
clocks. In addition, let us note that a system may have
one or several clocks and it is then also possible to
define clock constraints in order to either impose
dependencies or define relationships between the
clocks. A MARTE model library provides predefined
time units and clocks, such as idealClk. This ideal
clock is supposed to faithfully respect physical time
(i.e., with no skew or drift).
MARTE also provides a general-purpose
mechanism to express non-functional properties (NFP)
in UML models, and to specify constraints on these
properties. This mechanism relies on the possibility to
annotate UML diagrams with constraints stereotyped
as « nfpConstraint » and « timedConstraint ». We will
see later in this paper that this mechanism is applicable
to various non-functional properties (e.g., memory
size, network throughput or power consumption). We
focus here on how to express time-related properties. A
constraint stereotyped as « timedConstraint » has a
reference to a given clock (e.g., the ideal clock instance
of the MARTE library). The constraint body is a UML
ValueSpecification that may be defined using the
textual Value Specification Language (VSL)
introduced with the MARTE profile. The core of VSL
reuses some OCL constructs to define complex
expressions. These constructs are completed by an
extensible mechanism to reference structured data
types (that may represent physical quantities),
operators, as well as time instant observations or time
duration observations declared in different diagrams.
VSL provides numerous constructs that can be applied
on these observations, including for example the ability
to specify an occurrence index (for observations of
repetitive behaviors), to relate an observation to a
conditional expression, or to express time-related
notions such as jitters of periodic behaviors.
Figure 3 shows a scenario that exposes the
exchanged messages when the control station sends a
command to update the route followed by the robot. It
contains a UML time observation in order to relate to
the send event of the receive message. We apply the
MARTE « timedInstantObservation » stereotype to
this time observation, in order to reference the ideal
clock. In a similar way, we define a UML time
observation that relates to the receive event of the
53
Authorized licensed use limited to: Baylor University. Downloaded on December 23, 2008 at 15:23 from IEEE Xplore. Restrictions apply.
control message. We apply again the previous
stereotype to refer the same ideal clock. Our purpose is
then now to express that the time elapsed from the
instant when the control station sends the command
until the engine actually process the order shall not
take more than one second. For that purpose, we define
a time constraint, the body of which is defined in the
VSL language. In a VSL expression, we indicate that
the duration between the two previously defined
observations: receiveControl and sendCommand shall
not exceed 1000 ms. The time dimension
(NFP_Duration) along with a collection of time units is
defined in the MARTE model library. The constraint
body can be parsed and typed as an inequality between
two durations.
Note that, the notation defined in the UML
SimpleTime lacks a concrete support in terms of
tooling. This notation, quite natural when sketching
diagrams on a whiteboard, is not implemented in any
commercial tool on the market. Fortunately, it is
supported in the Papyrus [12] open source
implementation of MARTE. This has been one of the
key factors for choosing Papyrus in our case study.
Figure 3. Example of an end-to-end performance
scenario annotated with MARTE
Based on the different use case realizations, we are
able to reify the behavior of the entities identified
during the system architecture design illustrated in
Figure 2.
State machines are often used in the real-time and
embedded domain. They allow the description of a
system behavior in terms of states and transitions
between these states. UML introduces behavioral state
machines—an object-based variant of Harel’s state-
charts—and protocol state machines. In UML state
machines, transitions are triggered by events, which
can be of various kinds. CallEvent, ChangeEvent and
SignalEvent are used in event-triggered transitions
while TimeEvent provides support for time-triggered
transitions. An issue with UML time events (defined in
SimpleTime) is their very limited semantics. Among
others, they do neither explicitly relate to a clock, nor
define a language for the value specifications that can
be used along with their when property. Another
important limitation in UML is that it is not possible to
specify the duration of a behavior, either the duration
of the state machine itself or the duration of behaviors
attached to states.
MARTE introduces mainly two time-related
concepts that can be used to improve the usage of the
UML behaviors, such as state machines, for developing
real-time systems: timed processing and timed events.
The « timedProcessing » stereotype enables modelers
to specify duration for a behavior (or a message
transfer defined inside an interaction). The stereotype
references a clock. It can also reference events,
triggered when a behavior or processing starts and
ends. The duration can be specified using the VSL
language, which supports time expressions.
The « timedEvent » stereotype extends the
SimpleTime::TimeEvent meta-class of UML and allows
one to characterize the logical or physical clock on
which a time event relates. Provided that a logical
clock is used, MARTE introduces the means to specify
synchronous transitions in state machines, like in
SyncCharts [14] for instance. MARTE also provides
means to specify the value of the when property
defined in TimeEvent using the VSL language. The
unit used in such a VSL expression shall be compatible
with the clock the time event is referring to (e.g., one
would expect a physical clock to measure time in terms
of seconds). Finally, MARTE provides support for
repeated occurrences of timed events.
Figure 4 depicts a state machine that provides a
simplified view of the Supervisor behavior. The
Supervisor has three states: Ready, Update and
Blocked. The nominal supervisor state is the Ready
state. Periodically, it enters in the Update state for
updating the robot sensors values. The sensors values
update (i.e., updateRobotState activity) has to be done
with a period of 50 ms and lasts 2 ms. Then it returns
in a Ready state. If a sensor detects an obstacle, the
Supervisor enters the Blocked state. From there, the
operator has 50 seconds to enter a new route. If no
route is received within this time frame, then a time out
is triggered.
First, we apply the « timedProcessing » stereotype
on the state machine itself in order this latter may
reference the ideal clock. Then, we apply the
« timedProcessing » on the updateRobotState activity
and reference the ideal clock. We indicate that the
duration of this time processing is (2, ms) (the duration
stereotype attribute is not shown in the diagram).
Finally, we apply the « timedEvent » stereotype on the
UML timed events that triggers the obstacleTimeout
and the updateTimeOut transitions and we make sure
that these events refer to the same ideal clock. All the
54
Authorized licensed use limited to: Baylor University. Downloaded on December 23, 2008 at 15:23 from IEEE Xplore. Restrictions apply.
elements of the state machine have the same time
reference. We indicate that the values of the when
property are respectively “(50, ms)” and “(50, s)”.
Figure 4. Example of UML state machine annotated
with MARTE time-related information
3.3.Software Resource modeling
As depicted in Figure 4, the sensors values have to
be updated every 50 ms. To support this periodic task,
a POSIX RTOS is embedded in the embeddedPC.
Hence, the updateRobotState behavior is allocated onto
a periodic task of that system.
Within MARTE, the SRM framework provides
modeling artifacts to describe software execution
platform modeling. The SRM profile provides a broad
range of modeling capabilities covering main
multitasking framework such as dedicated real-time
language libraries (e.g., task in ADA 95) and real-time
operating systems. The main advantage of using the
SRM profile is that this is not a new RTE API but
instead a standard framework for modeling existing
multitasking platform APIs with a low-level of details.
This profile supplies modelers with four main sub-
profiles: one to specialize the generic resource concept
to software domain, the second to describe
concurrency support (e.g., tasks, interrupts and alarms),
the third to detail interactions between concurrent
resources (e.g., messaging, synchronization and mutual
exclusion mechanisms) and the fourth to depict the
software resource brokers (e.g., driver and scheduler).
A more detailed explanation of the SRM profile is
available in [11] and [15]. Hence, the design of a
multitasking model with SRM is managed through
both following stages: platform providers or
methodologist providers describe their software
multitasking platform as a UML model library which is
then annotated with SRM. This model library includes
resources and resource instances provided by the
execution platform. Then, the concepts introduced
within the specific model library have to be used to
describe the multitasking application (e.g., with a
library import). According to that point of view, one
appendix of MARTE contains two examples of model
libraries, for ARINC-653 [16] and OSEK/VDX [17].
Figure 5 shows another example which is an
excerpt from the POSIX Std 1003.1 [18] API denoted
with MARTE. This figure contains example usages of
SRM, stereotyped in order to clarify the semantics of
the RTOS concepts denoted in the model library. For
example, the Process class is stereotyped as a
MemoryPartition (i.e., a specific address space), and
the Pthread class is stereotyped as a kind of
SwSchedulableResource.
Finally, the attributes are referenced by the SRM
stereotypes to clarify their taxonomies. For example,
the attribute named priority is referenced as a
priorityElements in the SwSchedulableResource
stereotype. Thus, both users and tools know
automatically how to fill the priority of a POSIX task
(i.e., they have to assign a value to the attribute named
priority).
Figure 5. A part of the POSIX library
Among resources (i.e., types and typed elements),
multitasking platforms provide also many data types.
Specific data types, such as the PriorityDataType, have
been described with the MARTE::VSL language as a
bounded type. This specific date-type ensures that the
priority values take their value out of a well-identified
subset of integers (1..255, according to Figure 6).
55
Authorized licensed use limited to: Baylor University. Downloaded on December 23, 2008 at 15:23 from IEEE Xplore. Restrictions apply.
Figure 6. A DataType to express POSIX priority
A specific model of the software platform is
instantiated from the previous library. Figure 7
represents the structural design of the periodic task,
which computes the trajectory, with a POSIX
programming interface (e.g., scheduling policy is
FIFO, priority is 1, period is 50 ms and the entryPoint
is the updateRobotState behavior).
Figure 7 . A periodic task to update Josefil states
3.4. Hardware Resource modeling
Besides software resources, MARTE allows us to
model hardware resources. Due to its general purpose,
UML lacks certain key native artifacts for describing
concrete and precise hardware RTE execution
platform. The UML profile for MARTE fills this lack
with two sub profiles: a generic resource modeling
(GRM) profile and a hardware resource modeling
profile (HRM). Both can be used to model hardware
platform. However, HRM better fits our case study to
describe efficiently the Josefil hardware execution
platforms. For example, the HRM profile allows
modeling directly and explicitly memory size,
processing clock frequency.
The HRM is composed of two views, a logical view
that classifies hardware resources depending on their
functional properties, and a physical view that
concentrates on their physical nature. Both are
specializations of the general model. The logical and
physical views are complementary. They provide two
different abstractions of hardware which could be
simply merged. A previous paper [19] describes the
Hardware Resource Model profile and proposes an
appropriate methodology to apply it during the
hardware design process. The design of a hardware
model with HRM may be managed through both
following stages: platform providers or methodologist
providers describe their hardware execution platform
as a UML model library which is then annotated with
HRM. Finally, the concepts introduced within the
specific model library have to be used to describe
hardware architecture. This model can be also
annotated with HRM.
Figure 8 illustrates a functional view of the Josefil
hardware execution platform. We have described
specific hardware resources such as ROM, RAM and
AMD processor in a library which is then imported to
describe a composite diagram of the Josefil
architecture. This model is then annotated with specific
Josefil hardware specification such as the RAM and
the ROM memory sizes. For example in Figure 8, we
give the sizes of the embeddedPC RAM (i.e. 64 MB)
and ROM (32MB). In the same way, we provide the
frequency of the AMD processor: 400 MHz. The Value
Specification Language, introduced previously, is used
again to specify the values related to the stereotype
attributes.
Allocation of the software elements presented in
section 3.3 to this abstract representation of a hardware
platform can be done in using allocation relationships.
MARTE introduces this notion of allocation, which
comprises spatial distribution and temporal scheduling
aspects, between application elements and execution
resource elements. Due to size limitation, this last part
is not detailed in this paper.
Figure 8. An example of the Josefil hardware
execution platform modeling
4.Experiment feedback
Using MARTE to design the Josefil case study has
provided significant benefits, compared to previous
UML-based experiments. MARTE defines standard
constructs to express non-functional properties, time-
related constraints and to describe execution platforms
(software and hardware). Those modeling artifacts are
essential concepts when designing real-time and
embedded systems. In the current practices, this
information is captured in the requirements of a
56
Authorized licensed use limited to: Baylor University. Downloaded on December 23, 2008 at 15:23 from IEEE Xplore. Restrictions apply.
system, usually described in natural language.
However, it cannot not be formalized in the design
models that satisfy the requirements, as supporting
constructs are missing. MARTE provides solutions to
overcome this limitation and to enable the application
of model-driven engineering techniques to the real-
time and embedded domain (e.g., platform-specific
code generation, model-based analysis.)
The VSL textual language to express non-
functional properties and time expressions is a major
feature MARTE. This feature is definitely missing in
UML. It now allows engineers to define values
(including expressions) with units, related meta-data,
on constraints and stereotype attributes.
RTOS API modeling with UML was already
possible without using MARTE::SRM and
MARTE::VSL profiles. Nevertheless, those profiles
alleviate the processing of such description by
automatic tools (e.g., code generator, model
transformer). One interest in SRM is that we could use
the same profile for describing proprietary and
commercial software multitasking platforms. We have
described part of the POSIX platform in that case
study, but we might have also described proprietary
platforms or middleware deployments.
The MARTE::HRM constructs enables abstract
representations of hardware platforms in UML,
providing the means to characterize these platforms
with non-functional properties, with the end goal to
tool up the deployment of software elements.
This experiment has also allowed us to identify
issues in the adopted specification of MARTE. Most of
these issues imply minor evolutions or enhancements
of the specification. They did not prevent us from
completing our case study.
We found small inconsistencies in the grammar and
the metamodel of the VSL language. Additionally, we
realized that missing concepts would be useful in the
language (e.g. sequences, derivatives), to provide a
comprehensive support to systems engineering.
We also wondered about the semantics of resource-
related stereotypes on instances and classifiers, as well
as their use in class diagrams and composite structure
diagrams. We suggested that a more detailed
explanation of these semantics is given in the
specification.
Finally, we identified minor inconsistencies in the
resource modeling chapters of MARTE. For instance,
we realized that a periodic schedulable resource has no
period property in the GRM profile.
We followed the OMG process to report these
issues to the MARTE Finalization Task Force that is
working on the evolutions of the standard. The task
force will take care of all these issues to complete a
fully finalized document during 2008.
 5.Conclusion and Future Work
In this paper, we presented a first case study on
modeling a RTES using MARTE. We discussed the
details of the experiment and illustrated how key
features of the MARTE profile have been used to
specify real-time behavior and to design hardware and
software execution platforms.
Based on this first experiment, we have started
another case study on a “real world” avionics system,
in the context of a demonstrator for the Usine
Logicielle project [20]. A key challenge for Thales is
to enable early validation of a system design before the
integration stages. Quantitative analysis provides
interesting solutions (such as scheduling or
performance analysis, either by the means of static
analysis or simulation). However, analysis tools are not
fully exploited today because they are not well enough
integrated in the development process. Using a model-
based approach along with quantitative analysis
techniques promises to achieve better results, as
engineers do not have to extract analysis input from
their design model, and then to deal with dedicated
formalisms. The MARTE SAM and PAM profiles
provide a specific support for these concerns in UML.
We plan to exploit these features to validate the real-
time behavior of our systems in the next stage of our
experiments of MARTE.
Model-based design using UML and SysML has
proven its benefits to address System Engineering
practices [21]. It is now a technology deployed on
operational programs in Thales, in the domain of large-
scale distributed systems. By the means of supporting
tools, the MARTE profile promises to foster the
deployment of model-driven engineering in another
key sector for Thales: the real-time and embedded
market.
6.Acknowlegment
The work presented here is partially carried out
within the System@tic competitiveness cluster project
Usine Logicielle.
The authors do thank S. Taha for its valuable
contribution to the hardware model of that case study.
7.References
[1] OMG. Unified Modeling Language : Superstructure (version
2.1.1) Object Management Group, Inc., Needham, MA 02494, Feb.
2007. OMG document number: formal/2007-02-05
[2] CEA, I-Logix, Uppsala, OFFIS, PSA, MECEL, ICOM, UML
based methodology for real time embedded systems, version 1.0,
April 2003, Project IST 10069 AIT-WOODDES.
[3] R.Ben Atitallah et al., Gaspard2 UML profile documentation,
INRIA technical report RT-0342, http://hal.inria.fr/inria-
00171137/fr/
57
Authorized
View publication stats licensed use limited to: Baylor University. Downloaded on December 23, 2008 at 15:23 from IEEE Xplore. Restrictions apply.
[4] S. Graf, I. Ober, and I. Ober. A real-time profile for UML.
STTT, Software Tools for Technology Transfer, 8(2):113–127, April
2006
[5] L. Apvrille, J.-P. Courtiat, C. Lohr, P de Saqui-Sannes, A Real-
Time UML Profile Supported by a Formal Validation Toolkit, IEEE
Transactions on Software Engineering, Vol 30, N° 7, pp 473-487,
July 2004
[6] OMG. Systems Modeling Language (SysML) Specification.
Object Management Group, Inc., Needham, MA 02494, May 2006.
OMG document number: ptc/06-05-04
[7] OMG. UML Profile for Schedulability, Performance, and Time
Specification. Object Management Group, Inc., Needham, MA
02494, January 2005. OMG document number: formal/05-01-02
(v1.1)
[8] Object Management Group: Pending Issues sent to the OMG
Finalization Task Force: UML Schedulability, Performance and
Time profile.
[9] Gérard S. (edited by): Report on SIVOES’2004-SPT Workshop
on the usage of the UML profile for Scheduling, Performance and
Time Mai 25th, 2004, Toronto, Canada.
[10] OMG. MDA Guide (version 1.0.1) Object Management Group,
Inc., Needham, MA 02494, June. 2003. OMG document number:
omg/2003-06-01
[11] OMG. A UML Profile for MARTE (version beta 1) Object
Management Group, Inc., Needham, MA 02494, August 2007. OMG
document number: ptc/07-08-04
[12] Papyrus. Open Source Tool for Graphical UML 2 Modeling.
http: //www.papyrusuml.org
[13] Josefil. Challenge, http://www.ensieta.fr/mda/JOSEFIL
[14] André C. Representation and Analysis of Reactive Behaviors:
A Synchronous Approach. CESA’96, IEEE-SMC, Computational
Engineering in Systems Applications, pp 19-29, Lille (F), July, 1996
[15] Thomas F., Gérard S., Delatour J., Terrier F., « Software Real-
Time Resource Modeling », Forum on Specification and Design
Languages (FDL) 2007, ECSI, Barcelona, Spain, september 2007,
p.231-236.
[16] ARINC The Airlines electronic engineering committee,
Avionics Application Software Standard Interface, ARINC
Specification 653-1, Aeronautical radio, INC., Annapolis, Maryland,
USA, October 2003
[17] OSEK The OSEK/VDX Group, OSEK/VDX OS specification,
Version 2.2.3, http://portal.osek-vdx.org/files/pdf/specs/os223.pdf,
2005
[18] POSIX The Open Group Base Specifications, Portable
Operating System Interface (POSIX), ANSI/IEEE Std 1003.1, 2004
[19] Taha S., Radermacher A., Gerard S., Dekeyzer J-L. « An Open
Framlework for Hardware Detailed Modeling”, SIES’07 :
Proceedings of the IEEE Second International Symposium on
Industrial Embedded Systems, IEEE Computer Society, Lisbon,
Portugal, 2007, p. 118-125.
[20] System@tic competitiveness cluster project: Usine logicielle.
http://www.usine-logicielle.org
[21] Normand V., Exertier D., MDSysE: a Model-Driven Systems
Engineering Approach at Thales, INCOSE Mid-Atlantic Researchers
Conference, MARC 2004 (Baltimore, USA).