Chapitre 1

Real-time Systems – Design and analysis
Chapter 1: Introduction
1
Outline
• Real-time systems overview

– What are they?
• Terms and concepts for real-time systems
• Real-time systems analysis and design flow
• Current status for real-time systems design – need of
higher abstractions
• Introduction to objects and the UML language
INF 6600 – Real-Time Systems – Design and Analysis 2

© 2005
Real-time systems overview
• Computing systems are everywhere

• Most of us think of “desktop” computers
– PC’s
– Laptops
– Mainframes
– Servers
• But there’s another type of computing system
– Far more common...

© 2005
• Embedded computing systems

Computers are in here...
– Computing systems embedded within
electronic devices and here...
– Hard to define. Nearly any computing and even here...

system other than a desktop computer
– Billions of units produced yearly, versus
millions of desktop units
– Perhaps 50 per household and per
automobile Lots more of these,
though they cost a lot
less each.

© 2005
• Computing systems that monitor, respond to, or control an

external environment
• Real-time systems must meet various timing constraints
imposed on it by the external environment
– the correctness depends not only on the logical result but
also the time it was delivered
– failure to respond is as bad as the wrong response!

• The external environment and the computing systems are
connected through sensors, actuators, and other input-output
interfaces

© 2005
Real-time systems applications and examples
• Ubiquitous and proliferating appearing as part of commercial,

governmental, military, medical, education and cultural
infrastructures, …
– Vehicle systems for automobiles, aircraft, railways, …
– Traffic control for highways, airspace, …
– Process control for power plants, chemical plants, …
– Medical systems for radiation therapy, patient monitoring, …
– Military uses (firing weapons, tracking, …)
– Telephone, radio and satellite communications
– Computer games, multimedia systems (audio, video interfaces)
– Building managers that control such entities as heat light, doors, elevators
– …
© 2005
Outline

– What are they?
higher abstractions

© 2005
Terms and concepts for real-time systems
• Timing constraints
– Both logically and temporary correctness
– The most common and simple assertion is the deadline
• A limit on time when a computation must complete
– e.g. in a robot control system, there may be a deadline or a
limit between the time that a moving robot senses an
obstruction in its path and the time that an actuator, such as a
wheel controller, is activated to move the robot in a safer
direction

© 2005
• Hard and soft real-time systems

– Hard real-time systems – without exception they must meet their timing
constraints
• If a constraint is violated, the system fails
• E.g. the controller of the vertical motion of an elevator
– Missing a particular timing constraint could mean that the elevator stops
between two floors
– Soft real-time systems – they may be considered successful, that is,
perform their mission, despite missing some timing constraints
• E.g. a telephone system that sometime fails to make a connection (the
sender just dials again)
– There is a continuum between the extremes of hardness and softness,
and most systems fit somewhere in between

© 2005
• Deterministic (non-statistical) timing constraints

– Deadline and other assertions involving time are expressed
in terms of exact or fixed values, rather than aggregate
measures such as averages
– Failure to meet deterministic guarantees often means
mission failure (especially for hardware real-time systems)
• E.g. the railway crossing gate on a road must always be closed by
the time a train reaching the crossing, not closed “most of the time”

© 2005
• Concurrency – distinguishing feature of real-time

systems
– True concurrency – Several processors running in parallel
– Pseudo-concurrency – Model to represent logically parallel
activities, even though they may be implemented by
interleaving the activities on a single processor
– Physical concurrency – part of the external world to which
they are connected (e.g. signals from the environment can
arrive simultaneously)

© 2005
• Issues surrounding the execution of concurrent systems

– Scheduling concurrent tasks
• Many strategies for concurrency control are possible. Most prevalent are :
– FIFO run-to-completion event handling
– Non-preemptive task switching
– Time slicing round robin
– Cyclic executive
– Priority-based preemption
– Event arrival patterns
• Periodic arrival patterns – the task is reinitiated on a fixed period ± a small
variation (jitter)
• Aperiodic arrival patterns – the tasks don’t occur with a regular period
– Timing of aperiodic events may be: irregular, bursty, bounded, bounded average
rate, unbounded
– Robust sharing of resources (e.g. asynchronous access, critical sections)

© 2005
• Real-time programming – Systems design become

