Page 1

Using the UML Profile for Schedulability, Performance and Time

Bruce Powel Douglass, Ph.D.

Chief Evangelist

I-Logix, Inc.

www.ilogix.com

bpd@ilogix.com

Page 2

About the Author• 20++ years in safety-critical hard-real time systems• Mentor, trainer, consultant in real-time and object-oriented systems• Author of

• Real-Time UML 2nd Edition: Efficient Objects for Embedded Systems (Addison-Wesley, Dec. 1999)• Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns (Addison-Wesley, 1999)

• Advisory Board• Embedded Systems Conference • UML World Conference• Software Development Magazine

• UML World Advisory Board• Co-chair of OMG RTAD Work Group

Page 3

Collaborators

• This work is a collaborative development effort by a number of companies and individuals. They include (primary contact, in alphabetical order by company)– Alan Moore (Artisan Software Tools, Inc.)– Bruce Douglass (I-Logix Inc.)– Bran Selic (Rational Software Corporation,

Inc.)– Morgan Bjorkander (Telelogic AB)– Mark Gerhardt (Timesys Corporation)– Ben Watson (TriPacific Software)

Page 4

Agenda

• What’s a Profile and Why Do I Care?• Overview of the RT Profile Submission• General Resource Model• Models of Time• Concurrency Model• Schedulability Model• Ongoing Work• Using the Profile• Work ongoing in the OMG

Page 5

What’s A Profile and Why Do I Care?

Page 6

UML Profiles

• A UML Profile is a specialized subset of the UML that– Is consistent with the UML specification– May be constrained to omit portions of the UML

or constrain how it is used– May include custom or specialized notation– Applies to a vertical market or application

domain– Extends or specializes the UML using the

“lightweight extension mechanisms”• Stereotypes• Tagged Values• Constraints

Page 7

The “RT UML” Profile

• Submitted in response to an OMG RFP – RFP for a UML Profile for Schedulability,

Performance, and Time (OMG document ad/99-03-13).

– RFP generated by the Real-Time Analysis and Design Working Group (RTAD) within the OMG

• Submitters (in alphabetical order):– Artisan Software Tools, Inc.– I-Logix Inc.– Rational Software Corporation, Inc.– Telelogic AB– Timesys Corporation– TriPacific Software

Page 8

Goal of the RT Profile

• RFP calls for “proposals for a UML profile that defines standard paradigms of use for modeling of time-, schedulability-, and performance-related aspects of real-time systems”– Define some standard means to capture real-time

modeling concerns– Permit exchange of model information between tools, e.g.

• Between design automation tools• Between design automation and schedulability tools

– Facilitate communication of design intent among engineering staff and other stakeholders

Note: The UML is considered to be fully adequate tomodel real-time and embedded systems. The profileis NOT necessary to make UML applicable to real-time systems.

Page 9

Guiding Principles

• Do not change the UML unless absolutely required

• Do not limit the way UML is used.

• Provide the ability to annotate a UML model to allow for [quantitative] analysis in a standard way.

• Do not require a deep understanding of applicable analysis techniques, e.g.– Rate monotonic analysis– Queuing theory

Page 10

(More) Guiding Principles

• Simple analysis should be simple to do. More complex analysis may require more work.

• Support, but do not restrict modeling to existing techniques.– E.g. RMA, DMA

• Automated tools should be able to influence the UML model.– E.g. update priorities of task threads so that they

become schedulable

• Support both model analysis and synthesis

Page 11

Using the RT Profile

Provide AnalysisResource Model

ProvideInfrastructure

ProvideInfrastructure

Model

InfrastructureProvider

AnalysisMethodProvider

Modeler

ProvideAnalysisMethod

SynthesizeModel

AnalyzeModel

ImplementSystem

Page 12

Overview of the RT Profile Submission

Page 13

Response to the RFP

• RFP was issued by the OMG in March, 1999

• A consortium of companies formed to respond to the submission

• The response has been adopted by the OMG in 2001

Page 14

General Approach

• Use light-weight extensions to add standard modeling approaches and elements– Stereotypes, e.g. resources– Tagged values, e.g. QoS properties

• Divide submission into sub-profiles to allow easier comprehension and usage of relevant parts

Page 15

RT Profile StructureCommonBase

Infrastructure

EnhancedTimeRT_CORBA

