Binghamton University EngiNet™ State University of New York.

Binghamton University

EngiNet™

State University of New York

Thomas J. Watson

School of Engineeringand Applied Science

WARNING

All rights reserved. No part of the course materials used in the instruction of this course may be reproduced in any form or by anyelectronic or mechanical means, including the useof information storage and retrieval systems,without written approval from the copyright owner.

©2009 Binghamton UniversityState University of New York

CS 554

Introduction to Real-Time Embedded Systems

Professor Kyoung-Don Kang

Lecture 1January 29, 2009

Misconceptions About Real-time Computing : A Serious Problem for Next-generation Systems

J. A. Stankovic, Misconceptions about Real-Time Computing: A Serious Problem for Next Generation Systems, IEEE Computer, 21(10), pp. 10-19, October 1988.

23年 4月 19日 Real-time computing 7

Real-Time Computing The correctness of the system

Logical result of the computation Functional correctness

Time to produce the result Next generation RT system

Distributed/adaptive Online guarantees Long lifetime


There is no science in RT system design Most good science grew out of attempts to

solve practical problems Real-time system engineers need help

The first flight of a space shuttle was delayed due to a subtle timing bug due to a transient overload during system initialization

A scientific framework to prevent such a bug to be included is needed

Real-time scheduling, resource management, RT programming language, …


Advances in supercomputer hardware will cover RT requirements

One can exploit parallel processors to improve throughput It does not mean timing constraints can be met

automatically Unless HW is designed to perfectly match the

application, the processors and their communication subsystems may not be able to handle all of the task load and time-critical traffic Real-time task and communication scheduling can get

harder as more hardware is used


Demand for computational power often exceeds supply

Intelligent management of finite resources is required


RT Computing = Fast Computing RT computing

The objective of fast computing is to minimize the average response time

The objective of real-time computing is to meet the individual timing requirement of each task Meet individual task deadlines

Fast computing cannot necessarily provide predictability Fastest hardware & software used in the space shuttle

failed to support the timing requirements Testing is not the answer


Fast is relative Worst case, not average case, response time matters Not speed but predictability is the goal Functional and timing behaviors should be as deterministic

as necessary to satisfy system specification Guarantee the delay is shorter than the upper bound Predictability is not only hardware or algorithmic issue

The delay statement in Ada only specifies the minimum delay before the next task is scheduled

Many things, including scheduling theory, software design, formal methods, RTOS, can change things


RT Programming =Assembly Coding, Priority Interrupt

Programming, Device Driver Writing

Hand-coding may have bugs, especially large RT program

Objective in RT research Automate Customized resource scheduler from timing-

constraint spec.


RT System Research = Performance Engineering

To investigate effective resource allocation strategies to satisfy timing-behavior requirement (≈Perf. Engineering)

Specification & verification of timing behavior Programming language semantics Theoretical problems

Common misconceptions(5)


Real-time systems function in static environment Not necessarily true Once deployed, real-time systems stay for

more than 10 years Many embedded real-time systems these

days need configurable, composable RTOS


Main Research Issues Specification and verification

Modeling and verification of systems that are subject to timing constraints

RT scheduling theory Meet the specified timing requirements Support the utilization bound to meet all

deadlines Meet as many deadlines as possible, if it is

impossible to meet all deadlines


Main Research Issues

RTOS Guarantee RT constraint Support FT and distribution Scheduling time-constrained resource allocation

RT programming language and design methodology High level abstraction to deal with complex real-time

systems Management of time Schedulability check Reusable RT software module


Main Research Issues

(Distributed) RTDB Concurrency in transaction processing RT scheduling algorithm

Fault tolerance Formal specification of the timing constraints Error handling

RT system architecture Interconnection topology (process, I/O) Fast, reliable, and time-constrained communication Cost-effective and integrated fashion WCET analysis


Main Research Issues RT communication

End-to-end deadlines Packet scheduling Dynamic routing Network buffer management

Wireless Sensor Networks Newly emerging area Small, inexpensive, wireless sensors for RT

sensing & control


Rate Monotonic, EDF (Earliest Deadline First), and Deadline Monotonic Scheduling Algorithms C. Liu and J. Layland,

Scheduling Algorithm for Multiprogramming in a Hard Real-time Environment, Journal of the ACM, 20(1), pp. 41-61, January 1973.

N.C. Audsley, A. Burns, M.F. Richardson, and A. J. Wellings, Hard real-time scheduling: The deadline monotonic approach, IEEE Workshop on Real-Time Operating Systems, 1992.

N.C. Audsley, A. Burns, M.F. Richardson, and A. J. Wellings, Applying new scheduling theory to static priority preemptive scheduling, Software Engineering Journal, 8(5):284-292, Sept 1993.


Terminologies

Job Each unit of work that is scheduled and executed by the system

Task A set of related jobs For example, a periodic task Ti consists of jobs J1, J2, J3, …

coming at every period Release time