especially difficult when one combines the problems of
concurrency with those related to time
Program Complexity
Real-time programs
Multiprograms
(implementing logical parallelism)
Sequential programs
Informal hierarchy of program complexity [Wirth77]

© 2005
• Correctness and robustness

– A system is correct when it does the right think all the time
– Such a system is robust when it does the right thinks under
novel (unplanned) circumstances, even in the presence of
unplanned failures of portions of the system
– Designers must be on guard for
• Deadlock – a task waits indefinitely for conditions that can never
occur
• Exceptional conditions
– Identify the fault
– Take “evasive action” (correct the failure or repeat the previous
computation to restore the correct system state or enter a fail-safe
condition)
• Race conditions

© 2005
• Reliability
– Is a measure of how often a system will fail
– Alternatively, it is the probability that a system will perform correctly
over a given period of time
• Fault tolerance
– Is concerned with the recognition and handling of failures
– Avoid failure is possible through techniques for reliability
• Criticality
– A measure of the failure cost – the higher the cost of failure, the more
critical the system
• E.g. of very critical systems: aircraft controller, nuclear power plant
controller
– Criticality is a different dimension than hardness/softness
• E.g. a computer game might still be a hard system, even though it is not a
critical one

© 2005
• Others distinguishing features of real-time systems

– Predictability
• The extent to which system responses characteristics may be known
in advance
• The more common aspects are schedulability and memory
– Application-specific and stand alone systems
– The human-machine interfaces need to be designed
especially carefully in order to prevent human errors and
confusions.

© 2005
Example of Air Traffic Control (ATC)
• Real-Time System that monitors aircraft flying

© 2005
© Alan C. Shaw
Example of Air Traffic Control (ATC)
• Some timing constraints

– The radar should track each
plane in the space at a rate
of at least one operation
every 10s per plane
– The current position and
track of each plane should
be updated and displayed at
least once every 3s
– A response must be
provided to an operator
command within two
seconds
© Alan C. Shaw

© 2005
Hardware Architecture for Real-time Systems
Node IP1 Memory … IP2
Bus
Node Node Cache IP3 … IP4

Processor
Memory
Actuators
I/O sensors
Devices display
T1 T2 T3
Low-level Hardware Interfacing
RTOS • One of the hallmarks of real-
Hardware Architecture time and embedded systems
• Hardware devices often require
custom devices

© 2005
Real-time Operating Systems
• Functions of an RTOS
– Managing the interface to the underlying hardware
– Scheduling and preempting tasks
– Managing memory
– Providing common services
• RTOS differ from normal OS in
– Scaleability
– Scheduling policies
– Support for embedded target environments
© 2005
Common Services Provided by the Real-Time
Operating Systems
Component Typical Services Provided
Kernel - Task Scheduling
- Memory management
- Resource protection
- Interrupt handling
- Task message passing
- Task-event pend and post
File System - File creation and deletion, file I/O
- Directory structure and navigation
Device I/O - Device drivers for standard hardware devices
Networking - Low-level protocol and device-driver support for network communication
High level comm. - Communications protocols (e.g. TCP/IP, SMTP, FTP)
Debugging -Monitor task execution
- Start and stop tasks

© 2005
Outline

– What are they?
higher abstractions

© 2005
Real-time Systems Analysis & Design Flow
• Requirements analysis results in a functional view. The question

is: what should the system do ?
• Preliminary design performs an operational analysis and leads to
the choice of logical components of a logical architecture. The
question is: how to do it ?
• Hw and Sw specific designs are often developed in parallel. The
question is: with which Hw/Sw units/components?
• Integration testing combines all the Hw and Sw and perform
global validation
• User validation – measurements, sometimes combined with formal
methods. It is done prior to acceptance of the system.

© 2005
Real-time Systems Analysis & Design Flow
Abstraction

© 2005
Design process model
• Describes order that design steps are processed Waterfall design model
– Behavior description step Analysis
– Behavior to structure conversion step
– Mapping structure to physical implementation Design
step
Implementation
• Waterfall model
– Proceed to next step only after current step Testing
completed
• Spiral model Spiral design model
– Proceed through 3 steps in order but with less Analysis Design
detail
– Repeat 3 steps gradually increasing detail
– Keep repeating until desired system obtained
– Becoming extremely popular (hardware & Code
software development) Test

