MARTE A New Standard For Modeling and An

MARTE:
A New Standard for Modeling and Analysis

of Real-Time and Embedded Systems
Dr. Sébastien Gérard

(CEA LIST, France, sebastien.gerard[at]cea.fr)
Dr. Julio Medina

(CEA LIST, France, julio.medina[at]cea.fr)
Pr. Dorina Petriu

(Carleton University, Canada, petriu[at]sce.carleton.ca)
(with the contributions of: Huascar Espinoza,

Frédéric Thomas and Safouan Taha)
Agenda
09:00 am to 10:15 am
Introduction to MDD for RT/E systems
MARTE foundations
10:15 am to 10:45 am: Break
10:45 am to 12:00 am
High-level modeling constructs
Detailed software and hardware platforms modeling
13:00 pm to 14:30 pm: Lunch
14:30 pm to 15:00 pm
Introduction to model-based RTE analysis
15:00 pm to 15:45 pm
Model-based schedulability analysis
15:45 pm to 16:15 pm: Break
16:15 pm to 17:00 pm
Model-based performance analysis
17:00 pm to 17:30 pm
Conclusions and perspectives about MARTE
/ MARTE Tutorial 2
Models in Traditional Engineering
Probably as old as engineering
Extracted from B. Selic presentation during Summer School

MDD For DRES 2004 (Brest, September 2004)
/ MARTE Tutorial 3
Inspired from B. Selic presentation during Summer School
What is a Model in MDD MDD For DRES 2004 (Brest, September 2004)
One definition
A reduced/abstract representation of some system that highlights the
properties of interest from a given viewpoint.
The viewpoint defines concern, scope and detail level of the model.
Modeled system Functional model
/ MARTE Tutorial 4
Why Model Driven Engineering is Needed?
To deal with complexity of systems development
Abstract a problem to focus on some particular points of interest
Î improve understandability of a problem
Possible set of nearly independent views of a model
Separation of concerns (e.g. “Aspect Oriented Modeling”)
Iterative modeling may be expressed at different level of fidelity
To minimize development risks

Through analysis and experimentation performed earlier in the design cycle
Enable to investigate and compare alternative solutions
To improve communication ...

... to foster information sharing and reuse!
A model is often best suited than a long speech !
To focus on specific domain expertise while developing software system

Domain Specific Language
/ MARTE Tutorial 5
Characteristics of Useful Models

Abstract
Emphasize important aspects while removing irrelevant ones
Understandable
Expressed in a form that is readily understood by observers
Accurate
Faithfully represents the modeled system
Predictive
Can be used to answer questions about the modeled system
Inexpensive
Much cheaper to construct and study than the modeled system
To be useful, engineering models must satisfy all of

