The Engineering of RealTime Software Systems

1
The Engineering of Real-Time Software Systems

• Bran Selic
• Principal EngineerRational Software Canada
• bselic_at_rational.com

2

• The engineer should be equipped with
  knowledge of many branches of study and varied
  kinds of learning, for it is by his judgement
  that all work done by the other arts is put to
  test. This knowledge is the child of practice and
  theory.
• - Vitruvius
• On Architecture, Book I (1st Century BC)

3
An Eminent Authority Speaks.
Edsgar Wybe Dijkstra (1930 2002)

• I see no meaningful difference between
  programming methodology and mathematical
  methodology (EWD 1209)
• The interrupt was a great invention, but also
  a Pandoras Box..essentially, for the sake of
  efficiency, concurrency became visible and
  then, all hell broke loose (EWD 1303)

4
Two Opposing Views

• Because programs are put together in the
  context of a set of information requirements,
  they observe no natural limits other than those
  imposed by those requirements. Unlike the world
  of engineering, there are no immutable laws to
  violate.
• Wei-Lung WangComm. of the ACM (45, 5)
• May 2002

All machinery is derived from nature, and is
founded on the teaching and instruction of the
revolution of the firmament. - VitruviusOn
Architecture, Book X 1st Century BC
5
What is Engineering?

• Merriam-Webster Collegiate Dictionaryengineerin
  g the application of science and mathematics by
  which the properties of matter and the sources of
  energy in nature are made useful to people
• How relevant is this to software design?

6
The Classical Engineering Design Problem
7
What is Software Made of?
8
Exhibit A An Internet Application

• The logic of this application depends on the
  physical characteristics (e.g., delay values) of
  the underlying platform

9
Exhibit B Distributed Notification Servers

• Variable delays leading to message order
  scrambling

• Different parts of the application have a
  different view of the situation
• Program logic has to account for the possibility
  that different parts ofthe system may have a
  radically different view of the system state

10
Software Physics 101 An Impossibility Result

• It is not possible to guarantee that agreement
  can be reached in finite time over an
  asynchronous communication medium, if the medium
  is lossy or one of the distributed sites can fail
• Fischer, M., N. Lynch, and M. Paterson,
  Impossibility of Distributed Consensus with One
  Faulty Process Journal of the ACM, (32, 2) April
  1985.

11
What Software is Made of
Software Application

• The platform constitutes the raw material of
  software
• Its physical characteristics (speed, reliability,
  capacity, etc.) are passed on to the application
  software
• These characteristics are inherently finite due
  to the finite nature of matter

12
Conclusion Software Engineering

• As in other forms of engineering, the qualitative
  and quantitative characteristics of the
  construction material (platform) can have a
  profound effect on our design (application logic)
• Sometimes perilous to ignore them
• This effect is particularly noticable in case of
• Concurrent systems (e.g., processing capacities)
• Real-time systems (e.g., response times)
• Physically distributed systems (e.g., fault
  tolerance, delays)
• There is (should be) a lot more engineering in
  software engineering than many people realize

13
Engineering Models
14
From the Engineers Toolkit Modeling

• Before we build the real thing...

and then verify them
we first build models
15
Models and Modeling

• Why model?
• To help us understand a problem and its
  solution(s)
• Characteristics of good models
• Detail that is irrelevant to the subject of study
  is hidden or abstracted out
• Expressed in a form that most directly
  communicates the essentials
• Significantly cheaper and faster to construct
  than the modeled system
• Usage of models
• To detect errors and omissions (through
  experimentation and analysis) before committing
  full resources ? minimize engineering risk
• To communicate with stakeholders
• To drive implementation

16
Models of Software

• A description of the software which
• Abstracts out or hides irrelevant detail
• Uses problem-domain concepts (vs.
  implementation-domain concepts)

case mainState of initial send(I am
here) end Off case event of
on send(oa,5) next(On) end off
next(Off) end end On case event
of off next(Off) end done
terminate end end end
17
Evolving Models