© 2005
Waterfall method
• Not very realistic
– Bugs often found in later steps that must be fixed in
earlier step
• E.g., forgot to handle certain input condition
– Prototype often needed to know complete desired
Waterfall design model
behavior
• E.g, customer adds features after product demo Analysis
– System specifications commonly change Design

• E.g., to remain competitive by reducing power, size
– Certain features dropped Implementation
• Unexpected iterations back through 3 steps Testing

cause missed deadlines
– Lost revenues
– May never make it to market
© 2005
Spiral method
• First iteration of 3 steps incomplete
• Much faster, though
– End up with prototype
• Use to test basic functions
• Get idea of functions to add/remove
Spiral design model
– Original iteration experience helps in following
iterations of 3 steps
Analysis Design
• Must come up with ways to obtain structure and
physical implementations quickly
– E.g., FPGAs for prototype
• silicon for final product
Code
– May have to use more tools Test
• Extra effort/cost
• Could require more time than waterfall method
– If correct implementation first time with waterfall

© 2005
Outline

– What are they?
higher abstractions

© 2005
Current status for real-time systems design – need
of higher abstractions
• The most important trend in embedded systems
– Predicted in 1965 by Intel co-founder Gordon Moore
IC transistor capacity has doubled roughly every 18 months
for the past several decades
10,000
1,000
Logic transistors 100

per chip 10
(in millions) 1
0.1
Note:
0.01
logarithmic scale
0.001
1987
1991
1993
1999
2001
2005
1983
1985
1989
1995
1997
2003
2007
1981
2009
© 2005
• Graphical illustration of Moore law

1981 1984 1987 1990 1993 1996 1999 2002
10,000 150,000,000
transistors transistors
Leading edge Leading edge

chip in 1981 chip in 2002
• Something that doubles frequently grows more quickly

than most people realize!
– A 2002 chip can hold about 15,000 1981 chips inside itself
© 2005
• Design productivity gap
– While designer productivity has grown at an impressive rate
over the past decades, the rate of improvement has not kept
pace with chip capacity
10,000 100,000
1,000 10,000
Logic transistors 100 1000

per chip 10
IC capacity
Gap 100 Productivity
(in millions) 1
(K) Trans./Staff-Mo.
10
0.1 1
productivity
0.01 0.1
0.001 0.01
1993
1995
1999
2001
2003
2007
1981
1985
1987
1989
1991
1997
2005
2009
1983

© 2005
• Methodologies based on abstractions, where details are

taken into account gradually are mandatory
• These methodologies are one of the key issues for
covering the presented productivity gap
• UML and object-oriented are foundations for next
generations methodologies

© 2005
Outline

– What are they?
higher abstractions

© 2005
Object-oriented approach
• Advantages
– Consistency of models view
– Improved problem-domain abstraction
– Improved stability in the presence of changes
– Improved scaleability
– Better support for reliability and safety concerns
– Inherent support for concurrency
• Disadvantages
– Objects are an immature technology
– Objects are inefficient
– Lack of compiler and other tool support

© 2005
Unified Modeling Language (UML)
• UML is a language for expressing the constructs and relationship of complex
systems
• It was jointly developed by some of the major companies (e.g. Texas
Instruments, Microsoft, I-Logics, Oracle,…)
• It was accepted as a standard by OMG (Object Management Group’s)
• Major features
– Object Model
– Use cases and scenarios
– Behavioral modeling with statecharts
– Packaging of various kinds of entities
– Representations of tasking and task synchronization
– Models of physical topology
– Models of source code organization
– Support for object-oriented patterns

© 2005
Object-oriented in UML
• Objects
– Data and behavior
– They may represent
• Real world thinks (e.g. sensor, engine)
• Purely conceptual entities (e.g. bank account)
• Visual thinks (e.g. font)
– Main aspects
• Attributes (data)
• Behavior (operation and methods) - operation - named behavior of a class
• State - method - implementation of an operation
• Identity - interface - named collection of operations
• Responsibilities – the roles it serves within the system. Behavior and interfaces
provide the mean by which responsibilities are met.
• A class is an abstraction of the common properties from a set containing
many similar objects. A class may be thought as the type of an object

