real time embedded systems n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Real-Time Embedded Systems PowerPoint Presentation
Download Presentation
Real-Time Embedded Systems

Loading in 2 Seconds...

play fullscreen
1 / 45

Real-Time Embedded Systems - PowerPoint PPT Presentation


  • 172 Views
  • Uploaded on

Real-Time Embedded Systems. Krithi Ramamritham. Outline. Special Characteristics of Real-Time Systems Scheduling Paradigms for Real-time systems Operating System Paradigms Real-Time Linux Real-Time NT. What is “real” about real-time?. computer world real world

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Real-Time Embedded Systems' - thane-snow


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
real time embedded systems
Real-Time Embedded Systems

Krithi Ramamritham

outline
Outline
  • Special Characteristics of Real-Time Systems
  • Scheduling Paradigms for Real-time systems
  • Operating System Paradigms
  • Real-Time Linux
  • Real-Time NT
what is real about real time
What is “real” about real-time?

computer worldreal world

e.g., PC industrial system, airplane

average response events occur in environment at

for user, interactive own speed

occasionally longerreaction too slow: deadline miss

reaction: reaction:

user annoyed damage, pot. loss of human life

computer controls speed computer has to follow real speed

of user of environment

“computer time” “real-time”

why real time why not simply fast
Why real-time, why not simply fast?

“Fast enough”: dependent on system and its environment and

  • turtle: fast enough to eat salad
  • mouse: fast to enough steal cheese
  • fly: fast enough to escape
slide5

what if environment is changed?“systems” not fast enough

  • mouse trap
  • fly-swatter

time scale depends on - or dictated by - environment

cannot slow down environment

…is the real world

average vs worst case
Average vs. Worst Case

“There was a man who drowned crossing a river with an average depth of 20cm.”

Standard computing is concerned with average behavior of systeme.g., if it responds fast enough on average, it is acceptableword processing, etc.

Real-time computing requires timely behavior in all given situationse.g., a single value delivered too late can cause the system to fail, even when the average timing is keptair planes, power plants, etc.

real time systems

I/O - data

event

time

Real-time

computing system

action

I/O - data

Real-Time Systems

A real-time system is a system that reacts to events in the environment by performing predefined actions

within specified time intervals.

real time systems properties of interest
Real-Time Systems: Properties of Interest
  • Safety: Nothing bad will happen.
  • Liveness: Something good will happen.
  • Timeliness: Things will happen on time -- by their deadlines, periodically, ....
in a real time system
In a Real-Time System….

correct value delivered too late is incorrect

e.g., traffic light: light must be green when crossing, not enough before

Real-time:

(Timely) reactions to events as they occur, at their pace:(real-time) system (internal) time same time scale as environment (external) time

Correctness of results depends on valueand its time of delivery

types of rt systems
Types of RT Systems

Dimensions along which real-time activities can be categorized:

  • how tight are the deadlines? --deadlines are tight when the laxity (deadline -- computation time) is small.
  • how strict are the deadlines? what is the value of executing an activity after its deadline?
  • what are the characteristics of the environment? how static or dynamic must the system be?

Designers want their real-time system to be fast, predictable, reliable, flexible.

hard soft firm

value

hard

soft

time

+

deadline (dl)

Hard, soft, firm
  • Hardresult useless or dangerousif deadline exceeded
  • Softresult of some - lower -value if deadline exceeded
  • Firm

If value drops to zero at deadline

-

Deadline intervals:result required not laterand not before

examples
Hard real time systems

Aircraft

Airport landing services

Nuclear Power Stations

Chemical Plants

Life support systems

Soft real time systems

Mutlimedia

Interactive video games

Examples
example of real time systems
Example of Real time systems

Temperature sensor

Input port

CPU

Memory

Output port

Heater

code for example
Code for example

While true do

{

read temperature sensor

if temperature too high

then turn off heater

else if temperature too low

then turn on heater

else nothing

}

comment on code
Comment on code
  • Code is by Polling device (temperature sensor)
  • Code is in form of infinite loop
  • No other tasks can be executed
  • Suitable for dedicated system or sub-system only
extended polling example
Extended polling example

Conceptual link

Temperature Sensor 1

Task 1

Heater 1

Temperature Sensor 2

Heater 2

Task 2

Computer

Temperature Sensor 3

Heater 3

Task 3

Temperature Sensor 4

Heater 4

Task 4

polling
Polling
  • Problems
    • Arranging task priorities
    • Round robin is usual
    • Urgent tasks are delayed
other methods
Other methods
  • Use interrupt driven system
  • Use general purpose operating system plus tasks
  • Use task handling language (e.g ADA)
  • Use special purpose operating system
interrupt driven systems
Interrupt driven systems
  • Advantages
    • Fast
    • Little delay for high priority tasks
  • Disadvantages
    • Programming
    • Code difficult to debug
    • Code difficult to maintain
how can we monitor a sensor every 100 ms
How can we monitor a sensor every 100 ms

Initiate a task T1 to handle the sensor

T1:

Loop

{Do sensor task T2

Schedule T2 for +100 ms

}

Note that the time could be relative (as here) or could be an actual time - there would be slight differences between the methods, due to the additional time to execute the code.

an alternative
An alternative…

Initiate a task to handle the sensor T1

T1:

Do sensor task T2

Repeat