• A model at different levels of refinement

18
The Remarkable Thing About Software
Software is the only engineering medium that
allows us to directly evolve our models into
implementations without changing methods, tools,
or materials!

• Model-driven development a method for
  developing software based on automatic (complete)
  program generation from models

19
The OMGs Model Driven Architecture

• The OMG has formulated an initiative called
  Model-Driven Architecture (MDA)
• A framework for a set of standards in support of
  a model-centered style of development
• Inspired by the widespread public acceptance of
  UML
• Key characteristic of MDA
• The focus and principal products of software
  development are models (instead of programs)
• Models all the way the design is the
  implementation

20
The Unified Modeling Language
21
The Unified Modeling Language

• Standardized by the Object Management Group in
  1997
• The foundation of MDA
• A consolidation of proven ideas and practices
  based on the object paradigm into a
  general-purpose OO modeling language
• Major advantages
• widely adopted by software practitioners
• widely taught in universities and technical
  seminars
• supported by many software tool vendors

22
The Evolution of UML
UML 2.0 (MDA)
UML 1.4.1
UML 1.4 (action semantics)
UML 1.3 (extensibility)
UML 1.1 (OMG Standard)
Foundations of OO (Nygaard, Goldberg,
Meyer,Stroustrup, Harel, Wirfs-Brock,
Reenskaug,)
23
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

24
UML Model Viewpoints

• Requirements (use case diagrams)
• Static structure (class diagrams)
• kinds of objects and their relationships
• Object behavior (state machines)
• possible life histories of an object
• Inter-object behavior (activity, sequence, and
  collaboration diagrams)
• flow of control among objects to achieve
  system-level behavior
• Physical implementation structures (component and
  deployment diagrams)
• software modules and deployment on physical nodes

25
Model-Based and View-Based Approaches

• UML uses a model-based approach rather than a
  view-based approach

?
Model-view consistency is enforced through the
UML metamodel
26
UML Class Diagrams

• Shows the kinds of entities in a system and their
  general relationships

Association class
Airplane
Association
owner
0..
ordered
Airline
27
Object Instance Diagrams

• Shows object instances in a particular case of a
  general class diagram

Link
28
Collaboration Diagram

• Depict generic structural and behavioral patterns

Classifier role
NB It is possible to havecollaboration
diagramswithout an Interaction overlay (pure
structure)
Message part of an Interaction
29
Sequence Diagrams

• Show interactions between objects with a focus on
  communications (a different representation of a
  collaboration)

30
Sequence Diagrams and RT Design

• Sequence diagrams are extremely useful for
  showing object interactions
• very common, particularly in real-time systems
• well suited for event-driven behavior
• in telecom, many protocol standards are defined
  using sequence diagrams
• However
• Inadequate modeling of timing constraints
• Overly simplified model of time (centralized
  timing source, no provision for modeling clock
  accuracy, resolution, etc.)
• Do not scale up to complex systems

31
Activity Diagrams

• Different focus compared to sequence diagrams

Caller
Operator
Callee
activity
ContactOperator
ContactCallee
swimlane
Respond
Notify Parties
32
Activity Diagrams and RT Design

• Better than sequence diagrams for
• showing concurrency (forks and joins are
  explicit)
• scaling up to complex systems
• However
• No standard way of denoting timing information
• Simplistic model of concurrency (mapping to OS
  concurrency mechanisms not clear)

33
UML Statechart Diagrams

• Very suitable for specifying complex event-driven
  behavior

34
State Machines and RT Design

• Many real-time systems are event-driven
• very well suited to those systems
• scale up very nicely
• However
• not directly connected to time (except for time
  events)
• run-to-completion paradigm (can cause priority
  inversion)
• Undefined relationship to platform concurrency
  mechanisms

35
Component and Deployment Diagrams

• Implementation focus

