MARTE: The Future of the UML Profile for Schedulability ... · MARTE: The Future of the UML Profile...

MARTE: The Future of the UML Profile for

Schedulability, Performance and Time

11 July, 2005

1Murray Woodside and Dorina C PetriuCarleton University

MARTE: The Future of the UML Profile for Schedulability, Performance and Time page 1© C.M. Woodside, D.C. Petriu, 2005 WOSP’2005

MARTE: The Future of the

UML Profile for Schedulability,

Performance and Time

Murray Woodside and Dorina C. PetriuCarleton University

Department of Systems and Computer EngineeringOttawa, Canada, K1S 5B


Three OMG Profiles

� UML Profile for Schedulability, Performance and Time (SPT)� current OMG standard for UML 1.4 / UML1.5� OMG adoption process:

� Request For Proposals (RFP) – issued 2000

� Initial and revised proposals – 2001, 2002� Finalization Task Force – makes minor corrections� Adopted Formal Specification – September 2003

� UML Profile for Modeling Quality of Service and Fault ToleranceCharacteristics and Mechanisms (QoS Profile)� current status: Finalization Task Force

� UML Profile for Modeling and Analysis of Real-Time and Embedded systems (MARTE)� current status: RFP issued February 2005


What is a UML Profile

� A package of related specializations of general UML concepts that capture domain-specific variations and usage patterns� A domain-specific interpretation of UML

� Fully conformant with the UML standard� does not extend the UML metamodel� uses only standard extension mechanisms: stereotypes, tagged values,

constraints� additional semantic constraints cannot contradict the general UML

semantics� within the “semantic envelope” defined by the standard

Standard UML Semantics

Profile XProfile Y


Specializing UML: Stereotypes

� We can add semantics to any standard UML concept (metaclass) The extensions are defined as stereotypes that apply to existingmetaclasses.� Must not violate standard UML semantics

Watch

resolution: Integer

<<stereotype>>Clock

<<metaclass>>Class

tagged value or attribute of the stereotype

<<Clock>>Watch

Defining a stereotypePresentation options of

an extended class

extension relationship



11 July, 2005



Stereotypes in UML 2.0

� A Stereotype extends an existing metaclass and enables the use of platform or domain specific terminology

� A Stereotype may have properties (attributes), which are referred to as tag definitions � when the stereotype is applied to a model element, the values of the

properties are referred to as tagged values

� A Stereotype may only generalize or specialize another Stereotype� According to the most recent UML 2.0 Superstructure specification

(document ptc/04-10-12):� it is not possible to define an association between two stereotypes or

between a stereotype and a metaclass� such associations within profiles can be achieved in limited ways by

specializing some existing associations from the reference metamodel� BUT this restriction may be somehow relaxed by the Finalization Task

Force, by allowing for a tagged value to refer to the name of other model elements.


Constraints as an annotation mechanism

� A constraint is a condition expressed in natural language text or in a machine readable language for expressing semantics� a constraint can be attached to more than one model element

� A user-defined constraint is described in a specified language, whose syntax and interpretation is a tool responsibility� OCL: a predefined language for writing constraints � other languages are allowed (programming or natural)

� Two main rules:a) the value specification for a constraint must evaluate to a boolean

valueb) evaluating the value specification for a constraint must not have side

effects.


Current UML SPT Profile:

the Performance Subprofile


Current UML SPT Profile Structure

Analysis Models Infrastructure Models

«modelLibrary»

RealTimeCORBAModel

General Resource Modeling Framework

«profile»

RTresourceModeling

«profile»RTconcurrencyModeling

«import»«import»

«profile»

RTtimeModeling

«profile»

PAprofile

«import»

«profile»

RSAprofile

«import»

«profile»

SAProfile

«import»«import»



11 July, 2005



Performance Profile: fundamental concepts

� A Scenario defines a response path through the system, so it’s the unit for which performance specifications and predictions are given.� however, there is no Scenario stereotype in the Performance Profile to

be applied to a UML model element� scenario annotations are attached to its first Step instead

� a Scenario is composed of Steps (which can be simple or composite)� a Step stereotype has tags that define performance specifications

� workload intensity parameters, demands for resource usage, etc.

� Scenarios use the services of Resource instances� resource parameters: service policy, multiplicity, operation time� resource performance measure: utilization� quantitative resource demands given for each step

� Each scenario is executed by a Workload:� open workload: requests arriving at in some predetermined pattern� closed workload: a fixed number of active or potential users or jobs


Performance Profile: the domain model

PerformanceContext

WorkloadresponseTimepriority

PScenariohostExecDemandresponseTime

PResourceutilizationschedulingPolicythroughput

PProcessingResourceprocessingRatecontextSwitchTimepriorityRangeisPreeemptible

PPassiveResourcewaitingTimeresponseTimecapacityaccessTime

PStepprobabilityrepetitiondelayoperationsintervalexecutionTime

ClosedWorkloadpopulationexternalDelay

OpenWorkloadoccurencePattern

0..n

1..n

1..n 1

11

1..n 1..n

0..n

0..n

0..n

0..1

1..n

1

1{ordered}

+successor

+predecessor

+root

+host


Performance parameters and measures

� UML performance annotations define two types of information:� Performance parameters (inputs to a performance evaluation) describe:

� workload� resource usage (measured or estimated)

� behaviour of the program � Performance measures describe the performance itself:

� response time, throughput, utilization, percentage of lost packets, etc. � may be given as required values� may be performance predictions - performance evaluation results

� for the same measure we can have:• required and predicted values • more than one specified value (normal service, premium service) • more than one prediction


Specifying Time Values

� Time values can be represented by a special Value stereotype «RTtimeValue» in different formats:� 12:04 (time of day)� 5.3, ‘ms’ (time interval, unit)� 2000/10/27 (date)� Wed (day of week)� $param, ‘ms’ (parameterized value, unit)� ‘poisson’, 5.4, ‘sec’ (time value with a Poisson distribution)� ‘histogram’ 0, 0.28 1, 0.44 2, 0.28, 3, ‘ms’

P=0.28P=0.44

P=0.28

0 ms 1 ms 2 ms 3 ms



11 July, 2005



Specifying Performance Values

� A complex structured string with the following format<performance-value> ::=“(“<kind-of-value> “,“ <modifier> “,“ <time-value>”)”

where:<kind-of-value> ::= ‘req’ | ‘assm’ | ‘pred’ | ‘msr’

required, assumed, predicted, measured