these characteristics!
(Extracted from B. Selic presentation during Summer School MDD For DRES 2004 (Brest, September 2004)
/ MARTE Tutorial 6
A Bit of Modern Software…
SC_MODULE(producer) SC_CTOR(consumer)
{ {
sc_outmaster<int> out1;
SC_SLAVE(accumulate, in1);
sc_in<bool> start; // kick-start
sum = 0; // initialize
void generate_data () };
{ SC_MODULE(top) // container
for(int i =0; i <10; i++) {
{
out1 =i ; //to invoke slave;}
} producer *A1;
SC_CTOR(producer) consumer *B1;
{ sc_link_mp<int> link1;
SC_METHOD(generate_data); SC_CTOR(top)
sensitive << start;}}; {
SC_MODULE(consumer)
A1 = new producer(“A1”);
{
sc_inslave<int> in1;
A1.out1(link1);
int sum; // state variable B1 = new consumer(“B1”);
void accumulate (){ B1.in1(link1);}};
sum += in1;
cout << “Sum = “ << sum << endl;}
Can you spot the architecture?
/ MARTE Tutorial 7
…and its UML Model
«sc_link_mp»
««sc_ctor»
sc_ctor»
sc_ctor» link1 ««sc_ctor»
sc_ctor»
sc_ctor»
producer
producer consumer
consumer
start
Can you spot the architecture?
/ MARTE Tutorial 8
Model Evolution: Refinement
void generate_data()
«sc_method»
«sc_method» producer {for (int i=0; i<10; i++)
producer {out1 = i;}}
producer out1
start
NotStarted
producer
start /generate_data( )
NotStarted Started
refine
start St1 St2
Started
Models can be refined continuously until the specification is complete

/ MARTE Tutorial 9
Model-Driven Style of Development (MDD)

An approach to software development in which the focus and
primary artifacts of development are models (as opposed to
programs)
Based on two time-proven methods
(1) ABSTRACTION (2) AUTOMATION
Realm of
modeling «sc_module»
sc_module» «sc_module»
sc_module»
languages Realm of tools
producer producer
start out1 start out1
SC_MODULE(producer) SC_MODULE(producer)
{sc_inslave<int> in1; {sc_inslave<int> in1;
int sum; // int sum; //
void accumulate (){ void accumulate (){
sum += in1; sum += in1;
cout << “Sum = “ << sum << cout << “Sum = “ << sum <<
endl;} endl;}
/ MARTE Tutorial 10
The Remarkable Thing About Software
Software has the rare property that it allows us

to directly evolve models into fully-fledged
implementations without changing the
engineering medium, tools, or methods!
This ensures perfect accuracy of software models,

since the model and the system that it models are
the same thing.
The software model may evolve into the system it was
modeling in a seamless process.
/ MARTE Tutorial 11
Two Kinds of OMG Modeling Languages

General Purpose Language (GPL)
E.g., UML2, SysML and CCM
Domain Specific Language
E.g. LwCCM, UML profile for SoC and MARTE
M2 Level
(Language Model Level)
GPL (General Purpose Language)
« reference »
« reference »
DSL (Domain Specific Language)
« profile » « profile »
UML profile for SoC UML profile MARTE
/ MARTE Tutorial 12
From UML 1.x to UML 2.0: Static Point of View
Component available at design-time

not only at implementation-time.
Hierarchical structure description of

classifiers: Ports and Parts. Modified to support new component
concept definition.
/ MARTE Tutorial 13
From UML 1.x to UML 2.0: Dynamic Point of View
Enhanced version of UML1.x statemachine:

Some new concepts and notation shortcuts (e.g. EntryPoint,
ExitPoint in composite state)
Protocol statemachines
UML2 Behavior Diagram Depict data/object/control flow diagrams:

Defined independently of statemachines
Petri-net like semantics
New
State Machine Diagram Activity Diagram Use Case Diagram

Modified
Previous “Collaboration
Sequence Diagram Communication Diagram diagrams” of UML1.x
Timing Diagram Interaction Overview Diagram

New New
Focus on system state changes regarding time

progression.
Î not very clearly defined!
Specialization of activity diagrams

Activity graph of SD or CD.
~ to High-level Message Sequence Chart of SDL
/ MARTE Tutorial 14
SysML: A UML Extension for System Engineering
Systems Modeling Language (www.omgsysml.org)

General-purpose systems modeling language
Specification, analysis, design, verification and validation of a broad range of
complex systems
Expected to be customized to model domain specific applications
E.g., Space, Automotive, Aerospace and Communications
UML-compatible systems modeling language

For supporting the exchange of information using standardized notations
and semantics that are understood in precise and consistent ways
Aligned with the ISO AP-233 standard
/ MARTE Tutorial 15
From UML 2.0 to SysML: Static Point of View
Minor extensions:
Shortcut for inheritance modeling.
Concepts of dependency group.
Reused of UML2 structured classes.

Provided more neutral concept for Define graphical notations for
any kind of domain (not only mathematical or logical constraints.
preponderant software systems).
/ MARTE Tutorial 16
From UML 2.0 to SysML: Dynamic Point of View
UML2 Behavior Diagram
New
State Machine Diagram Activity Diagram Use Case Diagram

Modified
Sequence Diagram Communication Diagram
Timing Diagram Interaction Overview Diagram

New New
Extensions of SysML activity diagram:

New types of object/data flow
(continuous, streaming or rate.)
Probability on edges of the graph.
/ MARTE Tutorial 17
Domain Specific Modeling Languages

Use of domain concepts as language constructs
E.g. concepts of “memory”, “task”, “bus”, instead of general ones
“components”, “nodes”, “classes”…
Criteria for success of a DSML
Technical validity and absence of ambiguities (MoCCs mapping)
Interoperability with other technologies (verification, code generation)
Domain appropriateness: syntax close to embedded systems ontology
Support: tools, documentation, capacity for evolution
But mainly… balance between expressive power and simplicity!
Main approaches to defining a DSML

Define a new language from scratch
Extend an existing language (add new language constructs)
Refine an existing language (specialize language constructs)
/ MARTE Tutorial 18
Which Technics for Making an OMG DSL?
Meta-models (using MOF)
For heavyweight extension mechanisms
Ensures full manipulation of MMs
Add, remove meta-classes and relationships inbetween
Profiles
For lightweight extension mechanisms
Adaptation of existing meta-models without modifications!
E.g., Only possible to add constraints
May extend any standard MM of the OMG
E.g., UML profiles and CWM profiles
Extracted from UML superstructure doc.:
Profiles vs. meta-models "There is no simple answer for when you
It may depend on: should create a new metamodel and
Scope of the extensions when you instead should create a new
Tooling constraints profile."
Engineer level of experiment/education
…
/ MARTE Tutorial 19
Profiling UML for a Domain

Advantages of UML Profiles
Reuse of language infrastructure (tools, specifications)
Require less language design skills
Allow for new (graphical) notation of extended stereotypes
A profile can define model viewpoints
E.g., UML activity diagram extended to specify multitask behavior
Disadvantage
Constrained by UML metamodel
How to face these limitations?

Profile semantics: on-going work: ‘Executable UML Foundation’
Clear mapping of profile extensions to domain ontology
Create rich profiles (expressiveness) and complement with specific
methodologies (precise semantics and pragmatics)
/ MARTE Tutorial 20
Main Goals for Making UML Profiles
Define a domain specific terminology
Define a domain specific notation
Define concrete syntax to specific elements
E.g., for action
Define semantics rule for:
Variation points
E.g., On BroadcastSignalAction, scope of target objects in Signal.
Ambiguous definition
New purpouse
Add usage constraints on the UML MM
e.g. for method point of view
E.g., to force behavior specification via protocol state-machine
Tag a model with additional information
e.g. for code generation purpose
E.g., for C++, «virtual», «inline»…
/ MARTE Tutorial 21
Outlines of UML2 Extension Mechanisms

Profiles
Define limited extensions to a reference metamodel with the purpose of
adapting the metamodel to a specific platform or domain.
Consists of stereotypes extended the metamodel classes.
Stereotypes
Define how a specific metaclass may be extended
Provide additional semantics information, but only for:
Semantics restriction or clarification of existing concept
New features (but compatible with exiting one!)
Ensure introduction of domain specific terminology
E.g., EAST-ADL2, a UML profile for automotive ECUs (http://www.atesst.org)
May define specific notation
E.g., new icons or shapes
May have values that are usually reffered to as tagged values
/ MARTE Tutorial 22
OMG Standardization Process
MARTE FTF: Comments due for 22 december 2007 !
WP no
?
yes
RFI no
?
yes
no
RFP ?
yes
Prop-1
… Prop ? no
Prop-n yes
Draft Adopted Specification: 16 July 2007
Revised Version
Final Adopted Specification Publication: 6 August 2007
Comments Due: 22 December 2007 FTF
Recommendations and Report Deadline: 4 July 2008 MARTE v1.0
/ MARTE Tutorial 27
UML Profiles for RTES

SPT
(2005-adopted)
SPT was the first OMG’s UML profile for Real-Time Systems:
Support for Schedulability Analysis with RMA-type techniques
Support for Performance Analysis with Queuing Theory and Petri Nets
A rich model for “metric” Time and Time Mechanisms
Despite its extensive use, several improvements were required:

Modeling HW and SW platforms, Logical Time, MoCCs, CBSE…
Alignment to UML2, QoS&FT, MDA,…
SPT’s constructs were considered too abstract and hard to apply
…
Hence, a Request For Proposal for a new profile was issued.
/ MARTE Tutorial 28
General Requirements of the MARTE RFP
Proposals shall support Modeling and Analysis of Real-Time
and Embedded (in short MARTE) systems including its
software and hardware aspects.
The Proposals will define a metamodel and its underlying UML
profile.
It shall be possible to use independently software and hardware
parts of the profile.
It shall comply with existing standards
It shall update the SPT profile 1.1
Ref. of MARTE RFP (realtime/05-02-06):

http://www.omg.org/cgi-bin/doc?realtime/05-02-06
/ MARTE Tutorial 29
The ProMARTE Team

Public web site => www.promarte.org
Partners
Industrials
Alcatel*
Lockheed Martin*
Thales*
Tool vendors
ARTISAN Software Tools*
International Business Machines*
Mentor Graphics Corporation*
Softeam*
Telelogic AB (I-Logix*)
Tri-Pacific Software
France Telecom
No Magic
Mathworks
Academics
Carleton University
Commissariat à l’Energie Atomique
ESEO
ENSIETA
INRIA
INSA from Lyon
Software Engineering Institute (Carnegie Mellon University)
Universidad de Cantabria
* Submitter to OMG UML Profile for MARTE RFP

/ MARTE Tutorial 30
Relationships with other OMG Standards
Relationships with generic OMG standards
Profile the UML2 superstructure meta-model
Replace UML profile for SPT
Use OCL2
Relationships with RT&E specific OMG standards
Existing standards
The UML profile for Modeling QoS and FT Characteristics and Mechanisms
Addressed through MARTE NFP package (in a way detailed in the NFP presentation)
The UML profile for SoC
More specific than MARTE purpose
The Real-Time CORBA profile
Real-Time CORBA based architecture can be annotated for analysis with Marte
The UML profile for Systems Engineering
Specialization of SysML allocation concepts and reuse of flow-related concepts
Ongoing discussion to include VSL in next SysML version
Overlap of team members
/ MARTE Tutorial 31
Design Pattern Adopted for the MARTE Profile

Stage 1 Æ Description of MARTE domain models
Purpose: Formal description of the concepts required for MARTE
Techniques: Meta-modeling
Stage 2 Æ Mapping of MARTE domain models towards UML2

Purpose: MARTE domain models design as a UML2 extensions
Techniques: UML2 profile
« metamodel »
Marte domain model
« refine »
« profile »
Marte profile UML2 metamodel
« reference »
/ MARTE Tutorial 32
MARTE Overview Foundations for RT/E systems
modeling and analysis:
Î CoreElements
Î NFPs
Î Time
Î Generic resource modeling
Î Generic component modeling
Î Allocation
Specialization of MARTE fondations Specialization of foundations for

for modeling purpose (specification, annotating model for analysis
design…): purpose:
Î RTE model of computation and Î Generic quantitative analysis
communication Î Schedulability analysis
Î Software resource modeling Î Performance analysis
Î Hardware resource modeling
/ MARTE Tutorial 33
Agenda
09:00 am to 10:15 am
Introduction to MDD for RT&E systems
MARTE foundations
10:45 am to 12:00 am
14:30 pm to 15:00 pm
15:00 pm to 15:45 pm
16:15 pm to 17:00 pm
17:00 pm to 17:30 pm
/ MARTE Tutorial 34
Outlines of the MARTE Foundations
MARTE foundations
Define a set of basic concepts for MDD of RTES
Intended to be used as basic layer at OMG for future RTE related stds
Consists of five sub-profiles
/ MARTE Tutorial 35
Non-Functional Properties (NFPs)

Non-functional properties describe the “fitness” of systems behavior
(E.g., performance, memory usage and power consumption)
Nature of NFPs
Quantitative: magnitude + unit (E.g., energy, data size and duration)
Qualitative (E.g., periodic or sporadic event arrival patterns)
NFP values need to be qualified
E.g. source, statistical measure, precision,…
NFPs need to be parametric and derivable
Variables: placeholders for unknown values
Expressions: math. and time expressions
NFPs need clear semantics
Predefined NFPs (E.g., end-to-end latency, processor utilization)
User-specific NFPs (but still unambiguously interpreted!)
/ MARTE Tutorial 36
Introduction to the MARTE’s NFPs Framework
UML lacks modeling capabilities for NFPs!!
Measures?
Value qualifiers?
UML Profile for NFPs
NFP Libraries?
Annotation mechanism?
But UML expression syntax is also not sufficient!!
Variables? Structured Values?

Value Specification
Language (VSL)
Data Type System?
Complex time expressions?
/ MARTE Tutorial 37
The MARTE’s NFP sub-profile

Relies on the ability to put additional information on models
Three possible model-based annotation mechanisms in UML
Value of stereotype properties
Slots value of classifier instance
Constraints
/ MARTE Tutorial 38
Annotating NFPs in Tagged Values
1) Declare NFP types
Define measurement units and
conversion parameters
Define NFP types with qualifiers
2) Define NFP-like extensions

Define stereotypes and their
MARTE pre-defined
attributes using NFP types «stereotype»
Scenario
respT: NFP_Duratio
NFP_Duration
m p le ...
exa
3) Specify NFP values
Apply stereotypes and specify
their attribute values using
VSL
/ MARTE Tutorial 39
Annotating NFPs in Slots

2) Declare NFPs
« import
rt »
Define classifiers and their
attributes using NFP types
Task
Such attributes are marked ClassifierModel
«nfp» deadline: NFP_Duration
as «nfp» exam
le
ple ...

Instantiate classifiers and
Model-specific NFPs
specify their slot values using
VSL
/ MARTE Tutorial 40
Annotating NFPs in Constraints
2) Declare NFPs
« import »
Define classifiers and their
attributes using NFP types Processor
ClassifierModel
«nfp» utilization: NFP_Percentage
ple
exam «nfp» clockFreq: NFP_Frequency
...

Create Constraints to define
assertions on NFP values
using VSL
/ MARTE Tutorial 41
The MARTE’s NFP Modeling Framework
Three main language extensions to UML syntax:

1. Grammar for extended expressions
2. Stereotypes for extended data types
2. Complex time expressions
Value Specification
Language (VSL)
/ MARTE Tutorial 42
Basic Textual Expressions in VSL
9 Extended Primitive Values
9 Extended Composite Values
9 Extended Expressions
Value Spec. Examples

Real Number 1.2E-3 //scientific notation
DateTime #12/01/06 12:00:00# //calendar date time
Collection {1, 2, 88, 5, 2} //sequence, bag, ordered set..
{{1,2,3}, {3,2}} //collection of collections
Tuple and choice (value=2.0, unit= ms) //duration tuple value
periodic(period=2.0, jitter=3.3) //arrival pattern
Interval [1..251[ //upper closed
d interval between integers
[$A1..$A2] //interval between variables
Variable declaration io$var1 //input/output variable declaration
& Call var1 //variable call expression.
Arithmetic +(5.0,var1) //”add” operation on Real datatypes
Operation Call 5.0+var1 //infix operator notation
Conditional ((var1<6.0)?(10^6):1) //if true return 10 exp 6,else 1
Expression
/ MARTE Tutorial 43
VSL Extended Data Types

Declaration example…
VSL reuses UML DataType constructs, but adds…
9 BoundedType
9 IntervalType
9 CollectionType
9 TupleType
9 ChoiceType
Specification example…
MyClass
length: Long
priorityRange: IntegerInterval
position: IntegerVector
shape: IntegerMatrix
consumption: Power
arrival: ArrivalPattern
cl: MyClass
length = 212333
priorityRange = [0..2]
position= {2,3}
shape = {{2,3},{1,5}}
consumption = (-, exp=x*v1, unit= mW, source= calc)
arrival= periodic (period= 10, jitter= 0.1)
/ MARTE Tutorial 44
Examples of Time Expressions with VSL
Duration
constraint
Variable declaration
Variable declaration denoting a duration
denoting an instant (UML DurationObservation)
(UML Time Observation)
Bounded duration
interval constraint
Bounded instant
interval constraint
/ MARTE Tutorial 45
Summary of the “MARTE’s NFP”

Synthesis of best modeling practices…
OCL: full constraint language, but complex and not real-time oriented
SPT Profile: built-in TVL language is simpler, but not flexible
QoS&FT Profile: annotation mechanism is flexible, but complex
NFP & VSL reuse selected modeling features, while still providing
simplicity and flexibility
Foundations…
Reuse OCL constructs: grammar for values and expressions
Generic data type system: (based on ISO’s General-Purpose Datatypes)
VSL extends UML Simple Time model (occurrence index, jitters,...)
Formally defined by abstract and concrete syntaxes (grammar).
Flexibility: expression operators in model-specific libraries
/ MARTE Tutorial 46
MARTE foundations
/ MARTE Tutorial 47
Scope of the Time Profile of MARTE

MARTE adopts models of time that rely on partial ordering of
instants
Three basic time models
Chronometric time model
Mainly concerns with time cardinality
E.g., delay, duration and clock time
Logical time model
Mainly concerns events ordering.
E.g., ev1 is before ev2
Synchronous time model
Specialization of the logical time model
Introduce notion of simultaneity
E.g., ev1 and ev2 occurs at the same instant
/ MARTE Tutorial 48
Time Packages of MARTE
Defines literals used to
specify the way to interpret
Defines literals used to a time expression: either as
specify the discrete or a duration or as an instant.
dense nature of a time
value.
Define time related Defines time

extensions of UML related facilites
for user models
/ MARTE Tutorial 49
The TimeLibrary Model Library

Predefined - Used to type time-related properties.
enumerates <<modelLibrary>> - Has to be parameterized according to
TimeLibrary
related to time unit to used (TUK template parameter).
TUK
« enumeration »
<<tupleType>>
TimeUnitKind
TimedValueType
«unit» s
«unit» ms {baseUnit=s, convFactor=0.001} value: Real
«unit» us {baseUnit=ms, convFactor=0.001} expr: ClockedValueSpecification
«unit» ns {baseUnit=us, convFactor=0.001} unit: TUK
«unit» min {baseUnit=s, convFactor=60}
«unit» hrs {baseUnit=min, convFactor=60}
onClock: String
«unit» dys {baseUnit=hrs, convFactor=24}
E.g., 1.5 ms on idealClk
<<primitive>>
ClockedValueSpecification
<<enumeration>> <<enumeration>>
TimeStandardKind LogicalTimeUnitKind
<<unit>> tick <<clockType>>

TAI
{ nature = dense, unitType = TimeUnitKind,
UT0
getTime = currentTime }
UT1
<<enumeration>> IdealClock
UTC
Local EventKind
currentTime( ): Real
TT start
TDB finish
TCG send
TCB receive <<clock>>
Sidereal consume { unit = s }
GPS idealClk:IdealClock
- Predefined clock modeling time which is

used in physical laws (dense time)
- It should be imported in models that
/ MARTE Tutorial refer to chronometric time. 50
« ClockType »
Used to declare clock types of user applications
Example of properties defining the clock type
nature: TimeNatureKind [1] nature: TimeNatureKind [1]
Dense or discrete unitType: Enumeration [0..1]
isLogical: Boolean [1] = false
isLogical: Boolean [1] resolAttr: Property [0..1]
Default value is false maxValAttr: Property [0..1]
offsetAttr: Property [0..1]
resolAttr: Property [0..1] getTime: Operation [0..1]
setTime: Operation [0..1]
Refers a property which slot will define the clock resolution indexToValue: Operation [0..1]
Examples
« clockType »
IdealClock
currentTime( ) : Real
/ MARTE Tutorial 51
« Clocks »
Clocks are instance specification of ClockTypes
Clocks properties are:
standard: TimeStandardKind [0..1]
unit: Unit [0..1]
type: ClockType [1]
Example
« clockType »
IdealClock
currentTime( ) : Real
/ MARTE Tutorial 52
Timed & Clock Constraints and TimedDomain
« TimedConstraint »
Imposes constraints on either instant values or duration values
associated with model elements bound to clocks.
Can be conveniently expressed in VSL
« ClockConstraint »
Imposes dependency between clocks
Refers to a set of clocks and possibly to other model elements
Described via an opaque expression using a dedicated language
E.g. CCSL (Clock Constraint Specification Language) defined in Annex C
« TimedDomain »
Namespace for:
Clock and ClockTypes user definitions
But also for ClockConstraints (see example later)
Model elements of the TimedDomain may refer to Clocks to express that
their behavior depends on time
/ MARTE Tutorial 53
Example of Timed Constraints

Duration constraint between Timing constraint with
two successive time instants condition expression
« constraint »
« timedConstraint »
{ (t0[i+1] - t0[i]) > (100, ms) }
/ MARTE Tutorial 54
Example of TimedDomain with a ClockConstraint
« clockType »
IdealClock
currentTime( ): Real
Instants chronograms of clocks cc1 and cc2
/ MARTE Tutorial 55
Timed Instant and Duration Observations

Reference to a Reference a
time instant during duration during an
an execution and execution and
points out an points out the
element in the elements in the
model to observe. model to observe.
« stereotype » « stereotype »
TimedInstantObservation TimedDurationObservation
obsKind:EventKind[0..1] obsKind:EventKind[0..2]
MARTE observations
on clarify which events is to
on
1 1 observe:
MARTE observations
have to reference a clock. « stereotype »
Clock
/ MARTE Tutorial 56
Examples of «TimedInstantObservation» and
«TimedDurationObservation»
/ MARTE Tutorial 57
Timed Events and Processings

Specifies an instant in time
via an expr. and may be
absolute or relative.
Optional duration
Bound of repetitions
value between two
successive
occurrences
/ MARTE Tutorial 58
Example of «TimedProcessing» & «TimedEvent»
with Logical Time
« clockType » « enumeration » « clock »
{ nature = discrete, isLogical = true, CAMLogicalTimeUnitKind { unit = tick }
unitType = CAMLogicalTimeUnitKind, camClk:CAMClock
getTime = getCamPos } « unit » °CAM
CAMClock
getCamPos( ): Real
/ MARTE Tutorial 59

MARTE foundations
/ MARTE Tutorial 60
Outlines of the GRM package
Provides basic concepts for modeling a general (high-level)
platform for processing RTE applications
Includes the features for modeling processing platforms at different
level of details.
The level of granularity needed depends on the concern motivating the
description of the platform
E.g., the type of the platform, the type of the application, or the type of
analysis to be carried out on the model
Build in a bottom-up process to abstract finer-level platforms
Processing platform for design concern
See HRM and SRM
Processing platform for analysis concern
See GQAM-related ptf and further refinements for performance and
schedulability analysis
/ MARTE Tutorial 61
Essence of the GRM Package
Object concern Classifier concern
0..** 1..**
ResourceInstance
instance type
e
contextt 1
exeServicess 0..**
instance
e 1..**
ResourceServiceExecution
0..** type
/ MARTE Tutorial 62
MARTE foundations
/ MARTE Tutorial 63
Allocation & Refinement

Basic ideas
Allocate an application element to an processing platform
element
Refine a general element into one or several more specific
elements
Inspired by the SysML allocation
Can only allocate application to execution platform
Can attach NFP constraints to the allocation
/ MARTE Tutorial 64
A two step process for allocation modeling
Identify possible sources and targets of allocations
What can be
allocated, the logical
view: What can serve as a
Î behavior or target of an allocation,
structure the physical view:
Î a resource or a
service.
Define allocation relationships and its features
/ MARTE Tutorial 65
Allocation example (1)
Application
mySpeedRegulator : SpeedRegulatorSystem [1]
SpeedController CarSpeed
RealTimeOperatingSystem
« schedulableResource » « storageResource »
OS_Task VirtualMemory
/ MARTE Tutorial 66
Application
« app_allocated » « app_allocated »
« schedulableResource, « storageResource,
ep_allocated » ep_allocated »
/ MARTE Tutorial 67
Application
« app_allocated » « app_allocated »
«allocate» «allocate»
{kind=timeScheduling} {spatialDistribution}
« schedulableResource, « storageResource,
ep_allocated » ep_allocated »
/ MARTE Tutorial 68
/ MARTE Tutorial 69

MARTE foundations
/ MARTE Tutorial 70
The Marte General Component Model
Defined within MARTE to support CBSE and to provide a common
denominator among various existing component models, which in
principle do not target exclusively the RTE domain
Introduce no new component-related concepts

Has to cope with various component models
E.g., UML2, SysML, Spirit, AADL, Lightweight-CCM, EAST-ADL2, Autosar, …
Main features
Mainly refined UML structured classes, on top of which a support for
SysML blocks has been added
But also compatible with a support for Lightweight-CCM, AADL and
EAST-ADL2, Spirit and Autosar
Shortcuts for UML2 modeling of components/composites diagrams
/ MARTE Tutorial 71
Example of Normal UML2 Structured Class
UML2 port
UML2 structured class
Normal UML2 port typed by a class realizing and using interfaces:

the port rp provides PRegInterface and required RRegulatorInterface
/ MARTE Tutorial 72
The MARTE GCM Sub-profile
: concepts for data-based flow communication

: concepts for message-based flow communication
/ MARTE Tutorial 73
Examples of FlowPort usage

Atomic flow port example
Non-atomic flow port example
/ MARTE Tutorial 74
Example with « MessagePort »
/ MARTE Tutorial 75
Agenda
09:00 am to 10:15 am
MARTE foundations
10:45 am to 12:00 am
14:30 pm to 15:00 pm
15:00 pm to 15:45 pm
16:15 pm to 17:00 pm
17:00 pm to 17:30 pm
/ MARTE Tutorial 76
RTE Model of Computation & Communication
High-level modeling concepts where RT/E concerns are
embedded inside modeling artifacts (E.g., UML active/passive
objects)
Implicit semantics
Two families of concerns
Quantitative aspects
E.g. concurrency and behavior
Qualitative aspects as real-time feature
E.g. deadline or period
Package dependencies
/ MARTE Tutorial 77
Qualitative RT features Modeling

« RtUnit »
Generalization of UML2 Active Objects
Autonomous processing resource, able to
handle different messages at the same time
Owns at last one schedulable resource
Managed either statically (via a SR pool) or dynamically
May have operational mode description
May be main objects
Refer to the main operation
« PpUnit »
Generalization of UML2 Passive Objects
Concurrency policy specified either locally or globally
Processing is either immediateRemote or deferred
/ MARTE Tutorial 78
Quantitative RT features modeling
« RealTimeFeature »
« RteConnector »
/ MARTE Tutorial 79
The Arrival Pattern data type

Defined in the MARTE_Library
/ MARTE Tutorial 80
Dynamics aspects of « RtUnit » and « PpUnit »
Services specification
« metaclass »
UML2::BehavioralFeature
« enumeration »
SynchronisationKind
RtService « enumeration » « enumeration »
ConcurrencyKind ExecutionKind synchronous
isAtomic: Boolean [1] = false asynchronous
concPolicy: ConcurrencyKind reader deferred delayedSynchronous
exeKind: ExecutionKind writer remoteImmediate rendezVous
synchKind: SynchronizationKind parallel localImmediate other
Classifier behavior specification
/ MARTE Tutorial 81
Usage examples of the RTEMoCC extensions (1)

CruiseControlSystem
isDynamic = false
« rtUnit » « rtUnit » isMain = false
isMain = true CruiseControler ObstacleDetector poolSize = 10
main = start poolPolicy = create
tgSpeed: Speed startDetection()
stopDetection()
«rtService» {exeKind=deferred} start()
«rtService» {exeKind=deferred} stop()
spm « ppUnit » spm

1 {concPolicy=guarded} 1
Speedometer
« dataType »
getSpeed(): Speed Speed
/ MARTE Tutorial 82
occKind = aperiodic ()
sd CruiseControlStart
value = (tRef=t0, relDl=(10, ms), miss=(1, %, max))
:CruiseControl :Speedometer
start()
startAcquisition()
@t0
occKind = periodic (period=(10, ms), jitter=(2, us))
getSpeed() value = (tRef=t0, relDl=(10, ms), miss=(1, %, max))
occKind = periodic (period=(10, ms), jitter=(2, us))

Speed value = (tRef=t0, relDl=(10, ms), miss=(1, %, max))
/ MARTE Tutorial 83

priority=1
computeTrajectory
occKind = periodic (period=(10,ms), jitter=(2,us))
@t0 relDl=(3,ms)
tRef=t0
miss=(1, %, max)
syncKind=delayedSynchronous
getLocation «rtAction, rtf»

getFlightPlan
priority=1
occKind = periodic (period=(10,ms), jitter=(2,us))
relDl=(4,ms)
«rtAction, rtf» tRef=t0
performComputation miss=(1, %, max)
syncKind=synchronous
« rtAction, rtf» priority=1

generateCommand occKind = periodic (period=(10,ms), jitter=(2,us))
relDl=(1,ms)
tRef=t0
miss=(1, %, max)
syncKind=synchronous
/ MARTE Tutorial 84
Agenda
09:00 am to 10:15 am
MARTE foundations
10:45 am to 12:00 am
14:30 pm to 15:00 pm
15:00 pm to 15:45 pm
16:15 pm to 17:00 pm
17:00 pm to 17:30 pm
/ MARTE Tutorial 85
Detailled Resource Modeling within MARTE
/ MARTE Tutorial 86
What is the Software Resource Modeling Profile (SRM) ?
A UML profile for modeling APIs of RT/E sw execution supports

Real Time Operating Systems (RTOS)
Dedicated Language Libraries (e.g. ADA)
BUT it is NOT a new API standard dedicated to the RT/E domain!
Î SRM = a unified mean to describe such existing or proprietary APIs
In which steps shall I use SRM ?
/ MARTE Tutorial 87
Items shown in next slides

SRM overview
Details of SRM through the OSEK/VDX case study
Interests to use SRM through examples

Model of multitask design
E.g., a robotic case study
Generation of OS configuration file
E.g., OSEK OIL configuration file generation
Porting existing RTE application models
E.g., from OSEK to ARINC
/ MARTE Tutorial 88
Main expected use cases of SRM
Describe execution
support API
Execution Platform Provider

« include »
Use
« extend » Model
API model
Transformation
Methodology
Software Designer Provider
« extend »
Code generation
/ MARTE Tutorial 89
Why shall I use SRM for modeling RTOS APIs?
RTOS API modeling with UML is already possible

But, generics UML is lacking RTE native artifacts!
No modeling artifacts to describe specific concepts
E.g. tasks, semaphores and mailboxes
Consequently, models relies only on naming conventions
Î Not possible to define generic tools using these models
E.g. code generator or model transformations for analysis.
Hence, SRM profile allows:
To model precise multitasking designs
To be able to describe generic generative tools
To describe SW exemodels in an unified and standard way
SRM profile is a sub-profile of the MARTE standard
/ MARTE Tutorial 90
What is supported by the SRM profile ?
Concurrent execution contexts: Hardware and software
• Schedulable Resource (~Task) resources brokering:
• Memory Partition (~Process) • Drivers
• Interrupt Resource • Memory management
GRM
• Alarm
SRM « import »
« import » SW_ResourceCore « import »
« import »
SW_Concurrency SW_Interaction SW_Brokering
Interactions between concurrent contexts:

• Communication
9 Shared data
9 Message (~Message queue)
• Synchronization
9 Mutual Exclusion (~Semaphore)
9 Notification Resource (~Event mechanism)
/ MARTE Tutorial 91
Snapshot of the UML extensions provided by SRM
SRM::SW_Concurrency
SRM::SW_Interaction SRM::SW_Brokering
« MessageComResource » « NotificationResource »
« SharedDataResource » « SwMutualExclusionResource »
/ MARTE Tutorial 92
The OSEK/VDX case study
OSEK/VDX standard (http://www.osek-vdx.org)
Automotive industry a standard for an open-ended architecture
for distributed control units in vehicles
OSEK/VDX architecture consists of three layers:

OSEK-COM layer: Communication
Data exchange support within and between electronics control units
(ECUs)
OSEK-NM layer : Network Management
Configuration determination and monitoring
OSEK-OS layer: Operating System
API specification of RTOS for automotive ECU
/ MARTE Tutorial 93
Overview of the OSEK/VDX-OS layer

Main characterisics
A single processor operating system
A static RTOS where all kernel objects are created at compile time
Main artifacts
Support for concurrent computing
Task
A task provides the framework for the execution of functions
Interrupt
Mechanism for processing asynchronous events
Alarm & Counter
Mechanisms for processing recurring events
Support for synchronizations of concurrent computing
Event
Mechanism for concurrent processing synchronization
Resource
Mechanism for mutual concurrent access exclusion
/ MARTE Tutorial 94
Focus on the OSEK/VDX Task definition
Semantic
An OSEK-VDX task provides the framework for computing application
functions. A scheduler will organize the sequence of task executions.
Example of properties
Priority: UINT32
Priority execution of the task
StackSize: UINT32
Stack size associated to the execution of the task
Example of provided services

ActivateTask (TaskID: TaskType)
Switch the task, identified by the TaskID parameter, from suspended to ready
state
ChainTask (TaskID: TaskType)
Terminate of the calling task and activate the task identified by the TaskID
parameter
/ MARTE Tutorial 95
Which SRM concepts for OSEK Task?
Concurrent execution contexts:

• Schedulable Resource (~Task)
• Memory Partition (~Process)
• Interrupt Resource GRM
• Alarm
SRM « import »
« import »
/ MARTE Tutorial 96
Details of «SwSchedulableResource»
Semantic (from MARTE::SRM::Concurrency package)
Resource which executes, periodically or not, concurrently to other concurrent resources
==> SRM artifacts for modeling OSEK-VDX Task!
Main features
Owns an entry point referencing the application code to execute
May be restricted to execute in a given address space (i.e. a memory partition)
Owns properties
E.g., Priority, Deadline, Period and StackSize
Provides services
E.g., activate, resume and suspend
Extract from the SRM::SwConcurrency meta model
/ MARTE Tutorial 97
Model of an OSEK Task with «SwSchedulableResource»
1. Define a UML model for OSEK_VDX::Task

a. Add model library applying the SRM profile
b. Add a class and defines its features (properties and operations)
2. Applying the «SwSchedulableResource» stereotype
3. Fullfill the tagged values of the applied stereotype
(Step 1) (Step 2) (Step 3)

Models have been realized with the Papyrus
Eclipse-based open-source tool for UML2:
http://www.papyrusuml.org
/ MARTE Tutorial 98
SRM modelling facilities
How to model multiples candidates for the same semantic ?
Answer : All stereotype tags have multiple multiplicities. Thus, it is possible to
reference multiple candidates for the same tag.
Examples
Both name attributes and taskId parameter are task identifier
Both activateTask and chainTask operations are task activating services

« swSchedulableResource »
Task « swSchedulableResource »
activateService = activateTask, chainTask
+ activateTask (taskID taskType)

+chainTask()
/ MARTE Tutorial 99
SRM modeling facilities (seq.)

How to model a feature which have multiple semantic ?
Answer : Feature can be referenced by several different tags
Example
The chainTask service is both a terminate service and an activate service
« swSchedulableResource » « swSchedulableResource »
Task activateService = activateTask, chainTask
terminateService = chainTask
+ activateTask (taskID taskType)

+ chainTask()
Is it possible to reference a feature even if the feature owner is not the stereotyped
element ?
Answer : Yes, there is no constraints on the feature owner
« SwSchedulableResource »
priorityElements = priority « interface »
activateService = activateTask() « swSchedulableResource » TaskService
Task
+activateTask()
- priority : Integer
SRM allows multiple usages

User can use constraints, such as OCL rules, to limit those possibilities
/ MARTE Tutorial 100

Focus on the OSEK/VDX Event definition
Semantic :
The event mechanism is a means of synchronisation that initiates state
transitions of tasks to and from the waiting state.
Example of owned properties

Mask : EventMaskType
Define the mask associated with the event
Examples of provided services

SetEvent (TaskID: TaskType, Mask: EventMaskType)
The events of the task referenced by the TaskID parameter are set according to the
event mask specified by the Mask parameter.
Calling the service SetEvent causes the task identified by the TaskID parameter to
be transferred to the ready state, if it was waiting for at least one of the events
specified in the Mask parameter.
WaitEvent (Mask: EventMaskType)
The state of the calling task is set to waiting, unless at least one of the events
specified in the Mask parameter has already been set.
Which SRM concepts for OSEK Event?
GRM
SRM « import »
« import »
Interactions between concurrent contexts:

• Communication
9 Shared data
9 Message (~Message queue)
• Synchronization
9 Mutual Exclusion (~Semaphore)
9 Notification Resource (Event mechanism)

Details of «NotificationResource»
Semantic
NotificationResource supports control flow by notifying the occurrences of
conditions to awaiting concurrent resources
==> SRM artifacts for modeling OSEK-VDX Event!
Main features
Examples of owned attribute
maskElements and mechanism
Examples of provided service
flushServices, signalServices,waitServices and clearServices
Extract from the SRM::SwInteraction meta model
OSEK/VDX Event as a NotificationResource
(i) Stereotype icon
(ii) Stereotype shape

In which typical cases shall I use SRM ?
Describe execution
support API
Execution Platform Provider

« include »
Use
« extend » Model
API model
Transformation
Methodology
Software Designer Provider
« extend »
Code generation
Use examples of one RTOS modeled with SRM
Example 1: Model-based design of multitask applications

Illustrated on a robot controller application
Example 2: OS configuration file generation

Generation of the OSEK OIL configuration files
Example 3: Assistance to port applications

From OSEK to ARINC multitask design

Case study: A simple robot controller software
Goal
A motion controller system for an
exploration autonomous mobile robot.
Robot features
Pioneer Robot (P3AT)
Four driving wheels
A camera
Eight sonar sensors, etc.
Design features of the robot controller
OSEK/VDX execution support
Simulation on Trampoline
(http://trampoline.rts-software.org/) Robot Simulator
Two periodic tasks http://playerstage.sourceforge.net/gazebo/gazebo.html
Data acquisition task
Get position data from sonar sensors
every 1 ms
trajectory computing task
Set new speed every 4 ms
Purpose and context of the example 1

Provide a multitask design of the robot controller
Target of the design is an OSEK/VDX-based platform
Design process
A platform provider supplies the OSEK/VDX model library
Model library is described with the SRM Profile (as previously shown)
A user designs a multitask model of the application

Step 1: Describe the application model (also called functional model)
Step 2: Propose a multitask design using the OSEK model library artifact

Application design
Application model at the functional level
One robot controller entity
Aims at controlling the robot motions
Main functions
Acquire the sonar data
Compute the new speed of each 4 motions and send new orders
A robot driver entity
Aims at interfacing robot sensors and actuators with the control application
Driver to interface
sensors and actuators
Acquire sonar data

from sensors
Compute the 4
Terminate
motion
a mission
speed values
Principles of the applied multitask design

Two periodic tasks
For data acquisition
Get position data from sonar sensors
Entry point
Operation MotionController::acquire()
Periodic
Period = 1 ms
For trajectory control
Compute and assign new speed order
Entry point
Operation MotionController::trajectoryControl()
Periodic
Period = 4 ms

Periodic task in OSEK/VDX
A design pattern for implementing periodic task on OSEK/VDX-
based platforms
One OSEK/VDX Counter
Counter period = period of the required periodic task
One OSEK/VDX Task
Entry point : periodic task Entry Point
One OSEK/VDX Alarm
AutoStart : Triggered by the counter SRM Profile is used
Action : Activate the task to describe the pattern
Basic Robot Controller task models
SRM stereotype to bind

application and platform
Period of the periodic task acquisition : 1 ms

Example 2: OSEK Configuration File generation
OIL_VERSION = "2.5" : "RobotController" ;
Purpose
IMPLEMENTATION OSEK {
Generation of the OSEK OIL configuration };
files from the multi-task design of the robot
CPU cpu {
controller APPMODE std {
};
OIL: OSEK Implementation Language
COUNTER counter {
http:://osek-vdx.org MAXALLOWEDVALUE = 255 ;
TICKSPERBASE = 1 ;
The goal of OIL is to provide a mechanism MINCYCLE = 1 ;
to configure an OSEK application for a };
ALARM alarmAcqu {
particular CPU COUNTER = counter ;
ACTION = ACTIVATETASK {
Principle TASK = acquisition ;
};
For each CPU, there must be an OIL AUTOSTART = TRUE {
description ALARMTIME = 1 ;
CYCLETIME = 1 ;
All OSEK system objects are described APPMODE = std ;
};
using OIL objects };
OIL descriptions may be : TASK acquisition {

PRIORITY = 2 ;
hand-written SCHEDULE = FULL ;
ACTIVATION = 10 ;
or generated by a system AUTOSTART = FALSE ;
configuration tool STACKSIZE = 32768 ;
};
…
Principle to go from a UML model to an OIL file
Template description
based on SRM profile
OIL description file User source code
E.g. ACCELEO
Platform www.acceleo.org
Specific model
OSEK Compiler
using SRM
OIL File Generation
Executable file

Example of an OIL generation template
For each UML InstanceSpecification {

if its classifier has the SRM SwSchedulableResource stereotype then {
generateText {
Task <Instance Name>{}
}endGenerate
}endif
}
« SwSchedulableResource »
BasicTask
Task acquisition{
« instanceOf » }
« instanceOf »
acquisition : BasicTask Task trajectoryController{
ACCELEO }
trajectoryController : BasicTask
Generation of the OIL file in the Papyrus UML Tool

Example 3: Assist user to port multitask designs
Purpose
Assist user to port the multitask design to an ARINC-653 RTOS
ARINC 653 standard provides avionics application software with the set of
basic services to access the operating system and other system-specific
resources.
Principles of the model transformation
Pattern matching description

• Matching rules
• Design pattern description
Model transformation toolkit

ATL ARINC-653 specific
OSEK/VDX Specific
http://www.eclipse.org/m2m/atl/
model using SRM model using SRM

Matching pattern example (1/2)
• generate a new Instance Specification;
• its target classifier is that which is stereotyped
SwSchedulableResource in the target execution support;
}endGenerate
}endif
}
« SwSchedulableResource » « SwSchedulableResource »
BasicTask Process
« instanceOf » « instanceOf »
« instanceOf » « instanceOf »
acquisition : BasicTask ATL acquisition : Process
trajectoryController : BasicTask trajectoryController : Process
Matching pattern example (2/2)

• …
• each source priorityElements match one target priorityElements
}endGenerate
}endif
}
ATL
OSEK/VDX ARINC-653