© 2005
• Aspects of a message-transaction object
Attributes Behavior State Identity Responibilities

-Retry count -Send -Idle -Transaction for -Implements reliable
-Max retries -Receive -Sending message 0x200 transmissions for the
-Time to retry -Notify sender -Waiting sender
-Resends message after
fixed period of time has
elapsed until some max
retry count is exeeded
-Notifies the sender if
unable to complete
transaction

© 2005
• Messaging
– The logical interface between objects is done with the passing of
messages
– A message is an abstraction of data and/or control information passed
from one object to an other
– Different implementations are possible
• A function call
• Sending/Receiving via an RTOS
• An interrupt
• …
– The key messages are identified during the early analysis phase
– Later design elaborates an implementation strategy (synchronization
and timing requirements for each message)

© 2005
• Objects as autonomous Machines

– Each object acts as a separated entity
– These machines does not have to be very smart, but it must own its
responsibilities and collaborate with other machines to achive some
higher-order goals
– Object must ensure at least
• Data integrity
• Respect of interface protocol
• Their own behavior
– Distributed intelligence – fundamental role of object systems
• Each system, however lowly and simple, must have enough intelligence to
mange its resources and perform its own behavior

© 2005
Class diagrams in UML
• UML classes are represented using rectangles with the name

of the class inside
• A variation uses a three-segment box
– The top segment holds the name of the class
– The middle segment contains a list of attributes
– The bottom segment contains a list of operations
Not all the attributes and operations need to be listed
WindSpeed_sensor Class Name

Speed : int
Calibration constant : int Attributes
GetValue() Behavior
Calibrate()

© 2005
– relations between class and objects –
• Associations are relationships that typically manifest
themselves at run-time to permit the exchange of
messages between objects
• It is shown using simple lines connecting two objects
• Unless otherwise specified, associations are bidirectional and support
messaging in either direction
• Examples
Class Association Class
Linear Engine has a Piston
position Sensor Flight computer controls an Engine
sensor Linear position sensor is a type of Sensor
© 2005
• Aggregation associations are used when one object

logically pr physically contains an other
– It is shown with diamond at the owner (aggregate) end of the
relationship
– The number at each end of the relationship line denotes the
number of objects in the relationship. This is called
multiplicity of the role
Multiplicity
0,1
Aggregate Window Menu

© 2005
• Composition is a strong form of aggregation in which

the owner is explicitly responsible for the creation and
destruction of the part objects
– It is shown either with filled-in aggregation diamonds or the
physical containment of classes within the composite class
– Note: components of composites can not be shared
Window
0,2 1
:Scrollbar :Client area

© 2005
• Generalization is the relationship used when one class

is the specialization of another
– It is an “is-a-kind-of” relationship among classes (e.g.: an
infrared sensor is a kind of sensor)
– It allows objects to be specified by difference rather than
from scratch each time
– An important principle of generalization is the Liskov
Substitution Principle (LSP) – a class must continue to act as
though it were also in instance of its superclass
– Generalization is shown with directed lines with closed
arrowheads
© 2005
• Dependency is a relationship Type of Description
in which changes to one dependency
model element (the supplier) Abstraction Relates two models that
impact another model represent the same concept at
element (the client) different abstraction levels
Binding Connects templates arguments
– It is displayed in the diagram
to template parameters
editor as a dashed line with an
open arrow that points from Realization Indicates that the client is an
implementation of the supplier
the client model element to the
supplier model element Usage Indicates that one model
– Types of dependency requires an other model for its
full implantation

© 2005
Example for dependency
and generalization relationships

© 2005
Use Cases in UML
• A use case is a cohesive piece of functionality of the system that

is visible from exterior. It is a function that returns an
observable value to an actor
• Actors are objects that exists outside the scope of your system
• A use case is not a class, it must be ultimately realized by
collaborations of objects working together to achieve the use
case functionality
• Use cases can receive messages from actors and send messages
to them
• A use case may have relations with other use cases (they will be
detailed in chapter 2)
• Use cases are shown as ovals with solid borders Use case
• The icon of an actor is a figure

© 2005
Sequence Diagrams in UML
• A particular path through a use case is a scenario

