Real Time Systems Design

actuallyabandonedΗλεκτρονική - Συσκευές

15 Νοε 2013 (πριν από 3 χρόνια και 6 μήνες)

101 εμφανίσεις


Real Time Systems Design

The RTS design is investigated using
common component based model

1

Embedded vs. Real Time Systems


Real Time System: Correctness of the system depends not
only on the logical results, but also on the time in which the
results are produced.


Embedded system: is a computer system that performs a
limited set of specific functions. It often interacts with its
environment.

Embedded

Systems

Real Time

Systems

2

Examples


Real Time Embedded:


Nuclear reactor control


Flight control


Basically any safety critical system


GPS


MP3 player


Mobile phone


Real Time, but not Embedded:


Stock trading system


Skype


Pandora


Embedded, but not Real Time:


Home temperature control


Sprinkler system


Washing machine, refrigerator, etc.


Blood pressure meter


3

Characteristics of RTS


Event
-
driven, reactive.


High cost of failure.


Concurrency/multiprogramming.


Stand
-
alone/continuous operation.


Reliability/fault
-
tolerance requirements.


Predictable behavior.


4

Time

digital clock

tick

granule

now

instant

instant

past

future

duration

event

event

time line

5

Definitions


Hard

real
-
time



systems

where

it

is

absolutely

imperative

that

responses

occur

within

the

required

deadline
.

E
.
g
.

Flight

control

systems
.


Soft

real
-
time



systems

where

deadlines

are

important

but

which

will

still

function

correctly

if

deadlines

are

occasionally

missed
.

E
.
g
.

Data

acquisition

system
.


Real

real
-
time



systems

which

are

hard

real
-
time

and

which

the

response

times

are

very

short
.

E
.
g
.

Missile

guidance

system
.


A single system may have all hard, soft and real real
-
time subsystems.

In reality many systems will have a cost function associated with missing each deadline

6

Control systems


Man
-
machine interface: input devices, e.g. keyboard and output devices,
e.g. display


Instrumentation interface: sensors and actuators that transform between
physical signals and digital data


Most control systems are hard real
-
time


Deadlines are determined by the controlled object, i.e. the temporal
behavior of the physical phenomenon

Operator

Controlled
Object

Real
-
Time
Computer
System

Man
-
Machine

Interface

Instrumentation

Interface

7

Control system example


Example:

A simple one
-
sensor, one
-
actuator control system.

control
-
law

computation

A/D

A/D

D/A

sensor

plant

actuator

r
k

y
k

y(t)

u(t)

u
k

reference

input r(t)

The system

being controlled

Outside effects

8

Control systems cont’d.

Pseudo
-
code for this system:

set timer to interrupt periodically with period
T
;

at each timer interrupt
do


do analog
-
to
-
digital conversion to get
y
;


compute control output
u
;


output
u

and do digital
-
to
-
analog conversion;

end do

T

is called the
sampling period
.
T

is a key design choice.
T
ypical

range for
T
: seconds to milliseconds.

9

10

Taxonomy of Real
-
Time Systems

11

Taxonomy of Real
-
Time Systems

12

Taxonomy of Real
-
Time Systems

13

Taxonomy: Static


Task arrival times can be predicted


Static (compile
-
time) analysis possible


Allows good resource usage (low idle time for
processors).


14

Taxonomy: Dynamic


Arrival times unpredictable


Static (compile
-
time) analysis possible only for
simple cases.


Processor utilization decreases dramatically.


In many real systems, this is very difficult to
handle.


Must avoid over
-
simplifying assumptions


e.g., assuming that all tasks are independent,
when this is unlikely.

15

Taxonomy: Soft Real
-
Time


Allows more slack in the implementation


Timings may be suboptimal without being
incorrect.


Problem formulation can be much more
complicated than hard real
-
time


Two common and an uncommon way of handling
non
-
trivial soft real
-
time system requirements


Set somewhat loose hard timing constraints


Informal design and testing


Formulate as an optimization problem

16

Taxonomy: Hard Real
-
Time


Creates difficult problems.


Some timing constraints are inflexible


Simplifies problem formulation.

17

Taxonomy: Periodic


Each task (or group of tasks) executes
repeatedly with a particular period.


Allows some static analysis techniques to be
used.