<modifier> ::= ‘mean’ | ‘sigma’ | ‘kth-mom’ , <Integer> |‘max’ | ‘percentile’ <Real> | ‘dist’

<time-value> is a time value described by the RTtimeValue type

� A single characteristic may combine more than one performance values:<PAcharacteristic> ::= <performance-value> [<performance-Value>]*

� Example:{PAdemand = (‘pred’, ‘mean’, (20, ‘ms’)) }{PArespTime = (‘req’, mean, (1, ‘sec’)) (‘pred’, mean, $RespT) }

required predicted => analysis result


Specifying Arrival Patterns

� Method for specifying standard arrival pattern values:� Bounded: ‘bounded’, <min-interval>, <max-interval>� Bursty: ‘bursty’, <burst-interval> <max.no.events>� Irregular:

‘irregular’, <interarrival-time>, [<interarrival-time>]*� Periodic: ‘periodic’, <period> [, <max-deviation>]� Unbounded: ‘unbounded’, <probability-distribution>

� Probability distributions supported:� Bernoulli, Binomial, Exponential, Gamma, Geometric, Histogram,

Normal, Poisson, Uniform� What happens when other distributions are needed?

� tradeoff between � flexibility (allow users to introduce their own definitions) � simplicity/convenience of expression (i.e., provide pre-packaged

definitions).


Performance Stereotypes(1)

A deferred receivePAutilization [0..*]PAschdPolicy [0..1]PArate [0..1]PActxtSwT [0..1]PAprioRange [0..1]PApreemptible [0..1]PAthroughput [0..1]

Classifier, Node, ClassifierRole, Instance, Partition

«PAhost»

An open workloadPArespTime [0..*]PApriority [0..1]PAoccurrence [0..1]

Action, ActionExecution,Stimulus, Action, Message, Method…

«PAopenLoad»

A performance analysis context

Collaboration, CollaborationInstanceSet, ActivityGraph

«PAcontext»

A closed workloadPArespTime [0..*]PApriority [0..1]PApopulation [0..1]PAextDelay [0..1]

Action, ActionExecution,Stimulus, Action, Message, Method…

«PAclosedLoad»

DescriptionTagsApplies ToStereotype


Performance Stereotypes (2)

A step in a scenarioPAdemand [0..1]PArespTime [0..1]PAprob [0..1]PArep [0..1]PAdelay [0..1]PAextOp [0..1]PAinterval [0..1]

Message, ActionState, Stimulus, SubactivityState

«PAstep»

A passive resourcePAutilization [0..*]PAschdPolicy [0..1]PAcapacity [0..1]PAmaxTime [0..1]PArespTime [0..1]PAwaitTime [0..1]PAthroughput [0..1]

Classifier, Node, ClassifierRole, Instance, Partition

«PAresource»

DescriptionTagsApplies ToStereotype



11 July, 2005



Applying the SPT Profile


Case Study – Building Security System (BSS)

� Select key-performance use cases

Access control

Log entry/ exit

Acquire/store video

Manage access rights

Manager

DatabaseVideo Camera

<<includes>>User


Deployment Diagram (UML 1.4)

<<PAhost>>ApplicCPU

<<PA resource>> LAN

VideoAcquisition<<PAhost>>DB_CPU

Database

<<PAresource>>

SecurityCardReader

<<PAresource>>

DoorLock Actuator

<<PAresource>>

VideoCamera

<<PAresource>>

Disk{PAcapacity=2}

AccessControl

Access Controller

Video Controller

AquireProc

StoreProc

<<PAresource>>Buffer

{PAcapacity=$Nbuf}

BufferManager


DD: Strategy and changes for UML2

Strategy:� elements that are identified in

behaviour diagrams by lifelines or swimlanes must be deployed

� other resources can be identified here (e.g. Buffer)

UML2:� “artifacts” that “manifest”

components are deployed � Activity Diagram “partitions”

group together actions with “some characteristic in common”� actions performed by an instance

may be grouped in a partition � actions may reference operations

of instances

Database

VideoAcquisition

AccessControl

Access Controller

Video Controller

AquireProc

StoreProc

<<PAresource>>Buffer

{PAcapacity=$Nbuf}

BufferManager

<<PA resource>> LAN

<<PAhost>>

DB_CPU

<<PAresource>>

SecurityCardReader

<<PAresource>>

DoorLock Actuator

<<PAresource>>

VideoCamera

<<PAresource>>

Disk{PAcapacity=2}

ApplicCPU

<<PAhost>>

<<artifact>>Access

Contol.exe

<<artifact>>Video

Acq.exe

<<artifact>>Database.exe

<<manifest>> <<manifest>> <<manifest>>

<<deploy>><<deploy>><<deploy>>



11 July, 2005



Sequence Diagram for Video Acquire/Store Scenario

<<PAresource>>

VideoController

<<PAresource>>

AcquireProc

<<PAresource>>

BufferManager

<<PAresource>>

StoreProc

*[$N] procOneImage (i)

<<GRMacquire>>allocBuf (b)

getImage (i, b)

passImage (i, b)storeImage (i, b)

<<GRMrelease>>releaseBuf (b)

freeBuf (b)

<<PAresource>>Database

{PAcapacity=10}

writeImg (i, b)

getBuffer()

store (i, b)