Assist user to port multi-task designs in the
Papyrus UML tool : a basic example
Hardware Resource Modeling with MARTE

Specialization of GRM
HRM and SRM share a common structure
It eases HW/SW allocation!

HRM use cases
MARTE
HRM
Allocation
« include »
System Architect
High level HW
modeling
« extend »
Application
« include »
modeling
Specialized HW
Software developper modeling
HW designer
« include » « include »
Analysis
Detailed HW
modeling
Analyzer
3 use cases = 3 levels of details
HRM use cases -- High level hardware modeling
How?
High level of abstraction
Architectural view of the HW platform
With key properties:
E.g., instruction set and memory size.
A formal view of usual block diagrams
For
High level description of existing and targeted HW platform
First steps of design of new HW architecture
By
System architects
Software developers

HRM use cases -- Specialized hardware modeling
How?
Specialized HW description model
Nature of details depends on the point of view
Ex1 : autonomy analysis requires power consumption modeling
Ex2 : WCET analysis need details on processor speed,
communication bandwidth and memory organization…
For analysis purpose
By analyzers
HRM use cases -- Detailed hardware modeling
How?
HRM is a detailed HW architecture design language
Level of details depends on the description accuracy
Ex1: Functional simulator of a processor only requires its instruction
set family
Ex2: Performance simulation need a fine description of processors
micro-architecture.
For
Model-based datasheets description
Simulation
generation of configurations for simulation tools
By
HW designers