Resource

Time Concurrency

AnalysisMethods

SchedulabilityAnalysis

Required by virtually ALL real-time systems

Technology-specific subprofiles

Page 16

One person’s abstraction is another’s Concretization

• Models can always be viewed at multiple levels of abstraction

• Analysis may be need to be done at any or all of these levels of abstraction

• There is intrinsic difficulty in maintaining consistency among different levels of abstraction

Page 17

Abstraction Levels

DisplayDataTask

{period = 100ms;Execution time = 10ms;

Priority = 3;Deadline = 100ms; }

DisplayData Task

Sensor

acquire

FilterPolicy

filter

Waveform Queue

putget

Waveform View

drawscroll

{Execution time = 3 ms;Deadline = 25ms; }

{Execution time = 4 ms;Deadline = 40ms; }

{Execution time = 0.5 ms;Deadline = 5ms; } {Execution time = 0.5 ms;

Deadline = 5ms; }

{Execution time = 1.5 ms;Deadline = 20ms; }

{Execution time = 1 ms;Deadline = 5 ms; }

Page 18

General Resource Model

CommonBase

Infrastructure

EnhancedTimeRT_CORBA

Resource

Time Concurrency

AnalysisMethods

SchedulabilityAnalysis

Page 19

Basic Concepts Of the GRM

• Resource: a model element that has some finite properties– reflects some finite physical quantity– may be logical (e.g., buffers) or physical– resources offer services (client-server model)– need to quantify the demand/supply of services

• Quality of Service (QoS): limitations on services offered by a resource. – a (usually quantitative) specification of:

• the level of service required by a client from a resource or

• the level of service offered by a resource to its clients

Page 20

GRM (Static Form)

• A somewhat simplified view of the relations between resources and clients of those resources

• Allows general, but not necessarily, detailed quantitative analysis, e.g.– Global RMA

Page 21

GRM (Static Form)

AnalysisContext

ResourceService

0..n0..n +offeredQoS

Resource

0..n

+offeredQoS

0..n

1..n

1..n

1..n

1..n

0..n0..n

ResourceUsage

0..n

+requiredQoS

0..n

1..n

1..n

1..n

1..n

1..n0..n 1..n0..n

1..n0..n 1..n0..n

/

QoSCharacteristic

Page 22

Required/Offered QoS

Page 23

Required/Offered QoS

Page 24

GRM (Static Form) Example 2

Page 25

GRM (Static Form) Example 2

Page 26

GRM (Dynamic)

• Takes into account the dynamic behavior for qualitative analysis

• More detailed, permitting more detailed qualitative analysis

Page 27

GRM (dynamic form)

0..n

AnalysisContext

ScenarioEvent

ResourceService

QoSCharacteristic

0..n +offeredQoS

Resource

0..n

+offeredQoS

0..n

1..n

1..n

1..n

1..n

0..n0..n

{ordered}

ScenarioStep

0..10..1

ResourceUsage

0..n

+requiredQoS

0..n

1..n

1..n

1..n

1..n

1..n0..n 1..n0..n

1..n0..n 1..n0..n

/

Scenario0..n

0..1

0..1

0..1

0..1

0..n

0..1

0..n

0..1

/

0..n

1

0..n

1

/

ResourceClient

0..n +participants 0..n

0..1

Page 28

GRM (Dynamic) Example

1. sendData

2. acquireData

3. filterData

4. packetizeData

5. transmitPacket

{qosActualExecTime = 7ms}

{qosActualExecTime = 4ms} {qosActualExecTime = 2ms}

{qosActualExecTime = 1ms}

{qosActualExecTime = 1ms}

Page 29

Models of Time

CommonBase

Infrastructure

EnhancedTimeRT_CORBA

Resource

Time Concurrency

AnalysisMethods

SchedulabilityAnalysis

Page 30

Time Model

TimingMechanism

Resource

TimeEventScenarioEvent

PhysicalInstant

Timer

isPeriodic : Boolean

setValue()readValue()start()stop()destroy()

+generatedEvent

0..n

1

TimeValue

addTime()subtract()multiplyBy()divideBy()lessThan()greaterThan()greaterThanOrEqual()lessThanOrEqual()equal()

1..n

0..n

1..n

0..n

models

1

0..n

+value

1

0..n