<<PAstep>>{PAdemand =(‘assm’,‘mean’, (1.5, ‘ms’)}

<<PAstep>>{PAdemand=(‘assm’,‘mean’, (1.8, ‘ms))}

<<PAcontext>>

o

<<PAstep>>{PAdemand=(‘ assm’,

‘mean’, ($P * 1.5, ‘ms’)),PAextOp = (network, $P)}

<<PAstep>>{PAdemand=(‘assm’,

‘mean’, ($B * 0.9, ‘ms’)),,PAextOp=( writeBlock, $B)}

<<PAclosedLoad>>{PApopulation = 1,PAinterval =((‘req’,’percentile’,95,

(1, ‘s’)),(‘pred’,’percentile’, 95, $Cycle)) }

<<PAstep>>{PArep = $N}

<<PAstep>> {PAdemand=(‘assm’,

‘mean’, (0.5, ‘ms’))}

o

o

<<PAstep>>{PAdemand=(‘ assm’,‘mean’, (0.5, ‘ms’))}

<<PAstep>>{PAdemand=(‘assm’,‘mean’, (0.9, ‘ms’))} <<PAstep>>

{PAdemand=(‘assm’,‘mean’, (1.1, ‘ms’))}

<<PAstep>>{PAdemand=(‘assm’,‘mean’, (2, ‘ms’))}

<<PAstep>>{PAdemand=(‘assm’,‘mean’, (0.2,’ms’))}

o

This object manages the resource Buffer

o


Sequence Diagram for Video Acquire/Store Scenario

<<PAresource>>

VideoController

<<PAresource>>AcquireProc

<<PAresource>>

BufferManager

*[$N] procOneImage(i)

<<GRMacquire>>allocBuf (b)

getBuffer()

<<PAstep>>{PAdemand =(‘assm’,‘mean’, (1.5, ‘ms’)}

<<PAclosedLoad>>{PApopulation = 1,PAinterval =((‘req’,’percentile’, 95,

(1, ‘s’)),(‘pred’,’percentile’, 95, $Cycle)) }

o


<<PAstep>>{PAdemand=(‘assm’,‘mean’, (0.5, ‘ms’))}o

This object managesthe resource Buffer

Result

Requirement


Video Acquire/Store Scenario: top-level AD

<<PAcontext>>

<<PAclosedLoad>>{PApopulation = 1, PAinterval=((‘req’,’percentile’, 95, (1,’s’)), (‘pred ’,’percentile’, $Cycle))}

VideoController

procOneImage*[ N ]

cycleOverhead<<PAstep>>

{PAdemand= (‘assm’,‘mean’, (1.8, ‘ms))}


composite activity detailed on the next slide


Composite activity procOneImage

wait_SP

getBuffer

<<GRMacquire>>allocBuf

wait_DB

<<GRMrelease>>releaseBuf

AcquireProc StoreProcBufferManager Database

getImage

passImage

image

store

writeImg

freeBuf

wait_SP

wait_DB

<<PAstep>>{PAdemand=(‘assm’, ‘mean’, 1.5, ‘ms’)}

<<PAstep>>{PAdemand=(‘assm’,

‘mean’,($P * 1.5, ‘ms’)),PAextOp = (network, $P)}

<<PAstep>>{PAdemand=(‘assm’, ‘mean’,( 0.5, ‘ms’)) }

<<PAstep>>{PAdemand=(‘assm’,‘mean’, (0.9, ‘ms’)) }

<<PAstep>>{PAdemand=(‘assm’, ‘mean’, (2, ‘ms’)) }

<<PAstep>>{PAdemand=(‘assm’, ‘mean’, 0.5, ‘ms’)}

<<PAstep>>{PAdemand=(‘assm’, ‘mean’, (0.2, ‘ms’))}

<<PAstep>>{PAdemand=(‘assm’,‘mean’, ($B * 0.9, ms’)),

PAextOp=(writeBlock, $B)}

storeImage

<<PAstep>>{PAdemand=(‘assm’, ‘mean’, (1.1, ‘ms’)) }



11 July, 2005



Sequence Diagram for Access Control Scenario

getRights()

User

CardReader DoorLock Alarm AccessController

Database Disk

readCard

admit (cardInfo)

readRights()[not_in_cache] readData()

checkRights()[OK] openDoor()

[not OK] alarm()[need to log?] logEvent()

writeRec()

enterBuilding

writeEvent()

<<PAstep>>{PAextOp=(read, 1)}

<<PAstep>>{PAdemand=(‘assm’, ‘mean’, (3, ‘ms’))}



<<PAcontext>>

o

o

<<PAstep>>{PAdemand=(‘assm’, ‘mean’, (1.8, ‘ms’)),

PAextOp = (network, 1)}

<<PAstep>>{PAdemand=(‘assm’, ‘mean’,

(1.5, ‘ms’)), PAprob = 0.4}


(0.5, ‘ms’)), PAprob = 1}

<<PAstep>>{PAprob = 0}



(0.2, ‘ms’), PAprob=0.2}


o

<<PAopenLoad>>{PAoccurencePattern = (‘poisson’, 120, ‘s’),PArespTime =((‘req’,’percentile’,95, (1, ‘s’)),

(‘pred’,’percentile’, 95, $RT))}

ResultRequirement


Performance Model (LQN) (or QN or Petri Net)

procOneImage[1.5,0]

alloc[0.5, 0]

bufEntry

getImage[12,0]

passImage[0.9, 0]

AcquireProc

BufferManager

Buffer

AcquireProc2

acquireLoop[1.8]

VideoController

lock[0, 500]

Lock

releaseBuf[0.5, 0]

BufMgr2

alarm[0,0]

Alarm

network[0, 1]

Network(infinite)

storeImage[3.3, 0]

StoreProc

Userrate=0.5/sec

Users

readCard[1, 0]

CardReader

admit[3.9, 0.2]

AccessController

writeEvent[1.8, 0]

writeImg[7.2, 0]

readRight s[1.8,0]

writeRec[3, 0]

writeBlock[1, 0]

readData[1.5, 0]

(1,0)

(forwarded)

(1, 0) (1, 0)(0, 1)

($P, 0) (1, 0) (1, 0)

($N)

(1, 0)

(0, 0.2)

($B, 0) (0.4, 0) (1, 0)

(forwarded)

(0, 0)

ApplicCPU

DBCPU

DiskP

LockP

AlarmP

CardP

UserP

NetP

Dummy

DataBase(10 threads)

Disk(2 threads)

(1)

(1,0)

(The Layered Queuing Network model derivation is not part of this talk)


Current SPT Limitations

� Users cannot define a delay measure between an arbitrary pair of events (an “end-to-end delay”)� currently, delay measures are associated to scenarios and steps (i.e., a

delay is associated to a single model element)� if the beginning and end events are defined by different model elements,

a delay should be associated to two model elements) � Missing annotations for the size of messages passed between

processes� network and communication delays are related to message length.

� Lack of annotations on state machine behaviours � Lack of support for component-based software engineering

� no Service and service-based QoS attributes are used now� challenge: one interface definition can be mapped to different service

realizations, each of which should be modelled separately (different behaviour, resource demands, performance results, etc.)


UML Profile for Modeling Quality of Service and

Fault Tolerance

Characteristics and Mechanisms

(QoS Profile)



11 July, 2005



Goals of QoS Profile

� QoS Profile has a broader scope than the SPT Profile, allowing for user defined QoS and Fault-Tolerance concepts.� based on ISO Quality of Service Framework (1998)� SPT Profile: focused on schedulability and performance analysis

� QoS Profile contains:� QoS subprofile - extends the General Resource Model (GRM) from the

SPT profile� QoS model library� Risk Assessment subprofile� Fault Tolerance subprofile