Component
Node
Generally not sophisticated enough for complex
real-time system needs
36
Application Platforms

• In practice, platforms are often applications
  built on top of other platforms

Software Application
37
Implementation Diagrams and RT Systems

• Probably the weakest part of UML
• Not sophisticated enough to capture the various
  complex aspects of deployment common to real-time
  systems
• deferred mapping of software to hardware
• mapping of software to software
• No standard way to describe the quantitative
  requirements/characteristics of hardware and
  software (e.g., scheduling discipline)
• ..

38
Conclusion Standard UML and RT Design

• While standard UML has many modeling capabilities
  useful for real-time software design, it also has
  some significant deficiencies
• Undefined model of time
• Inadequate model of concurrency
• Inadequate facilities for modeling platforms and
  software-to-platform mappings
• No standard provision for associating
  quantitative information with models
• How can these issues be overcome?

39
Specializing UML
40
Specialization of UML

• Avoiding the PL/I syndrome (language bloat)
• UML standard as a basis for a family of
  languages

Variations produced using built-in extensibility
mechanismsstereotypes, tagged
values, constraints
UML Standard 1.4
41
Stereotypes and Tagged Values

• Stereotype a custom specialization of an
  existing UML concept (or another stereotype)
• Inherits all the attributes of the (metamodel)
  superclass
• By default, inherits the notation but may have
  its own notation or icon
• Identified by a stereotype label between
  guillemets quotation marks
• Tagged value a pair consisting of a label and a
  value
• Like an attribute of the new metaclass
• E.g. delay 100
• Can be attached to an element of a model
• Usually associated with specific stereotypes

42
How Do We Specialize UML?

• Typically used to capture semantics that cannot
  be specified using UML itself

Integer
Semantics an active counter whose value
changes synchronously with theprogress of
physical time
Specialization through regular inheritance
43
Specializing UML Stereotypes

• We can add semantics to any standard UML concept
• Must not violate standard UML semantics

An example of the UMLClass concept
Integer
clock Stereotype of Class with added semantics
an active counter whose value changes
synchronously with theprogress of physical time
Tagged value associatedwith the clock
stereotype
resolution 500 ns
44
UML Profiles

• 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
• additional semantic constraints cannot contradict
  the general UML semantics
• within the semantic envelope defined by the
  standard

Standard UML Semantics
Profile X
Profile Y
45
Format Domain Model and Extensions
Corresponding UMLextensions (tabularform)
46
The Real-Time UML Profile
47
Requirements for a RT Profile

• In 1999, the OMG issued a request for proposal
  (RFP.1) UML profile for scheduling performance
  and time
• Requirements for 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
• Appropriate notation for above capabilities

48
RT Profile Guiding Principles

• Ability to specify quantitative information
  directly in UML 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

49
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
• Current quantitative analysis methods
• 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?

50
Issues with Quantitative Methods

• Require uncommon and highly-specialized skills
• Software is notoriously difficult to model
• highly non-linear (detail often matters)
• models are frequently severely inaccurate and not
  trustworthy
• typical modeling process is highly manual

Actual System
51
RT-UML Development Process Model

• Seamless inter-working of specialized tools based
  on shared standards

Automated model conversion
QoS Specifications
Model Editing Tool
Model Analysis Tool
2.5
Inverse automated model conversion
52
Quality of Service Concepts

• Quality of Service (QoS)
• a specification (usually quantitative) of how
  well a particular service can or should be
  performed
• e.g. throughput, capacity, response time
• Two sides to this notion
• offered QoS the QoS that it provides to its
  clients
• required QoS the QoS it requires from other
  components to support its QoS obligations

53
Resources and Quality of Service

• Resource
• an element whose service capacity is limited,
  directly or indirectly, by the finite capacities
  of the underlying physical elements
• These capacities are expressed as QoS attributes