HRM structure
Hierarchical taxonomy of hardware concepts
Successive inheritance layers
From generic concepts (GRM-like)
HwComputingResource, HwMemory, HwCommunicationResource…
To specific and detailed resources
HwProcessor, HwBranchPredictor, HwCache, HwMMU, HwBus,
HwBridge, HwDMA…
All HRM concepts are HwResource(s)
Two modeling views to separate concerns

Logical / Physical
HRM structure -- Logical modeling

Provides a functional description
Based on a functional classification of hardware resources:

HRM structure -- Physical modeling
Provides a physical properties description
Based on both following packages
HwLayout
Forms: Chip, Card, Channel…
Dimensions, area and arrangement mechanism within rectilinear grids
Environmental conditions: e.g. temperature, vibration, humidity…
HwPower
Power consumption and heat dissipation
HRM profile overview

HRM profile -- HwMemory
HwMemory
MARTE::GRM::Storage HwResource
« stereotype » « dataType »
HwMemory Timing
memorySize : NFP_DataSize notation : NFP_String

addressSize : NFP_DataSize description : NFP_String
timings : Timing [*] value : NFP_Duration
« stereotype » « stereotype » « stereotype » « stereotype »

HwCache HwRAM HwROM HwDrive
level : NFP_Natural = 1 organization : MemoryOrganization type : ROM_Type sectorSize : NFP_DataSize

type : CacheType isSynchronous : NFP_Boolean organization : MemoryOrganization
structure : CacheStructure isStatic :NFP_Boolean
repl_Policy : Repl_Policy isNonVolatile : NFP_Boolean 0..1
writePolicy : WritePolicy repl_Policy : Repl_Policy
buffer
writePolicy : WritePolicy
{subsets ownedHW}
« enumeration » « enumeration » « enumeration » « dataType » « dataType » « enumeration »

Repl_Policy WritePolicy CacheType CacheStructure MemoryOrganization ROM_Type
LRU WriteBack Data nbSets : NFP_Natural nbRows : NFP_Natural MaskedROM

NFU WriteThrough Instruction blocSize : NFP_DataSize nbColumns : NFP_Natural EPROM
FIFO Other Unified associativity : NFP_Natural nbBanks : NFP_Natural OTP_EPROM
Random Undefined Other wordSize : NFP_DataSize EEPROM
Other Undefined Flash
Undefined Other
Undefined
HRM profile -- HwMemory -- HwCache

HwMemory
MARTE::GRM::Storage HwResource
HwCache is a processing memory where

frequently used data can be stored for
« stereotype » « dataType »
rapid access.
HwMemory Timing
memorySize : NFP_DataSize notation : NFP_String

Detailed description of the HwCache is
addressSize : NFP_DataSize
timings : Timing [*]
description : NFP_String
value : NFP_Duration
necessary for performance analysis and

simulation
« stereotype » « stereotype » « stereotype »
HwRAM HwROM HwDrive
organization : MemoryOrganization type : ROM_Type sectorSize : NFP_DataSize

isSynchronous : NFP_Boolean organization : MemoryOrganization
isStatic :NFP_Boolean
isNonVolatile : NFP_Boolean 0..1
repl_Policy : Repl_Policy
buffer
writePolicy : WritePolicy
{subsets ownedHW}
« enumeration » « enumeration » « enumeration » « dataType » « dataType » « enumeration »

Repl_Policy WritePolicy CacheType CacheStructure MemoryOrganization ROM_Type
LRU WriteBack Data nbSets : NFP_Natural nbRows : NFP_Natural MaskedROM

NFU WriteThrough Instruction blocSize : NFP_DataSize nbColumns : NFP_Natural EPROM
FIFO Other Unified associativity : NFP_Natural nbBanks : NFP_Natural OTP_EPROM
Random Undefined Other wordSize : NFP_DataSize EEPROM
Other Undefined Flash
Undefined Other
Undefined

Specifies the cache level.

Default value is 1

Specifies the HwCache structure
HwCache is organized under sets of blocks.
Associativity is the number of blocks within
each set.
If associativity = 1, cache is direct mapped.
If nbSets = 1, cache is fully associative.
OCL rule:
memorySize = nbSets x blocSize x associativity

Specifies the cache write policy

WriteBack: Cache write is not immediately
reflected to the backing memory.
WriteThrough: Writes are immediately
mirrored.
HRM usage
HRM stereotypes extends the main structural UML metaclasses
Classifier, Class
InstanceSpecification, Property
Association (HwMedia, HwBus…), Port (HwEndPoint)
HRM can be used with all Structural UML diagrams:

Class diagram
Component diagram
Composite Structure Diagram (well adapted for HW)
HRM profile application

Tag definitions are optional
Specified if needed
Specified when needed (Refinement)
At class level for technology definition (e.g. type of HwCache)
At instance level for component definition (e.g. size of HwCache)

Very early Hw Architecture Description
SMP (Symmetric MultiProcessing) hardware platform
4 identical processors
Unified Level 2 cache for each
Shared main memory (SDRAM)
Central FSB (Front Side Bus)
DMA (Direct Memory Access)
Battery Only HwResouces
HRM usage example: Logical view

« hwLogical::hwResource »
smp : SMP
« hwProcessor » « hwProcessor » « hwProcessor » « hwProcessor »

cpu1 : CPU cpu2 : CPU cpu3 : CPU cpu4 : CPU
{frequency = 800Mhz} {frequency = 800Mhz} {frequency = 800Mhz} {frequency = 800Mhz}
« hwCache » « hwCache » « hwCache » « hwCache »

l2 : UL2 l2 : UL2 l2 : UL2 l2 : UL2
{memorySize = 512kB} {memorySize = 512kB} {memorySize = 512kB} {memorySize = 512kB}
« hwBus »
fsb : FSB
{frequency = 133Mhz,
wordWidth = 128bit}
« hwSupport » « hwDMA» « hwRAM »