Matches characteristics of many real problems


It is possible to have tasks with deadlines
smaller, equal to, or greater than their period.


The later are difficult to handle (i.e., multiple
concurrent task instances occur).

18

Periodic


Single rate:


One period in the system


Simple but inflexible


Used in implementing a lot of wireless sensor
networks.


Multi rate:


Multiple periods


Should be harmonics to simplify system design



19

Taxonomy: Aperiodic


Are also called sporadic, asynchronous, or
reactive.


Creates a dynamic situation


Bounded arrival time interval are easier to
handle


Unbounded arrival time intervals are
impossible to handle with resource
-
constrained systems.

Example: Adaptive Cruise Control


Demo video



Control system


Hard Real Time


Multi
-
rate periodic



Camera


GPS


Low
-
speed mode for
rush hour traffic

United States Patent 7096109

20

Data Acquisition and Signal
-
Processing
Systems



Examples:


Video capture.


Digital filtering.


Video and voice compression/decompression.


Radar signal processing.



Response times range from a few milliseconds to a few
seconds.


Typically simpler than control systems

21

Other Real
-
Time Applications


Real
-
time databases.


Examples: stock market, airline reservations, etc.


Transactions must complete by deadlines.


Main dilemma
:

Transaction scheduling algorithms and real
-
time
scheduling algorithms often have conflicting goals.


Data is subject
temporal consistency

requirements.



Multimedia.


Want to process audio and video frames at steady rates.


TV video rate is 30 frames/sec. HDTV is 60 frames/sec.


Telephone audio is 16 Kbits/sec. CD audio is 128 Kbits/sec.


Other requirements
:

Lip synchronization, low jitter, low end
-
to
-
end
response times (if interactive).

22

Are
All

Systems Real
-
Time Systems?


Question:

Is a payroll processing system a real
-
time system?


It has a time constraint:

Print the pay checks every two weeks.



Perhaps it is a real
-
time system in a definitional sense, but it
doesn’t pay us to view it as such.



We are interested in systems for which it is not
a priori

obvious how to meet timing constraints.

23

The “Window of Scarcity”


Resources

may be categorized as:



Abundant:

Virtually any system design methodology can be used to
realize the timing requirements of the application.



Insufficient:

The application is ahead of the technology curve; no design
methodology can be used to realize the timing requirements of the
application.



Sufficient but scarce:

It is possible to realize the timing requirements of
the application, but careful resource allocation is required.

24

Example: Interactive/Multimedia
Applications

sufficient

but scarce

resources

abundant

resources

insufficient

resources

Requirements

(performance, scale)

1980

1990

2000

Hardware resources in year X

Remote

Login

Network

File Access

High
-
quality

Audio

Interactive

Video

The
interesting

real
-
time

applications

are here

25

OS or not?

Hardware

Operating

System

User Programs

Typical OS Configuration

Hardware

Including Operating

System Components

User Program

Typical Embedded Configuration

26

Foreground/Background Systems


Task
-
level, interrupt level


Critical operations must
be performed at the
interrupt level (not good)


Response time/timing
depends on the entire
loop


Code change affects
timing


Simple, low
-
cost systems

27

RTS Programming


Because of the need to respond to timing demands made by different stimuli/responses,
the system architecture must allow for fast switching between stimulus handlers.


Because of different priorities, unknown ordering and different timing requirements of
different stimuli, a simple sequential loop is not usually adequate.


Real
-
time systems are therefore usually designed as cooperating processes with a real
-
time
kernel controlling these processes.

Concurrent programming

28

Real Time Java?


Java supports lightweight concurrency (threads and
synchronized methods) and can be used for some soft
real
-
time systems.


Java is not suitable for hard RT programming but real
-
time
versions of Java are now available that address problems
such as


Not possible to specify thread execution time;


Uncontrollable garbage collection;


Not possible to access system hardware;


Etc.


Real
-
Time Specification for Java


Sun Java Real
-
Time System



Requires a Real Time OS underneath (e.g., no Windows support)



29

Classification of Scheduling Algorithms

All scheduling algorithms

static scheduling

(or offline, or clock driven)

dynamic scheduling

(or online, or priority driven)

static
-
priority

scheduling

dynamic
-
priority

scheduling