• Sequence diagrams are used to capture the set of
interesting scenarios
• Sequence diagrams may capture also the sequence of
messages between objects

© 2005
Physical Representation in UML
• A deployment diagram is a simplified representation

of the electronic architecture on with the software will
execute
– Nodes
– Connections
• Node may contain deployable software units called
components
• Components may be
– Static (e.g. files containing source code, unit tests)
– Dynamic (e.g. executable libraries and sub-systems)

© 2005
Sample Deployment Diagram in UML

© 2005
Packages in UML
• A package represent a logical grouping of elements

• Example – user interface package
User Interface
Client Area Scrollbar
Window
SDI Window MDI Window

© 2005
Stereotypes in UML
• Stereotypes are used in UML models to clarify and extend its

meaning
• Example – node stereotypes

© 2005
Summary
• Real-time systems are everywhere

• Key challenge – complete design methodologies, able
to deal with systems complexity
• Raising abstraction levels is necessary to improve
productivity
– Object-oriented approach and UML introduction

© 2005

Chapitre 1

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Chapitre 1

Hochgeladen von

Copyright:

Verfügbare Formate

Real-time Systems – Design and analysis

• Real-time systems overview

INF 6600 – Real-Time Systems – Design and Analysis 2

• Computing systems are everywhere

INF 6600 – Real-Time Systems – Design and Analysis 3

• Embedded computing systems

– Hard to define. Nearly any computing and even here...

INF 6600 – Real-Time Systems – Design and Analysis 4

• Computing systems that monitor, respond to, or control an

– failure to respond is as bad as the wrong response!

INF 6600 – Real-Time Systems – Design and Analysis 5

• Ubiquitous and proliferating appearing as part of commercial,

• Real-time systems overview

INF 6600 – Real-Time Systems – Design and Analysis 7

INF 6600 – Real-Time Systems – Design and Analysis 8

• Hard and soft real-time systems

INF 6600 – Real-Time Systems – Design and Analysis 9

• Deterministic (non-statistical) timing constraints

INF 6600 – Real-Time Systems – Design and Analysis 10

• Concurrency – distinguishing feature of real-time

INF 6600 – Real-Time Systems – Design and Analysis 11

• Issues surrounding the execution of concurrent systems

INF 6600 – Real-Time Systems – Design and Analysis 12

• Real-time programming – Systems design become

Informal hierarchy of program complexity [Wirth77]

INF 6600 – Real-Time Systems – Design and Analysis 13

• Correctness and robustness

INF 6600 – Real-Time Systems – Design and Analysis 14

INF 6600 – Real-Time Systems – Design and Analysis 15

• Others distinguishing features of real-time systems

INF 6600 – Real-Time Systems – Design and Analysis 16

• Real-Time System that monitors aircraft flying

INF 6600 – Real-Time Systems – Design and Analysis 17

• Some timing constraints

INF 6600 – Real-Time Systems – Design and Analysis 18

Node IP1 Memory … IP2

Node Node Cache IP3 … IP4

INF 6600 – Real-Time Systems – Design and Analysis 19

INF 6600 – Real-Time Systems – Design and Analysis 21

• Real-time systems overview

INF 6600 – Real-Time Systems – Design and Analysis 22

• Requirements analysis results in a functional view. The question

INF 6600 – Real-Time Systems – Design and Analysis 23

INF 6600 – Real-Time Systems – Design and Analysis 24

INF 6600 – Real-Time Systems – Design and Analysis 25

– System specifications commonly change Design

• Unexpected iterations back through 3 steps Testing

INF 6600 – Real-Time Systems – Design and Analysis 27

• Real-time systems overview

INF 6600 – Real-Time Systems – Design and Analysis 28

Logic transistors 100

• Graphical illustration of Moore law

Leading edge Leading edge

• Something that doubles frequently grows more quickly

Logic transistors 100 1000

INF 6600 – Real-Time Systems – Design and Analysis 31

• Methodologies based on abstractions, where details are

INF 6600 – Real-Time Systems – Design and Analysis 32

• Real-time systems overview

INF 6600 – Real-Time Systems – Design and Analysis 33

INF 6600 – Real-Time Systems – Design and Analysis 34

INF 6600 – Real-Time Systems – Design and Analysis 35