Real-Time
Theory and Application
Bran Selic Ben Watson
Rational Software Canada Tri-Pacific Software, Inc.
bselic@rational.com watson@tripac.com
Tutorial Objectives
To
To clarify the relationship between the object paradigm
and real -time systems
real-time
match or mismatch?
Describe
Describe and analyze UML from a real -time designers
real-time
perspective
To
To introduce the UML Profile for Schedulability,
Performance, and Time
To
To introduce an engineering -oriented design approach
engineering-oriented
for real -time systems
real-time
2
Tutorial Overview
Real-Time
Real-Time Systems and the Object Paradigm
UML
UML as a Real -Time Modeling Language
Real-Time
The
The Real -Time UML Profile
Real-Time
Engineering-Oriented
Engineering-Oriented Design of Real -Time Systems
Real-Time
Summary
Summary and Conclusions
3
Real-Time
Real-Time Systems and the Object Paradigm
Real-Time System Essentials
Real-Time
UML
UML as a Real -Time Modeling Language
Real-Time
The
The Real -Time UML Profile
Real-Time
Engineering-Oriented
Engineering-Oriented Design of Real -Time Systems
Real-Time
Summary
Summary and Conclusions
4
Real-Time System
Systems
Systems that maintain an ongoing timely interaction with
its environment
environment
signal Real-Time
source System
inputs
(state) controlled
controlled
entities
entities
signal outputs = f (inputs, state) outputs
source coordination
inputs
5
Under the Hood
Concurrency
Concurrency conflict
conflict
signal Real-Time
source Agent
System
inputs
(state) controlled
controlled
Agent
entities
entities
signal outputs = f (inputs, state) outputs
source Agent
coordination
inputs
6
Classifications of RT Systems
Based
Based on nature of key inputs
time-driven: for continuous (synchronous) inputs
time-driven:
event -driven: for discrete (asynchronous) inputs
event-driven:
Based
Based on time criticality
hard RT systems: every input must have a timely response
soft RT systems: most inputs must have timely response
Based
Based on load:
static: fixed deterministic load
dynamic: variable (non -deterministic) load
(non-deterministic)
Many
Many practical systems are combinations of these
7
Sample Real-Time Application
INSTRUCTOR
INSTRUCTOR
STATION
STATION
AIRFRAME
AIRFRAME
ATMOSPHERE
ATMOSPHERE
MODEL
MODEL
CONTROL
CONTROL PILOT
SURFACES PILOT
GROUND SURFACES CONTROLS
CONTROLS
GROUND
MODEL
MODEL
ENGINES
ENGINES
50msec
= 50 msec band
ENGINES
ENGINES
= 100 msec band (2 parts: A and B)
= 200 msec band (4 parts: A, B, C, D)
= 400 msec band (8 parts: A, B, C, D, E, F, G, H)
The
The solution is adjusted to fit the implementation
technology (i.e., the step-at-a-time programming style of
step-at-a-time
procedural programming) rather than human needs
In addition to the inherent complexity of the problem
designers need to contend with the accidental complexity
of the implementation technology
Overwhelming
Overwhelming complexity is by far the biggest hurdle in
most real -time software systems
real-time
reducing complexity is crucial to success
10
Real-Time
Real-Time Systems and the Object Paradigm
Real-Time System Essentials
Real-Time
Essentials of the Object Paradigm
UML
UML as a Real -Time Modeling Language
Real-Time
The
The Real -Time UML Profile
Real-Time
Engineering-Oriented
Engineering-Oriented Design of Real -Time Systems
Real-Time
Summary
Summary and Conclusions
11
The Essence of the Object Paradigm
Combines
Combines all the various features of a logical unit
(procedures and data) into a single package called
an object
Defines a software system as a structure of
collaborating objects
Airframe
Airframe
Control
Control
Atmosphere
Atmosphere Surfaces
Surfaces
12
Objects and Real-Time Systems
The
The structure of real -time systems tends to persist
real-time
through time because it reflects the physical entities of
the real world
This
This structure is the framework through which (infinitely)
many different behavior threads are executed
Hence,
Hence, the focus is on structure rather than behavior
The
The structural focus of the object paradigm is better
suited to real-time systems than the procedural paradigm
real-time
13
Yes, But What About...
Performance?
Performance?
the cost of abstraction (encapsulation, automatic garbage
collection, dynamic binding, etc.)
Modeling
Modeling real -time specific phenomena?
real-time
time and timing mechanisms
resources (processors, networks, semaphores, etc.)
Exploiting
Exploiting current real -time system theory?
real-time
sschedulability
chedulability analysis (e.g., rate-monotnic theory)
rate-monotnic
performance analysis (queueing theory)
14
Performance of OO Technology
Hardware
Hardware is becoming ever faster ((Moores
Moores law)
previously unacceptable response times may now be
acceptable
OO
OO software technologies are becoming real -time aware
real-time
bounded dynamic binding techniques
tunable automatic garbage collection (bounded latency)
real-time variants of popular OO languages (e.g., EC++, RT
real-time
Java)
15
Objects
Conceptual units with
a unique identity (dedicated memory)
a public interface
a hidden (encapsulated) implementation
Data Attributes
Data Attributes
Telephone1:
void:offHook ();
busy : boolean {busy = true;
reqDialtone();
offHook()
};
Operations
Operations onHook ()
ring()
16
Conceptual Objects
Not
Not all objects necessarily require a physical
underpinning
For
For example, the telephone call object
Telephone1
Telephone1 Telephone2
Telephone2
Telephone
Telephone Call
Call
Telephone Call Object
abortCall ()
addParty (t:Telephone)
reportDuration ()
In
In essence, an object is a server
generic object lifecycle:
Initialize
Initialize
Handling
Handling depends
depends Object
Object
on
on specific
specific request
request
type
type and
and object
object state
state
Wait
Waitfor
for
Invokes
Request
Request
Invokes
operations
operations on
on
other
other objects
objects void:offHook
void:offHook ();
(); Handle
{busy
{busy == true;
true;
Handle
obj.reqDialtone();
obj.reqDialtone();
Request
Request
};
};
Terminate
Terminate
Object
Object
18
Making Things Happen with Objects
Higher-level
Higher-level behavior emerges through the interactions
of individual objects
Airframe:
3.position()
3.position()
2.gust()
2.gust()
Atmosphere: Spolier:
1.roughAir()
1.roughAir()
4.change()
4.change()
19
Objects and Emergent Behavior
One
One of the main problems of many current OO
programming languages is that they do not provide a
means for specifying high -level emergent behavior
high-level
keyhole view of high -level behavior
high-level
difficult to ensure desired high -level behavior will necessarily
high-level
emerge
20
Classes and Instances
More
More than one object can be constructed from the same
specification the class
specificationthe
A design environment concept
Objects
Objects created from some class specification are called
instances of that class
A run -time concept
run-time
Class
Class (Spec)
(Spec) Class
Class Instance
Instance
TelephoneClass Telephone1:TelephoneClass
busy : boolean
offHook()
Telephone2:TelephoneClass
onHook ()
ring()
21
Inheritance and Polymorphism
A generalization and re-use mechanism
GenericTelephone
TouchTone Polymorphism:
Polymorphism: RotaryDial
Telephone different
different realizations
realizations Telephone
busy : boolean of
of the
the same
same operation
operation busy : boolean
offHook() offHook()
onHook () onHook ()
dialDigit() dialDigit()
playTone()
22
Objects: Summary
The
The object paradigm is very well adapted to real -time
real-time
software systems because of its powerful structural
modeling capability
networks of collaborating objects
In
In addition, the object paradigm comes packaged with a
number of well -established techniques:
well-established
modularity
information hiding
generalization/refinement mechanisms (e.g., inheritance)
genericity
23
Real-Time
Real-Time Systems and the Object Paradigm
Real-Time System Essentials
Real-Time
Essentials of the Object Paradigm
UML
UML as a Real -Time Modeling Language
Real-Time
The
The Real -Time UML Profile
Real-Time
Engineering-Oriented
Engineering-Oriented Design of Real -Time Systems
Real-Time
Summary
Summary and Conclusions
24
The Unified Modeling Language
Standardized
Standardized by the Object Management Group in 1997
Major
Major advantages:
widely adopted by software practitioners
widely taught in universities and technical seminars
supported by many software tool vendors
25
Evolution of UML
Planned major revision (2002) UML 2.0
Basic
Basic set of (extensible) modeling concepts
used for modeling both problems and solutions (object, class,
association)
deep semantic roots
Formal
Formal rules of semantically meaningful composition
(well -formedness)
(well-formedness)
Graphical
Graphical notation for modeling concepts
8 different diagram types (requirements, structure, behavior,
deployment)
27
Introducing Views and Viewpoints
Viewpoint: a set of related concerns regarding some system
View: a model of a system based on a particular viewpoint
abstracts out detail that is irrelevant for that set of concerns
28
Model-Based and View-Based Approaches
UML
UML uses a model-based approach rather than a view
model-based view--
based approach
View
View 22 View
View 22
w 33 w 33
i e
e w i e
e w
VVi VVi
View
View 11 View
View 11
29
UML Model Views
Requirements
Requirements (use case diagrams)
Static
Static structure (class diagrams)
kinds of objects and their relationships
Object
Object behavior (state machines)
possible life histories of an object
Inter-object
Inter-object behavior (activity, sequence, and
collaboration diagrams)
flow of control among objects to achieve system -level behavior
system-level
Physical
Physical implementation structures (component and
deployment diagrams)
software modules and deployment on physical nodes
30
Use Case Diagrams
Used
Used to capture functional requirements
useful as principal drivers of the overall development process
AircraftSimulator
AircraftSimulator
Use
Use case
case
Fail
Fail one
one
instructor
instructor engine
engine
actor
actor include
include
Prepare
Prepare flight
flight Run
Run checklist
checklist
trainee
trainee
Land
Land plane
plane
31
Use Cases and RT Systems
As
As useful as in any other domain
fundamental drivers of definition, development, and testing
However.
However.
Focus on function (functional requirements)
In RT systems, much focus on non -functional requirements
non-functional
e.g.,
e.g., end-to-end delays,
end-to-end delays, maximum
maximum response
response times,
times,
No standard way of associating such non -functional
non-functional
requirements with use cases
Use cases do not deal with many important ilities
ilities (availability,
reliability, maintainability,) that are critical in many real -time
real-time
systems
32
Class Diagram
Shows
Shows the entities in a system and their general
relationships
Association class Association class
designatedPlane
designatedPlane crew
crew
Airplane
Airplane Pilot
Pilot
11 1..*
1..*
0..*
0..*
Association
Association
Flight
Flight
route
route
start
start
duration
Captain
Captain First
First Officer
Officer
duration
0..*
0..*
owner
owner 0..*
0..* {ordered}
{ordered}
Airline
Airline 11
33
Object Instance Diagram
Shows
Shows object instances in a particular case
Link
Link
Donald
Donald D.
D. :: Pilot
Pilot
N1313:Airplane
N1313:Airplane
Mickey
Mickey M.
M. :: Pilot
Pilot
CA345
CA345 :: Flight
Flight
CA123
CA123 :: Flight
Flight
DecrepitAir
DecrepitAir :: Airline
Airline CreakyAir
CreakyAir :: Airline
Airline
34
Class Diagrams and RT Systems
Class
Class diagrams are very abstract and sometimes leave
out crucial system information (e.g., topology)
e.g., common class diagram for both systems
N2:Node
N2:Node
N1:Node
N1:Node N3:Node 0..2
N3:Node Node
Node
N4:Node
N4:Node
0..2
N1:Node
N1:Node N2:Node
N2:Node N3:Node
N3:Node
35
Object Diagrams to the Rescue?
Object
Object (instance) diagrams do show topologies
However
However
in principle, object diagrams only represent snapshots of a
system at a particular point in time
no guarantee that they hold throughout the lifetime of the
system
need prototypical object diagrams
but, such semantics are not defined in the current standard
36
Collaboration Diagram
Depict
Depict generic structural and behavioral patterns
Classifier
Classifier role
role
P2:TTSet
P2:TTSet
/CallProc
/CallProc
2.call()
2.call()
3.sendTone()
3.sendTone()
4.dialtone()
4.dialtone()
1.offHook()
P1:BusSet
P2:TTSet
/PhoneIF
P1:BusSet
/PhoneIF
P2:TTSet /ToneGen
/ToneGen
1.offHook()
NB:
NB: ItIt is
is possible
possible to
to have
have P1:BusSet
P1:BusSet
collaboration
collaboration diagrams
diagrams
without
without an an Interactions
Interactions
overlay
overlay (pure structure)
(pure structure)
37
Sequence Diagrams
Show interactions between objects with a focus on
communications (a different representation of a collaboration)
ack
number
call
ack
transfer
talk
time
time
38
Sequence Diagrams and RT Systems
Sequence
Sequence diagrams are extremely useful for showing
object interactions
very common in many real -time systems
real-time
well suited for event -driven behavior
event-driven
in telecom, many protocol standards are defined using
sequence diagrams
However
However
No standard way of denoting timing information
UML sequence diagrams do not scale up very well for
modeling large systems with complex sequences
39
Using Timing Marks with Sequence Diagrams
Specifying
Specifying constraints
read( )
register( )
40
Activity Diagrams
Different
Different focus compared to sequence diagrams
/Caller /Operator /Callee
activity
activity
Contact
Contact
Operator
Operator
Contact
Contact
swimlane
swimlane Callee
Callee
Respond
Respond
Notify
Notify
Parties
Parties
Acknowledge
Acknowledge Acknowledge
Acknowledge
41
Activity Diagrams and RT Systems
Better
Better than sequence diagrams for
showing concurrency (forks and joins are explicit)
scaling up to complex systems
However
However
No standard way of denoting timing information
Less well-suited for describing event
well-suited -driven behavior
event-driven
42
State Machine Diagram
Each state corresponds to a selective receive action
Initial
Initial pseudostate
pseudostate State
State machine
machine
transition
transition
State
State
Initialize
Initialize
Object trigger
Object
created trigger
Wait
Waitfor
for
Event
Event start/^master.ready()
start/^master.ready()
Handle
Handle
Action
Action
Event ready expression
Event expression
stop/
stop/
Final
Final state
state
Terminate poll/^master.ack()
poll/^master.ack()
Terminate
Object
Object
43
Hierarchical States and Transitions
Allows step-wise refinement and viewing of complex
behavior
off/ group
group
OffLine transition
transition
default
default
transition
transition on/
OnLine
Ready done/
req/handle()
Busy composite
composite
state
state
44
State Machines and RT Systems
Many
Many real-time systems are event
real-time -driven
event-driven
very well suited to those systems
scale up very nicely
However
However
not directly connected to time (except for time events)
e.g., run-to-completion paradigm
run-to-completion
45
Implementing Time-Triggered Systems
Periodic
Periodic timers:
once initiated they repeatedly send TimeEvents at the
appropriate intervals until explicitly stopped or cancelled
In
In steady-state mode, active objects stimulated
steady-state
exclusively by periodic timers become periodic tasks
allows rate-monotonic scheduling policies
rate-monotonic
schedulers use the priorities of periodic timers to make
scheduling decisions
46
Objects and Concurrency
Passive objects: have no control of their communications
Clients determine when to invoke an operation
Active objects: can control when to respond to requests
Can avoid concurrency conflicts
Require at least one independent engineering-level thread
engineering-level
Initialize
Initialize Initialize
Initialize
Object
Object Object
Object
Wait
Waitfor
for Wait
Waitfor
for
Request
Request Request
Request
Handle
Handle Handle
Handle
Request
Request Request
Request
Terminate
Terminate Terminate
Terminate
Object
Object Object
Object
47
The Active Objects of UML
Single
Single thread of execution
Behavior
Behavior defined by state machines (event driven)
anActiveObject
#currentEvent : Eventpoll/defer
created
+ start ( )
start start/^master.ready() ready
+ poll ( )
+ stop ( )
ready
stop/
poll/^master.ack()
48
Active Object Semantics
Concurrent incoming events are queued and handled
one-at-a-time regardless of priority
run-to-completion (RTC) execution model
anActiveObject
created
ready
lo
hi (queued)
hi
50
RTC Analysis
Advantages:
Advantages:
Eliminates concurrency conflicts for all passive objects
encapsulated by active objects
No explicit synchronization code required
Low -overhead context switching (RTC implies that stack does
Low-overhead
not need to be preserved)
Disadvantage:
Disadvantage:
Limited priority inversion can occur (higher priority activity mmayay
have to wait for a lower -priority activity to complete)
lower-priority
Can be circumvented but at the expense of application -level
application-level
complexity
51
Example: Active Objects
Active object OS thread
Active
two-tier scheduling scheme
two-tier
event priorities vs thread priorities
OSProcess
OSThread1 OSThreadN Lightweight
Lightweight
specialized
specialized
multitasking
multitasking
...
Active Active Heavyweight
Heavyweight
object object general
general--
scheduler scheduler purpose
purpose
multitasking
multitasking
Operating System
(schedules process and threads)
52
UML Concurrency Model and RT Systems
Active
Active objects are the major concurrency mechanism of
UML
automatically resolve certain concurrency conflicts
However...
However...
The priority inversion inherent in RTC may be unacceptable in
some cases
How does this map to concurrency mechanisms that are used
in the real -time domain (processes, threads, semaphores,
real-time
real -time scheduling methods, etc.)?
real-time
No clear way of exploiting real -time analyses methods (e.g.,
real-time
schedulability analysis)
53
Scheduling in UML
Scheduling
Scheduling approach undefined
Hints of event -based priorities (versus thread
event-based -based)
thread-based)
Timing events allow realization of time -triggered systems
time-triggered
The
The actual scheduling policy is unspecified
A semantic variation point
Can be customized to suit application requirements
54
The Model of Time in UML
Unbiased
Unbiased and uncommitted (i.e., it does not exist):
Time data type declared but not defined (could be either
continuous or discrete)
No built -in assumptions about global time source (open to
built-in
modeling distributed systems)
Related
Related concepts:
Time events: generated by the occurrence of a specific instant
Assumes some kind of run -time Timing Service
run-time
55
Component and Deployment Diagrams
Implementation
Implementation focus Component
Component
:Scheduler
reservations
Probably
Probably the weakest part of UML
Not
Not sophisticated enough to capture the various complex
aspects of deployment common to real -time systems
real-time
deferred mapping of software to hardware
mapping of software to software
No
No standard way to describe the quantitative
requirements/characteristics of hardware and software
(e.g., scheduling discipline)
..
..
57
UML Summary
An
An industry standard for analysis and design of object
object--
oriented systems
based on extensive experience and best practices
gaining rapid acceptance (training, tools, books)
Comprises:
Comprises:
set of modeling concepts
a standard graphical notation
Represented
Represented through 8 different diagram types
class, state machine, collaboration, use case, sequence,
activity, component, deployment
58
UML and RT Systems Summary
Using
Using UML for real -time systems automatically brings the
real-time
benefits of the object paradigm
structural focus, inheritance, strong encapsulation,
polymorphism,
However,
However, there are many open questions
best ways of using UML in the real -time domain
real-time
missing or non -standard concepts
non-standard
ability to create predictive models for real time
59
Real-Time
Real-Time Systems and the Object Paradigm
Real-Time System Essentials
Real-Time
Essentials of the Object Paradigm
UML
UML as a Real -Time Modeling Language
Real-Time
The
The Real -Time UML Profile
Real-Time
Engineering-Oriented
Engineering-Oriented Design of Real -Time Systems
Real-Time
Summary
Summary and Conclusions
60
Semantic Variation in UML
Semantic
Semantic aspects that are:
undefined (e.g., scheduling discipline), or
intentionally ambiguous (multiple, mutually -exclusive,
mutually-exclusive,
interpretations)
Why?
Why?
Different domains require different specializations
The applicability and usefulness of UML would have been
severely constrained if it could not support such diversity
The
The scope and semantic impact of semantic variation
choices must be strictly limited
61
Specialization of UML
Avoiding
Avoiding the PL/I syndrome (language bloat)
UML standard as a basis for a family of languages
Variations
Variations produced
produced
using
using built-in
built-in
UML Standard 1.4 extensibility
extensibility mechanisms:
mechanisms:
stereotypes,
stereotypes, tagged
tagged values,
values,
constraints
constraints
Real-Time UML
Real-Time UML for eCommerce ..etc.
62
How Do We Specialize UML?
Typically
Typically used to capture semantics that cannot be
specified using UML itself
Integer
Integer
But, how can we
specify a clock?
Counter
Counter Semantics:
ResetCounter ()
ResetCounter() an active counter whose
value changes
Specialization
Specialization synchronously with the
through
through regular
regular
inheritance
inheritance
progress of physical time
63
Stereotyping UML Concepts
Example:
Example: a clock stereotype based on the generic UML
Class concept
Semantics:
Semantics:
Integer
Integer an
an active
active counter
counter whose
whose
value
value changes
changes
synchronously
synchronously with
with the
the
progress
progress of
of physical
physical time
time
clock
MyTimePiece
MyTimePiece
SetTime ()
SetTime()
64
UML Profiles
Fully
Fully conformant with the UML standard
additional semantic constraints cannot contradict the general
UML semantics
within the semantic envelope defined by the standard
Standard
Standard UML
UML Semantics
Semantics
Profile
Profile Y
Y Profile
Profile X
X
65
UML Extensibility and RT Systems
The
The extensibility mechanisms of UML provide an
excellent opportunity to fill in the missing bits for real -time
real-time
applications
If
If we can define a standard set of extensions (real -time
(real-time
profile) then these could provide a common facility for
real -time UML modelers and tool builders
real-time
66
Real-Time A&D WG (1 of 2)
Bridges
Bridges two domains: modeling and real -time
real-time
RT-AD WG
67
Real-Time A&D WG (2 of 2)
Mission:
Mission:
to investigate and issue requests ((RFPs)
RFPs) for standard ways
and means to apply UML to real -time problems
real-time
Three
Three principal areas of investigation:
Time -related modeling
Time-related
General quality of service modeling
(e.g., availability, reliability, security,)
Real -time system architecture modeling
Real-time
Status:
Status:
first RFP issued (April 1999)
second RFP drafted but not submitted
68
The Real-Time UML RFP
UML
UML profile for scheduling performance and time
First in a series of real-time specific RFPs (ad/99
real-time -03-13)
(ad/99-03-13)
Initial proposal submitted in August 2000 (ad/2000 -08-04)
(ad/2000-08-04)
Approved by the Analysis & Design Task Force and by the OMG
Architecture Board Sept. 2001 (final vote pending)
Standard methods for UML modeling of:
Physical time
Timing specifications
Timing services and mechanisms
Modeling resources (logical and physical)
Concurrency and scheduling
Software and hardware infrastructure and their mapping
..including specific notations for the above where necessary
69
Important Caveat
The
The RFP does not ask for new real -time concepts or
real-time
methods
Instead,
Instead, the intent is to support existing and future
modeling techniques and analysis methods in the context
of UML
response should not be biased towards any particular
technique or method
70
Response to the RFP
Just one submission throughout
Consortium team:
ARTiSAN (UML tool vendor)
II-Logix
-Logix (UML tool vendor)
Rational (UML tool vendor) - lead
Telelogic (UML tool vendor)
TimeSys (RT tool and technology vendor)
Tri -Pacific Software (RT tool vendor)
Tri-Pacific
In consultation with many of the top real -time system experts
real-time
((toolbuilders,
toolbuilders, analysis technique experts, academics)
Prof. Murray Woodside and Prof. Dorina Petriu (Carleton U.)
performance analysis profile
71
RT Profile: Guiding Principles
Ability to specify quantitative information directly in UML mode ls
models
key to quantitative analysis and predictive modeling
Flexibility:
users can model their RT systems using modeling approaches and
styles of their own choosing
open to existing and new analysis techniques
Facilitate the use of analysis methods
eliminate the need for a deep understanding of analysis methods
as much as possible, automate the generation of analysis models and
the analysis process itself
72
Quantitative Methods for RT Systems
Once we have included QoS information in our models, we can
use quantitative methods to:
predict system characteristics (detect problems early)
analyze existing system
synthesize elements of the model
Methods considered for the profile:
Schedulability analysis
will the system meet all of its deadlines?
Performance analysis based on queueing theory
what kind of response will the system have under load?
73
Issues with Quantitative Methods
Require
Require uncommon and highly -specialized skills
highly-specialized
Software
Software is notoriously difficult to model
highly non -linear (detail often matters)
non-linear
models are frequently severely inaccurate and not trustworthy
typical modeling process is highly manual:
System analysis
analysis
Model results
results
+
-
Actual
measurements
measurements
System
74
Desired Development Model
Seamless
Seamless integration of technologies and tools based on
standards for real -time modeling
real-time
Automated
Automated
model
model conversion
conversion
Model Editing
Tool Model Analysis
44
Tool
3.1
3.1
55
Inverse
Inverse
model
model conversion
conversion
75
Structure: Domain Model and Extensions
Resource
etc.
import
profile
import
ADprofile
metaclass metaclass
Specialized Analysis Domain Model Class Object
Analysis
Client stereotype
Analysis stereotype
etc. Resource ADresource
etc.
profile
RTresourceModeling
import import
profile profile
RTconcurrencyModeling RTtimeModeling
import import
import
import
profile
RSAprofile
77
Quality of Service Concepts
Quality
Quality of Service (QoS):
a specification (usually quantitative) of how a particular servi ce
service
is (to be) performed
e.g. throughput, capacity, response time
The
The specification of a model element can include:
offered QoS: the QoS that it provides to its clients
required QoS: the QoS it requires from other components to
support its QoS obligations
78
Resources and Quality of Service
Resource:
Resource:
an element whose service capacity is limited, directly or
indirectly, by the finite capacities of the underlying physical
computing environment
These
These capacities are expressed through QoS attributes
of the service or resource
Resource
Resource Usage
S1
Usage
S1
Client S1
S1 Resource
RequiredQoS
RequiredQoS OfferedQoS
OfferedQoS
{RequiredQoS OfferedQoS}
{RequiredQoS OfferedQoS}
79
Simple Example
Concurrent tasks accessing a monitor with known response time
characteristics
Required
Required QoS
QoS
Client1 Client2
access ( ) access ( )
{Deadline = 3 ms} {Deadline = 5 ms}
myMonitor
{MaxExecutionTime = 4 ms}
Offered
Offered QoS
QoS
80
Instance- vs Class-Based Models
N2:Node
N2:Node
1
Node
Node
N1:Node
N1:Node N3:Node
N3:Node
1
N4:Node
N4:Node
RealizationModel
DynamicUsageModel StaticUsageModel
(from ResourceUsageModel) (from ResourceUs ageModel)
Resourc eManagement
CausalityModel ResourceTypes
CoreResourceModel
82
Core Resource Model
+type
Inst ance Descriptor
0..n 1..n
NB:
NB: This is a model of the domain concepts
(i.e., it is not a UML metamodel)
83
Basic Resource Usage Model
EventOccurence
(f rom Cau sali ty Mo del )
AnalysisContext
1 0..n
1
1..n
1..n 1..n +usedResourc es
0..1 1 ResourceInstance
UsageDemand ResourceUsage 0..n 1..n (from CoreResourceModel)
+workload
1..n
+us edServices
ResourceServiceInstance
0..n (from CoreResourceModel)
StaticUsage DynamicUsage
84
Basic Causality Loop
Used
Used in modeling dynamic scenarios
EventOccurence
+cause +effect
Stimulus
StimulusGeneration
1 1..n
+receiver
Instance
(from CoreResourceModel) 0..1 0..n
+effect 0..n 1 +cause
1..n +executionHost
85
Dynamic Usage Model
DynamicUsage
(from ResourceUsageModel)
+usedResources
Scenario ResourceInstance
1..n / 1..n (from CoreResourceModel)
(from Caus ality Model)
1..n
{ordered}
+step /
1..n
1.. n
+successor ActionExecution +usedServices
ResourceServiceInstance
0..n 1..n (from CoreResourceModel)
0..n
+predecessor 0..n 0.. n
0..n
0..n +requiredQoS +offeredQoS
QoSvalue
(from CoreResourceModel)
86
Static Usage Model
StaticUsage Instance
(from ResourceUsageModel) (from CoreReso urceMode l)
+usedResources ResourceInstance
Client
1..n 1..n (from CoreResourceModel)
0..n 0..n
+requiredQoS 1..n
QoSvalue +offeredQoS /
(from CoreResourceModel)
0..n
+instance 0..n
+type 1
QoScharacteristic
(from CoreResourceModel)
87
Resource Categorizations
ResourceInstance
(from CoreResourceModel)
purposeKind
88
Exclusive Use Resources and Actions
ResourceServiceInstance ActionExecution
(from CoreResourceModel) (from DynamicUsageModel)
1
Acces sControlPolicy
0..n
0..1
ExclusiveService AcquireService
/ / Releas eService
isBlocking : Boolean
1 0..n
0..n 1..n 0..n
ProtectedResource /
/
1
89
Resource Management Model
Instance
(from CoreResourceModel)
ResourceBroker ResourceManager
90
Mapping to UML Extensions
Elements
Elements of the general resource model are represented
as stereotypes (with tags) of base UML concepts:
GRMresource
GRMresource
Resource
Resource BufferPool
BufferPool
Service 0..n
0..n
GRMresSrvc () {GRMexTime
GRMresSrvc GetBuffer()
GetBuffer
GetBuffer() {GRMexTime == 5}
5}
Classifier,
GRMresource N/A
Instance
GRMresSrvc BehavioralFeature GRMexTime
GRMresource
GRMresource
aPool
aPool :: BufferPool
BufferPool
91
Example System
Periodic
Periodic concurrent tasks sharing resources
WCET
WCET == 22 ms
ms
Period
Period == 100
100 ms
ms
WCET = 20
WCET = 20 msms
1. read( )
master : Master
d : DBaseServer
Period
Period == 150
150 ms
ms
WCET
WCET == 4040 ms
ms 2. register( )
WCET
WCET == 20
20 ms
ms
dBadmin : Admin
sort( )
Period WCET
WCET == 10
10 ms
ms
Period == 350
350 ms
ms
WCET = 100
WCET = 100 ms ms
poller : Poller
invoke( )
cs : CommServer
WCET
WCET == 10
10 ms
ms
92
Standard Stereotypes
To
To allow an analysis tool to extract the necessary QoS
information, we define a set of standard stereotypes and
related tags*
Tags
Stereotype UML base concepts
Classifier, GRMperiod,
GRMclient
Instance GRMwcet
Classifier, N/A
GRMprotResource
Instance
GRMresService BehavioralFeature GRMwcet
GRMperiod RTtimeString
GRMwcet RTtimeString
** The
The stereotypes
stereotypes and
and tags
tags have
have been
been simplified
simplified for
for this
this present ation
presentation
93
Example: QoS Annotations
Using
Using the standard stereotypes...
GRMclient 1. read( )
master : Master GRMprotResource
{GRMperiod = 100 ms} d : DBaseServer
{GRMwcet = 20 ms}
2. register( )
GRMclient
dBadmin : Admin
{GRMperiod = 150 ms}
sort( )
{GRMwcet = 40 ms}
GRMclient
poller : Poller
invoke( ) GRMprotResource
{GRMperiod = 350 ms}
cs : CommServer
{GRMwcet = 100 ms}
94
Example: Class Diagram
QoS
QoS annotations can be added to classes as well
GRMprotResource
CommServer GRMclient
1 Poller
1 GRMserv invoke() {GRMwcet = 10ms} 0..n
95
Example: Model Analysis
Result:
Result:
aa new
new model
model with
with
analysis
analysis variable
variable
values
values set
set
GRManalysisContext
GRManalysisContext GRManalysisContext
GRManalysisContext
Schedulability
Analyzer
(RMA)
May
May include
include
additional
additional
tool-specific
tool-specific
results
results encased
encased
in
in UML
UML Notes
Notes
96
General Time Model
TimingServices
TimedEvents
TimeModel TimingMechanisms
97
Physical and Measured Time
Physical Clock
Time
(from TimingMechanisms)
1 +referen ceClock
{ordered} n 0..n
n +measurement TimeValue
PhysicalInstant
kind : {discrete, dense}
0..n
+start 1 1 +end 1 +s tart 1 +end
n n n n
Duration +measurement Tim eIn terval
0..n 0..n
98
Timing Mechanisms Model
ResourceInstance
(from CoreResourceModel)
+currentValue 0..n
TimeValue TimingMec hanism
(from TimeModel) 1 stability +origin TimedEvent
+max imalValue 0..n drift (from TimedEvents)
skew 1
1
set(time : TimeValue)
0..n
get() : TimeValue
reset()
start()
0..n pause()
1 +resolution
TimeInterval
(from Tim eModel)
1 +offset
1 +times tam p
+accuracy 1..n
1 +referenceClock
0..n
+duration TimeValue
Clock Timer (from Tim eModel)
isPeriodic : Boolean 0..n 1
0..n 1 1
99
Example Timing Stereotype
Stereotype Base Class Tags
RTaction Action RTstart
ActionExecution RTend
RTduration
Message
Stimulus
Method
ActionSequence
ActionState
SubactivityState
Transition
State
100
Timed Stimuli
0..n
+end
0..n 0..n
Timeout
1..n
/ ClockInterrupt
101
Timed Events and Timed Actions
EventOccurence Scenario
(from CausalityModel) (from CausalityModel)
TimedAction
TimedEvent
0..n
Delay
1..n +start 1..n +end 1..n +duration 1
+timestamp
TimeInterval
TimeValue
(from TimeModel)
(from TimeModel)
102
Time Annotations
In
In various behavioral diagrams (sequence, activity, state)
PAclosedLoad PAcontext
{PApopulation=$NUsers,
PAextDelay=('mean','asgn',20,'ms')}}
processSelection
PAstep
initialPlayout
More compact forms are also
initializePlayer {PAdemand=
(('est','mean',15,'ms'),
('est','sigma',10))}
PAstep
confirm
PAstep
{PAdemand=
sendFrame
possible:
{PArespTime= ('est','mean',1,'ms')}}
('req','percentile',95,500,'ms')}}
showFrame
InstanceA : InstanceB :
PAstep
{PArep=$N, *[$N]
PAdemand=('est','mean',10,'ms'),
PAextOp=('filesys',12),('network',65)} terminalPlayout
helloMsg
PAstep {0 ms}
{PAinterval= {1.5 ms}
('req','percentile',99,30,'ms')}}
{2 ms}
ackMsg
probability distributions, percentile values, etc. {10.2 ms}
{11 ms}
(NB: tools can help reduce visual clutter)
103
Notation: Timing Marks and Constraints
sendTime()
receiveTime() callHandler.startTime()
ack
On action blocks (new):
callHandler.endTime()
startTime() ack.sendTime()
endTime()
Timing constraint
104
Defined Stereotypes (1 of 3)
Stereotype Applies To Tags Description
105
Defined Stereotypes (2 of 3)
Stereotype Applies To Tags Description
106
Defined Stereotypes (3 of 3)
Stereotype Applies To Tags Description
107
Specifying Time Values
Time
Time values can be represented by a special stereotype
of Value ( RTtimeValue) in different formats; e.g.
(RTtimeValue)
12:04
12:04 (time
(time of
of day)
day)
5.3,
5.3, ms
ms (time
(time interval)
interval)
2000/10/27
2000/10/27 (date)
(date)
Wed
Wed (day
(day of
of week)
week)
$$param,
param, ms (parameterized
(parameterized value)
value)
poisson,
poisson, 5.4,
5.4, sec
sec (time
(time value
value with
with a Poisson distribution)
histogram
histogram 0,0, 0.3
0.3 1,
1, 0.4
0.4 2,
2, 0.3,
0.3, 3,
3, ms
ms
P=0.4
P=0.3 P=0.3
0 ms 1 ms 2 ms 3 ms
108
Specifying Arrival Patterns
Method
Method for specifying standard arrival pattern values
Bounded: bounded, <min -interval>, <max
<min-interval>, -interval>
<max-interval>
Bursty
Bursty:: bursty,
bursty, <burst-interval> <max.no.events>
<burst-interval>
Irregular: irregular, <interarrival -time>, [<interarrival
<interarrival-time>, -time>]*
[<interarrival-time>]*
Periodic: periodic, <period> [, <max -deviation>]
<max-deviation>]
Unbounded: unbounded, <probability -distribution>
<probability-distribution>
Probability
Probability distributions supported:
Bernoulli, Binomial, Exponential, Gamma, Geometric,
Histogram, Normal, Poisson, Uniform
109
General Concurrency Modeling
ActiveResource
/ (from ResourceTypes)
1.. n
110
Defined Stereotypes
Stereotype Applies To Tags Description
111
Performance Analysis Concepts
PerformanceContext
1 0.. n
1
1..n
1..n
1..n
W orkload +resource PResource
PScenario
responseTime 1..n 0..n 0..n utilization
priority 1 hostExecutionDemand
responseTime schedulingPolicy
0..n throughput
1
<<deploys>>
{ordered}
ClosedWorkload OpenWorkload +root 1 1..n +host 0..1
population oc currencePat tern PStep PProcessingResource PPassiveResource
externalDelay
probabilty processingRate waitingTime
+successor repetition contextSwitchTime responseTime
delay priorityRange capacity
0..n operations isPreemptible accessTime
interval
executionTime
+predecessor 0..n
112
Relationship to General Resource Model
UsageDemand AnalysisContext Scenario
(from ResourceUsageModel) (from ResourceUsageModel) (from CausalityModel)
PPassiveResource PProcessingResource
waitingTime processingRate
responseTime contextSwitchTime
capacity priorityRange
accessTime isPreemptible
113
Example: Web Video Application
Engineering Instance Model
vp : VideoPlayer vw : VideoWindow b : Browser ws : WebServer vs : VideoServer
vw : VideoWindow b : Browser
: Internet
vp : VideoPlayer ws : WebServer
Usage Scenario
b : Browser ws : WebServer vs : VideoServer vp : VideoPlayer vw : VideoWindow
vs : VideoServer processSelection
initialPlayout
initializePlayer
confirm
sendFrame
showFrame
*[$N]
terminalPlayout
114
Example: Performance Requirements
Frames in a video $N
115
Example: Annotations for a Scenario
PAclosedLoad PAcontext
{PApopulation=$NUsers,
PAextDelay=('mean','asgn',20,'ms')}}
processSelection
PAstep
initialPlayout {PAdemand=
initializePlayer
(('est','mean',15,'ms'),
('est','sigma',10))}
confirm
PAstep
PAstep {PAdemand=
{PArespTime= sendFrame
('est','mean',1,'ms')}}
('req','percentile',95,500,'ms')}}
showFrame
PAstep
{PArep=$N, *[$N]
PAdemand=('est','mean',10,'ms'),
PAextOp=('filesys',12),('network',65)} terminalPlayout
PAstep
{PAinterval=
('req','percentile',99,30,'ms')}}
116
Example: More Annotations
PAcontext
{PAschdPolicy=PR,
PArate=1, PAhost PAhost PAhost
PAutilization=$Util, :ClientWorkstation : WebServerNode : VideoServerNode
PActxtSwT=('est','mean',40,'us')}
PAcontext
vs : VideoServer vp : VideoPlayer vw : VideoW indow
: Internet
PAstep
{PAdemand=('est','mean',10,'ms'),
send PAextOp=('filesys',12),('network',65)}
frame
PAstep {PAdemand=
receive (('est','mean',15,'ms'),
('est','sigma',10))}
frame
PAstep
{PAinterval=
('req','percentile',99,30,'ms')}} show
frame
117
Defined Stereotypes (1 of 2)
Stereotype Applies To Tags Description
118
Defined Stereotypes (2 of 2)
Stereotype Applies To Tags Description
119
Specifying Performance Values
Where:
Where:
<kind -of-value> ::= req
<kind-of-value> req | assm
assm | pred
pred | msr
msr
Required, assumed, predicted, measured
<modifier> ::= mean | sigma | kth-mom
kth-mom , <Integer> |
max | percentile <Real> | dist
E.g.:
{{PAdemand
PAdemand = ((msr,
msr, mean, (20, ms))}
120
Schedulability Analysis Sub-Profile
121
Policies Supported
Scheduling
Scheduling Policies:
Rate Monotonic, Deadline Monotonic, HKL, Fixed Priority,
Minimum Laxity First, Maximize Accrued Utility, Minimum
Slack Time
may be extended in the future
Access
Access Control Policies:
FIFO, Priority Inheritance, No Preemption, Highest Lockers,
Priority Ceiling
may be extended in the future
122
Example
Sensors A.1:gatherData ( )
TelemetryGatherer TGClock : Clock
:SensorInterface
:DataGatherer
TGClock : Clock
A.1.1.1: writeStorage ( )
SensorData
C.1:displayData ( ) :RawDataStorage
B.1.1 : main ( )
C.1.1.1: readStorage ( ) B.1.1.1: readStorage ( )
TelemetryDisplayer TelemetryProcessor
: DataDisplayer :DataProcessor
TGClock : Clock
123
Example: Schedulability Annotations
SAAction
SASituation {SAPriority=2,
A.1.1:main ( )
SAWorstCase=(93,'ms'), SATrigger
RTduration=(33.5,'ms')} {SASchedulable=$R1, Result
Result
RTat=('periodic',100,'ms')}
A.1:gatherData ( )
SAResponse
Sensors {SAAbsDeadline=(100,'ms')}
TelemetryGatherer TGClock : Clock
:SensorInterface
:DataGatherer
SASchedulable
SATrigger
{SASchedulable=$R2, SensorData
{SACapacity=1,
RTat=('periodic',60,'ms')}
C.1:displayData ( ) :RawDataStorage
SAAccessControl=PriorityInheritance}
SAResponse
SAResponse
{SAPriority=3,
{SAAbsDeadline=(60,'ms')} B.1.1 : main ( )
SAWorstCase=(177,'ms'),
RTduration=(46.5,'ms')}
SAAction SAAction
C.1.1.1: readStorage ( ) B.1.1.1: readStorage ( )
{RTstart=(3,'ms'), {RTstart=(10,'ms'),
RTend=(5,'ms')} RTend=(31.5,'ms')}
TelemetryDisplayer TelemetryProcessor
: DataDisplayer
SASchedulable :DataProcessor
SASchedulable
Display SATrigger
{SASchedulable=$R3,
SAResponse :DisplayInterface RTat=('periodic',200,'ms')}
B.1:filterData ( )
{SAPriority=1, SAResponse
C.1.1 : main ( )
SAWorstCase=(50.5,'ms'), {SAAbsDeadline=(200,'ms')}
RTduration=(12.5,'ms')}
TGClock : Clock
124
Example: Deployment Specification
GRMdeploys
SAEngine
SAOwns SAResource
{SARate=1,
SASchedulingPolicy=FixedPriority} SensorData
:Ix86Processor :RawDataStorage
125
Example: Analysis Results
SASituation
SAAction
{SAPriority=2,
SAWorstCase=(93,'ms'), SATrigger
RTduration=(33.5,'ms')} {SASchedulable=$true,
Additional
Additional A.1.1:main ( ) RTat=('periodic',100,'ms')}
SAResponse
tool-specific
tool-specific {SAAbsDeadline=(100,'ms')}
A.1:gatherData ( )
results
results encased
encased Sensors
SASchedulable
TelemetryGatherer TGClock : Clock
in
in UML
UML Notes
Notes :SensorInterface
:DataGatherer
SAAction
{RTstart=(16.5,'ms'),
RTend=(33.5,'ms')}
TGClock : Clock A.1.1.1: writeStorage ( )
SATrigger SAResource
{SASchedulable=$true {SACapacity=1,
RTat=('periodic',60,'ms')} SAAccessControl=PriorityInheritance}
SAResponse
SAResponse SensorData {SAPriority=3,
{SAAbsDeadline=(60,'ms')}
C.1:displayData ( ) :RawDataStorage SAWorstCase=(177,'ms'),
RTduration=(46.5,'ms')}
B.1.1 : main ( )
SAAction SAAction
{RTstart=(3,'ms'), {RTstart=(10,'ms'),
RTend=(5,'ms')} RTend=(31.5,'ms')}
C.1.1.1: readStorage ( ) B.1.1.1: readStorage ( )
SASchedulable SASchedulable
TelemetryDisplayer TelemetryProcessor
: DataDisplayer :DataProcessor
SATrigger
{SASchedulable=$true
SAResponse RTat=('periodic',200,'ms')}
{SAPriority=1, Display SAResponse
SAWorstCase=(50.5,'ms'), :DisplayInterface {SAAbsDeadline=(200,'ms')}
RTduration=(12.5,'ms')} B.1:filterData ( )
C.1.1 : main ( )
TGClock : Clock
126
Defined Stereotypes (1 of 3)
Stereotype Applies To Tags Description
127
Defined Stereotypes (2 of 3)
Stereotype Applies To Tags Description
128
Defined Stereotypes (3 of 3)
Stereotype Applies To Tags Description
129
Real-Time CORBA: Schedulability Sub-Profile
SResource
(from Sche dulin gDomanModel )
+usedResources RTCserver
0..n 0.. n
serverPriority
/ 1..n
1
0..n +usedResources RTCconnection
/ isShared 0..n
1..n
hiPriority
0..n +clientScenario
loPriority /
/
RTCclient
timeout 1..n / +host
+hos t RTCorb
clientPriority
1
private <<deploys>> 1
130
Example: RT CORBA
SASituation
RSAserver
RTclock {SACapacity=10}
TGClock : Clock Sensor2
:SensorInterface
RSAclient
RSAserver
{RSAtimeout=(105,'ms),
{SACapacity=4}
RSAclPrio=12
Sensor1
TelemetryGatherer GRMdeploys
:SensorInterface
: DataGatherer
GRMdeploys GRMdeploys
GRMdeploys
SAEngine SAEngine
{SASchedulingPolicy= {SASchedulingPolicy=
'RateMonotonic', 'RateMonotonic',
SARate=1} SARate=0.5}
P1 : I586 P2 : Ix86
131
Example: RT CORBA Usage Scenario
SASituation
SAAction
{SAW orstCase=(15,'ms'),
RTduration=(10,'ms')}
SAresponse
readSensor ( )
{SAAbsDeadline
=(100,'ms')
SAAction
{SAW orstCase=(30,'ms'),
RTduration=(20,'ms')}
readSensor ( )
SAAction
{SAW orstCase=(25,'ms'),
RTduration=(5,'ms')}
compare ( )
132
Defined Stereotypes
Stereotype Applies To Tags Description
133
Real Time CORBA: Infrastructure Model
<<CORBAModule>>
<<CORBAModule>> RTPortableServer
RTCORBA
<<CORBAModule>>
RTCosScheduling
134
Model Processing Paradigm and Tools
Configuration
Data Set
Model Processor
3 4 5
Configured
Model Model Domain
UML Model
Configurer Convertor Model
(XMI)
2 6
Parametrized Processing
Model
UML Model Control
(XMI) Analyzer Specification
1 7
10 9 8
Results
Model UML Model
Results Processing
Editor Convertor Results
(XMI)
135
The Tag Value Language
Tagged
Tagged value format:
{<tag-name> = <tag
{<tag-name> -value>}
<tag-value>}
Used
Used to specify complex (structured) tagged values
Based
Based on a small proper subset of the freeware Perl
language
Includes: variables, numbers, booleans
booleans,, strings, lists,
expressions (including conditionals), operators, and functions
Suitable
Suitable for:
expressing complex dependencies between values
writing processing scripts
136
Summary: The Real Time UML Profile
The
The RT UML Profile defines a set of extensions for
directly expressing real -time domain concepts in UML:
real-time
resources
concurrency mechanisms
time and timing mechanisms
Furthermore,
Furthermore, it allows the specification of quantitative
aspects in the same models such that the models can be
analyzed
predictive models that can be used to validate (risky) design
approaches before major investments are made
137
Real-Time
Real-Time Systems and the Object Paradigm
Real-Time System Essentials
Real-Time
Essentials of the Object Paradigm
UML
UML as a Real -Time Modeling Language
Real-Time
The
The Real -Time UML Profile
Real-Time
Engineering-Oriented
Engineering-Oriented Design of Real -Time Systems
Real-Time
Summary
Summary and Conclusions
138
Common Wisdom...
When
When designing software, we are instructed to ignore
details of the technology and similar implementation
issues until we have a sound logical solution to the
problem
simplifies the design problem (separation of concerns)
software is portable to new/different technologies
But,
But, what about real-time systems?
real-time
139
The Ideal and the Real
Possibility
Possibility of out -of-date state information due to lengthy
out-of-date
(and variable) transmission delays
observer
on off
on
on
State?
State?
on
on
Its
Its aa game
game of
of numbers!
numbers!
141
Real System Design Issues (2)
Inconsistent
Inconsistent views of system state:
different observers see different event orderings
clientA
clientA notifier1
notifier1 notifier2
notifier2 clientB
clientB
e2
e2
e1
e1
e1
e1
e2
e2
time
Its
Its aa game
game of
of numbers!
numbers!
142
Distributed System Characteristics
Key
Key characteristics:
concurrency and asynchrony
need for communication and synchronization between sites
communication delays
possibility of partial failure
Each
Each of these adds significant weight to the
programming problem
Distributed
Distributed programming is different from and much more
complex than conventional programming
143
Real-World Real-Time Design Issues
Much
Much of the complexity associated with these systems is
the result of the intrusion of the inherently complex
physical world into the idealized logical world of software
The
The real -time design dilemma:
real-time
if the physical world intrudes on the logical world, how can we
separate the logical world of design from the physical world
of implementation to achieve portability?
144
Logical (Conceptual) Viewpoint
AIRFRAME
AIRFRAME
ATMOSPHERE
ATMOSPHERE
MODEL
MODEL
CONTROL
CONTROL PILOT
SURFACES PILOT
GROUND SURFACES CONTROLS
CONTROLS
GROUND
MODEL
MODEL
ENGINES
ENGINES
145
Engineering (Realization) Viewpoint
The
The realization of a specific set of logical components
using facilities of the run -time environment
run-time
Processor
OS
OS process
process
Processor
stack
Ethernet LAN
OS
OS process
process TCP/IP
TCP/IP socket
socket
stack
TCP/IP
TCP/IP socket
socket
OS
OS process
process
stack
146
Views and Mappings
Logical
Logical View
View INSTRUCTOR
INSTRUCTOR
STATION
STATION
AIRFRAME
AIRFRAME
ATMOSPHERE
ATMOSPHERE
MODEL
MODEL
CONTROL PILOT
CONTROL
SURFACES PILOT
GROUND SURFACES CONTROLS
GROUND CONTROLS
MODEL
MODEL
ENGINES
ENGINES
Realization
Realization
mappings
mappings
Engineering
Engineering View
View
Processor
OS
OSprocess
process
Processor
Ethernet LAN stack
OS
OSprocess
process TCP/IP
TCP/IPsocket
socket
stack TCP/IP
TCP/IPsocket
socket
OS
OSprocess
process
stack
147
Realization Mappings
Semantics:
Semantics: the logical elements are implemented by the
corresponding engineering model elements
logical elements can be viewed as residing on the
corresponding engineering elements
AIRFRAME
AIRFRAME OS
OS process1
process1
Processor
CONTROL OS
CONTROL OS process1
process1
SURFACES
SURFACES
Model
Model 11 Model
Model 22 Model
Model 33
148
Selecting a Level of Abstraction
Intermediate
Intermediate levels may be abstracted out
depends on the desired granularity of modeling
affects the semantics of the realization relationship
AIRFRAME
AIRFRAME OS
OS process1
process1
Processor
CONTROL OS
CONTROL OS process1
process1
SURFACES
SURFACES
Model
Model 11 Model
Model 22 Model
Model 33
AIRFRAME
AIRFRAME
Processor
CONTROL
CONTROL
SURFACES
SURFACES
Model
Model 11 Model
Model 33
149
The Engineering Viewpoint in RT Systems
The engineering view represents the raw material out of which
we construct the logical view
the quality of the outcome is only as good as the quality of the
ingredients that are put in
as in all true engineering, the quantitative aspects are often ccrucial
rucial (How
long will it take? How much will be required?)
Airframe client
client
resource
resource usage
usage
The
The same QoS framework can be used for quantifying
realization relationships
151
Two Interpretations of Resource Model
The
The peer interpretation
accesses
accesses
client
client resource
resource
The
The layered interpretation (the 22-viewpoint
-viewpoint model)
Logical
Logical View
View
realize
realize
Engineering
Engineering View
View
WinNT
WinNT WinNT
WinNT
Process
Process Process
Process
152
Example: Realization Relationships
For
For sophisticated multi -layer deployment modeling
multi-layer
GRMdeploys
temp : Temperature
GRMdeploys
GRMdeploys
LWT
GRMdeploys OSprocess Thread1 : T
HostProcess: P {ctxtSw = 10usec}
LWT
{ctxtSw = 80usec;
Thread2 : T
heap = 30 kB}
{ctxtSw = 10usec}
LWT
Thread3 : T
{ctxtSw = 10usec}
153
Forms of Realization
154
Modeling Realization in UML
An
An association between models with explicit realization
mappings between model elements
Logical
Logical Model
Model Engineering
Engineering Model
Model
GRMrealizes X Y
asc GRMrealizes
A
B Z
155
Specifying Realization Mappings
Captures
Captures the specifics of the realization mapping
Either as a string (tag value) or as a table
Logical Engineering Mode Linkage Additional
Elements Elements Constraints
<List of logical <List of <If there are multiple <Interaction mode <Any additional
model corresponding engineering elements, between levels, one constraints that
elements> engineering one of:> of:> apply to the
model elements> {inclusive, {sync, mapping>
exclusiveStatic, async,
exclusiveDynamic} replace}
L1 L
sync = SW to SW
async = SW to SW
replace = SW to HW
E1 En E
156
Engineering-Oriented Design (EOD)
Analysis
Analysis and design of software systems based on use of
Models
QoS specifications (accounting for physical properties)
Quantitative analysis techniques and simulation
Complements
Complements any model -based development method
model-based
Advantages:
Advantages:
Higher reliability (simplification due to modeling)
Ability to predict system characteristics (and major design
flaws) prior to full realization
Portability!
157
Achieving Portability with EOD
Dilemma:
Dilemma: How can we account for the engineering
aspects of the system without prematurely and possibly
unnecessarily committing to a particular technology?
Approach:
Approach: Provide an abstract technology -independent
technology-independent
but quantified specification of the required characteristics
of the engineering model as part of the logical model
158
Viewpoint Separation
Required
Required Environment
Environment:: a technology -neutral environment
technology-neutral
specification required by the logical elements of a model
Logical
Logical View
View
Required
Required Environment
Environment
Engineering
Engineering View
View (alternative
(alternative A)
A) Engineering
Engineering View
View (alternative
(alternative B)
B)
UNIX
UNIX UNIX
UNIX WinNT
WinNT WinNT
WinNT
Process
Process Process
Process Process
Process Process
Process
159
Required Environment Partitions
Logical
Logical elements often share common QoS requirements
INSTRUCTOR
INSTRUCTOR
STATION
STATION
AIRFRAME
AIRFRAME
ATMOSPHERE
ATMOSPHERE
MODEL
MODEL
CONTROL
CONTROL PILOT
SURFACES PILOT
GROUND SURFACES CONTROLS
CONTROLS
GROUND
MODEL
MODEL
ENGINES
ENGINES QoS
QoS domain
domain
(e.g.,failure
(e.g.,failure unit,
unit,
uniform
uniform comm
comm properties)
properties)
160
QoS Domains
Specify
Specify a domain in which certain QoS values apply
universally:
failure characteristics (failure modes, availability, reliabilit y)
reliability)
CPU performance
communications characteristics (delay, throughput, capacity)
etc.
The
The QoS values of a domain can be compared against
those of a concrete engineering environment to see if a
given environment is adequate for a specific model
161
Modeling QoS Domains in UML
Similar
Similar to realization: mapping of logical elements to a
desired (required) engineering environment
Logical
Logical View
View
GRMrequires:
GRMrequires:
aa specialization
specialization of
of the
the
realizes
realizes relationship
relationship
Required
Required Environment
Environment
QoS1
QoS1 QoS2
QoS2 QoS3
QoS3
UML base
Stereotype Tags
AA local
local engineering
engineering model
model concepts
162
Example: QoS Domain for an Active Object
Using
Using a stereotype of Node
in conjunction with the required environment relationship
Active
Active class
class
R
R
UML base
readObj
readObj ()
() Stereotype Tags
concepts
priority [0..1] : Integer
Node,
GRMthreadEnv heap [0..1] : Real
Instance
stack [0..1] : Real
GRMrequires
GRMrequires
GRMthreadEnv
ThreadForR
{priority = 3; heap = 20 KB; Environment
Environment expected
expected
stack = 3 KB} by
by instances
instances of
of class
class RR
163
Example: Task Allocation
The
The allocation of logical model to engineering model
elements
Task1
Task2
dBadmin : Admin
MainTask
Task3
164
Example: UML Model of Allocation
LogicalPkgX
LogicalPkgX
dBadmin : Admin
GRMrequires
GRMrequires poller : Poller cs : CommServer GRMrequires
GRMrequires
GRMrequires
GRMrequires
GRMrequires
GRMrequires GRMrequires
GRMrequires
EngineeringPkgY
EngineeringPkgY
import
import
EngineeringPkgZ
EngineeringPkgZ
GRMschedulableEntity
Task
165
Example: Completing the Mapping
Mapping
Mapping to hardware
EngineeringPkgY
EngineeringPkgY
GRMrealize
GRMrealize GRMrealize
GRMrealize GRMrealize
GRMrealize GRMrealize
GRMrealize
EngineeringPkgD
EngineeringPkgD
SAProcessingResource
Proc1
166
Example: UML Model of Allocation
LogicalPkgX
LogicalPkgX
dBadmin : Admin
GRMrealize
GRMrealize poller : Poller cs : CommServer GRMrealize
GRMrealize
GRMrealize
GRMrealize
GRMrealize
GRMrealize GRMrealize
GRMrealize
EngineeringPkgY
EngineeringPkgY
import
import
EngineeringPkgZ
EngineeringPkgZ
GRMschedulableEntity
Task
167
Example: Completing the Mapping
Mapping
Mapping to hardware
EngineeringPkgY
EngineeringPkgY
GRMrealize
GRMrealize GRMrealize
GRMrealize GRMrealize
GRMrealize GRMrealize
GRMrealize
EngineeringPkgD
EngineeringPkgD
SAProcessingResource
Proc1
168
Summary: RT Design and Engineering
In
In complex RT systems, the logical design is strongly
influenced by the characteristics of the engineering
environment
In
In such systems, it is often crucial to formally determine if
a system will meet its non -functional requirements
non-functional
(throughput, response time, availability, etc.)
The
The QoS -based approach described here can serve as a
QoS-based
basis for:
quantitative analysis of UML-based models
UML-based
a real-time modeling standard that will facilitate automated
real-time
exchange between design and analysis tools
169
Real-Time
Real-Time Systems and the Object Paradigm
Real-Time System Essentials
Real-Time
Essentials of the Object Paradigm
UML
UML as a Real -Time Modeling Language
Real-Time
The
The Real -Time UML Profile
Real-Time
Engineering-Oriented
Engineering-Oriented Design of Real -Time Systems
Real-Time
Summary
Summary and Conclusions
170
Summary: The Problem
Complexity!
Complexity!
The
The design of real -time systems is influenced significantly
real-time
by the physical properties of:
the environment in which the system exists
the implementation technology
Most
Most of them stem from the physical world
the physical dimension plays a major role in the design of real
real--
time software since it imposes limitations on the logical design
171
Summary: The Solution (1 of 2)
The
The object paradigm
reduces incidental complexity
its structural bias is better suited to the real-time domain than
real-time
the procedural paradigm
additional key features (encapsulation, inheritance,
polymorphism, etc.) add further expressive power
Engineering-oriented
Engineering-oriented design
accounts for the physical dimension during logical design
based on a quality of service (QoS) framework as represented
in the generic resource model
allows de -coupling from actual implementation technologies
de-coupling
(through required environment specifications)
suitable for analysis and synthesis
enables early detection of critical design flaws
172
Summary: The Solution (2 of 2)
UML
UML provides a common and standardized underpinning
that supports all the components of our solution
for object-oriented modeling
object-oriented
for predictive QoS modeling (via the real -time profile)
real-time
for design analysis and synthesis (tool interchange)
for architectural definition
for implementation (through full automatic code generation)
Furthermore,
Furthermore, as a standard, it enables model interchange
between specialized tools and is a basis for significant
automation of the RT software development process
173
Where to Obtain the RT Profile
A copy of the real -time standard submission can be
real-time
obtained from the Object Management Group website at:
http://www.omg.org/cgi-bin/doc?ad/2001-06-14
http://www.omg.org/cgi-bin/doc?ad/2001-06-14
174
Bibliography
Cooper,
Cooper, R.,
R., Introduction
Introduction to
to Queueing
Queueing Theory,
Theory, The
The Macmillan
Macmillan Compa ny, 1972.
Company, 1972.
I.I. Jacobson,
Jacobson, G.G. Booch
Booch,, and
and J.
J. Rumbaugh
Rumbaugh,, The
The Unified
Unified Software
Software Development
Development Process,,
Process,,
Addison -Wesley, 1999.
Addison-Wesley, 1999.
Klein,
Klein, M.M. et
et al.,
al., AA Practitioners
Practitioners Handbook
Handbook for
for Real -Time Analysis:
Real-Time Analysis: Guide
Guide to
to Rate
Rate Monotonic
Monotonic
Analysis
Analysis forfor Real -Time Systems,
Real-Time Systems, Kluwer
Kluwer Academic
Academic Publishers,
Publishers, 1993.
1993.
OMG,
OMG, The
The Unified
Unified Modeling
Modeling Language
Language version
version 1.3,
1.3, The
The Object
Object Man agement Group,
Management Group,
August
August 1999.
1999.
OMG,
OMG, UML
UML Profile
Profile for
for Scheduling,
Scheduling, Performance,
Performance, and and Time
Time -- Request
Request forfor Proposal,
Proposal, The
The
Object
Object Management
Management Group,
Group, March
March 1999
1999 (doc
(doc ad/99 -03-13).
ad/99-03-13).
UML
UML Real -Time Consortium,
Real-Time Consortium, Response
Response toto the
the OMG
OMG RFPRFP for
for Schedulability,
Schedulability, Pe rformance,
Performance,
and
and Time,
Time, August,
August, 2000
2000 (OMG
(OMG document
document ad/2000 -08-04).
ad/2000-08-04).
J.
J. Rumbaugh
Rumbaugh,, I.I. Jacobson,
Jacobson, andand G.
G. Booch
Booch,, The
The Unified
Unified Modeling
Modeling Language
Language Reference
Reference
Manual,,
Manual,, Addison -Wesley, 1999.
Addison-Wesley, 1999.
B.
B. Selic,
Selic, Turning
Turning Clockwise:
Clockwise: Using
Using UML
UML inin the
the Real -Time Domain,
Real-Time Domain, Communications
Communications of of the
the
ACM,
ACM, vol.42,
vol.42, no.10,
no.10, October
October 1999
1999 (pp.46 -54).
(pp.46-54).
B.
B. Selic,
Selic, A
A Generic
Generic Framework
Framework for for Modeling
Modeling Resources
Resources with
with UML,
UML, IEEE
IEEE Computer
Computer vol.33,
vol.33,
no.6,
no.6, June
June 2000
2000 (pp.
(pp. 64 -69).
64-69).
B.
B. Selic
Selic and
and J.
J. Rumbaugh:
Rumbaugh: Using
Using UML
UML for
for Modeling
Modeling Complex
Complex Real -Time Systems,
Real-Time Systems,
ObjecTime
ObjecTime Limited
Limited and
and Rational
Rational Software
Software Corp.,
Corp., March
March 1998.
1998. (http ://www.rational.com)
(http://www.rational.com)
175