Time instant at which a job becomes available for execution It can be executed at any time at or after the release time

Deadline Time instant by which a job should be finished Relative deadline: Maximum allowable response time Absolute deadline = release time + relative deadline


Periodic task Ti

Period Pi

Worst case execution time Ci

Relative deadline Di

Job Jik

Absolute deadline = release time + relative deadline Response time = finish time – release time

Deadline miss if Finish time > absolute deadline Response time of Jik > Di


Optimal Scheduling Algorithm A scheduling algorithm S is optimal if S

cannot schedule a real-time task set T, no other scheduling algorithm can schedule T

E.g., Rate Monotonic & EDF


Assumptions

Single processor Every task is periodic Deadline = period Tasks are independent WCET of each task is known Zero context switch time


Fixed Priority vs. Dynamic Priority Scheduling Algorithms Fixed priority system

Assign the same priority to all the jobs in each task

Rate monotonic Dynamic priority system

Assign different priorities to the individual jobs in each task

EDF


Rate Monotonic

Optimal fixed priority scheduling algorithm Shorter period → Higher priority

Higher rate → higher priority Utilization bound


RM Example

1

2

3

time

Task Execution Time (C) End Of Period (T = Period Length)


Utilization Bound (UB) Test

Processor Utilization for a task, i Ui = Ci

Ti

Utilization Bound for n tasks U(n) = n(2 - 1)1n

Results:

• If U (= Ui) ≤ U(n) then the set of tasks is schedulable.

• If U(n) < Ui ≤ 1 then the test is inconclusive.

• U < U(n) is sufficient but not necessary


Utilization Bound Test

TaskExecution Time

(C)Period (T)

1 40 100

2 40 150

3 100 350

U(3) = 3(21/3 – 1) = 0.779U1 = 40 / 100 = 0.4

U2 = 40 / 150 = 0.267

U3 = 100 / 350 = 0.286

Utotal = 0.953

Result:

U1+2 = 0.667, schedulable.

However, 0.779 < 0.953 < 1

Therefore, inconclusive for 3.


EDF

Shorter absolute deadline → Higher priority Utilization bound Ub = 1

Ub is necessary and sufficient


Comparisons

RMS RMS may not guarantee schedulability even when U < 1 Low overhead: Priorities do not change for a fixed task set

EDF EDF guarantee schedulability as long as U <= 1 High overhead: Task priorities may change dynamically

For more comparisons, refer to “Rate Monotonic vs. EDF: Judgment Day”


Assumptions

Single processor Every task is periodic Relative deadline = period Tasks are independent WCET of each task is known Zero context switch time

What happens if relative deadline < period?


Deadline Monotonic Scheduling Algorithm Shorter relative deadline → higher priority RMS is a special case of DMS where Di = Pi

Necessary and sufficient schedulability analysis, called response time analysis, exists


Optimal Scheduling AlgorithmsRelative Deadline < Period DMS

Shorter relative deadline → Higher priority Optimal preemptive fixed priority scheduling

EDF Shorter absolute deadline → Higher priority Optimal preemptive dynamic priority scheduling


DMS Response Time AnalysisAudsley et al. Tasks are sorted in non-increasing order of priority. (Ti has the

highest priority)

for (each task Ti) {

I = 0; R=0;while (I + Cj > R) {

R = I + Ci;

if (R > Di) return Unschedulable;

I = ∑k=1, i-1 R/Pi Ci;

}

}

return Schedulable


Summary

Di = Pi D < P

Fixed Priority

RMS

Utilization bound

Response time analysis

DMS

Response time analysis

Dynamic Priority

EDF

Utilization bound

EDF

Processor demand analysis

Note: EDF is optimal for aperiodic tasks too

Project Ideas

Choice 1: This option actually has two choices. Note that you can start working on this as soon as you learn EDF, RM, and priority inheritance/abort concepts, all of which will be covered within two weeks at most. (1) Develop a discrete even real-time simulator and

implement two out of three programming assignments using the discrete event simulator.

(2) Alternatively, write a well organized object-oriented simulator that allows users to choose all possible combinations of the real-time scheduling options provided by the three programming assignments.


Project Ideas

Choice 2: Develop a video streaming application using Javolution, evaluate performance (i.e., packet losses and delay), and write a report that describes how RTJS and Javolution help writing a real-time application.


Project Ideas

Choice 3: Extend the vehicle merge algorithm developed in Prof. Krithi Ramamritham’s class at IIT. A more detailed description and source code you can extend are available at http://www.cse.iitb.ac.in/~cs684/?id=205 .


Project Ideas

Choice 4: Extend our Chronos real-time database, for example, to provide more sophisticated/scalable schema/design or data mining/machine learning capability.

Choice 5: Feel free to suggest your own ideas!


Date post:	27-Dec-2015
Category:	Documents
Upload:	deborah-alicia-paul
View:	221 times
Download:	1 times

Binghamton University EngiNet™ State University of New York.

Documents