Real-Time Embedded Systems

Slides:



Advertisements
Similar presentations
© Alan Burns and Andy Wellings, 2001 Real-Time Systems and Programming Languages n Buy Real-Time Systems: Ada 95, Real-Time Java and Real-Time POSIX by.
Advertisements

EE5900 Advanced Embedded System For Smart Infrastructure
Categories of I/O Devices
Real-Time Embedded Systems
Tasks Periodic The period is the amount of time between each iteration of a regularly repeated task Time driven The task is automatically activated by.
Model for Supporting High Integrity and Fault Tolerance Brian Dobbing, Aonix Europe Ltd Chief Technical Consultant.
Basic Real Time Concepts Systems Concepts Real-Time Definitions Events and Determinism CPU Utilization Real-Time System Design Issues Example Real-Time.
Chapter 13 Embedded Systems
1: Operating Systems Overview
Embedded and Real Time Systems Lecture #2 David Andrews
Embedded and Real Time Systems Lecture #4 David Andrews
Chapter 13 Embedded Systems
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Real-Time Systems and Programming Languages
By Group: Ghassan Abdo Rayyashi Anas to’meh Supervised by Dr. Lo’ai Tawalbeh.
CprE 458/558: Real-Time Systems
Real-Time Operating System Chapter – 8 Embedded System: An integrated approach.
1 Chapter 13 Embedded Systems Embedded Systems Characteristics of Embedded Operating Systems.
EMBEDDED SOFTWARE Team victorious Team Victorious.
Chapter 1 Embedded And Real-Time System Department of Computer Science Hsu Hao Chen Professor Hsung-Pin Chang.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15 Slide 1 Real-time Systems 1.
Distributed Real-Time systems 1 By: Mahdi Sadeghizadeh Website: Sadeghizadeh.ir Advanced Computer Networks.
Real-Time Software Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
Instructore: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Concurrent and.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Real Time Process Control (Introduction)
1. Introduction 1.1 Background 1.2 Real-time applications 1.3 Misconceptions 1.4 Issues in real-time computing 1.5 Structure of a real-time system.
1 소프트웨어공학 강좌 Chap 11. Real-time software Design - Designing embedded software systems whose behaviour is subject to time constraints -
CS4730 Real-Time Systems and Modeling Fall 2010 José M. Garrido Department of Computer Science & Information Systems Kennesaw State University.
© Oxford University Press 2011 DISTRIBUTED COMPUTING Sunita Mahajan Sunita Mahajan, Principal, Institute of Computer Science, MET League of Colleges, Mumbai.
EEL Software development for real-time engineering systems.
Scheduling policies for real- time embedded systems.
Multiprocessor and Real-Time Scheduling Chapter 10.
Chapter 101 Multiprocessor and Real- Time Scheduling Chapter 10.
Reference: Ian Sommerville, Chap 15  Systems which monitor and control their environment.  Sometimes associated with hardware devices ◦ Sensors: Collect.
Real Time Scheduling Telvis Calhoun CSc Outline Introduction Real-Time Scheduling Overview Tasks, Jobs and Schedules Rate/Deadline Monotonic Deferrable.
Slide 1 Chapter 11 Real –time Software Designs. Slide 2 Real-time systems l Systems which monitor and control their environment l Inevitably associated.
© Krithi Ramamritham / Kavi Arya 1 IT-606 Embedded Systems (Software) Krithi Ramamritham Kavi Arya IIT Bombay Real-Time Support.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
CprE 458/558: Real-Time Systems (G. Manimaran)1 CprE 458/558: Real-Time Systems Introduction to Real-Time Systems.
Accessing I/O Devices Processor Memory BUS I/O Device 1 I/O Device 2.
Presentation on Real Time Systems and Adaptive Cruise Control.
©Ian Sommerville, Robin Abraham 2004CS 361, Summer 2004 Slide 1 Real-time Software Design.
Real-time Software Design King Saud University College of Computer and Information Sciences Department of Computer Science Dr. S. HAMMAMI.
CS4730 Real-Time Systems and Modeling Fall 2010 José M. Garrido Department of Computer Science & Information Systems Kennesaw State University.
Special Class on Real-Time Systems
Real-Time Systems, Events, Triggers. Real-Time Systems A system that has operational deadlines from event to system response A system whose correctness.
Lecture 12 Page 1 CS 111 Online Using Devices and Their Drivers Practical use issues Achieving good performance in driver use.
For a good summary, visit:
Misconceptions About Real- Time Databases IEEE Computer Authors: John Stankovic, Sang Hyuk Son, Jorgen Hansson Presented By: Patti Kraker.
1 G53SRP: Introduction to Real Time Scheduling Chris Greenhalgh School of Computer Science.
Unit - I Real Time Operating System. Content : Operating System Concepts Real-Time Tasks Real-Time Systems Types of Real-Time Tasks Real-Time Operating.
Embedded Real-Time Systems Processing interrupts Lecturer Department University.
Embedded System Design and Development Introduction to Embedded System.
Real-time Embedded Systems Module overview Introduction to Real-time Systems and Scheduling.
CONCEPTS OF REAL-TIME OPERATING SYSTEM. OBJECTIVE  To Understand Why we need OS?  To identify Types of OS  To Define Real - Time Systems  To Classify.
Real-Time Operating Systems RTOS For Embedded systems.
Real-time Software Design
Real-time Software Design
Real-time Software Design
REAL-TIME OPERATING SYSTEMS
Non-Preemptive Scheduling
Introduction Frank Drews
Wayne Wolf Dept. of EE Princeton University
Unit OS9: Real-Time and Embedded Systems
Lecture 4 Schedulability and Tasks
Real-time Software Design
GEOMATIKA UNIVERSITY COLLEGE CHAPTER 2 OPERATING SYSTEM PRINCIPLES
Multiprocessor and Real-Time Scheduling
Chapter 10 Multiprocessor and Real-Time Scheduling
Presentation transcript:

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 e.g., PC industrial system, airplane average response events occur in environment at for user, interactive own speed occasionally longer reaction 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? “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

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 “There was a man who drowned crossing a river with an average depth of 20cm.” Standard computing is concerned with average behavior of system e.g., if it responds fast enough on average, it is acceptable word processing, etc. Real-time computing requires timely behavior in all given situations e.g., a single value delivered too late can cause the system to fail, even when the average timing is kept air planes, power plants, etc.