battery : Battery dma : DMA sdram : SDRAM
{managedMemories = sdram} {frequency = 266Mhz,
memorySize = 256MB}

HRM usage example: Physical view
« hwCard »
smp : SMP
grid = 4,3
area = 5000mm²
r_conditions = (Temperature; Operating; ‘’’’; [10°C,60°C])
« hwChip » « hwChip » « hwCard »

« hwComponent» sdram : SDRAM
cpu1 : CPU cpu3 : CPU
SMP
position = [1,1], [1,1] position = [2,2], [1,1] position = [3,4], [1,1]
{kind = Card}
staticConsumption = 5W staticConsumption = 5W nbPins = 144
« hwComponent »
« hwComponent »
CPU [4] « hwComponent »
DMA
{kind = Chip} FSB
{kind = Chip}
{kind = Channel}
« hwChannel »
fsb : FSB
position«= hwPowerSupply
[1,4], [2,2] »
« hwComponent » « hwComponent »
Battery
UL2 SDRAM
{kind = Other,
{kind = Unit} {kind = Card}
capacity = 40Wh}
« hwChip » « hwChip » « hwChip » « hwPowerSupply »
cpu2 : CPU cpu4 : CPU dma : DMA battery : Battery
position = [1,1], [3,3] position = [2,2], [3,3] position = [3,3], [3,3] position = [4,4], [3,3]
staticConsumption = 5W staticConsumption = 5W capacity = 10Wh
weight = 150g
HRM case study -- TC1796 (μController)

Advanced 32-bit TriCore™-based Next Generation
Microcontroller for Real-Time Embedded systems
Automotive control systems
Industrial robotic control
Features
Super-scalar TriCore CPU
Superior real-time performance
Efficient interrupt handling
4 stage pipeline
DSP capabilities
150 MHz operational frequency

HRM case study -- TC1796
Complex memory architecture
Embedded Program Memory (>2MByte): PMI (ICACHE,
SPRAM), PMU (BROM, PFLASH, DFLASH)
Data Memory : DMI(LDRAM, DPRAM), DMU(SRAM, SBRAM)…
Extendable memory using an external bus
High performance triple bus structure

Two Local memory busses (64-bit) to program and data
memories
32-bit system peripheral bus to on-chip peripherals
32-bit remote peripheral bus to external peripherals
Independent bus control units
16-channel DMA controller…
Block diagram of the TC1796 CPU-Subsystem

HRM case study -- TC1796 CPU-Subsystem
DEMO
(Papyrus)
HRM application -- HW emulation
UML models have now a precise standard XML

representation (using the XMI definition).
Then, all model manipulations and transformations can be
easily done using widely known XML technologies.
Eclipse plugins (EMF, UML2…), Acceleo…
The steps are:

1. Describe the HW models in UML using HRM
2. Parse and Capture all the required HW properties
3. Verify coherency and completion
4. Generate the configuration file for the target emulation tool
5. Simulate the application software on the emulated HW

Examples of Possible Hw Emulators
Simics (Virtutech, www.virtutech.com/ )
Support for most HW components
Functional and Performance simulation
Enable to run heavy software applications (e.g., linux)
Free for academics
Skyeye (www.skyeye.org/)
Support for ARM-like processors, most of memories and peripherals
Functional simulation
Enable to run only light sw applications (E.g., μLinux and ARMLinux)
GPL
SimpleScalar (www.simplescalar.com/)
Academic tool easy to extend
Performance simulation
Run C code
Agenda
09:00 am to 10:15 am
MARTE foundations
10:45 am to 12:00 am
14:30 pm to 15:00 pm
15:00 pm to 15:45 pm
16:15 pm to 17:00 pm
17:00 pm to 17:30 pm

Design rationale for GQAM
Updates SPT
Alignment to UML2
Harmonization between the two SPT analysis sub-profiles:
schedulability and performance
Extension of timing annotations expressiveness
Overheads (e.g. messages passing)
Response times (e.g. BCET & ACET)
Timing requirements (e.g. miss ratios and max. jitters)
Provides support for methodological aspects
Sensitivity analysis and design-space exploration
Modeling reuse and component-based design
Support of the MDA approach
GQAM overview
Generic Quantitative Analysis Modeling (GQAM) expresses
foundation concepts and NFPs shared by different quantitative
analysis domains – e.g., schedulability and performance - that have
their own terminology, concepts and semantics
core GQAM concepts describe how the system behavior uses resources
over time
NFPs used in quantitative analysis techniques:
“input NFPs” - taken as input data
e.g., request or trigger arrival rates, execution demands, deadlines, QoS targets
“output NFPs” - computed as results
e.g., response times, deadline failures, resource utilizations, queue sizes
Different analysis goals:
Point evaluation of the output NFPs for a given operating point defined
by input NFPs
Search over the parameter space for feasible or optimal solutions
Sensitivity of some output results to some input parameters
Scalability analysis: how the system performs when the problem size or
the system size grow.

Processing schema for model-based analysis
UML2 + Marte
Analysis specific
« profile »
framework
MARTE
UML2 editor Analysis model
Model
converter
Annotated model
Analysis tool
Results/Diagnostic
Results Analysis results
converter
GQAM dependencies and architecture

GQAM (Generic Quantitative Analysis Modeling): Common concepts for analysis
SAM: Modeling support for schedulability analysis techniques.
PAM: Modeling support for performance analysis techniques.

GQAM domain model – top package
Main concepts common for quantitative analysis:
Resources
Behavior
Workload
All embedded in an analysis context (may have analysis parameters)
GQAM domain model: Workload and Behavior

Workload
Behavior/
Scenario
Steps