Resource(e.g., data base)
Client
Resource Usage
RequiredQoS (e.g., 2 ms response)
OfferedQoS(e.g., 1 ms response)
Key analysis question (RequiredQoS ? OfferedQoS)
?
54
Offered QoS

• Like all guarantees, the offered QoS is
  conditional, contingent on the resource getting
  the QoS that it needs from its resources

55
What the Real-Time Profile Provides

• A set of stereotypes and their associated tagged
  values and constraints that
• Identify clients, resources, and resource usages
  in a UML model
• Specify corresponding offered and required QoS
  values

Offered QoS
Required QoS
56
UML Real-Time Profile Components and Structure
General Resource Modeling Framework
Analysis Models
Infrastructure Models
57
Domain Model Basic Resource Usage

• Models a particular situation that needs to be
  analyzed for some time-related property (e.g.,
  response time)

58
Domain Model Time Concepts
59
Domain Model Timing Mechanisms
60
Specifying Time Values

• Time values can be represented by a special
  stereotype of Value (RTtimeValue) in different
  formats e.g.
• 1204 (time of day)
• 5.3, ms (time interval)
• 2000/10/27 (date)
• Wed (day of week)
• param, ms (parameterized value)
• poisson, 5.4, sec (time value with a Poisson
  distribution)
• histogram 0, 0.3 1, 0.4 2, 0.3, 3, ms

61
Example Telemetry System

• Three cyclical tasks

62
Example Schedulability Annotations
SASituation
Result
63
Example Deployment Specification
SASchedulable
SASchedulable
SASchedulable
TelemetryGatherer
TelemetryDisplayer
TelemetryProcessor
DataGatherer
DataDisplayer
DataProcessor
SAEngine
SARate1,
SASchedulingPolicyFixedPriority
Ix86Processor
64
Example Analysis Results
SASituation
SAAction
SAPriority2,
SAWorstCase(93,'ms'),
SATrigger
Additional tool-specific results encased in UML
Notes
RTduration(33.5,'ms')
A.1.1main ( )
RTat('periodic',100,'ms')
SAResponse
SAAbsDeadline(100,'ms')
A.1gatherData ( )
SASchedulable
Sensors
TelemetryGatherer
TGClock Clock
SensorInterface
DataGatherer
SAAction
RTstart(16.5,'ms'),
RTend(33.5,'ms')
TGClock Clock
A.1.1.1 writeStorage ( )
SAResource
SATrigger
SACapacity1,
SAAccessControlPriorityInheritance
RTat('periodic',60,'ms')
SAResponse
SensorData
SAResponse
SAPriority3,
SAAbsDeadline(60,'ms')
RawDataStorage
SAWorstCase(177,'ms'),
C.1displayData ( )
RTduration(46.5,'ms')
B.1.1 main ( )
SAAction
SAAction
RTstart(10,'ms'),
RTstart(3,'ms'),
RTend(31.5,'ms')
RTend(5,'ms')
B.1.1.1 readStorage ( )
C.1.1.1 readStorage ( )
SASchedulable
SASchedulable
TelemetryDisplayer
TelemetryProcessor
DataDisplayer
DataProcessor
SATrigger
SAResponse
RTat('periodic',200,'ms')
Display
SAPriority1,
SAResponse
DisplayInterface
SAWorstCase(50.5,'ms'),
SAAbsDeadline(200,'ms')
RTduration(12.5,'ms')
B.1filterData ( )
C.1.1 main ( )
TGClock Clock
65
The Blessing of Platform Independence
Platform-independent Software Application
and/or
Operating System-1
Operating System-2
Computing Hardware-1
Computing Hardware-2
Platform1
Platform2

• Platform independent applications are
• Easily portable
• Less complex (separation of concerns)

66
Achieving Platform Independence

• Dilemma How can we achieve platform independence
  if our (real-time) application is sensitive to
  the physical characteristics of the platform?
• Fact No application is 100 platform independent
• There are always some assumptions about the
  underlying technology