� Current status of the QoS Profile� The QoS profile was adopted by OMG in June 2004:

OMG document ptc/2004-06-01, June 2004� currently in the finalization phase, which precedes the formal adoption.


QoS Modeling Elements

� QoS Characteristic = a quantifiable aspect of QoS, defined independently of the means by which it is represented or controlled� quantified with some specific parameters and methods, or with other

characteristics with a lower abstraction level. � can be grouped into categories� QoS Value instantiate QoS Characteristic and gives it specific values� QoS Dimension: a characteristics may be characterized by many values

� QoS Constraints define restrictions on QoS characteristics: � QoSRequired, QoSOffered, QoSContract, CompoundConstraint

� Different QoS Levels of Execution for the same characteristics may have different constraints

� QoS Adaptation and Monitoring� for the transition from one execution mode to another requires� for the detection of faults


Catalog of QoS Categories� Performance: makes reference to the timeliness aspects

� QoS Characteristics included: latency and throughput

� Dependability: � QoS Characteristics included: availability, reliability, safety, integrity

� Security: covers protection of entities, and access to resources� QoS Characteristics included: access control and confidentiality

� Integrity: the service provided is not the service expected (e.g., different levels of error or accuracy)

� Coherence: concurrent and temporal consistency� Throughput� Latency� Efficiency: produce results with minimum resource consumption� Demand� Reliability� Availability.


QoS Profile annotation process

� QoS Annotations are done in three steps:1. Define the QoS characteristics of interest for the analysis to be carried

out in a specific domain - define template classes2. Define a Quality Model for the specific domain

� the parameters of the QoS characteristic template classes specified in the first step are all resolved by bindings

3. Annotate a UML given model - in three ways:

� attach a note with a OCL constraint to a model element � connect the constrained element with an instance of a class

stereotyped as <<QoSValue>> by a << QoSContract>> dependency(it implies the creation of additional objects in the UML model)

� stereotype the constrained model element with a QoS constraint and use AllowedValue and logicalOperator properties to reference a set of QoS Values and their relationships.



11 July, 2005



Example: Embedded Automation System

� System controlled by two cyclic control processes that are activated simultaneously and synchronized at the end of each cycle :� read a sample input from sensors

� elaborate the future state� save the new state in memory and produce output for actuators

� Fault tolerance strategy includes:� fault masking during elaboration of future state:

hw/sw replication and voting� error detection during read/save operations: sw watchdog� error diagnosis and recovery or reconfiguration from failure

� Different non-functional requirements:� performance: “cycle-time at most 15 ms”

� dependability: “mean availability at least 98%”


Example: logical viewAutomation

Site

Plant

Plant Component

Automation System

Communication

control AutomationFunction

performAutomationComponent

Automation Elaboration

Function

Automation Communication

Function

MemoryElaboration

Automation MemoryFunction

Error

PhysicalFault

cause

effect

cause

effect

HaltingFailure

affect

affect

affectWatchDog

Voter

RecoveryMechanism

notifynotify

address

address

address

address

restart-reconfigure

check-status


Example: Memory Fault Scenario

AS:Automation System

AEFi:Automation Elaboration

Function

PC:PlantComponent

ACF1:Automation Communication

Function


Function

WD:WatchDog

REC:RecoveryMechanism

FAIL:HaltingFailure

ER_MEM2:Error

FT_MEM2:Fault

V:Voter

1:init 1.1:transf

1.1.1:start

3:disab 3.1:transf

3.1.1:pause

4:compute_new_state

4.1:compute

5*:send 5.1:transf 5.1.1:outcome

7:enable 7.1:transf

7.1.1:restart

9:Iamalive 9.1:transf

9.1.1:kick

11:affect12:effect

12.2:effect12.1:affect

12.2.1:affect

14:backward_recovery

6:result

6.1:transf6.1.1:result

13:notify

13.1:diagnose

AC_MEM1:Memory

AC_COM:Communication

AC_ELABi:Elaboration

AMF2:Automation

Memory Function

AC_MEM2:Memory

10a:read 10b:read

10b.1:rd10a.1:rd

10a.1.1:I

2a:read

2b.1:rd

2b:read

2a.1:rd

2a.1.1:I2b.1.1:I

8a:save 8b:save

8b.1:cpy8a.1:cpy

8a.1.1:08b.1.1:0

AMF1:Automation

Memory Function


Step 1: Define QoS CharacteristicsLatency categoryDemand category

<<QoSCharacteristic>>latency

<<QoSCharacteristic>>alarm-latency

<<QoSDimension>>+ timer-duration: real

{unit(TimerUnit)}

TimerUnit: string

MinLatUnit:string, MaxLatUnit: string, JitterUnit:string

<<QoSCharacteristic>>resource-service-time

<<QoSDimension>>+ S: real{direction(decreasing),statisticalQualifier(Distribution)}

ExpoUnit:string,Distribution:string

<<description>>context turn-around::turn-around-valuepost resultOK: result = self.instant-of-result - self.instant-of-request

<<QoSCharacteristic>>turn-around

<<QoSDimension>>+ instant-of-request: real

{unit(requestUnit)}

<<QoSDimension>>+ instant-of-result: real

{unit(resultUnit)}

<<QoSDimension>>+ turn-around-value()

{unit(Unit),direction(decreasing)}

requestUnit:string, resultUnit: string, Unit:string

Legendfrom template library

new template definition



11 July, 2005



<<QoSCharacteristic>>resource-service-time

ExpoUnit:string, Distribution:string

<<QoSCharacteristic>>elab-service-time

<<bind>>{TemplateParameters (Unit->ms, Distribution->exponential)}

<<QoSCharacteristic>>alarm-latency

TimerUnit: string

voter-alarm-latency

<<bind>>{TemplateParameters (

TimerUnit->ms)}

<<QoSCharacteristic>>wd-alarm-latency

Step 2: Define Quality Model

� Resolve all the parameters of theQoS characteristic template classes specified in Step 1 by bindings.

� Problem: cannot bind template parameters to variables or expressions, only to concrete values.


requestUnit: string, resultUnit: string, Unit: string

<<QoSCharacteristic>>system-turn-around

<<bind>>{TemplateParameters (requestUnit->ms, resultUnit ->ms, Unit-> ms)}

<<QoSCharacteristic>>

<<bind>>{TemplateParameters (

TimerUnit->ms)}

MARTE: The Future of the UML Profile for Schedulability, Performance and Time page 38© C.M. Woodside, D.C. Petriu, 2005 WOSP’2005 Step 3