30

Scheduling strategies


Non pre
-
emptive scheduling


Once a process has been scheduled for execution, it runs to
completion or until it is blocked for some reason (e.g. waiting for I/O).


Pre
-
emptive scheduling


The execution of an executing processes may be stopped if a higher
priority process requires service.


Scheduling algorithms


Round
-
robin;


Rate monotonic;


Shortest deadline first;


Etc.

31

Real
-
time operating systems


Real
-
time operating systems are specialised operating systems
which manage the processes in the RTS.


Responsible for process management and

resource (processor and memory) allocation.


Do not normally include facilities such as file management.

14

32

Operating system components


Real
-
time clock


Provides information for process scheduling.


Interrupt handler


Manages aperiodic requests for service.


Scheduler


Chooses the next process to be run.


Resource manager


Allocates memory and processor resources.


Dispatcher


Starts process execution.

33

Interrupt servicing


Control is transferred automatically to a

pre
-
determined memory location.


This location contains an instruction to jump to

an interrupt service routine.


Further interrupts are disabled, the interrupt

serviced and control returned to the interrupted

process.


Interrupt service routines MUST be short,

simple and fast.

34

Metrics for real
-
time systems differ from that for time
-
sharing systems.












schedulability

is the ability of tasks to meet all hard deadlines


latency

is the worst
-
case system response time to events


stability

in overload means the system meets critical deadlines even if all
deadlines cannot be met


What’s Important in Real
-
Time


Time
-
Sharing
Systems

Real
-
Time
Systems

Capacity

High throughput

Schedulability


Responsiveness

Fast average response

Ensured worst
-
case
response

Overload

Fairness

Stability

35


Page
36

Limited Resources


Common Component based software engineering
(CBSE) technologies (JavaBeans, CORBA and COM) are
seldom used as they:


Require excessive processing requirements


Require excessive memory requirements


Provide unpredictable timing characteristics


Page
37

System Level Analysis


At system level we analyze to determine if the system
composed fulfils the timing requirements.


Several different mature analysis methods exist, for
example, analysis for priority
-
based systems and pre
-
run
-
time scheduling techniques


Page
38

Real
-
time Component Models


Using a standard operating system in a real
-
time
application, such as windows NT must be done
carefully, as it was designed to be used so.


Page
39

Application
-
specific Component Models


Maintain a component library which the application
engineer can use when developing an application.



In addition to infrastructure components, domain
specific component models, which in fact have been
used for many years for certain domains must be
considered.



Page
40

IEC 61131
-
3 Application Structure



Global and

direct

variables

Access

path

Execution

control

path

Variable

access

path

FB

Task

Program

Program

FB

FB

Task

Program

Task

Program

FB

FB

Task

Resource

Resource

Configuration

Communication

Function

Function

Block

Variable


Page
41

A Configuration in IEC 61131
-
3


Encapsulates all software for an application

and
consists of

one or several
resources

which provide the
computational mechanisms.


Page
42

A Program in IEC 61131
-
3


A program is written in any of the languages proposed
in the standard, for example:


Instruction lists


Assembly languages


Structured text


A high level language similar to Pascal


Ladder diagrams


Function block diagrams (FBD)


Page
43

A Port
-
based Object Approach


The model is based upon the development of domain
-
specific components which maximize usability,
flexibility and predictable temporal behavior.


Independent tasks are the bases for the PBO model.


Whenever a PBO needs data for its computation, it
reads the most recent information from its in
-
ports,
irrespective of its producer.


The

PBOs

are

in

their

nature

periodic

and

the

system

can

be

analyzed

using

traditional

schedulability

analysis
.


Page
44

A Port
-
based Object

Port
-
based

object

Variable

input ports

Variable

output ports

Resource ports for

communication
with sensors and actuators

Configuration parameters


Page
45

Designing Component
-
based RTS

System specification

Top
-
level design

Detailed design

Scheduling / interface
check

Obtain components
timing behavior on
target platform

System verification

Final product

Component
library

Create specifications for
the new components

Implement and verify
new components using
classical development
methods

Add new
components
to library

Architecture analysis


Page
46

Top
-
level Design


The first stage of the development process involves de
-
composition of the system into manageable
components



Page
47

Detailed Design