• Solution Include a technology-independent
  specification of the required platform
  characteristics (required QoS) as part of the
  application
• Defines the envelope of acceptable platforms for
  the application

67
Required Environment Partitions

• The Internet-based video application

QoS domain
vw VideoWindow
b Browser
Environment A -- IPC rate -- CPU speed
-- availability
vp VideoPlayer
ws WebServer
vs VideoServer
68
QoS Domains

• Specify a domain in which certain QoS values
  apply universally
• failure characteristics (failure modes,
  availability, reliability)
• CPU performance
• communications characteristics (delay,
  throughput, capacity)
• etc.
• During realization, the QoS values of a domain
  can be compared against those of a concrete
  platform (engineering environment) to see if a
  given environment can support that model
• In essence, through the use of QoS domains, we
  are
• Specifying explicitly the kind of environment
  expected by our program logic in a way that is
  independent of specific technologies or hardware
  configurations

69
Modeling QoS Domains in UML

• GRMrequires stereotype of GRMdeploys
• Defines a reference platform for an application

70
Summary The Problem

• Many software applications, and real-time systems
  in particular, are highly sensitive to the
  quantitative characteristics of the physical
  environment in which they operate
• They can have a fundamental impact on application
  logic
• Ignoring this issue often leads to major failures
  of design
• Unfortunately, many general software
  methodologies actually postpone consideration of
  these issues until the closing stages of
  development
• a misunderstanding of the notion of
  platform-independent design
• New methods and tools are required to properly
  address the problem of real-time software design

71
Engineering-Oriented Software Design

• Analysis and design of software systems based on
• Models (model-driven development)
• Explicit QoS specifications (accounting for
  physical properties)
• Quantitative analysis techniques and simulation
• Advantages
• Simpler and more reliable systems since models
  use domain concepts rather than
  implementation/programming concepts
• Predictability crucial design characteristics
  can be calculated prior to actual construction
• Continuity through model evolution no
  error-inducing discontinuities in the process,
  tools, or materials used

72
Summary The Real-Time UML Standard

• A key tool for engineering-oriented development
• A standard yet flexible framework for expressing
  real-time concepts and mechanisms using UML
• includes the ability to specify quantitative
  information through its QoS-based general
  resource model
• Supports automation of certain complex design
  functions

73
Where to Obtain the RT Profile

• A copy of the real-time standard submission can
  be obtained from the Object Management Group
  website at
• http//www.omg.org/cgi-bin/doc?ptc/2002-03-02

74
Bibliography

• Cooper, R., Introduction to Queueing Theory, The
  Macmillan Company, 1972.
• I. Jacobson, G. Booch, and J. Rumbaugh, The
  Unified Software Development Process,,
  Addison-Wesley, 1999.
• Klein, M. et al., A Practitioners Handbook for
  Real-Time Analysis Guide to Rate Monotonic
  Analysis for Real-Time Systems, Kluwer Academic
  Publishers, 1993.
• OMG, The Unified Modeling Language version 1.3,
  The Object Management Group, August 1999.
• OMG, UML Profile for Scheduling, Performance,
  and Time - Request for Proposal, The Object
  Management Group, March 1999 (doc ad/99-03-13).
• J. Rumbaugh, I. Jacobson, and G. Booch, The
  Unified Modeling Language Reference Manual,,
  Addison-Wesley, 1999.
• B. Selic, Turning Clockwise Using UML in the
  Real-Time Domain, Communications of the ACM,
  vol.42, no.10, October 1999 (pp.46-54).
• B. Selic, A Generic Framework for Modeling
  Resources with UML, IEEE Computer vol.33, no.6,
  June 2000 (pp. 64-69).
• B. Selic and J. Rumbaugh Using UML for Modeling
  Complex Real-Time Systems, ObjecTime Limited and
  Rational Software Corp., March 1998.
  (http//www.rational.com)