AEFi:Automation Elaboration

Function

PC:PlantComponent


Function


Function

REC:RecoveryMechanism

FAIL:HaltingFailure

ER_MEM2:Error

FT_MEM2:Fault

V:Voter

1:init 1.1:transf

1.1.1:start

3:disab 3.1:transf

3.1.1:pause

4:compute_new_state

4.1:compute

5*:send 5.1:transf 5.1.1:outcome

7:enable 7.1:transf

7.1.1:restart

9:Iamalive 9.1:transf

9.1.1:kick

11:affect12:effect

12.2:effect12.1:affect

12.2.1:affect

14:backward_recovery

6:result

6.1:transf6.1.1:result

13:notify

13.1:diagnose

AC_MEM1:Memory

AC_COM:Communication


AMF2:Automation

Memory Function

AC_MEM2:Memory

10a:read 10b:read

10b.1:rd10a.1:rd

10a.1.1:I

2a:read

2b.1:rd

2b:read

2a.1:rd

2a.1.1:I 2b.1.1:I

8a:save 8b:save

8b.1:cpy8a.1:cpy

8a.1.1:O 8b.1.1:O

AMF1:Automation

Memory Function

WD:WatchDog

<<QoSRequired>>{ context availability inv:availability-value >= 0.98}

{ context system-turn-around inv:turn-around-value <= 15}


WD:WatchDog

<<QoSOffered>>{AllowedValues =

V1, V2, V3logicalOperator = or}

<<QoSValue>>V1: wd-alarm-latency

timer-duration = 4


timer-duration = 4.5


timer-duration = 5


<<QoSValue>>mem-elab:

elab-service-time

mean = 0.5

<<QoSOffered>>


QoS Profile: What it provides

� it is only about defining QoS measures (required and offered)� very general measures... discussed later� object oriented structure� library of pre-defined measures

� user extensible

� the QoSvalue object defines the measure names� Chatacteristic defines the value and units

� a measure must be a scalar� thus, mean and variance of a delay are separate dimensions of the same

characteristic

� measures are defined by objects and associated with objects


Compare measure definitions� SPT PAPerfMeasure has

“(“ <source-modifier> “,” <type-modifier> “,” <time-value> “)”Where:

<source-modifier> ::= ‘req’ | ‘assm’ | ‘pred’ | ‘msr’(means respectively: required, assumed, predicted, and measured)

<type-modifier> ::= ‘mean’ | ‘sigma’ | ‘kth-mom’ , <Integer> | ‘max’ |’percentile,’ <real> | ‘dist’

<time-value> is a RTtimeValue type, very general

e.g. PAinterval = (‘req’, ‘percentile’, 95, (1, ‘ms’))

PActxSwT=(‘assm’, ‘mean’, (100*$a + $b, ‘microsec’))

� QoSCharacteristic has Dimension slotsQoSDimension has � units� statisticalQualifier, corresp to type-modifier above� a “direction” of increasing quality indicating whether bigger is

better or worse



11 July, 2005



Strengths of QoS Profile

� Power and flexibility� inheritance structure among constructs and among

measures

� Precision� the class definitions can contain precisde definitions of the

measures, rather than depending on “well-known” meanings

� Aligned with ISO QoS standard (which perhaps is directed mainly to network QoS)


Limitations of QoS Profile

� Heavy weight� Requires a lot of special definitions to use it (overhead to the user)

� Values must be numeric� Cannot use variables like $N, $contextSwitch� Cannot use expressions for values, as provided by the Tag Value

Language in SPT.� (but, can use expressions in constraints on values)

� Cannot express an “end-to-end” delay� more later...neither can SPT

� Does not express execution characteristics like branch probabilities, demands of Steps.� can express Open workload intensities, but not Closed


Annotation Style in the SPT and QoS Profiles


QoS Profile annotation: response time (steps 1, 2)

Step 1: use template from QoS Catalog if appropriate

Step 2: bind template

<<description>>context turn-around::turn-around-valuepost resultOK: result = self.instant-of-result - self.instant-of-request


<<QoSDimension>>+ instant-of-request: real

{unit(requestUnit)}

<<QoSDimension>>+ instant-of-result: real

{unit(resultUnit)}

<<QoSDimension>>+ turn-around-value()

{unit(Unit),direction(decreasing)}

requestUnit:string, resultUnit: string, Unit:string


requestUnit: string, resultUnit: string, Unit: string

<<QoSCharacteristic>>response-time

<<bind>>{TemplateParameters (requestUnit->ms, resultUnit ->ms, Unit-> ms)}



11 July, 2005



QoS Profile annotation: response time (step 3)

� A constraint can be attached to any model element:� structural: component, operation,

interface, port, etc.� behavioural: action, message, etc.

� Convenient expression of requirements as OCL constraints

� Definition of response-time as QoSCharacteristics allows for defining attributes such as� instant-of-request� instant-of-reply

� However, there is no easy way to:� identify the starting and ending events

corresponding to a response time� define a placeholder variable for a

response time result.

<<QoSRequired>>

{context response-time inv:turn-around-value <= 35 }

a: ProcessA b: ProcessB

request()


QoS Profile annotation: execution demand

� Note: there is no appropriate template for execution time demands in the QoS Catalog (not even in the Demand category)

Step 1: define new template

<<QoSCharacteristic>>

execution_time_demand

<<QoSDimension>>+ mean: real

{unit(Unit), statisticalQualifier(exponential)}

Unit: stringDistrinution: string

<<QoSCharacteristic>>execution_time_demand

<<QoSCharacteristic>>cpu_demand

<<bind>>{TemplateParameters

(Unit->ms,(Distribution->exponential)}

Step 2: bind template

Unit: stringDistrinution: string


Step 3: alternatives for execution demand

� can be attached to any model element, BUT

� a constraint must evaluate to aboolean value and should not have side effects

� can attach a QoSValue only to structural model elements, because dependency relationships may be defined only between classifiers

a) Attaching a constraint to a model element

<<QoSRequired>>{context cpu-demand

inv: mean = 2.8}


request()

b) Attaching a QoSValue object to a model element through a QoS dependency relationship

<<QoSValue>>m1: demand

mean = 2.8

<<QoSRequired>>

b: ProcessB


STP Profile annotation: response time

� response time for a scenario attached to its first step

� can express multiple values from different sources for the same measure by using qualifiers:� required, measured, predicted,

assigned

� multiple performance value types, as defined in TVL

� can use variables and expressions, as defined in TVL

� cannot express requirements as logical expressions as in OCL.