{Schedule T2 for n * 100 ms

n:=n+1}

There are some subtleties here...

clock interrupts tasks
Clock, interrupts, tasks

Interrupts

Clock

Processor

Examines

Job/Task queue

Task 1

Task 2

Task 3

Task 4

Tasks schedule events using the clock...

real time items and terms
Real-Time: Items and Terms

Task

  • program, perform service, functionality
  • requires resources, e.g., execution time

Deadline

  • specified time for completion of, e.g., task
  • time interval or absolute point in time
  • value of result may depend on completion time
slide24

time

periodic

  • Periodic
    • activity occurs repeatedly
    • number of instances
    • e.g., to monitor environment values, temperature, etc.

period

slide25

time

  • Aperiodic
    • can occur any time
    • no arrival pattern given

aperiodic

aperiodic

slide26

time

  • Sporadic
    • can occur any time, but
    • minimum time between arrivals

mint

sporadic

who initiates triggers actions
Who initiates (triggers) actions?

Example: Chemical process

  • controlled so that temperature stays below danger level
  • warning system: distance level to danger point, so that cooling can still occur

Two possibilities:

  • action whenever temp raises above warn; event triggered
  • look every int time intervals; action when temp if measures above warntime triggered
slide28

t

time

TT

ET

slide29

t

time

TT

ET

et vs tt
ET vs TT
  • Time triggered
    • Stable number of invocations
  • Event triggered
    • Only invoked when needed
    • High number of invocation and computation demands if value changes frequently
slide31

Apollo 11, 1969, first lunar landing

Michael Collins (astronaut Apollo 11)

“At five minutes into the burn (6000 feet above the surface)

... "Program alarm", barks Neil, "Its a 1202", what the hell is that?I don't have the alarm numbers memorized for my own computer, much less for the LM's I jerk out my checklist and start thumbing through it, but before I can find 1202 Houston say, "Roger, we're GO on that alarm" no problem in other words. My checklist says 1202 is an "executive overflow" meaning simply that the computer has been called upon to do too many things at once and is forced to postpone some of them. A little farther, at just 3000 feet above the surface the computer flashes 1201, another overflow condition, and again the ground is superquick to respond with assurances.

Excerpt from Apollo, Expeditions to the Moon,

Scientific and Technical Information Office, NASA, Washington D.C., 1975

slide34

interrupt handler

radar

error 1201

slow down the environment
Slow down the environment?
  • Importance
    • which parts of the system are important?
    • importance can change over timee.g., fuel efficiency during emergency landing
  • Flow controlwho has control over speed of processing, who can slow partner down?
    • environment
    • computer system

RT: environment cannot be slowed down

performance metrics in real time systems
Performance Metrics in Real-Time Systems
  • Beyond minimizing response times and increasing the throughput:
    • achieve timeliness.
  • More precisely, how well can we predict that deadlines will be met?
what is predictability
What is Predictability

A simplified definition:

The ability to reliably determine whether an activity will meet its deadline.

A complete definition can be quite complex and -- subject to assumptions about failure, etc.

achieving predictability
Achieving Predictability
  • Layer by layer: Predictability requirement of an activity percolates down/up the layers.
  • Top-layer: Do your best to meet the deadline of an activity. If deadline cannot be met, handle the exception predictably.
layer by layer predictability
Layer-by-layer Predictability

Applications: Activities having deadlines.

Processes: Processes with deadlines.

one or more processes make up an activity.

Tasks: Tasks with deadlines

multiple (precedence-related) tasks make up a process.

Operating System: Bounded code execution time.

Bounded Operating System primitives.

Bounded synchronization costs.

Bounded scheduling costs.

Architecture: Bounded memory access times.

Bounded instruction execution times.

Bounded inter-node communication costs.

top layer predictability
Top-layer Predictability

An activity has

  • a component executed in the usual case with deadline (d -- r) executed using best-effort approaches
  • a component executed in the exception case -- typically simple execution (if needed) is guaranteed.
issues to worry about
Issues to worry about
  • Meet requirements -- some activities may run only:
    • after others have completed - precedence constraints
    • while others are not running - mutual exclusion
    • within certain times - temporal constraints
  • Scheduling
    • planning of activities, such that required timing is kept
    • models
    • methods
issue running time of programs
Issue: Running time of programs
  • Depends on hardware, memory wait cycles, clock etc.
  • Depends on virtual memory and caching
  • Depends on data
  • Depends on program control
  • Depends on pipelining
  • Depends on memory management
more issues
More Issues…
  • Operating Systems
    • Off-the shelf (COTS)
    • Application-specific
  • Dataflow
    • data are read from environment - sensors
    • data are processed by tasks
    • results are processed by other tasks…
    • data are transferred to environment

– actuators

further issues
Further Issues
  • Programming languages
    • Maximum execution times
    • Difficult with recursions, unbounded loops, etc
  • Networks
    • Bounded transmission times
    • e.g., ethernet, CSMA/CD large number of collisions
  • Synchronization of clocks
    • Clock drift apart
    • Faulty clocks can cause wrong synchronization, e.g., for average
even more issues
Even more issues…
  • Fault tolerance
    • Deadlines cannot be kept if computer or network has hardware errors
    • Tolerate certain faults within timing
  • Real-Time Databases
    • maintain data consistent and fresh
  • Design
    • derive and specify timing