frank drewsreal-time systems introduction frank drews [email protected]

30
Real-Time Systems Introduction Frank Drews [email protected]

Upload: franklin-lyness

Post on 29-Mar-2015

221 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Real-Time Systems

Introduction

Frank Drews

[email protected]

Page 2: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Real-time Systems

• A real-time system is a system whose specification includes both logical and temporal correctness requirements.

• Logical Correctness: Produces correct outputs.– Can by checked, for example, by Hoare logic.

• Temporal Correctness: Produces outputs at the right time.– In this course, we spend much time on techniques

and technologies for achieving and checking temporal correctness.

Page 3: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Embedded Systems

• [www.webopedia.com]: An embedded system is “a specialized computer system that is part of a larger system or machine. Typically, an embedded system is housed on a single microprocessor board with the programs stored in ROM. Virtually all appliances that have digital interfaces (e.g., watches, microwaves, VCRs, cars) utilize embedded systems […]”

• Many embedded systems are real-time systems

Page 4: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Typical Characteristics of Real-Time Systems

• Event-driven, reactive.

• High cost of failure.

• Concurrency/multiprogramming.

• Stand-alone/continuous operation.

• Reliability/fault-tolerance requirements.

• Predictable behavior.

Page 5: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Misconceptions about Real-Time Systems (Stankovic ‘88)

• There is no science in real-time-system design.– We shall see…

• Advances in supercomputing hardware will take care of real-time requirements.– The old “buy a faster processor” argument…

• Real-time computing is equivalent to fast computing.– Only to ad agencies. To us, it means PREDICTABLE

computing.

Page 6: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Misconceptions (Continued)

• Real-time programming is assembly coding, – We would like to automate (as much as possible) real-time

system design, instead of relying on clever hand-crafted code.

• “Real time” is performance engineering. – In real-time computing, timeliness is almost always more

important than raw performance …

• “Real-time problems” have all been solved in other areas of CS or operations research. – OR people typically use stochastic queuing models or one-shot

scheduling models to reason about systems.– In other CS areas, people are usually interested in optimizing

average-case performance.

Page 7: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Misconceptions (Continued)

• It is not meaningful to talk about guaranteeing real-time performance when things can fail.– Though things may fail, we certainly don’t

want the operating system to be the weakest link!

• Real-time systems function only in a static environment.– Note true. We consider systems in which the

environment may change dynamically.

Page 8: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Are All Systems Real-Time Systems?

• Question: Is a payroll processing system a realtime 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

Page 9: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

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.

Page 10: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Example: Interactive/Multimedia Applications

Page 11: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Example: Real-Time Applications

Many real-time systems are control systems

Example 1: A simple one-sensor, one-actuator control system

Page 12: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Simple Control System (Continued)

Pseudo-code for this system:

T is called sampling period. T is a key design choice. Typical range for T: seconds to milliseconds.

Page 13: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Time

Page 14: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Multi-rate Control SystemsMore complicated control systems have multiple sensors

and actuators and must support control loops of different rates.

Example 2: Helicopter flight controller.

Note: Having only harmonic rates simplifies the system

Page 15: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Hierarchical Control Systems

Page 16: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Air Traffic Control

[Reddaway et al. WMPP’05]

Page 17: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Signal-Processing System

• Signal-processing systems transform data from one form to another.

• Examples:– Digital filtering.– Video and voice compression/decompression.– Radar signal processing.

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

Page 18: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Example: Radar System

Page 19: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Internet/Multimedia Applications• Web farms hosting multiple web

domains– Each web domain receives a certain

share of the overall resources (CPU, network, file system)

– Each web domain consists of an application pool (static content, dynamic content, streaming video/audio, etc.)

• Challenges– Sharing the resource among domains

(i.e. application pools) may be hard in general purpose Operating Systems

– Guarantee of a uniform, steady, jitter-free execution of time critical multimedia applications while not starving other applications

– Support of multiprocessor server systems

Server

Domain 1

Domain 2

Domain 3

static content

dynamic content

streaming video/audio

Page 20: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Other Real-Time Applications

• Real-time databases.– Transactions must complete by deadlines.– Main dilemma: Transaction scheduling algorithms and real-time

scheduling algorithms often have conflicting goals.– Data may be subject to absolute and relative temporal

consistency requirements.– Overall goal: reliable responses

• 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).

Page 21: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Hard vs. Soft Real Time

• Task: A sequential piece of code.• Job: Instance of a task• Jobs require resources to execute.

– Example resources: CPU, network, disk, critical section.– We will simply call all hardware resources “processors”.

• Release time of a job: The time instant the job becomes ready to execute.

• Deadline of a job: The time instant by which the job must complete execution.

• Relative deadline of a job: “Deadline - Release time”.• Response time of a job: “Completion time - Release

time”.

Page 22: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Example

Job is released at time 3.

It’s absolute deadline is at time 10.

It’s relative deadline is 7.

It’s response time is 6.

Page 23: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Hard Real-Time Systems

• A hard deadline must be met.– If any hard deadline is ever missed, then the system

is incorrect.– Requires a means for validating that deadlines are

met.

• Hard real-time system: A real-time system in• which all deadlines are hard.

– We consider hard and soft real-time systems in this course.

• Examples: Nuclear power plant control, flight control.

Page 24: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Soft Real-Time Systems

• A soft deadline may occasionally be missed.– Question: How to define “occasionally”?

• Soft real-time system: A real-time system in which some deadlines are soft.

• Examples: multimedia applications.

Page 25: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Performance

• Two particular factors are important– How fast does a system respond– When it fails, what happens?

Page 26: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

The Speed of Response

• All required responses are time-critical– The designer should predict the delivered

performance of the systems with the required performance

– Unfortunately, it may not be possible to give 100% guarantees

Page 27: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Periodic vs. Aperiodic Tasks

• Periodic Tasks– Tasks run at regular, pre-defined intervals– Example: closed loop digital controller having

fixed, pre-set sampling rates

t0 t1 t2

time

Executecontrol task

Executecontrol task

Idle time Idle time

Sampling interval

Synchronous real-time clock signals

Page 28: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Periodic vs. Aperiodic Tasks

• Aperiodic Tasks– Occur when the computer must respond to (generally) external events which

occur at random (asynchronous or aperiodic); have either soft or no deadlines

• Sporadic Tasks– Similar to aperiodic tasks; however, the event must be serviced within a specific

maximum time period; hard deadline

e0

time

Executeevent task

Executeevent task

Idle time

Idle time

Asynchronous events

e1 e2

Executeevent task

Page 29: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Mixing Periodic and Aperiodic Tasks

• We get into trouble in situations which involve a mix of periodic and aperiodic(sporadic) events, which are usual in real-time designs

• Much thought and skill are needed to deal with the response requirements of periodic and aperiodic tasks

Page 30: Frank DrewsReal-Time Systems Introduction Frank Drews drews@ohio.edu

Real-Time Operating Systems (RTOSs)

• RTOS: specialized operating system for RTS• Main responsibilities:

– Process management– Resource allocation (processor, memory, network)

• They may not include regular OS facilities such as file management, virtual memory, user/kernel level separation, etc.

• Manage at least two priority levels:– Interrupt level, for processes that need fast response– Clock level, for periodic processes

• Typical components: real-time clock, interrupt handler, scheduler, resource manager, dispatcher