request()

<<PAstep>>{ PArespTime =(‘req’, ’percentile’, 95, (1, ‘s’)),

(‘pred’,’percentile’, 95, $RT) }

Result placeholder

Requirement



11 July, 2005



STP Profile annotation: execution demand

� execution demand PAdemandis but one of the attribute of the stereotype <<PAstep>>

� in a sequence diagram, the stereotype <<PAstep>> can be attached to a message or to the corresponding action execution

� in an activity diagram, <<Pastep>> can be attached to an activity

� variables and expressions can be used, as defined in TVL

� different time values can be used, as defined in TVL

<<PAstep>>{ PAdemand=

(‘assm’,‘mean’, ($B * 0.9, ms’)),… }


request()


Annotation Style Comparison

� SPT annotations� strengths

� simpler, well defined syntax for time values, performance values and expressions

� weaknesses � does not allow for defining new measures

� QoS Profile annotations� strengths:

� designed to allow for user-defined measure� weaknesses :

� complex (3 steps)� pollutes the UML model with annotation objects � no parametric annotations


Developing the SPT and QoS Profiles

� SPT PerfValues may be made a lightweight shorthand for a set of standardized QoSDimensions

� New concepts needed in both STP and QoS profiles to express “end-to-end” delays� time intervals between two arbitrary events.

� Agreement is needed on the specification of complex timing values� stochastic time values� parametric models

� symbolic variables (e.g., $C, $N, $B) and expressions in SPT Tag Value Language (TVL)

� OCL cannot be used for this purpose� expressions: express CPU demand as $C*(log($N) + $B)

� the QoS Profile does not have such a capability yet.


Importance of Symbolic Values and

Expressions

� Parametric studies in the performance domain� parameters for demands and workload� parameters for varying the requirements

� Requirements that depend on context variables� required time to download is longer for a larger file

� Demands that depend on context variables� demand to sort depends on list length� demand is composed of variable quantities� several demands depend on just a few context variables



11 July, 2005



UML Profile for Modeling and

Analysis of Real-Time and Embedded systems

(MARTE)


MARTE structure

� RFP is structured around three subsets of requirements:

1. Requirements for Time and Concurrent Resources (TCR)that define common elements for both modeling and analysis of real-time and embedded systems -evolved from SPT

2. Requirements for Real-Time and Embedded Modeling (RTEM), to provide a customization of UML for both real time and embedded systems – a new part

3. Requirements for Schedulability and Performance Analysis (SPA) of RTES to support the analysis of temporal properties by specialized analysis tools –evolved from SPT.


MARTE Profile Structure

«import»

Real-Time and Embedded Systems

Modeling(RTEM)

Time and Concurrent Resources

(TCR)

Schedulability and Performance Analysis

(SPA)

«import»

«import»

evolved from the SPT Profile

upgrade of SPTProfile... adapt to UML2... improve

...remainder of SPT concerns

...profile for mechanisms inreal-time platforms(OS and hardware)


Time and Concurrent Resource (TCR) Part: Requirements

� Semantics to support interpretation of behaviour in RT systems� Support the following time models:

� Asynchronous/Causal models � Synchronous/Clocked models, (not in SPT)� Real/Continuous time models

� Support a rich set of measures for schedulability and performance: � expressed by statistical measures (such as average, variance, percentile

values, histograms, distributions, and deterministic values)� a delay measure shall be applicable to an interval bounded by a defined

start event and a defined end event. � extensible types of measures to allow for user-defined distributions,

statistics, bound definitions, etc. � any measure shall be expressible in multiple versions (e.g., a required

value, an offered value, an estimated value, a test result value, etc. )



11 July, 2005



TCR Requirements (2)

� Provide a concrete syntax definition for time values modeling (e.g., RTtimeValue in SPT ).

� Define modeling entities to specify tasking modelsincluding concurrency and scheduling mechanisms.

� Support for modeling of software deployment on heterogeneous platforms.

� Define a resource model to describe an abstract view of the hardware architecture including:� active/passive elements (e.g. CPU, Memories, FIFO, etc.)� communication media (e.g. Busses, Crossbar, etc.)� hierarchical models of hardware (e.g. SMP, multi-

processors, etc.).� not in SPT


TCR: Synchronous Time Semantics

� Time proceeds in timeSteps (a logical clock: the duration of a step is usually supposed to be a fixed physical time)

� Several actions can be specified to occur within one timeStep� see it as a clustering of behaviour to support analysis� the actions in one timeStep can have a sequential structure

of their own which is defined in continuous time within the timeStep

� behaviour in a timeStep can process several events (messages or signals) which were sent in a previous timeStep.

� Value is for analysis at the level of successive timeSteps


The new RTEM Part: Motivation

� Provide support to model the following classes of RTES� embedded systems� reactive systems� control/command systems

� intensive data-flow computation systems

� Ambitious goal: provide a common language for those involved in RTES development:� systems engineers - concerned with the overall architecture; usually

make trade-offs between implementing functionality in hardware, software;

� hardware engineers – language not meant for detailed circuit design, just for high-level description at block level

� software engineers - language meant for detailed software development


RTEM goals

� To define a platform-independent design of a real-time and embedded system (RTES)

� To enable interoperability between different RTE development tools

� To improve communications between developers by providing a common way for modeling both hardware and software aspects of RTES and their allocation.

� To refine platform-independent designs� To refine RTE platform-specific designs � To enable the construction of schedulability/performance

analysis models for quantitative predictions � To be used for RTES software design in the MDA context



11 July, 2005



RTEM Requirements

� Embedded System Requirements� support at least static allocation of resources � define non-functional requirements related to:

� real-time constraints (e.g. deadline, response time, etc.) � embedded constraints (e.g. power consumption, memory size)

� Behavior Requirements� specify computation models for data-flow and control-flow� support deterministic behavior modeling of RTES

� Structure Requirements� high-level modeling constructs for factorization of repetitive structures� allocation of software capabilities to an abstract view of the hardware� component-based modeling for RTES hardware architectures.


RTEM Structure

RTEMDomain Concepts

RTEMProfile Definition

(extensions to UML)

POSIX ...SoC

An extensible library of sub-profiles for specific types of platform, more or less specific, including RTOS and hardware characteristics, down to SoC (system-on-chip).


Schedulability and Performance Analysis (SPA) Requirements

� Harmonize the schedulability and performance analysis metamodels

� Base profile concepts on the current version of the UML 2 standard.