At this stage a detailed component design is performed,
by selecting components to be used from the candidate
set.


Page
48

Architecture Analysis


At this stage it is time to check that the system under
development satisfies extra
-
functional requirements
such as:


Maintainability


Reusability


Modifiability


Testability


Page
49

Scheduling


At this point we must check that the temporal
requirements of the system can be satisfied, assuming
time budgets assigned in the detailed design stage.



In other words, we need to make a schedulability
analysis of the system based on the temporal
requirements of each component



Page
50

WCET Verification


Performing a worst
-
case analysis can either be based
on measurements or on a static analysis of the
source code.



What is more interesting in the test cases is the
execution time behavior shown as a function of input
parameters as shown in the following slide.


Page
51

An Execution Time Graph



Execution time



Input



domain 1



domain 2



domain 3




The execution time shows different values for the different


input sub
-
domains.


Page
52

Maximum execution time per sub
-
domain




Execution time



Input



domain 1



domain 2



domain 3




Page
53

Implementation of New Components


New components; Those not already in the library must
be implemented. The designer of the component has
two requirements:


The functional requirements


The assigned time budget


Page
54

System Build and Test


Finally, we build the system using old and new
components.


We must now verify the functional and temporal
properties of the system obtained.


If the verification test fails, we must return to the
relevant stage of the development process and correct
the error.


Page
55

Component Library


Is the most central part of any CBSE system as it
contains binaries of components and their descriptions.


A component library containing real
-
time components
should provide the following:


Memory requirements


Worst cast execution time (WCET) test cases


Dependencies


Environment assumptions


Page
56

Composition of Components



Component 1

(
C
1
)


Component 2

(C
3
)


Component n

(C
2
)

in1_C
new

in2_C
new

in3_C
new

in4_C
new

in_C
1

in2_C
n

in1_C
2

in2_C
2

out_C
1

out_C
2

out1_C
n

out2_C
n

out1_C
new

out2_C
new

out3_C
new

New Component (C
new
)


Page
57

End
-
To
-
End Deadlines


End
-
to
-
end deadlines


Are set such that the system requirements are fulfilled in
the same way as the time budgets are set


Should be specified for the input to and output from the
component since the WCET cannot be computed since
its parts may be executing with different periods.


Page
58

Specification Of Timing Attributes


We specify virtual timing attributes of the composed
component, which are used to compute the timing
attributes of sub
-
components, ie:


IF virtual period is set to
P,


THEN the period of a sub
-
component A should be
f
A

*
P


AND the period of B is
f
B

* P,

WHERE
f
A

and
f
B

are constants for the composed
component, which are stored in the component library




Page
59

RT Components in Rubus OS


Rubus:


Is one of a few real
-
time operating systems currently
available which have some concept of components.


Is a hybrid operating system, in the sense that it
supports both pre
-
emptive static scheduling and fixed
priority scheduling.


Page
60

A Task and Its Interfaces


The timing requirements are specified by release
-
time,
deadline, WCET and period


Task:

BrakeLeftRight



Period:

50 ms


Release time:

10 ms

Deadline:

30 ms

Precedes:

outputBrakeValues

WCET:

2 ms


oil pressure

speed

….

brake left wheel

brake right wheel

Task state information


Page
61

A Composed System in the Red Model of Rubus


The task depicted below is required to execute before
the
outputBrakeValues

task, (i.E. Task
BrakeLeftRight

precedes task
outputBrakeValues
).




Component:

BrakeLeftRight


oil pressure

speed

brake left wheel

brake right wheel

State information

input 1

input 2


Component:
OutputBrakeValues


State information


Page
62

Composition of Components in Rubus

Task:
BrakeLeftRight
oil
pressure
speed
brake left
brake right
Task state information
Task:
OutputBrakeValues
Task state information
Component:
BrakeSystem
pressure
speed
An embedded
realtime

application using
Rubus

(CBSE) model in the design development


Page
63

Conclusion


The Rubus component model (CBSE) provides:


Methods to express the infrastructure of software
functions, i.e., the interaction between software
functions in terms of data
-
flow and control
-
flow


The resulting architecture is formal enough for
analysis of timing and memory properties


The components and the infrastructure allow for a
resource efficient mapping onto a run
-
time
structure

64