Workload concepts
Different workloads correspond to different operating modes:
takeoff, in-flight and landing of an aircraft
peak-load and average-load of an enterprise application.
A workload is represented by a stream of triggering events,
WorkloadEvent, generated in one of the following ways:
by a timed event
by a given arrival pattern
periodic, aperiodic, sporadic, burst, irregular, open, closed
by a generating mechanism named Workload Generator
(may be modeled as a state-machine)
multiple independent identical generating mechanisms may exist
(their number is called its "population“)
from a trace (EventTrace) stored in a file.
Behavior scenario concepts

BehaviorScenario describes a behavior triggered by an event
composed of sub-operations called Steps
any Step may be refined as another BehaviorScenario
A BehaviorScenario captures any system-level behavior description or any
operation and attaches resource usage to it in different ways:
each primitive Step executes on a host processor
a Step implicitly uses a SchedulableResource (process, thread or task)
a Step may be a specialized AcquireStep or ReleaseStep to acquire or release a
Resource
BehaviorScenarios and Steps may use other kind of resources, so
BehaviorScenario inherits from ResourceUsage which links resources with
concrete usage demands.
a few concrete forms of usage defined in GQAM: memory, CPU execution time, energy
from a power supply and size of messages.
Predecessor-successor relationship between Steps:
sequence, branch, merge, fork, join
A CommunicationStep defines the conveyance of a message
Services are provided by resources and by subsystems
a subsystem service associated with an interface operation provided by a
component may be identified as a RequestedService
RequestedService is a subtype of Step - may be refined by a BehaviorScenario.

GQAM domain model: Resources
Physical
Resources Logical
Resources
Resource concepts
ResourcesPlatform - the top class in the GQAM_Resource package
represents a logical container for all the resources
The viewpoint of resources is based on the abstract Resource class
from the GRM package
common features include a scheduling discipline, multiplicity, services
From an analysis viewpoint, four types of resources are important:
ExecutionHost: a processor or other device that executes operations
specified in the model. It has a host role relative to the processes and
the Steps that execute on it.
CommunicationsHost: hardware links between devices, with the role of
host to the conveyance of a message.
SchedulableResource: a schedulable service like a process or thread
pool, which is a software resource managed by the OS.
CommunicationChannel : a middleware or protocol layer that conveys
messages.
There are also other concurrency resources, such as mutual
exclusion resources from the GRM chapter
e.g., critical section; semaphores and locks; a finite buffer pool; pool of
admission control tokens.

GQAM domain model: Observers
Timing Observers are conceptual entities that collect timing requirements and predictions related
to a pair of user-defined observed events startObs and endObs.
annotate and compare timing constraints against timing predictions provided by analysis tools
can be used as predefined and parameterized patterns or by means of more elaborate expressions
(e.g., in OCL or VSL)
LatencyObserver specifies a duration observation, with a miss ratio assertion (percentage), a
utility function placing a value on the duration, and a jitter constraint.
Common NFP Attributes for Analysis (1)

NFP For Resource For Scenario and Step For Workload
Event
repetitions: NFP_Real[*] N/A the number of times the Step is N/A
repeated, once triggered
(default = 1).
probability: NFP_Real[*] N/A the probability that the step is executed, N/A
following its predecessor (for
conditions)
hostDemand:NFP_Duration[*], composite demand across For a Step, the CPU demand on the N/A
hostDemandOps:NFP_Real[*] all services of the host of the process that executes
Resource, in terms of the Step.
time and in terms of For a Scenario, the sum of all demands
processor operations for all its Steps.
priority : NFP_Integer[*] N/A For a Step, priority on its host N/A
respTime: NFP_Duration[*] response time, total delay from the trigger event until required value for the
composite average completion of the Step or Scenario
response time across Scenario
all services offered by
the resource
execTime : NFP_Duration[*] execution time respTime minus any scheduling delays N/A

Common NFP Attributes for Analysis (2)
NFP For Resource For Scenario and Step For Workload
Event
interOccTime: NFP_Duration[*] inter-occurrence time, interval between initiations interval between
interval between trigger events
successive requests
for services
throughput : NFP_Frequency[*] frequency of requests for frequency of initiations frequency of the
all services trigger event
utilization : NFP_Real[*] fraction of time the fraction of time the BehaviorScenario is N/A
resource is active active (between its trigger event
(has an active and its completion)
service). For a
multiple resource,
the mean number of
busy units.
utilizationOnHost: NFP_Real[*] N/A fraction of time the host is busy N/A
executing the BehaviorScenario. If
it has multiple hosts, this is a set
of values.
blockingTime: NFP_Duration[*] blocking time a pure delay which is part of the N/A
behavior of the Step or Scenario
GQAM Profile: top-level stereotypes

The UML extensions for the GQAM sub-profile are presented in four
figures related to corresponding domain model packages:
GQAM, GQAM_Workload, GQAM_Resources and GQAM_Observers.

GQAM Profile: Workload and Behaviour
Workload
Steps
Scenario
Applying behavior-related stereotypes

GaScenario and Step stereotypes inherit from:
TimeModels::TimedProcessing - which in turn extends Behavior,
Message, Actions
and from GRM::ResourceUsage - which extends NamedElement
Therefore, Scenario and Step stereotypes can be applied to a
wide set of behavior-related elements covered by the UML 2
metaclass NamedElement, such as:
Operations, Actions
Messages that initiate Operations or Actions
Transitions and States in state machine diagrams
Signals that trigger state machine transitions
Events, ExecutionOccurrenceSpecifications and
InteractionFragments in interaction diagrams
InputPins in activity diagrams
UseCases.

GQAM Profile: Resources
In general, resource-related stereotypes extend the UML metaclasses Classifier,
InstanceSpecification and Property
Therefore, resource stereotypes can be applied to all kinds of classes, instances,
components, parts and deployment nodes.
« profile »
GQAM
« stereotype »
« enumeration » MARTE:: GRM:: Resource
MARTE_ Library::
MARTE_ DataTypes::
TransmModeKind
Simple « stereotype» « stereotype »
HalfDuplex MARTE:: GRM:: MARTE:: GRM::
FullDuplex ProcessingResource ConcurrencyResource
Physical
Logical
Resources
« stereotype »
resources
MARTE:: GRM::
« stereotype » SchedulableResource
GaExecHost « stereotype »
commTxOvh: NFP_ Duration GaCommHost
commRcvOvh: NFP_ Duration
cntxtSwT: NFP_ Duration capacity: NFP_ DataTxRate [*] « stereotype »
clockOvh: NFP_ Duration packetT: NFP_ Duration [*] GaCommChannel
schedPriRange: NFP_ Interval blockT: NFP_ Duration [*]
transmMode: TransmModeKind packetSize: NFP_ DataSize
memSize: NFP_ DataSize utilization: NFP_ Real [*]
utilization: NFP_ Real [*] utilization: NFP_ Real [*]
throughput: NFP_ Frequency [*] throughput: NFP_ Frequency [*]
GQAM Profile: Observers

A timing observer may be attached to a start and end observed events, or to a behavior
element (whose execution start and end represent the observed events)
Such modeling constructs are useful for complex end-to-end flows, providing flexible
means to annotate analyzer-defined timing constraints.

Agenda
09:00 am to 10:15 am
MARTE foundations
10:45 am to 12:00 am
14:30 pm to 15:00 pm
15:00 pm to 15:45 pm
16:15 pm to 17:00 pm
17:00 pm to 17:30 pm
Key reasoning for the use of UML in the

scheduling analysis of RTE Systems
UML is a standard semi-visual language for conceptual modeling that enables the
usage of a Model Based approach for software and system engineering.
MDD and UML have been broadly introduced and used in principle by the
software engineering community, and have reached a significant number of
practitioners and tool support.
To take benefit of this in the RTE domain, they need to be capable of supporting
the necessary (at least timing) verifications.
This leads to the necessity of model based scheduling analysis techniques.
As well as the necessity to have the modeling elements to describe the platform,
the interacting environment and the timing requirements.

Topics
A flash of schedulability analysis:

RMA: the foundations
Offset-based techniques: high level models.
Structural and behavioral modeling elements in MARTE.
Examples of the notation used.
Options for managing time

Compile-time schedules:
Known as cyclic executives
Predictability through static schedule
Logical integrity often compromised by timing structure
Difficult to maintain, even with model based strategies
Run-time schedules:
Priority-based schedulers
Preemptive or non preemptive
Fixed priority or dynamic priority
Analytical methods needed for predictability
Separates logical structure from timing
Server-based frameworks:
Combine static or dynamic schedules with budgets and periods
enforced at run-time

Fixed-Priority Scheduling
Fixed-priority preemptive scheduling is very popular for

practical applications, because:
Timing behavior is simpler to understand

Treatment of transient overload is easier to predict
A complete analytical technique exists
All standard concurrent languages or operating systems specify
fixed-priority scheduling
FP analysis works also for non-preemptible tasks or non-

preemptible sections
Rate Monotonic Analysis (RMA)
Rate monotonic analysis is an engineering basis for analyzing

and designing real-time systems.
Provides guidelines for optimum priority assignment
Provides an analytical framework for verifying timing
requirements
Helps to identify timing bottlenecks and errors
Is very popular, and is supported by concurrent languages
and real-time operating systems.

A simple example
Tasks
Critical sections
(Slide credit: M.Gonzalez Harbour & the SEI RMA tutorial)
Why Are Deadlines Missed?

For a task to meet its deadline, it must accommodate
preemption: time waiting for higher-priority tasks
execution: time to do its own work
blocking: time delayed by lower-priority tasks
The task is schedulable if the sum of its preemption,

execution, and blocking is less than its deadline for the worst
possible case:
Execution is unavoidable (unless requirements change).
Preemption can be minimized by choosing an optimum priority
assignment
Main focus: identify and reduce blocking

Concepts and Definitions (periodic tasks)
Periodic task
initiated at fixed intervals
must finish before start of next cycle
Task’s CPU utilization: Ui = Ci / Ti

Ci = compute time (execution time) for task ti
Ti = period of task ti
Pi = priority of task ti
Di = deadline of task ti
fi = phase of task ti
Ri = response time of task ti
CPU utilization for a set of tasks: U = U1 + U2 + … + Un
Basic Principles of RMA
Two concepts help to build the worst-case condition:

Critical instant. The worst-case response time for all tasks in the
task set is obtained when all tasks are activated at the same time
Checking the first deadline. When all tasks are activated at the
same time, if a task meets its first deadline, it will always meet all
of its deadlines
Based on these concepts, several results arise:
Optimality of rate monotonic priorities

Utilization bound test
Exact test

Critical instant
(Slide credit: M.Gonzalez Harbour & the SEI RMA tutorial)
Utilization and Response Time tests

Utilization Bound(UB) Test: A set of n independent periodic
tasks, with deadlines at the end of the periods, scheduled by
the rate monotonic algorithm will always meet its deadlines,
for all task phasings, if: U <= U(n) = n(21/n - 1)
Completion time test:

For a number the tasks according to priority (highest priority=t1,
lowest priority=tn)
Under a critical instant condition, the amount of work Wi(t) of
tasks at priority Pi or higher started before t is

Response time evaluation
Ri may be computed by the following iterative formula:
The iteration ends when:
Task ti is schedulable if:
Effects of jitter
Periodic events with jitter have an arrival time which may be
early or late, within a bounded interval:
events arrive at to + nT +/- J
Jitter may have a delay effect on lower priority tasks

High pri.
Low pri.
t t
Execution sequence for Execution sequence
two periodic tasks. with jitter.
Worst case is one preemption Worst case is two preemptions
(Slide credit: J.C. Palencia & M.Gonzalez Harbour)

More general approach
Scenario(instance) based, distributed, control-flow dependencies
Real-Time System
R
R R
(Slidewcredit: J.M. Drake)
Distributed system model

ej-1,j ej,j+1
Linear Action: aj Tj-1,j = Tj = Tj,j+1
Linear Response to an Event:

CPU-1 Network CPU-2
e1 e1,2 e2,3
Action a1 a2 a3
e1 External
event d2
e1 Internal D2
event
ED3

Jitter in distributed systems
a2
a5
a1
a4 a7
a3
a8 Network
CPU-1 a6
CPU-2
Jitter in one processing resource depends on the response

times in other processing resources
Response times depend on jitters
Transactions
Fork
Step Step (Multicast)
External Precedence
Event Relationship
(Action) Precedence
Relationship
Timing
Requirement

Transactions
Shared Processing
Resources Resources
Usage Schedulable
Resource
Scheduling
Parameters
Event Event
Step
Event
Timing
Requirement Reference
Resources

« profile »
GRM
« metaclass »
« metaclass » « metaclass » « metaclass » « metaclass » UML::CompositeStructures::
UML::Classes::Kernel:: UML::Classes::Kernel:: UML::Classes::Kernel:: UML::Interaction::Basic InternalStructures::
Property InstanceSpecification Classifier Interactions::Lifeline ConnectableElement
« stereotype»
Resource
resMult: Integer = 1
« stereotype » isProtected: Boolean
« stereotype »
CommunicationEndPoint isActive: Boolean StorageResource
packetSize: Integer elementSize: Integer

SynchronizationResource ConcurrencyResource Scheduler
isPreemptible: Boolean = true

schedPolicy: SchedPolicyKind = FixedPriority
« stereotype » « stereotype » otherSchedPolicy: String
MutualExclusionResource SchedulableResource schedule: OpaqueExpression
protectKind: ProtectProtocolKind=priorityInheritance schedParams: SchedParameters [0..*]

ceiling: Integer isActive:Boolean = true {IsReadOnly}
otherProtectProtocol: String
isProtected:Boolean=true{IsReadOnly}
« stereotype »
SecondaryScheduler
« metaclass » « stereotype »
UML::CompositeStructures:: ProcessingResource
InternalStructures::
speedFactor: NFP_Real = (value = 1.0)
Connector

CommunicationMedia ComputingResource DeviceResource
elementSize: Integer
Domain model for Schedulable resources

Scheduling
GRM::ResourceManagem 1..* * GRM::ResourceManage broker brokedResource GRM::ResourceCore::

ent::AccessControlPolicy ment::ResourceBroker 1..* Resource
*
accCtrlPolicy
SchedulinglPolicy 0..1 mainScheduler

1 * ProcessingResource
Scheduler * 1..*
policy: SchedPolicyKind
otherSchedPolicy: String schedule:OpaqueExpression processingUnits speedFactor: NFP_Real =
policy (value = 1.0)
{Subset brokedResource}
{subset accCtrlPolicy}
host 1
« enumeration »
SchedPolicyKind SecondaryScheduler 1 GRM::ResourceTypes::
GRM::ResourceTypes::
EarliestDeadlineFirst host ComputingResource CommunicationMedia
FIFO dependentScheduler 0..1
FixedPriority
LeastLaxityFirst 1..* 0..*
virtualProcessingUnits schedulableResource GRM::ResourceTypes::
RoundRobin
TimeTableDriven DeviceResource
Undef SchedulableResource
Other * {isActive=True}
1 schedParams
GRM::ResourceTypes::
SchedulingParameters
ConcurrencyResource

Shared resources
Extensions for scheduling

« profile »
GRM
« stereotype »
« stereotype » « stereotype » MutualExclusionResource
ComputingResource ProcessingResource
protectKind: ProtectProtocolKind=PriorityInheritance
processingUnits 0..* ceiling: Integer
host 0..1 otherProtectProtocol: String
isProtected:Boolean=true{IsReadOnly}
mainScheduler 0..1
* protectedSharedResources
« stereotype » scheduler
Scheduler
0..1
isPreemptible: Boolean = true
schedPolicy: SchedPolicyKind = FixedPriority host
otherSchedPolicy: String
schedule: OpaqueExpression
0..1
schedulabledResources 0..*
« stereotype »
SchedulableResource
« stereotype »
SecondaryScheduler schedparams: SchedParameters[0..*]
isActive:Boolean=true{IsReadOnly}
dependentScheduler 0..1 0..* virtualProcessingUnits

Resource Usage
1. If the list usedResources is empty the list subUsages should not be empty and viceversa..
2. If the list usedResources has only one element, all the optional lists of attributes refer to this unique
Resource and at least one of them must be present.
3. If the list usedResources has more than one element, all of the optional lists of attributes that are
present, must have that number of elements, and they will be considered to match one to one.
4. If the list subUsages is not empty, and any of the optional lists of attributes is present, then more
than one annotation for the same resource and kind of usage may be expressed. In this case, if the
annotations have also the same source and statistical qualifiers they will be considered in conflict,
and hence the ResourceUsage inconsistent.

Structure of SAM
SAM Overview

SAM_Workload: End-to-endFlow
SAM_Workload
« dataType » GQAM_Workload::
« choiceType » WorkloadBehavior SAM_Observers::
ArrivalPattern
TimingObserver
periodic: PeriodicPattern
aperiodic: AperiodicPattern Timing
workload 1..* *
sporadic: SporadicPattern
burst: BurstPattern EndToEndFlow 1
irregular: IrregularPattern
closed: ClosedPattern isSchedulable: NFP_Boolean
open: OpenPattern schedulabilitySlack: NFP_Real
endToEndTime: NFP_Duration
endToEndDeadline: NFP_Duration
1..* endToEndStimuli endToEndResponse 1
GQAM_Workload::
WorkloadEvent 1..* 1
GQAM_Workload::
pattern: ArrivalPattern BehaviorScenario
inputStream effect
SAM_Workload: BehaviorScenario

SAM_Observers
SAM_Observers
« enumeration » NFP_Modeling::
ConstraintKind NFP_Annotation::
required NFP_Constraint
offered kind: ConstraintKind
contract
startObs
TimeModels:: GQAM_Observers:: « enumeration »
0..1 TimingObserver LaxityKind
TimedRelatedEntities::
TimedObservations:: endObs laxity: LaxityKind hard
TimedInstantObservation soft
0..1
undef
other
SchedulingObserver GQAM_Observers::
LatencyObserver
suspensions: NFP_Integer
blockingTime: NFP_Duration latency: NFP_Duration
overlaps: NFP_Integer missRatio: NFP_Real
utility: UtilityType
maxJitter: NFP_Duration
Resources in SAM (domain model)

Resources in SAM (profile)
Example
ClassesView_TeleoperatedRobot DeploymentView_TeleoperatedRobot
« ppUnit »
DisplayData
displayData displayData
data: Integer [*]
read (): Data

write (D: Data) Station
« rtUnit » « rtUnit »
DisplayRefresher CommandInterpreter
updateDisplay () processEvent ()
updateGraphics () planTrajectory ()
comm comm CAN_Bus

StationCommunication ControllerCommunication
sendCommand (C: Command) sendStatus (S: Status)

awaitStatus (): Status awaitCommand (): Command
comm comm
« rtUnit » « rtUnit »
Reporter CommandManager Controller VME_Bus RobotArm
report () manage ()
servosData
servosData
« ppUnit » « rtUnit »
ServosData ServosController
servosData
Data: Integer [*] controlServos ()
get (): Data controlAlgorithms ()
set (D: Data) doControl ()

Real-time situation
« gaWorkloadBehavior » NormalMode
« workloadEvent »
ControlTrigg
{ periodic (period= (5, ms)) } «gaScenario»
{ respTime= ($r1, ms),
utilization= $u1,
execTime= ($e1, ms) }
Control
« workloadEvent »
ReportTrigg
{ periodic (period= (100, $pR, ms)) }
«gaScenario»
utilization= $u2,
execTime= ($wcet1, max, ms) }
Report
« workloadEvent »
ReportTrigg
{ periodic (period= (1, s)) } «gaScenario»
utilization= $u3,
execTime= ($e3, ms) }
Command
Platform
« gaResourcesPlatform »
TeleoperatedRobot_Platform
« schedulableResource »
« saExecHost »
«allocate» : DisplayRefresherTask
: Station
{ fp (priority= 22) }
: MsjStatus
« saCommHost » «allocate» { fp (priority= 24) }
: CAN_Bus
{ transMode= Half-Duplex « schedulableResource »
speedFactor= ($prCAN) «allocate» : MsjCommand
blockT= (111, us, max, meas) { fp (priority= 24) }
packetT= (64, us, calc) }
: ServosControllerTask
«allocate»
« saExecHost » « schedulableResource »
: Controller : Reporter
{ speedFactor= (1.0) «allocate» { fp (priority= 24) }
clockOvh= (7, us, meas)
cntxtSwT= (5, us, meas)
ISRswitchT= (2.5, us, meas) : CommandManager
schedPrioRange= ([0..30], determ)
«allocate» { fp (priority= 16) }
ISRPrioRange= ([31..31], determ) }
«allocate»
: ControllerComm
: VME_Bus
« scheduler »
« saExecHost » : RTOS_Scheduler
: RobotArm { schedPolicy= FixedPriority }

A behavior scenario
Parametric analysis contexts

Agenda
09:00 am to 10:15 am
MARTE foundations
10:45 am to 12:00 am
14:30 pm to 15:00 pm
15:00 pm to 15:45 pm
16:15 pm to 17:00 pm
17:00 pm to 17:30 pm
Performance modeling formalisms