� Support the expression of predecessor-successor relationshipsbetween Steps/Actions, probabilities of branching, and loop counts for both performance and schedulability analysis.

� Provide support for parameterized expressions for annotations

� Support modeling of timed-utility functions which describe the cost of delay and the relative importance or urgency of responses

� Support analysis of component-based models, by attaching measures to services offered or required at interfaces/ports.

� Provide support for analyzing state machine based models.


Toward a Proposal for the

Schedulability and Performance Analysis (SPA) Subprofile



11 July, 2005



Challenges

� Extend the domain model of the SPT Performance Profile� merge the schedulability and performance domain concepts� concepts: services, components, QoS at interfaces� Properties of OS� scenarios Vs state-machines

� Annotation style� compare SPT and QoS styles of profile (stereotypes vs. templates)

� Take advantage of QoS profile

� Expressing and attaching performance measures� parametric annotations variables, expressions, functions, late binding of

values to parameters� end-to-end delays:

� extend SPT’s attachment of a measure to a single model element

� Openness to new user-defined measures


Domain Model Extension: Services

� Different meanings for the concept of “service”a) service offered by a Resource

� processor: executes instructions� network: moves bytes� process: executes an operation� semaphore: ensure mutual exclusion to an operation� buffer: provides memory space to be used

b) service offered by a Component at an Interfacec) end-to-end or point-to-point service defined purely by a

scenario� start: triggered by an event� end: satisfaction of a postcondition (completeness criterion)


Aspects of Defining a Service

In practice these aspects may be explicit or implicit:

� Identify the entity offering the service, and the interface used

� Define the service: what is done during the service

� Application services have a full definition

� Services by middleware and physical resources are often implied indirectly


Different Kinds of Services: a “levelled” view

Application Level:� by objects and components, fully defined, with defined interface

� method of object or of interface to component� service is defined by behaviour (may return, may be end-to-end)� can use extOp in SPT for application level services which are not defined

Middleware Level:� services to link application objects� entities, interfaces and service definition implied by annotations

Physical Level:� services to execute operations or convey messages defined in application

and middleware levels� entities defined by deployment, � service is defined:

� partly by the nature of the device, and relationship (e.g. PAhost)� partly by demands annotated on operations, messages, and by

annotations to nodes describing hardware (e.g. PAdemand, PArate)



11 July, 2005



A “levelled” view (2)

� ApplicationLevel:by design

� MiddlewareLevel:implied o’head

� Physical Level:execution of operations

Step

Step extOp

message, call, signal

call

(Services offered for scheduling, I/O and storage, memory management, and network messaging)...Implied by these operations, plus an indication of the OS and middleware

Indicated: Operation has demands and component, component has artifact, artifact has deployment that indicates physical host.

The role of the Service How use of the Service is indicated

Drawn:


Component2Component1

Services seen by Levels

� Application Layer:

invoke app service(logical service)

� OS/Middleware Layer:negotiate, connect

(logical services)

� Physical Layer:

execute (physical)

Step1 Step2

OS/MW 1 OS/M 2

NIC 1 NIC 2network Proc 2Proc 1


Characteristics of a Service

� a service has Quality of Service attributes (requirements, measures, etc.)

� a service is described by a scenario, which has a workload� a service may be associated with an interface, offered by a

component� a service has a trigger which may be a signal or message

arriving to an interface (port)� a service may have one or more end points; a criterion for

completion may be a postcondition related to the end points

� progress points may be defined along the service with QoS attributes attached.


Defining QoS of a Service

� An application service is defined by a scenario.

� QoS = delay (call-return or end-to-end)

� with progress points, a set of delays

� A middleware service may be required by a Step

� in principle we could identify m/w functions (too much detail?)

� then, QoS = delay (calculated in model)

� Processor services are specified as host demands of steps

� also Disk devices, other host devices� QoS = actual delay including contention, to give the service� or: define demands as operations, and an operation time.

QoS = operation delay

� higher level QoS depends on lower level� QoS depends on lower contention: not a free-standing property



11 July, 2005



Information to support Service analysis

Two aspects:

� identify the requests or demand levels for the Service

� define the content of the service so that its QoS can be calculated�give the delay directly as a parameter

�give the demands generated by the service, for other services, so the delay can be calculated,

�give the internal structure, from which the demands can be calculated.


Demands for Services

� Application: “workload” data for the scenario

� OS and Middleware: uses of services are implied by � message sending (ORB or protocol overhead)� file I/O� knowledge (outside the UML spec) of how the application

uses the m/w, perhaps

Thus frequency of use can be worked out from frequency of Step execution.

� Processor: the host demands of Steps define the demand for processor operations. Other devices are implied similarly.


Describing the internals of a Service

� An application service is defined by a scenario. � Steps describe details to support calculation

� Middleware services are not described?� maybe more in the MARTE profile on OS and m/w� demands per service operation could be stored

� Processor services are implied by hosting of Steps/Components� also Disk devices, other host devices� the demand is the internals


Different Scenario Structures and “end-to-end” QoS

... beyond call-return delay

Delay for call-return

Response objecttoProgress1: delay, fraction, etctoProgress2: delay...toProgress3: delay...toEnd: delay...

start progress1 progress2 progress3

end

Delays for complex combinations of events... a progress point may be defined by a condition... each point has its own QoS spec

start

end



11 July, 2005



Problems with end-to-end QoS

� It is difficult to identify the events in the scenario context, for the start/end or progress points.� events have no graphical notation standard� events are associated to graphical entities as:

� send or receive of a message, or � start of end of an executionSpecification (= Step)

� a Delay stereotype could perhaps be associated with multiple messages and executionSpecifications� not allowed?

� or, each message and executionSpecification could be stereotyped, and then these are associated.


PA Domain Model Extension: QoS at interfaces

� SPT Performance Subprofile is not using the stereotype Service� Component and services in UML

� an interface of a component contains a set of operations that define services provided or required by the component

� an asynchronous service may be triggered by a signal arriving to a port� Possible solution for MARTE:

� apply the stereotype Service to an Operation defined at an interface of a component or to a Signal arriving to a port

� Issues to be considered:� an operation defined at an interface can be mapped to multiple

operation realizations (e.g., due to polymorphism)� in a performance model, each service realization has to be represented

separately, as it has different behaviour, resource demands, etc. � reporting of the performance results: not per service definition, but per

service realization.


PA Domain Model Extension:

Scenarios Vs State Machines

� Minimal changes are required to support attaching workload information to state machines� Steps on transitions, branching probabilities� must also connect behaviour through between state