ScenarioEvent0..n1 0..n1

0..n

0..n

+timestamp

0..n

0..n

Duration

1+start 1 1 +end1

1 0..n1 0..n

/

1 0..n

+currentValue

1 0..n

1 0..n

+maximalTime

1 0..n

1

0..n

+origin1

10..n

+resolution

1

0..n

0..n

+standard0..n

0..n

DiscreteTimeValue

DenseTimeValue

ClockTick Timeout

Clock

accuracy

drift

setValue()readValue()start()stop()

Page 31

Concurrency Model

CommonBase

Infrastructure

EnhancedTimeRT_CORBA

Resource

Time Concurrency

AnalysisMethods

SchedulabilityAnalysis

Page 32

Concurrency Model

Page 33

Schedulability ModelCommonBase

Infrastructure

EnhancedTimeRT_CORBA

Resource

Time Concurrency

AnalysisMethods

SchedulabilityAnalysis

Page 34

Schedulability Modeling

Event

AbsoluteDeadlineRelativeDeadlineRecurrencePatternOverlaps

AnalysisContext

PassiveResource RealTimeSituation

defaultTimeUnits

Service

ExecutionTime

ResourceService

ActiveResourceProtectedResource

Scenario ScenarioEvent

ScenarioStep

{ordered}

ResourceAction

SchedulingPriorityisPreemptableExecutionTimeRelativeStartTime

0..n0..n

SchedulableEntity

ReleaseTimeReadyTimeExecutionTimeBlockingTimePreemptionTimeDelayTimeWorstCaseRespTimeSpareCapacityisSchedulable

0..n0..n

0..1 0..n

+triggeredSE

0..1 0..n

{ordered}

matchinghierarchies

{ordered}

AccessedResource

AccessControlPolicyCapacityAccessTimeisMultiProcessorAccessible

0..n

0..n0..n

Step

RelativeStartTimeBlockingTimePreemptionTimeWorstCaseExecTimeWorstCaseComplTime

1 0..n

+spec

1 0..n

1..n

+root

0..n0..n

0..n

0..n

ProcessingResource

SchedulingPolicyAccessControlPolicyProcessingRateContextSwitchTimePriorityRangeisPreemptableUtilizationisSchedulable

0..n

0..n

Executes

1

0..n

0..n

Resource

{ordered}

Page 35

Using the Profile

Page 36

GIGO• Select the appropriate stereotypes and tags of

the schedulability model to match the kind of analysis desired– Global RMA

• Elements: active objects, resources• Tags: execution time, deadline, period, priority, blocking

time, priority ceiling

– Detailed RMA• Elements: active objects, resources, actions, events,

scenarios, scenario steps, messages• Tags: execution time, deadline, period, priority, blocking

time, priority ceiling

– Simulation• Depends on particular approach

– etc

Page 37

Model Processing Paradigm

UMLModel

ModelProcessor

DeliveredSystem

Modeler

Customer

Tool vendor

Page 38

Page 39

Model Synthesis

1 Modeler designs system to meet requirements using standard stereotypes defined in the profile

2 Modeler annotates model with QoS properties using standard tags defined in the profile depending on the kind of analysis desired, for example– Priority (e.g. SAPriority)– Worst case execution time (e.g.

SAWorstCaseExecutionTime)– Period (e.g. SAPeriod)– Blocking (e.g. SABlockingTime)– Deadline (e.g. SADeadline)

Page 40

Model synthesis

3a Modeler submits QoS annotated model to model processor – This may be written by a schedulability analysis tool vendor

and know all the defined stereotypes and tags in the profile

4a Processor munches model– Analyses model for schedulability– Identifies constraint / allocation violations– Suggests changes to QoS annotations to enhance

schedulability (may automatically update model)– Marks model as schedulable or not

5a Modeler manipulates model QoS properties or model itself to make it schedulable

6a Repeat as necessary

Page 41

Model Synthesis

3b Modeler generates application from Model

4b Modeler tests model with test vectors (incl. QoS characteristics)

5b Modeler updates model as necessary

6b Repeat as necessary

7b Modeler delivers system to customer

Page 42

ROPES Approach to Using RTP

RequirementsAnalysis

Systems Engineering

Object Analysis

Analysis

ArchitecturalDesign

MechanisticDesign

DetailedDesign

Design

TranslationTesting