Different performance models developed over time in the performance
evaluation field may be used for performance analysis of UML models
model transformation from UML+MARTE to such target performance
models are needed
Classification of performance models
Analytic models
Queueing Networks (QN)
capture well contention for resources
efficient analytical solutions exists for a class of QN (“separable” QN)
Layered Queueing Networks (QN extension) are used as an example
Stochastic Petri Nets
good flow models, but not as good for resource contention
analytical solutions suffer from state space exponential explosion
Stochastic Process Algebra
introduced recently by merging Process Algebra and Markov Chains
Simulation models
less constrained in their modeling power, can capture more details
harder to build and more expensive to solve (run the model repeatedly).

Queueing Network (QN): Single Service Center
arriving departing
customers customers
Queue Server
Parameters
scheduling policy (FIFO, priority, etc.)
workload intensity - arrival process
e.g., Poisson arrival with rate 0.5/second
service demand per customer
e.g., exponential distribution with mean of 1.25 seconds
Performance measures
utilization = proportion of time the server is busy
residence time = average time spent at the service center by a customer,
both queueing and receiving service
queue length = average number of customers at the service center
throughput = rate at which customers pass through the service center.
Single Service Center: Performance Results

Typical non-linear behaviour for queue length and waiting time
server reaches saturation at a certain arrival rate (utilization close to 1)
at low workload intensity: an arriving customer meets low competition,
so its residence time is roughly equal to its service demand
as the workload intensity rises, congestion increases, and the residence time
along with it
as the service center approaches saturation, small increases in arrival rate
result in dramatic increases in residence time.
Utilization Residence Time Queue length

1 20 20
0.9
0.8
Residence Time
15 15
Queue length
0.7
Utilization
0.6
0.5 10 10
0.4
0.3
5 5
0.2
0.1
0 0 0
0 0.2 0.4 0.6 0.8 0 0.2 0.4 0.6 0.8 0 0.2 0.4 0.6 0.8
Arrival Rate Arrival rate Arrival rate

Network of queues
Open and closed QN models
out
Disk 1 ... Disk 1
CPU CPU
Terminals
Disk 2 Disk 2
Additional parameters needed to describe the movement of customers

through the network
e.g., after a CPU service, a customers moves with given probabilities or visit
ratios to Disk1, Disk2 or out
Multiple customer classes
each class has its own workload intensity, service demands and visit ratios
combination of open and closed classes is possible
the performance results will be obtained by class
Bottleneck service center - may be different for different classes.
Layered Queueing Network (LQN) model

http://www.sce.carleton.ca/rads/lqn/lqn-documentation
LQN is a extension of QN
models both software tasks (rectangles)
clientE ClientT
and hardware devices (circles)
represents nested services (a server is Client
also a client to other servers)
software components have entries CPU
corresponding to different services
device
arcs represent service requests service1 service2 Appl
(synchronous and asynchronous)
multi-servers used to model components
with internal concurrency entries task Appl
What we get from the LQN solver: CPU
Service time (mean, variance) including
nested services
Waiting time Query1 Query2 DB
Throughput
Utilization

DB
Probability of missing a deadline
(obtained only by simulation) CPU
Disk1 Disk2

Performance Analysis in MARTE
In MARTE, “performance modeling” describes the analysis of temporal
properties of best-effort systems and soft-real-time embedded systems
e.g., information processing systems, web-based applications and services,
enterprise systems, multimedia, telecommunications.
Performance measures (analysis outputs) are statistical, such as:
mean throughput and delay (response time)
mean queue length and queueing delay
probability of missing a target response time
resource utilization
Input parameters to the analysis may also be probabilistic, such as:
random arrival process,
random execution time for an operation
probability of a cache hit.
Common performance analysis techniques include:
simulations
queueing networks and extended queueing networks
discrete-state models such as Stochastic Petri Nets or Stochastic Process
Algebra.
behavior is often regarded as non-terminating for the purposes of analysis
(steady state behavior rather than transient behavior).
Performance Analysis Model (PAM) overview

PAM domain model employs and extends the GQAM domain model.
Workload:
PAM employs features such as the WorkloadEvent description of a stream of
arriving events
focus on some workload types: open and closed arrivals, workload generators
and traces
Behavior Scenario:
PAM uses the behavior-causality model of Scenarios and Steps
extends the properties of a Step to include more kinds of operation demands
during a step
adds the possibility of an asynchronous (non-synchronizing) parallel operation,
which is forked but never joins
other Step extension: a PassResource step which indicates the passing of a
shared resource from one process to another
Resources:
Important resources include hardware ExecutionEngines, concurrent process
threads (ScheduledResources), and LogicalResources defined by the software
logical resource examples: semaphore, lock, buffer pool, critical section
introduces a special concept of RunTimeObjectInstance as an alias for a process
or thread pool resource identified in behavior specifications by other entities (such
as lifelines and swimlanes)
Observers: uses the GQAM observer concepts.

AnalysisContext parameters
AnalysisContext (from GQAM) corresponds to the scope of an evaluation.
combines the system represented by its behaviour and resources with one or
more workloads.
gives a set of model parameters for defining the range of variation of cases that
will be analysed
One UML specification may give rise to several performance models, due to
variations in system usage, workload, allocation, deployment, and
configuration different models cases.
Parameterized NFPs are supported by the use of:
variables global to the AnalysisContext
variable names in place of numeric values of input properties for model elements.
functional dependencies of the input properties on the global variables, to define
values.
UML Model
Configuration/
Platform
Case Parameters Performance
Model
Input NFPs
(Parameter Output NFPs
Values) Performance (Performance
Model Solver Results)
Informal view of Services and Behavior

Service is an important concept in performance
requests for service may have a required quality of service
an actual service is defined by a BehaviorScenario, with a provided quality of service
Services may be incorporated into the modeled behavior in three ways:
by making a serviceDemand from a Step to a RequestedService, representing an
operation offered at some interface, which is in turn defined by a BehaviorScenario
by making a behaviorDemand from a Step to directly invoke a BehaviorScenario
by making an extOpDemand from a Step to request an external service, which is
defined in the performance environment outside the UML model.
PWorkloadGenerator
« use »
GQAM_Workload ::
BehaviorScenario
« use » « use » « use »
GQAM_Workload ::
BehaviorScenario PRequestedService ExternalOperation
« use » « use » « use »
« use » « use »
« use »
GQAM_Workload ::
BehaviorScenario PRequestedService ExternalOperation

PAM Domain Model: Workload and Behavior
Workload
Behavior
Scenario
Steps
PAM Step extensions

External resource demands
Resources which are not modeled within the software design may have an impact
on performance (e.g., disk access).
PAM domain model identifies "external operations" by such resources by a name
(a string), so they can be modeled in the performance model.
Demands by a Step for external operations are described by the pair of properties
externalOpDemand and externalOpCount:
externalOpDemand is an ordered list of operation names (strings)
externalOpCount is an ordered list (in the same order) of the number of demands made
during one execution of the Step (may be an integer, an average value or a probability
distribution)
Direct demands to a BehaviorScenario
Demands by a Step directly to a BehaviorScenario are described by the pair of
properties behavDemand and behavCount
“noSync” attribute
folowing a fork due to an asynchronous message or par operand, “noSync”
explicitly indicate that the respective parallel branch does not join
behaviour using noSync may provide increased concurrency and increased
performance.

PAM Domain Model: Resources
LogicalResource: defined by the software - has to be modeled as a
resource in the performance model because it introduces delays
RunTimeObjectInstance: alias for a process or thread pool resource
identified in behavior specifications by lifelines and swimlanes
Communication Channel
A message between two objects is conveyed by some
mechanism:
if the objects are in the same execution thread (process), it is
conveyed by the language runtime
if the objects are in different execution threads (processes) in the
same node (ProcessingHost) it is conveyed by the operating
system
if the objects are on different nodes, it is conveyed by a system
layer named here CommChannel, which may be:
a middlware layer (CORBA connection, Java Remote Method
Invocation, web services connection, etc.)
a Message-Passing Interface connection in a grid
a socket or secure socket connection
a more complex infrastructure such as a publish-and-subscribe
system.

Modeling Communication Channels
1. Within the same node, language runtime and operating system costs are
considered part of the scenario.
the inter-process communication cost per byte of the host may be used to
calculate the hostDemand for communication.
2. Between nodes the default is:
determine node hostDemands from the sending and receiving overhead on the
nodes
insert the latency of the link (an attribute of the connecting CommunicationsHost)
3. Between nodes the conveyance of the message may also be modeled as
an external operation, invoking a submodel of the communications layer
this may be an attractive option for modeling the behaviour of the Internet
4. Between nodes a communications layer such as CORBA may be defined as
a UML StructuredClass offering send and receive operations to the two end-
point processes
such a layer is denoted as a CommChannel with a conveyance operation
demanded by the CommunicationsStep in the scenario
its service is defined by a BehaviorScenario, which may involve directory look-
ups, authorization and redirection of requests
5. Between nodes a complex communications protocol can be modeled by a
pure BehaviorScenario not associated with a system component, but
describing a collaboration of the hosts.
Communication channels at different detail levels

Detail Level 2, conveyance modeled at the hardware level
SchedulableResource Message SchedulableResource
(sender) (receiver)
hardware-based conveyance
ProcessingHost CommunicationsHost ProcessingHost

(sender) (link) (receiver)
-sendOH -latency -recvOH
Detail levels 4 and 5: using a communications layer

SchedulableResource Message SchedulableResource
(sender) (receiver)
structured conveyance
{one or the other}
communications layer system-wide behavior

CommChannel BehaviorScenario
(sender to receiver) (sender to receiver)

PAM Domain Models: Communication
The domain model to support communications modeling contains:
CommChannel: mechanism for conveying messages
CommunicationStep: specialization of Step handling message
communication
PAM Profile: Workload, Behavior, Observer
Workload
Analysis
Context
Behavior Steps
Scenario
Observer

PAM Profile: Resources
Example 1: TCP-W deployment
«commHost» «commHost»
internet: lan:
{blockingTime = (100,us)} {blockingTime = (10,us),
capacity = (100,Mb/s)}
«execHost» «execHost» «execHost»

ebHost: webServerHost: dbHost:
{commRcvOverhead = (0.15,ms/KB), {commRcvOverhead = (0.1,ms/KB), {commRcvOverhead = (0.14,ms/KB),
commTxOverhead = (0.1,ms/KB), commTxOverhead = (0.2,ms/KB)} commTxOverhead = (0.07,ms/KB),
maxRI = 5} maxRI = 3}
«deploy»
«deploy» «deploy»
«artifact» «artifact» «artifact»

ebA webServerA databaseA
«manifest» «manifest» «manifest»

: EBrowser : WebServer : Database