machines, when one invokes anotherBUT, � State machines are defined by class

� different instances of an object may have different demands and probabilities

� this will probably limit the use of SM definitions� A scenario may use only part of the possible behaviour of

a SM... � again, one SM would support multiple scenarios


SM Annotation: a Possible Solution

� Problem: one SM may require multiple annotations for different scenarios or instances

� Solution: where needed, define specializations purely for the purpose of annotation� the base class provides defaults, specializations provide

overrides� identical SM classes, not necessarily used in the design� one specialization for each scenario

� where only one instance or one scenario, this is not neededNEGATIVES:� problem of designating the relationship� design clutter



11 July, 2005



Merging the Schedulability and Performance Subprofiles

� Many concepts are shared:� PAstep and SAaction both describe a unit of computation

with processor demands, within a scenario� PAworkload and SAtrigger define intensity of load

� sequence of steps has the same meaning� response time and deadline

� Differences are in emphasis, and usage of the information� PAstep has more general kinds of demands

� not just CPU (PAhostDemand), but also “extOp” demands� not just min and max, but statistics (mean, variance), and

distributions

� SAaction has more time attributes


Schedulability and Performance: Common Aspects

Using the usual terms for performance...

� Step in a scenario (SAaction) (often called a task)� Scenario (scheduling job, associated to an SAtrigger)

� Precedence relationships (sequence, branch, merge, fork, join, loop) (often called a task graph)

� Demands (SAworstCase) (execution time)� Stimulus and response, response time (SAtrigger)

� Host Processor (execution engine)


Differences (SA / PA)

� The “task” (SAaction) is more central in SA than PAStep is in PA:� task is scheduled (vs process in PA, and in many systems)

� task may be implemented as a process, for OS scheduling� jobs tend to be a single task, or a simple sequence

� BUT: more complex jobs are becoming common (convergence)

� Triggers tend to be more deterministic in SA (periodic, or min inter-arrival time)

� CPU demands tend to be more deterministic in SA and more constrained (by design)

� Passive resource demands are important in both� Deadlines are central in SA

� BUT: they are important in PA too... just harder to deal with!� AND: soft deadlines are more common in SA.� convergence here too


Differences (SA/PA) Suggest a Combination...

SA parameters and attributes can be expressed within PA

� execution time bound is a max CPU demand

� periodic trigger is an arrival process� used resources can be explicitly

acquired/released� deadline is a particular kind of response

time requirement (required max value)� some differences would require

augmenting PA, as noted.

HOWEVER, SA users could see this as clutter...

PA

SA

priority by step, and calculated properties



11 July, 2005



Detailed Differences: PAstep vs SAaction

CPU demand, expressed as � mean and perhaps variance� distribution (exponential, Erlang,

uniform, ...., histogram) with appropriate parameters (1 to n parameters)

� best-case, average-case and worst-case estimates of the mean

Demand counts for external operations identified by name� other devices/services not in the

software modelDelay (like a think time)Response time, interval (between

repetitions)

CPU demand � worst-case completion time: the

CPU time used in the analysisExecution attributes� priority, host, “isAtomic” � usedResources (passive resources)

Constraints on execution� release time, ready time� abs deadline, relative deadline,

“laxity” (= hard/soft deadline typeAchieved performance

� delay time (waiting)� blocking time� pre-empted time


Detailed Differences:

PAscenario vs SAscheduling job

� PAworkload is a stereotype on the first step, giving parameters

� open or closed

Precedence relationships: no differences

Scheduling is a host property

Calculated outputs:� from associated first Step,

responseTime attribute

� SAtrigger stereotypes the stimulus, with property occurrencePattern

� nominally only open

Scheduler is specified here.Outputs are spread over:� associated first SAaction properties� SAresponse stereotype on first

Action (slack)

� SAtrigger stereotype on stimulus (isSchedulable, endToEndTime)


Union of PA & SA

� OpenWorkload/Trigger� occurrencePattern� responseTime� priority (PA only)� isSchedulable (SA only)

� ClosedWorkload

� Scenario/SchedulingJob� scheduler (SA only)

� Step/Action� union of attributes seems wisest.


Union (2)

� ProcessingResource/SAengine� scheduling attributes (SA), rate, context switch cost, � utilization

� SchedulableResource� a process etc.

� capacity (multi threaded)� priority (PA)� means a realignment of PA: split PAresource into schedulable and

logical

� LogicalResource� a semaphore, buffer pool etc� units requested� capacity, time to acquire and release, consumable (?)



11 July, 2005



Expressing Performance Measures

� Complex types � expressed by statistical measures (such as average,

variance, percentile values, histograms, distributions, and deterministic values)

� extensible types of measures to allow for user-defined distributions, statistics, bound definitions, etc.

� Any measure shall be expressible in multiple versions(e.g., a required value, an offered value, an estimated value, a test result value, etc. )


Parametric Annotations

� Expressions and functions with variables of complex types� e.g., schedulability utility functions

� Late binding of values to parameters

� Ranges of values (e.g. for loops)� Language issues: TVL versus OCL


Attaching performance measures

� In SPT and QoS Profile each performance measure is attached to a single model element� response time to a scenario � execution time demand to a step� utilization to a resource

� MARTE requirement: a delay measure shall be applicable to an interval bounded by a defined start event and a defined end event� why this is a challenge:

� a UML stereotype can extend a single UML model element, so a delay measure cannot be defined as a stereotype


Openness to new user-defined measures

� Tradeoff between the simplicity of annotations (as in SPT) versus the flexibility to add used-defined measures (as in QoS Profile)

� Question - any difference between: � defining a new type for a given measure (e.g., a new

distribution for execution demand), and

� defining a new measure (e.g., a new definition for system availability)?



11 July, 2005



Conclusions

� Proposals in response to MARTE RFP are under preparation� Need to collect ideas from the software performance community

� How to merge the current Schedulability and Performance sub-profiles

� How to harmonize MARTE performance annotations with the existingQoS Profile

� Challenges in using the Performance Profile in the context of MDA� how to annotate UML models at different levels of abstraction:

� platform-independent models (PIM) � platform-specific models (PSM)� what constitutes a platform: middleware, OS, hardware?

� how to derive a performance model, which is inherently instance-based and platform dependent, by combining the PIM of an application with platform model(s).

Date post:	18-Feb-2019
Category:	Documents
Upload:	phungngoc
View:	215 times
Download:	0 times

MARTE: The Future of the UML Profile for Schedulability ... · MARTE: The Future of the UML Profile...

Documents