Real-Time Systems event action I/O - data time Real-time computing system 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 Safety: Nothing bad will happen. Liveness: Something good will happen. Timeliness: Things will happen on time -- by their deadlines, periodically, ....

Correctness of results depends on value and its time of delivery In a Real-Time System…. Correctness of results depends on value and its time of delivery 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

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 Hard result useless or dangerous if deadline exceeded value time deadline (dl) + soft Soft result of some - lower - value if deadline exceeded Firm If value drops to zero at deadline hard Deadline intervals: result required not later and 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

Example of Real time systems Temperature sensor Input port CPU Memory Output port Heater

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 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 Temperature Sensor 1 Conceptual link Heater 1 Task 1 Temperature Sensor 2 Heater 2 Task 2 Computer Temperature Sensor 3 Heater 3 Task 3 Temperature Sensor 4 Heater 4 Task 4

Polling Problems Arranging task priorities Round robin is usual Urgent tasks are delayed

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 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 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… 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 Processor Examines Job/Task queue Task 1 Task 2 Task 3 Task 4 Tasks schedule events using the clock...

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

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

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

minimum time between arrivals Sporadic can occur any time, but minimum time between arrivals mint time sporadic

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 warn time triggered

t time TT ET

t time TT ET

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

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

interrupt handler radar

interrupt handler radar

interrupt handler radar error 1201

Slow down the environment? Importance which parts of the system are important? importance can change over time e.g., fuel efficiency during emergency landing Flow control who 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 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 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 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 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 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 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 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… 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 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… 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