Example 1: simple scenario
«PaRunTInstance» «PaRunTInstance»
eb: EBrowser webServer: WebServer database: Database
{poolSize = (webthreads=80), {poolSize = (dbthreads=5),
instance = webserver} instance = database}
1:
«PaWorkloadEvent» 2:
{open (interArrT=(exp(17,ms))), «paStep»
«PaStep» «paCommStep»
{hostDemand = (4.5,ms)} {hostDemand = (12.4,ms),
rep = (1.3,-,mean),
msgSize = (2,KB)}
3:
4:
«paCommStep»
{msgSize = (50,KB)}
«PaCommStep»
{msgSize = (75,KB)}
Example 1: GetHomePage scenario

<<GaPerformanceContext>> {contextParams=Nusers, ThinkTime, Images, R}
browser webserver imageserver database
<<PaRunTInstance>> <<PaRunTInstance>> <<PaRunTInstance>> <<PaRunTInstance>>
{instance = browser} {instance = webserver} {instance = imageserver} {instance = database}
1: getHomePage
<<GaWorkload Event>> {closed (population=Nusers),
extDelay=ThinkTime)} opt [if customer is logged in] <<PaStep>> {rep=0.2}
<<PaStep>> {hostDemand = (1,ms),
respT={((1,s,percent95),req), 2: getCustomerData <<PaStep>> {hostDemand = (2,ms)}
((R,s,percent95),calc)} 3:
<<PaCommStep>> {msgSize=(2.9, KB)}
alt [first promo]

ref
Promotion1 <<PaStep {prob = 0.4}
[else] ref
Promotion2 <<PaStep {prob = 0.6}
4: getListOfSubjects <<PaStep>> {hostDemand=(10,ms)}

5:
par 6: logInteraction <<PaStep>> {noSync}
7: getHomeImages <<PaStep>> {hostDemand = (0.5,ms),

rep = Images,
8: extOpDemand = "ImageFileOp",
extOpCount = 1}
9: <<PaCommStep>>
{msgSize = (3.4 + 5*Images)}

Example 1: GetHomePage scenario (fragment)
<<GaPerformanceContext>> {contextParams=Nusers, ThinkTime, Images, R}
browser webserver database

<<PaRunTInstance>> <<PaRunTInstance>> <<PaRunTInstance>>
{instance = browser} {instance = webserver} {instance = database}
1: getHomePage
<<GaWorkload Event>> {closed (population=Nusers),
extDelay=ThinkTime)}
<<PaStep>> {hostDemand = (1,ms), opt [if customer is logged in] <<PaStep>> {rep=0.2}
respT={((1,s,percent95),req),
((R,s,percent95),calc)}
2: getCustomerData
<<PaCommStep>> {msgSize=(2.9, KB)}
<<PaStep>>
{hostDemand = (2,ms)}
3:
Workload generator for TPC-W

<<PaStep>>
<<GaAnalysisContext>> {contextParams=(Nusers)} GetHomePage
{behavDemand = getHomePage,
<<GaWorkloadGenerator>> {population=Nusers} behavCount = 1,
blockT = (4,s)}
<<PaStep>>
NewProducts
{behavDemand = newProduct,
behavCount = 1, blockT = (4,s)}
<<PaStep>>
<<PaStep>>
{probability = 0.9} {prob = 0.7}
<<PaStep>>
GetProductDetails
{blockT = (10,s),
behavDemand = getProductDetails,
behavCount = 1}
<<PaStep>>
{probability = 0.1}
<<PaStep>>
ShoppingCart
{blockT = (12,s),
behavDemand = ShoppingCart,
behavCount = 1}
<<PaStep>>
{probability = 0.3}
<<PaStep>>
Checkout
{blockT = (45,s),
behavCount = 1,
behavDemand = Checkout}
Example 2: Building Surveillance System
Two frequently executed scenarios are chosen for
performance analysis
Access
control
User
<<includes>>
Log entry/
exit
Video Acquire/store Database

Camera video
Manage
access rights
Manager
Building Surveillance System: deployment

<<GaAnalysisContext>>
{contextParams = {Nbuffers}, {paramValues=15}}
LAN <<GaExecHost>> Backend <<GaExecHost>>

<<GaExecHost>>
Camera ControlNode DataBaseNode
<<GaCommHost>> <<GaCommHost>>
{capacity = (100,Mb/s) {capacity = (1000,Mb/s)}
<<deploy>> <<deploy>> <<deploy>> <<deploy>> <<deploy>>
<<artifact>> <<artifact>> <<artifact>> <<artifact>> <<artifact>>

BufMgr Control Acquire Store DB
<<SchedulableResource>>
<<deploy>> <<manifest>> <<manifest>> <<manifest>> <<manifest>>
<<Resource>> : CameraControl : Acquire : Store : DB

bufferpool
{maxRI = Nbuffers}

Building Surveillance System: AcquireVideo scenario
<<GaWorkloadEvent>> {closed (population=1), <<GaAnalysisContext>>
interOccTime = {(1.0,s,percent95,req), {contexParams={Ncameras, frameSize, blocks, acquireThreads,
(CycleTime95,s,percent95,calc)} storeThreads, DBThreads},
cycleInit
<<PaStep>>{hostDemand = (0.2, ms), paramValues = {100, 0.1, 15, 1, 2, 2}}
extDelay = (0, s)}
getOneImage <<PaStep>> {repetitions = Ncameras}
<<PaRunTInstance>> <<PaRunTInstance>> <<PaRunTInstance>> <<PaRunTInstance>>

Acquire bufMgr Store DB
{maxRI = 1, {maxRI = storeThreads ,{maxRI = DBThreads,
{ instance = Acquire,
maxRI = acquireThreads} instance = Acquire} instance = Store} instance = DB}
<<Pa Step>>
getBuf <<PaStep>>
{hostDemand = <<GaAcquireStep>>
(1.8,ms)} allocBuffer
{hostDemand = (0.5,ms), <<Pa Step>>
acqRes = bufferpool, storeImage
getImage resUnits = 1} <<Pa Step>>
{hostDemand =
storeDB
<<PaCommStep>> (2.5,ms), noSync}
{hostDemand =
{msgSize = (frameSize,bytes),
{((blocks*0.9), ms,mean),
repetitions = (frameSize/1500)} <<Pa Step>> (blocks*0.2),var)},
<<PaResPassStep>> freeBuf extOpDemand = writeBlock,
{passRes = bufferpool, {hostDemand =
passImage resUnits = 1} extOpCount = blocks}
(0.2,ms)}
<<Pa Step>>
<<GaReleaseStep>>
deallocBuffer cleanUp
{hostDemand = (0.5,ms),
relRes = bufferpool}
From UML+MARTE to performance models

What is needed for performance analysis in a UML model
extended with MARTE annotations:
key use cases described by representative scenarios
frequently executed, with performance constraints
resources used by each scenario
resource types: active or passive, physical or logical, hardware or
software
quantitative resource demands for each scenario step
how much, how many times?
workload intensity for each scenario
open workload: arrival rate of requests for the scenario
closed workload: number of simultaneous users

Direct UML to LQN Transformation:
our first approach
Generate LQN model structure (tasks, devices and their inter-
connections) from:
UML model of the high-level software architecture
UML deployment diagram
Generate LQN detailed elements (entries, phases, activities
and their parameters) from:
UML models of key scenarios with performance annotations
Scenarios can be represented in UML by the software designers
as:
interaction diagrams
activity diagrams
UML LQN Transformation Algorithm
*HQHUDWHWKH/41PRGHOVWUXFWXUH
GHWHUPLQH/41VRIWZDUHWDVNVIURPKLJKOHYHOFRPSRQHQWV
GHWHUPLQH/41KDUGZDUHGHYLFHVIURPGHSOR\PHQWGLDJUDP
*HQHUDWH/41HQWULHVSKDVHVDFWLYLWLHVIURPVFHQDULRV
IRUHDFKVFHQDULRSURFHVVWKHDFWLYLW\ LQWHUDFWLRQ GLDJUDP V
PDWFKLQWHUFRPSRQHQWFRPPXQLFDWLRQVW\OHIURPSDWWHUQ
ZLWKPHVVDJHVEHWZHHQFRPSRQHQWVIURPWKHDFWLYLW\GLDJUDP
GLYLGH WKHDFWLYLW\GLDJUDPLQWRVXEJUDSKVFRUUHVSRQGLQJ
WRGLIIHUHQW/41HQWULHVSKDVHVDQGDFWLYLWLHV
FUHDWHWKHUHVSHFWLYH/41HOHPHQWV DQGFRPSXWHWKHLUSDUDPHWHUV
PHUJHWKH/41VXEPRGHOV FRUUHVSRQGLQJWRGLIIHUHQWVFHQDULRV
7UDYHUVHWKH/41JUDSKDQGZULWHRXWWH[WXDOPRGHOGHVFULSWLRQ

LQN model of a Building Surveillance System
acquireLoop
acquireLoop VideoController
VideoController User Users
[1.8]
[1, 8] rate=0.5/sec
UserP
($N) (1)
procOneImage AcquireProc readCard CardReader

[1.5,0] [1, 0]
Applic
(1,0) CardP
(1,0) CPU
alloc BufferManager admit AccessController

[0.5, 0] [3.9, 0.2]
(forwarded) (0, 0)
bufEntry
bufEntry alarm Alarm
Buffer
Buffer Dummy
[0,0]
(1, 0) (1, 0) (1, 0)
(forwarded) AlarmP
(0, 1)
getImage passImage AcquireProc2 storeImage StoreProc (0, 0.2) lock Lock

[12,0] [0.9, 0] [3.3, 0] [0, 500]
($P, 0) LockP
(1, 0) (1, 0)
network Network releaseBuf BufMgr2 writeImg readRights writeEvent DataBase

[0, 1] (infinite) [0.5, 0] [7.2, 0] [1.8,0] [1.8, 0] (10 threads)
($B, 0) (0.4, 0) (1, 0)
DB
CPU
NetP writeBlock readData writeRec Disk
[1, 0] [1.5, 0] [3, 0] (2 threads)
DiskP
LQN model of a Building Surveillance System

acquireLoop VideoController User Users
[1.8] rate=0.5/sec
UserP
($N) (1)
procOneImage AcquireProc readCard CardReader

[1.5,0] [1, 0]
Applic
(1,0) CardP
(1,0) CPU
alloc BufferManager admit AccessController

[0.5, 0] [3.9, 0.2]
(forwarded) (0, 0)
bufEntry alarm Alarm

Buffer Dummy
[0,0]
(1, 0) (1, 0) (1, 0)
(forwarded) AlarmP
(0, 1)
getImage passImage AcquireProc2 storeImage StoreProc (0, 0.2) lock Lock

[12,0] [0.9, 0] [3.3, 0] [0, 500]
($P, 0) LockP
(1, 0) (1, 0)
network Network releaseBuf BufMgr2 writeImg readRight s writeEvent DataBase

[0, 1] (infinite) [0.5, 0] [7.2, 0] [1.8,0] [1.8, 0] (10 threads)
($B, 0) (0.4, 0) (1, 0)
DB
CPU
NetP writeBlock readData writeRec Disk
[1, 0] [1.5, 0] [3, 0] (2 threads)
DiskP
Using the LQN Model for Improvements
Base case system capacity: 20 cameras

problem: software bottleneck at the buffers
Adding software resources:
4 Buffers and 2 StoreProc threads
result: 40 cameras supported, performance improvement 100%
next problem: hardware bottleneck at the processor
Replicating the processor:
Dual Application CPU
Increasing software concurrency level
use asynchronous messages – raise concurrency level
Agenda
09:00 am to 10:15 am
MARTE foundations
10:45 am to 12:00 am
14:30 pm to 15:00 pm
15:00 pm to 15:45 pm
16:15 pm to 17:00 pm
17:00 pm to 17:30 pm

MARTE Frontiers and Challenges
MARTE define the language constructs only!
Common patterns, base building blocks, standard NFP annotations
Generic constraints that do not force specific execution models, analysis
techniques or implementation technologies
It does not cover methodologies aspects:
Interface-Based Design, Design Space Exploration
Means to manage refinement of NFP measurement models
Concrete processes to storage, bind, and display NFP context models
Mapping to transform MoCCs into analysis models
MARTE is to the RTES domain as UML to the System &

Software domain: a family of large and open
specification formalisms!
Questions ?
www.martes.org
Workshop on model-based design and validation for RTES
Held in co,njunction with trhe Models 2007 conference
www.promarte.org
The MARTE web site
www.papyrusuml.org
On open source Eclipse plug-in for UML2 graphical modeling
MARTE implementation available end of July within the V1.7
relalease of the tool
Already available on:
https://speedy.supelec.fr/Papyrus/svn/Papyrus/extensions/MARTE/head/
Working on:
https://speedy.supelec.fr/Papyrus/svn/Papyrus/core/...

MARTE A New Standard For Modeling and An

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MARTE A New Standard For Modeling and An

Uploaded by

Copyright:

Available Formats

MARTE:

A New Standard for Modeling and Analysis

Dr. Sébastien Gérard

Dr. Julio Medina

Pr. Dorina Petriu

(with the contributions of: Huascar Espinoza,

Extracted from B. Selic presentation during Summer School

Inspired from B. Selic presentation during Summer School

Modeled system Functional model

 To minimize development risks

 To improve communication ...

 To focus on specific domain expertise while developing software system

Characteristics of Useful Models

To be useful, engineering models must satisfy all of

Can you spot the architecture?

…and its UML Model

Can you spot the architecture?

 Models can be refined continuously until the specification is complete

Model-Driven Style of Development (MDD)

Software has the rare property that it allows us

 This ensures perfect accuracy of software models,

Two Kinds of OMG Modeling Languages

GPL (General Purpose Language)

 Component available at design-time

 Hierarchical structure description of

From UML 1.x to UML 2.0: Dynamic Point of View

Enhanced version of UML1.x statemachine:

UML2 Behavior Diagram Depict data/object/control flow diagrams:

State Machine Diagram Activity Diagram Use Case Diagram

Timing Diagram Interaction Overview Diagram

Focus on system state changes regarding time

Specialization of activity diagrams

 Systems Modeling Language (www.omgsysml.org)

 UML-compatible systems modeling language

 Aligned with the ISO AP-233 standard

From UML 2.0 to SysML: Static Point of View

 Reused of UML2 structured classes.

UML2 Behavior Diagram

State Machine Diagram Activity Diagram Use Case Diagram

Sequence Diagram Communication Diagram

Timing Diagram Interaction Overview Diagram

Extensions of SysML activity diagram:

Domain Specific Modeling Languages

But mainly… balance between expressive power and simplicity!

 Main approaches to defining a DSML

Profiling UML for a Domain

 How to face these limitations?

Outlines of UML2 Extension Mechanisms

Recommendations and Report Deadline: 4 July 2008 MARTE v1.0

UML Profiles for RTES

 Despite its extensive use, several improvements were required:

Hence, a Request For Proposal for a new profile was issued.

Ref. of MARTE RFP (realtime/05-02-06):

The ProMARTE Team

* Submitter to OMG UML Profile for MARTE RFP

Design Pattern Adopted for the MARTE Profile

 Stage 2 Æ Mapping of MARTE domain models towards UML2

Specialization of MARTE fondations Specialization of foundations for

Non-Functional Properties (NFPs)

But UML expression syntax is also not sufficient!!

Variables? Structured Values?

The MARTE’s NFP sub-profile

 Slots value of classifier instance

To minimize development risks

To improve communication ...

To focus on specific domain expertise while developing software system

Models can be refined continuously until the specification is complete

This ensures perfect accuracy of software models,

Component available at design-time

Hierarchical structure description of

Systems Modeling Language (www.omgsysml.org)

UML-compatible systems modeling language

Aligned with the ISO AP-233 standard

Reused of UML2 structured classes.

Main approaches to defining a DSML

How to face these limitations?

Despite its extensive use, several improvements were required:

Stage 2 Æ Mapping of MARTE domain models towards UML2

Slots value of classifier instance

Define allocation relationships and its features

Introduce no new component-related concepts

Non-atomic flow port example

Classifier behavior specification

A UML profile for modeling APIs of RT/E sw execution supports

In which steps shall I use SRM ?

Details of SRM through the OSEK/VDX case study

Interests to use SRM through examples

RTOS API modeling with UML is already possible

OSEK/VDX architecture consists of three layers:

Example of provided services

Extract from the SRM::SwConcurrency meta model