Party!

IntegrationTesting

ValidationTesting

CodingUnit

Testing

IterativePrototypes

Capture Functional & QoS

requirements

Define high level architecture & HW/SW

breakdown

Define architecture using concurrency and other

patterns Identify semantic “analysis-level” classes to realize Use

Case collaborations

Refine collaborations by applying design patterns

Refine object internal details

Test interfaces among components and

subsystems

Test functional and QoS Requirements

Page 43

ROPES – Requirements Analysis• Use cases organize requirements• Two Approaches

– By example– By Specification

• Detailed Requirements– Functional requirements

• Messages• Sequences of messages• States• Actions and activities• Transitions

– Quality of Service• Constraints on any of the above• States

Page 44

ROPES – Systems Engineering

• Optional – depends on scope of project• Defines subsystem architecture (technology

independent)• For each subsystem

– Define subsystem-level use cases (derived from system use cases)

• Functional requirements• QoS requirements

– Define inter-subsystem interfaces– Demonstrate adequacy of architecture through

execution of elaborated use case scenarios– Make hw/sw decomposition to optimize QoS

Page 45

ROPES – Object Analysis

• For each use case– Identify semantic objects collaborating

together to realize the use case– Test adequacy of collaboration by

elaborating use case scenarios with collaboration structure and executing them

– Use propagation of constraints to decompose use case QoS requirements into performance budgets on operations, messages, states, transitions, actions, etc.

Page 46

ROPES – Architectural Design

• Apply architectural design pattern in each of the 5 areas of architecture– Subsystem and component– Concurrency– Distribution– Safety and Reliability– Deployment

Page 47

ROPES – Concurrency Architecture

• Identify tasks using Task Identification Strategies

• Define task synchronization / scheduling mechanisms

• For each task – Create an active object– Group appropriate semantic (analysis-level)

objects into the active object via composition relation

– Add QoS properties (priority, period,etc)– Refine scenarios via elaboration– Test concurrency model via execution of

elaborated use case scenarios

Page 48

ROPES – Mechanistic Design

• For each collaboration– Optimize collaboration against QoS by

applying mechanistic design patterns

Page 49

ROPES – Translation

• Translate UML model into source level language– Automatically (code-gen)– Manually– Combination

• Link in legacy source code and components• Unit test

– Functional– Operation performance budgets (QoS constraints

on operations, actions, messages, etc)

Page 50

ROPES – Integration Test

• Apply Integration Test plan– This can be started after subsystem

architecture and its interfaces are known • Systems Engineering (if present)• Architectural Design

– Demonstrates adherence to architectural design

• Signature• Preconditions / postconditions• QoS contracts (required QoS vs offered QoS)

Page 51

ROPES – Validation Test

• Tests against requirements– Known after Requirements Analysis– Use case scenarios translate into test

vectors– Test Both

• Functional Requirements• QoS requirements

Page 52

Work ongoing in the OMG

Page 53

Work Ongoing• An RFP is currently being written in RTAD to

address non-time related QoS, e.g. fault tolerance, safety, reliability, etc.

• Action Semantics submission should be submitted by this time

• A total of 3 UML 2.0 RFPs are released and submissions work is underway. – Infrastructure (internal metamodel stuff)– Superstructure (modeler-visible stuff)– OCL

• XMI standard RFP release to include diagram and notation

Page 54

Some References of Interest

• Douglass, Bruce Powel Doing Hard Time: Developing Real-Time Systems With UML, Objects, Frameworks and Patterns Addison-Wesley, 1999

• Douglass, Bruce Powel Real-Time UML 2nd Edition: Developing Efficient Objects for Embedded Systems Addison-Wesley, 1999

• Douglass, Bruce Powel Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems Addison-Wesley, 2002

• OMG Documents (www.omg.org)– Response to the OMG RFP for Schedulability, Performance, and Time Version 1.1

(OMG Document ad/2000-08-04) – OMG RFP for a UML Profile for Schedulability, Performance, and Time (OMG

document ad/99-03-13)– UML 2.0 Infrastructure RFP ( OMG Document ad/2000-09-01)– UML 2.0 OCL RFP (OMG Document: ad/2000-09-03)– UML 2.0 Superstructure RFP (OMG Document: ad/00-09-02)– OMG Unified Modeling Language Version 1.4