Rate

Monotonic

Analysis

for

Real-Time

Industrial

Computing

Mark

H.

Kleiny

John

P.

Lehoczkyz

and

Ragunathan

Rajkumary

ySoftware

Engineering

Institute

zDepartment

of

Statistics

Carnegie

Mellon

University

Pittsburgh

PA

Abstract

Real-time

industrial

computing

systems

can

be

characterized

as

systems

that

are

often

distributed

and

have

distinctively

stringent

timing

reliability

and

safety

requirements

imposed

by

the

application

environment

Issues

of

real-time

resource

management

arise

throughout

the

domain

of

industrial

computing

This

paper

shows

how

to

use

rate

monotonic

analysis

to

manage

the

real-time

requirements

of

such

sytems

illustrating

with

a

comprehensive

example

drawn

from

a

typical

real-time

industrial

computing

application

Introduction

Industrial

computing

capabilities

directly

affect

a

nation

's

technological

development

and

economic

competitiveness

Industrial

processes

are

becoming

increasingly

complex

in

the

sense

that

tight

control

must

be

maintained

and

process

monitoring

must

be

carried

out

to

ensure

that

the

resulting

products

will

meet

quality

specifications

The

trend

toward

distributed

flexible

manufacturing

in

which

facilities

can

be

quickly

reconfigured

to

meet

changing

production

requirements

coupled

with

the

need

for

tight

process

control

and

monitoring

puts

great

demands

on

the

computing

technology

used

to

support

this

environment

These

systems

often

require

a

high

degree

of

dependable

nonstop

operation

and

safety

assurance

Moreover

production

control

and

monitoring

requirements

in

an

industrial

computing

application

often

create

very

stringent

demands

for

real-time

processing

Issues

of

real-time

resource

management

are

pervasive

throughout

the

domain

of

industrial

computing

Unlike

general

purpose

computer

systems

where

resources

must

be

managed

to

provide

adequate

system

responsiveness

for

all

tasks

on

the

average

the

underlying

physical

processes

being

controlled

by

many

industrial

computing

applications

impose

explicit

timing

requirements

on

the

tasks

processed

by

the

computer

system

These

timing

requirements

are

an

integral

part

of

the

correctness

and

safety

conditions

of

a

real-time

system

-LRB-

See

Characterizing

Real-Time

Industrial

Computing

sidebar

-RRB-

research

is

supported

in

part

by

the

Office

of

Naval

Research

under

contract

and

by

the

Federal

Systems

Company

of

IBM

under

University

Agreement

The

Software

Engineering

Institute

is

sponsored

by

the

Department

of

Defense

Parts

of

this

article

are

drawn

from

-LSB-

-RSB-

It

is

tempting

to

think

that

speed

-LRB-

e.g.

processor

speeds

or

higher

communication

bandwidths

-RRB-

would

be

the

sole

ingredient

to

meeting

system

timing

requirements

however

speed

alone

is

not

enough

Proper

resource

management

techniques

must

also

be

used

for

example

to

prevent

situations

in

which

long

low

priority

tasks

block

higher

priority

tasks

with

short

deadlines

A

guiding

principle

in

real-time

system

resource

management

is

predictability

the

ability

to

determine

for

a

given

set

of

tasks

whether

the

system

will

be

able

to

meet

all

of

the

timing

requirements

of

those

tasks

Predictability

calls

for

the

development

of

scheduling

models

and

analytic

techniques

which

can

be

used

to

determine

a

priori

whether

or

not

a

real-time

system

can

meet

its

timing

requirements

The

primary

goal

of

this

paper

is

to

illustrate

an

analysis

methodology

that

is

suitable

for

managing

real-time

requirements

in

a

distributed

industrial

computing

situation

The

illustration

is

based

on

a

comprehensive

example

drawn

from

a

typical

industrial

application

This

paper

is

organized

as

follows

First

we

introduce

different

categories

of

real-time

tasks

and

discuss

different

ways

of

scheduling

them

With

the

basic

foundation

and

notation

having

been

described

we

then

introduce

a

comprehensive

robotics

example

This

is

followed

by

a

section

in

which

we

introduce

scheduling

methods

and

use

them

to

analyze

each

part

of

the

example

The

separate

analyses

are

combined

to

give

an

overall

analysis

We

then

discuss

extensions

to

the

methods

that

have

been

developed

and

summarize

our

conclusions

Start

Sidebar

Characterizing

Real-Time

Industrial

Computing

Real-time

industrial

computing

systems

can

be

characterized

as

systems

that

are

often

distributed

and

have

distinctively

stringent

timing

reliability

and

safety

requirements

imposed

by

the

application

environment

Also

industrial

computing

systems

such

as

tele-communication

networks

and

power

generation

networks

have

very

high

availability

requirements

which

require

that

software

and

hardware

upgrades

be

done

on-line

Examples

of

application

areas

in

which

industrial

computing

problems

arise

include

ffl

agile

manufacturing

facilities

that

are

able

to

quickly

reconfigure

plant

operations

to

meet

changing

requirements

and

to

permit

on-line

maintenance

and

upgrade

ffl

radars

and

other

sensors

for

monitoring

the

development

of

weather

patterns

seismic

data

the

status

of

power

distribution

grids

and

the

distribution

of

pollutants

ffl

satellites

fiber-optic

networks

and

high-speed

switches

to

transmit

large

volumes

of

live

audio

video

graphics

animation

and

text

data

ffl

vehicular

traffic

control

and

air

traffic

control

ffl

patient

monitoring

heart-lung

machines

CAT

scanners

MRI

and

other

medical

information

systems

The

development

of

advanced

industrial

computing

applications

will

require

that

computing

and

communications

technologies

be

integrated

with

real-time

scheduling

and

fault-tolerance

technologies

to

meet

the

stringent

timing

and

reliability

requirements

of

such

systems

Consider

for

example

vessel

traffic

systems

used

for

harbor

traffic

management

The

TRACS

Esprit

III

project

is

investigating

requirements

and

system

architectural

considerations

for

advanced

vessel

traffic

systems

Such

systems

have

the

need

of

implementing

hard

real-time

features

in

order

to

control

dangerous

situations

that

can

arise

and

that

may

imply

damage

or

loss

of

goods

and

injury

to

people

if

not

appropriately

handled

-LSB-

-RSB-

The

analysis

of

system

specifications

for

this

type

of

system

showed

the

need

for

handling

ffl

periodic

tasks

for

data

acquisition

and

control

ffl

stringent

timing

constraints

for

critical

activities

and

ffl

different

task

types

such

as

those

with

hard

and

soft

timing

requirements

These

types

of

requirements

are

typical

of

timing

requirements

for

industrial

computing

applications

Consider

another

example

involving

patient

monitoring

in

an

intensive

care

unit

of

a

hospital

A

clinician

monitoring

a

patient

's

status

requires

the

support

of

intelligent

monitoring

which

can

integrate

data

from

multiple

sources

in

real-time

We

quote

the

following

from

-LSB-

-RSB-

To

build

a

software

system

that

supports

such

a

monitor

we

must

achieve

predictable

real-time

performance

accomodate

heterogeneous

approaches

to

the

many

separable

sub-problems

and

design

a

useful

interface

The

need

for

real-time

performance

is

obvious

A

monitor

that

does

not

run

in

real

time

can

not

give

early

warning

of

lifethreatening

situations

Thus

predictability

in

the

context

of

hard

real-time

constraints

is

of

central

concern

for

this

application

The

robotics

example

discussed

in

this

paper

has

similar

timing

requirements

in

a

distributed

setting

Typical

industrial

computing

applications

such

as

robotics

systems

manufacturing

and

process

control

systems

vessel

traffic

systems

-LSB-

-RSB-

and

patient

monitoring

systems

-LSB-

-RSB-

can

comprise

a

collection

of

heterogeneous

resources

such

CPU

's

backplane

buses

networks

and

I/O

devices

that

must

be

scheduled

in

a

manner

that

is

predictable

flexible

and

amenable

to

mathematical

analysis

This

paper

uses

a

distributed

real-time

robotics

problem

to

show

how

rate

monotonic

analysis

can

be

used

to

guide

the

analysis

of

industrial

computing

applications

Ancilotti

P.

Buttazzo

G.

Di

Natale

M.

and

Spuri

M.

TRACS

A

Flexible

Real-Time

Environment

for

Traffic

Control

Systems

Proceedings

of

the

IEEE

Workshop

on

Real-Time

Applications

May

Factor

M.

Gelernter

D.

H.

Kolb

C.

E.

Miller

P.

L.

and

Sittig

D.

F.

Real-Time

Data

Fusion

in

the

Intensive

Care

Unit

IEEE

Computer

November

End

Sidebar

Classification

of

Tasks

and

Scheduling

Strategies

Classification

of

Tasks

There

are

three

types

of

tasks

that

are

commonly

encountered

in

real-time

systems

designed

for

monitoring

and

control

functions

The

most

common

type

is

a

periodic

task

If

a

computer

system

must

monitor

a

physical

system

or

process

then

it

must

sample

it

and

react

to

the

data

gathered

This

regular

sampling

gives

rise

to

the

periodic

task

A

periodic

task

refers

to

a

single

task

with

a

continuous

series

of

regular

invocations

-LRB-

jobs

-RRB-

beginning

with

an

initial

invocation

at

some

relative

initiation

time

I.

Subsequent

invocations

occur

periodically

every

T

time

units

Each

of

these

invocations

has

a

computation

requirement

of

C

units

which

may

be

deterministic

or

stochastic

If

the

computation

time

is

stochastic

then

C

often

denotes

the

upper

bound

-LRB-

or

worst

case

-RRB-

computation

time

Each

task

invocation

will

have

an

explicit

timing

requirement

The

most

common

requirement

is

that

a

task

invocation

must

be

completed

within

D

time

units

after

it

is

ready

a

timing

requirement

which

is

often

referred

to

as

a

hard

deadline

Thus

the

first

invocation

must

be

completed

by

time

I+D

the

second

by

I+T+D

etc.

Periodic

tasks

are

usually

invoked

by

internal

timers

with

the

periodicity

chosen

to

ensure

that

the

latency

is

short

enough

to

react

to

events

or

changes

in

the

underlying

physical

process

being

monitored

The

other

two

types

of

tasks

are

sporadic

tasks

and

aperiodic

tasks

While

periodic

tasks

refer

to

a

continuous

series

of

jobs

invoked

at

regular

intervals

both

sporadic

and

aperiodic

tasks

refer

to

a

continuous

series

of

jobs

invoked

at

irregular

intervals

Sporadic

tasks

have

hard

deadlines

and

a

bound

on

how

small

the

interarrival

interval

between

two

successive

jobs

can

be

On

the

other

hand

aperiodic

jobs

can

arrive

with

arbitrarily

small

interarrival

intervals

and

the

arrival

patterns

may

be

described

by

probability

density

functions

Timing

requirements

for

aperiodic

tasks

are

usually

stated

in

terms

of

satisfying

an

average

response

time

requirement

For

a

detailed

description

of

these

task

types

see

-LSB-

-RSB-

Classification

of

Scheduling

Strategies

Some

real-time

systems

are

sufficiently

simple

static

and

involve

relatively

few

tasks

that

they

can

be

scheduled

with

the

execution

sequence

being

laid

out

on

a

time-line

For

example

if

the

task

set

consists

solely

of

periodic

tasks

then

once

the

first

invocation

has

been

determined

all

future

invocation

times

can

be

determined

exactly

For

the

case

in

which

periodic

tasks

are

being

scheduled

the

resulting

off-line

schedule

is

called

a

cyclic

executive

These

schedules

can

be

efficient

can

reduce

overhead

from

task

swapping

and

offer

a

simple

method

to

enforce

mutual

exclusion

while

accessing

a

shared

resource

They

do

however

have

major

problems

Any

change

in

the

task

set

including

modifications

to

the

tasks

themselves

can

require

that

a

new

time-line

be

drawn

and

then

fully

tested

The

method

also

requires

that

the

task

set

be

relatively

small

and

cyclic

executives

are

not

well

suited

to

handling

mixtures

of

periodic

and

aperiodic

tasks

Consequently

they

do

not

offer

as

good

a

response

time

for

aperiodic

tasks

as

can

be

achieved

by

other

methods

To

efficiently

implement

a

cyclic

executive

the

task

periods

should

be

as

close

to

harmonic

as

possible

to

create

a

short

schedule

This

may

force

unnecessary

additional

processing

load

Finally

a

cyclic

executive

can

not

easily

deal

with

frame

overruns

where

a

code

segment

occasionally

executes

longer

than

expected

For

these

reasons

in

this

article

we

focus

only

upon

on-line

scheduling

algorithms

There

are

several

classifications

of

on-line

scheduling

algorithms

An

important

dichotomy

is

based

on

preemptive

and

non-preemptive

scheduling

algorithms

Preemptive

algorithms

assume

that

any

process

can

be

suspended

by

the

scheduler

at

any

time

with

relatively

small

overhead

and

later

resumed

from

the

point

of

suspension

The

most

common

reason

for

preemption

is

when

a

higher

priority

task

becomes

ready

to

run

Non-preemptive

scheduling

algorithms

do

not

permit

running

processes

to

be

suspended

Non-preemptive

schedulers

are

relatively

easy

to

implement

but

can

cause

high

priority

tasks

to

miss

their

deadlines

when

they

are

blocked

by

a

long

lower

priority

task

Nevertheless

partial

non-preemptivity

can

be

effectively

used

for

concurrency

control

for

example

in

enforcing

critical

sections

Furthermore

some

lack

of

preemptibility

is

often

inevitable

for

example

when

interrupts

on

behalf

of

lower

priority

tasks

are

not

masked

or

when

the

scheduler

or

other

operating

system

functions

are

executing

While

much

of

the

scheduling

literature

deals

with

the

non-preemptive

case

most

modern

computer

systems

allow

task

preemption

with

small

overhead

Thus

in

this

article

we

focus

primarily

on

the

preemptive

case

A

second

important

classification

of

scheduling

algorithms

is

static

priority

versus

dynamic

priority

algorithms

A

static

priority

scheduling

algorithm

will

preassign

a

fixed

priority

to

each

task

-LRB-

and

the

same

priority

to

every

invocation

of

that

task

-RRB-

Dynamic

priority

algorithms

allow

a

task

to

change

its

priority

at

any

point

in

time

between

its

readiness

and

its

completion

time

and

different

invocations

of

a

periodic

task

can

have

different

priorities

The

task

scheduling

problem

has

been

extensively

studied

in

the

operations

research

and

computer

science

literature

The

focus

of

that

literature

tends

to

be

on

optimal

scheduling

methods

and

their

computational

complexity

Most

realistic

real-time

scheduling

problems

which

incorporate

practical

issues

such

as

task

blocking

and

transient

overloads

are

NP-hard

As

such

optimal

methods

will

often

not

be

useful

in

real-time

systems

Garey

Graham

and

Johnson

-LSB-

-RSB-

summarize

the

situation

as

follows

Unfortunately

although

it

is

not

difficult

to

design

optimization

algorithms

-LRB-

e.g.

exhaustive

search

is

usually

applicable

-RRB-

the

goal

of

designing

efficient

optimization

algorithms

has

proved

much

more

difficult

to

attain

In

fact

all

but

a

few

scheduleoptimization

problems

are

considered

insoluble

except

for

small

or

specially

structured

problem

instances

For

these

scheduling

problems

no

efficient

optimization

algorithm

has

yet

been

found

and

indeed

is

expected

This

pessimistic

outlook

has

been

bolstered

by

recent

results

showing

that

most

scheduling

problems

belong

to

the

infamous

class

of

NP-complete

problems

For

real-time

systems

it

is

more

important

to

use

algorithms

which

while

not

optimal

will

be

predictable

guarantee

acceptably

high

levels

of

resource

utilization

and

which

address

practical

issues

such

as

operating

system

overhead

task

synchronization

aperiodic

events

and

transient

overload

There

are

two

scheduling

algorithms

that

are

especially

important

for

scheduling

real-time

systems

the

rate

monotonic

scheduling

algorithm

and

the

earliest

deadline

scheduling

algorithm

The

former

is

an

on-line

but

static

priority

algorithm

which

assigns

periodic

task

priorities

in

inverse

relation

to

the

task

periods

The

latter

is

a

dynamic

priority

algorithm

in

which

the

highest

priority

is

accorded

to

the

ready

task

with

the

nearest

deadline

A

comprehensive

scheduling

theory

has

been

developed

for

fixed

priority

preemptive

systems

based

on

the

rate

monotonic

algorithm

and

this

theory

is

referred

to

as

generalized

rate-monotonic

analysis

The

interested

reader

should

consult

the

handbook

by

Klein

et

al.

-LSB-

-RSB-

for

a

comprehensive

description

of

this

theory

Because

this

theory

is

capable

of

handling

many

of

the

practical

problems

that

arise

with

real-time

systems

it

can

form

a

basis

for

designing

predictable

real-time

industrial

computing

systems

This

article

provides

an

introduction

to

this

theory

Figure

A

High-Level

View

of

the

Application

An

Industrial

Computing

Example

To

illustrate

how

the

generalized

rate

monotonic

scheduling

theory

applies

to

a

large

class

of

industrial

computing

problems

we

will

analyze

a

realistic

example

based

on

a

real-time

robotics

application

that

is

an

elaboration

of

an

example

discussed

in

-LSB-

-RSB-

In

this

section

we

will

describe

the

example

and

in

the

next

section

we

will

discuss

resource

management

techniques

for

understanding

the

timing

behavior

of

this

example

Figure

represents

a

high-level

view

of

this

application

There

are

four

nodes

on

an

FDDI

-LRB-

ANSI

-RRB-

network

Nodes

and

are

dedicated

to

robotics

applications

Node

has

an

operator

's

console

system

for

displaying

system

measurement

data

and

for

issuing

commands

to

the

various

robotic

measurement

systems

at

the

other

nodes

The

system

must

satisfy

two

types

of

timing

requirements

ffl

Each

task

on

each

node

must

be

guaranteed

to

meet

its

deadline

ffl

System-level

timing

constraints

such

as

end-to-end

deadlines

across

nodes

must

be

satisfied

where

an

end-to-end

deadine

is

a

timing

requirement

for

processing

that

requires

several

resources

-LRB-

such

as

several

CPU

's

and

the

network

-RRB-

In

this

system

there

are

multiple

end-toend

deadlines

but

for

the

sake

of

this

discussion

we

shall

assume

a

single

end-to-end

deadline

We

will

describe

in

detail

the

tasks

that

execute

on

Nodes

and

For

the

purposes

of

this

example

we

will

assume

that

Nodes

and

are

similar

to

Node

Figure

Node

Tasking

Structure

Robotics

Application

on

Node

This

example

is

derived

from

a

real

robot

system

that

measures

the

shape

of

pipes

by

moving

around

them

and

using

a

distance

sensor

The

task

set

corresponding

to

this

system

has

been

simplified

to

reflect

only

the

important

activities

relevant

to

our

analysis

The

system

functions

are

represented

in

Figure

We

describe

the

system

in

terms

of

tasks

and

subtasks

Each

job

of

a

task

represents

the

response

to

some

event

-LRB-

for

example

the

arrival

of

sensor

data

-RRB-

A

subtask

represents

a

portion

of

that

response

that

executes

at

a

constant

priority

The

total

response

to

an

event

may

execute

at

multiple

and

hence

may

comprise

multiple

subtasks

There

are

tasks

ffl

Robot

control

Task

controls

the

robot

's

servomotors

and

has

two

subtasks

The

corresponding

activities

are

reading

the

inputs

from

the

servo-sensors

and

performing

the

control

action

for

moving

the

robot

ffl

Measurement

subsystem

Tasks

and

constitute

the

measurement

subsystem

and

numbers

mean

higher

priorities

synchronize

with

each

other

Task

reads

the

distance

sensors

does

some

data

preprocessing

and

sends

the

results

to

Node

Task

does

some

more

processing

on

the

sensor

data

for

local

use

ffl

System

command

Task

is

responsible

for

receiving

and

interpreting

commands

arriving

from

Node

while

has

to

process

and

execute

these

commands

Both

tasks

synchronize

with

each

other

and

also

has

to

update

some

control

variables

that

affect

the

operation

of

the

rest

of

the

tasks

Notice

that

tasks

can

execute

at

multiple

priorities

For

example

task

is

considered

to

be

a

single

task

but

is

in

fact

composed

of

two

system

subtasks

an

interrupt

service

routine

-LRB-

ISR

-RRB-

and

Servo

Control

where

Servo

Control

executes

only

as

a

consequence

of

being

signaled

by

the

ISR

Table

shows

the

execution

times

and

priorities

of

the

subtasks

and

the

periods

and

deadlines

of

these

tasks

All

of

the

values

are

in

milliseconds

-LRB-

ms

-RRB-

Task

Ti

Di

Table

Tasks

on

Node

-LRB-

units

are

in

milliseconds

-RRB-

Ti

is

the

period

of

the

ith

task

Di

is

the

deadline

of

the

ith

task

Cij

is

the

execution

time

of

the

jth

subtask

of

the

ith

task

Pij

is

the

execution

priority

of

the

jth

subtask

of

the

ith

task

All

tasks

have

deadlines

at

the

end

of

their

periods

Task

has

been

assigned

a

deadline

at

the

end

of

its

period

but

this

deadline

actually

arises

from

a

system-level

deadline

Specifically

there

is

an

end-to-end

deadline

of

seconds

from

the

time

the

data

is

sensed

by

on

Node

to

the

time

it

is

displayed

on

Node

Data

Display

Function

on

Node

This

node

performs

a

data

display

function

Tasks

and

need

mutually

exclusive

access

to

a

shared

resource

-LRB-

device

-RRB-

and

are

also

responsible

for

reading

and

displaying

data

from

Nodes

and

respectively

Task

is

responsible

for

displaying

data

sent

from

Node

Table

shows

the

execution

times

periods

deadlines

and

priorities

for

the

tasks

on

Node

Tasks

and

have

deadlines

at

the

end

of

their

periods

Task

has

a

deadline

of

ms

that

represents

a

part

of

the

second

end-to-end

deadline

of

the

sensor

data

of

task

on

Node

Description

of

FDDI

FDDI

is

a

Mbit/sec

local/metropolitan

area

network

that

uses

a

token

ring

protocol

The

time

it

takes

for

a

token

to

traverse

an

idle

ring

is

called

the

walk

time

-LRB-

Wt

-RRB-

which

is

ms

for

Task

Ti

Ci

Di

Pi

Resource

Access

-LRB-

time

-RRB-

Yes

-LRB-

-RRB-

No

-LRB-

-RRB-

Yes

-LRB-

-RRB-

Table

The

Tasks

on

Node

this

example

Under

this

protocol

the

network

parameter

known

as

the

target

token

rotation

time

-LRB-

TTRT

-RRB-

is

chosen

The

TTRT

is

the

maximum

amount

of

time

it

can

take

for

the

token

to

make

a

round

trip

in

the

network

Transmission

time

is

allocated

to

each

node

in

a

manner

that

enforces

the

TTRT

For

our

example

TTRT

is

ms.

The

total

amount

of

time

available

to

be

split

between

the

nodes

is

TTRT

W

t.

Each

robotics

node

will

be

allocated

of

the

available

time

and

the

display

station

will

be

allocated

the

remaining

of

the

available

time

We

will

assume

that

task

on

Node

transmits

Mbits

of

data

every

ms

to

Node

Applying

Rate

Monotonic

Analysis

In

this

section

we

analyze

the

timing

behavior

of

this

real-time

distributed

industrial

application

We

introduce

relevant

theoretical

results

and

then

illustrate

the

practical

applicability

of

each

result

by

using

it

to

analyze

different

aspects

of

the

application

Solution

Strategy

We

use

a

divide

and

conquer

approach

for

understanding

and

controlling

the

timing

behavior

of

this

application

The

solution

strategy

is

to

decompose

this

distributed

system

resource

scheduling

problem

into

separate

local

resource

scheduling

problems

and

then

apply

appropriate

real-time

resource

scheduling

techniques

to

each

resource

Sensor

data

received

at

Node

must

be

displayed

at

Node

within

the

end-to-end

timing

requirement

of

seconds

This

data

must

traverse

three

resources

the

CPU

at

Node

the

network

and

the

CPU

at

Node

We

will

decompose

this

end-to-end

deadline

as

follows

and

attempt

to

create

shorter

independent

deadlines

on

each

resource

If

the

sum

of

the

deadlines

on

these

three

resources

is

less

than

the

end-to-end

deadline

and

the

deadlines

are

satisfied

this

system

constraint

will

be

satisfied

A

simple

way

of

assigning

deadlines

on

individual

resources

is

to

assign

one

period

on

each

resource

Thus

the

assigned

deadline

for

the

sensor

data

on

Node

and

on

the

network

correspond

to

the

period

of

A

longer

deadline

is

necessary

on

Node

which

has

a

high

level

of

processor

utilization

Hence

the

allocated

timing

budget

for

each

resource

is

ffl

ms

for

task

on

Node

to

complete

its

processing

ffl

ms

for

task

to

tranmit

its

data

across

the

network

ffl

ms

for

task

on

Node

to

complete

its

processing

The

total

delay

adds

up

to

ms

which

is

less

than

the

end-to-end

deadline

of

seconds

Our

first

problem

is

to

understand

the

timing

behavior

of

periodic

tasks

Applying

Rate

Monotonic

Analysis

to

Periodic

Tasks

The

problem

of

scheduling

periodic

tasks

was

first

addressed

analytically

in

-LSB-

-RSB-

The

most

comprehensive

treatment

of

the

periodic

task

scheduling

problem

is

provided

by

Liu

and

Layland

in

-LSB-

-RSB-

They

considered

both

static

priority

and

dynamic

priority

scheduling

algorithms

and

studied

this

scheduling

problem

under

idealized

circumstances

by

assuming

that

all

tasks

are

independent

periodic

and

have

end-of-period

deadlines

Consider

a

set

of

n

periodic

tasks

on

Each

task

is

characterized

by

four

components

-LRB-

Ci

Ti

Di

Ii

-RRB-

i

n

where

Ci

computation

requirement

of

each

instance

of

oi

Ti

period

of

oi

Di

deadline

of

oi

Ii

phasing

of

oi

relative

to

some

fixed

time

origin

Each

periodic

task

creates

a

continual

sequence

of

jobs

The

jth

job

of

oi

occurs

at

time

Ii

-LRB-

j

-RRB-

Ti

and

the

Ci

units

of

computation

required

for

each

job

of

oi

have

a

deadline

of

Ii

-LRB-

j

-RRB-

Ti

Di

Liu

and

Layland

assumed

Di

Ti

A

task

set

is

said

to

be

schedulable

by

a

particular

scheduling

algorithm

provided

that

all

deadlines

of

all

the

tasks

are

met

under

all

task

phasings

if

that

scheduling

algorithm

is

used

Liu

and

Layland

-LSB-

-RSB-

proved

three

important

results

concerning

static

priority

scheduling

algorithms

Consider

first

the

longest

response

time

for

any

job

of

a

task

oi

where

the

response

time

is

the

difference

between

the

task

instantiation

time

-LRB-

Ii

kTi

-RRB-

and

the

task

completion

time

that

is

the

time

at

which

that

instance

of

oi

completes

its

required

Ci

units

of

execution

If

any

static

priority

scheduling

algorithm

is

used

and

tasks

are

ordered

so

that

oi

has

higher

priority

than

oj

for

i

j

then

Theorem

-LSB-

-RSB-

The

longest

response

time

for

any

instance

of

oi

occurs

when

it

starts

along

with

all

higher

priority

tasks

-LRB-

i.e.

Ii

-RRB-

A

critical

instant

is

defined

as

an

instant

at

which

a

request

for

a

job

will

result

in

the

longest

possible

response

time

for

the

job

A

critical

instant

occurs

when

In

which

is

called

the

critical

instant

phasing

because

it

is

the

phasing

that

results

in

the

longest

response

time

for

the

first

job

of

each

task

Consequently

this

creates

the

worst

case

task

set

phasing

and

leads

to

a

criterion

for

the

schedulability

of

a

task

set

Theorem

-LSB-

-RSB-

A

periodic

task

set

can

be

scheduled

by

a

static

priority

scheduling

algorithm

provided

the

deadline

of

the

first

job

of

each

task

starting

from

a

critical

instant

is

met

using

the

scheduling

algorithm

The

rate

monotonic

algorithm

assigns

every

instance

of

a

task

an

identical

priority

and

assigns

priorities

inversely

to

task

periods

Hence

oi

receives

higher

priority

than

oj

if

Ti

Tj

Ties

are

broken

arbitrarily

This

algorithm

is

an

optimal

static

priority

algorithm

in

the

sense

that

any

task

set

that

can

be

scheduled

by

some

static

priority

algorithm

can

also

be

scheduled

by

the

rate

monotonic

algorithm

It

is

interesting

to

note

that

the

rate

monotonic

scheduling

algorithm

considers

only

task

periods

not

task

computation

times

or

the

relative

importance

of

the

task

in

the

task

set

Serlin

and

Liu

and

Layland

went

on

to

offer

a

worst-case

upper

bound

for

the

rate-monotonic

scheduling

algorithm

In

other

words

there

exists

a

threshold

U?n

such

that

if

the

utilization

of

a

task

set

consisting

of

n

tasks

U

Cn

Tn

is

no

greater

than

U?n

then

the

rate-monotonic

scheduling

algorithm

is

guaranteed

to

meet

all

task

deadlines

Theorem

-LSB-

-RSB-

A

periodic

task

set

on

with

Di

Ti

i

n

is

schedulable

by

the

rate

monotonic

scheduling

algorithm

if

Un

U?n

n

-LRB-

n

-RRB-

n

The

sequence

of

scheduling

thresholds

is

given

by

U

U

U

U

U

Consequently

any

periodic

task

set

can

be

scheduled

by

the

rate

monotonic

algorithm

if

its

total

utilization

is

no

greater

than

Analyzing

Node

Using

Utilization

Bounds

We

will

use

Theorem

to

analyze

the

schedulability

of

tasks

on

Node

ignoring

the

mutual

exclusion

requirements

on

the

shared

resource

Theorem

only

applies

to

the

case

in

which

Di

Ti

For

task

this

constraint

represents

an

earlier

deadline

than

the

allocated

deadline

of

ms.

Table

illustrates

the

individual

and

cumulative

utilizations

for

the

task

set

and

also

lists

the

values

of

the

utilization

bounds

of

Theorem

Task

Ti

Ci

Di

Ui

Cumulative

Theorem

Bound

Less

than

Ui

Theorem

Bound

Yes

No

No

Table

Schedulability

of

Tasks

on

Node

We

see

from

Table

that

task

is

guaranteed

by

Theorem

to

meet

all

of

its

deadlines

since

its

utilization

is

less

than

the

utilization

bound

and

Di

Ti

However

Theorem

can

not

be

used

to

guarantee

the

deadlines

of

tasks

and

because

the

cumulative

utilization

exceeds

the

utilization

bound

of

Theorem

A

more

detailed

analysis

is

therefore

required

Exact

Analysis

for

Computing

Completion

Times

We

now

present

an

exact

analysis

of

the

schedulability

of

a

task

set

using

a

static

priority

scheduling

algorithm

We

will

use

this

refined

analysis

to

recheck

those

tasks

whose

schedulability

could

not

be

guaranteed

using

the

technique

based

on

utilization

bounds

Under

critical

instant

phasing

Pij

Cjd

tTj

e

Wi

-LRB-

t

-RRB-

gives

the

cumulative

demand

for

processing

by

tasks

oj

j

i

during

-LSB-

t

-RSB-

Using

Theorem

task

oi

meets

all

its

deadlines

if

its

first

job

meets

its

deadline

under

critical

instant

phasing

Thus

oi

will

meet

its

deadline

if

Wi

-LRB-

t

-RRB-

t

at

some

time

t

t

Di

the

deadline

of

the

first

job

of

oi

Equivalently

this

job

will

meet

its

deadline

if

and

only

if

there

is

a

t

t

Di

at

which

Wi

-LRB-

t

-RRB-

t

The

smallest

time

t

satisfying

this

inequality

gives

the

longest

possible

completion

time

of

any

instance

of

oi

We

summarize

this

in

the

following

theorem

Theorem

-LSB-

-RSB-

Let

a

periodic

task

set

on

be

given

in

priority

order

and

scheduled

by

a

fixed

priority

scheduling

algorithm

using

those

priorities

If

Di

Ti

then

oi

will

meet

all

its

deadlines

under

all

task

phasings

if

and

only

if

min

t

Di

iX

j

Cj

t

t

Tj

The

entire

task

set

is

schedulable

under

the

worst

case

phasing

if

and

only

if

max

i

n

min

t

Di

iX

j

Cj

t

t

T

j

ss

The

criterion

given

in

Theorem

is

not

difficult

to

compute

Create

a

sequence

of

times

with

Pij

Cj

Sn

Wi

-LRB-

Sn

-RRB-

If

for

some

n

Sn

Sn

Di

then

task

oi

is

schedulable

and

Sn

is

its

worst-case

completion

time

If

instead

Di

Sn

for

some

n

the

task

oi

is

not

schedulable

We

refer

to

this

as

the

completion

time

test

Analyzing

Node

Using

Exact

Analysis

We

now

use

Theorem

to

check

the

schedulability

of

tasks

and

Using

the

completion

time

test

for

task

first

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

Therefore

's

worst-case

completion

time

is

and

it

meets

its

deadline

at

Using

the

completion

time

test

for

task

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

Thus

completes

at

time

which

is

before

its

deadline

at

Even

so

this

is

insufficient

to

conclude

that

all

deadlines

of

all

invocations

of

will

meet

their

deadlines

This

is

because

the

assumption

Di

Ti

of

Theorem

is

violated

and

it

is

no

longer

sufficient

to

check

the

first

job

's

deadline

However

a

more

general

bound

is

available

Generalizing

Utilization

Bounds

We

first

consider

the

situation

in

which

the

task

deadlines

need

not

be

equal

to

the

task

periods

This

problem

was

initially

considered

by

Leung

and

Whitehead

-LRB-

-RRB-

They

introduced

a

new

static

priority

scheduling

algorithm

the

deadline

monotonic

algorithm

in

which

task

priorities

are

assigned

inversely

with

respect

to

task

deadlines

That

is

oi

has

a

higher

priority

than

oj

if

Di

Dj

They

proved

the

optimality

of

the

deadline

monotonic

algorithm

when

Di

Ti

i

n.

Theorem

-LSB-

-RSB-

For

a

periodic

task

set

on

with

Di

Ti

i

n

the

deadline

monotonic

scheduling

algorithm

is

an

optimal

static

priority

scheduling

algorithm

A

task

set

is

schedulable

by

this

algorithm

if

the

first

job

of

each

task

after

a

critical

instant

meets

its

deadline

Theorem

has

been

generalized

for

the

case

in

which

Di

Ti

i

n

and

and

for

-LSB-

-RSB-

In

this

case

the

rate

monotonic

and

deadline

monotonic

scheduling

algorithms

give

the

same

priority

assignment

We

have

the

following

generalization

of

Theorem

Theorem

-LSB-

-RSB-

A

periodic

task

set

with

Di

Ti

i

n

and

is

schedulable

if

Un

U?n

-LRB-

-RRB-

-LRB-

n

-LRB-

-LRB-

-RRB-

n

-RRB-

n

-LRB-

n

-RRB-

-LRB-

n

-RRB-

-LRB-

-LRB-

-RRB-

-LRB-

n

-RRB-

-RRB-

Applying

Generalized

Utilization

Bounds

Using

the

utilization

bound

for

n

and

from

Theorem

we

see

that

the

cumulative

utilization

for

which

is

less

than

-LRB-

-RRB-

-LRB-

-LRB-

-RRB-

-RRB-

Therefore

all

invocations

of

task

on

Node

are

guaranteed

to

complete

within

ms

of

the

time

they

are

initiated

Analysis

of

Synchronization

Requirements

Up

to

this

point

we

have

ignored

the

fact

that

and

need

to

synchronize

in

order

to

access

a

device

mutually

exclusively

In

this

section

we

analyze

the

impact

of

such

synchronization

requirements

Consider

the

following

scenario

Periodic

tasks

on

are

arranged

in

descending

order

of

priority

Suppose

tasks

and

on

share

a

data

structure

guarded

by

a

semaphore

S.

Suppose

that

on

begins

execution

and

enters

a

critical

section

using

this

data

structure

Task

is

next

initiated

preempts

on

and

begins

execution

During

its

execution

attempts

to

use

the

shared

data

and

is

blocked

on

the

semaphore

S.

Task

on

now

continues

execution

but

before

it

completes

its

critical

section

it

is

preempted

by

the

arrival

of

one

of

the

tasks

on

Because

of

these

tasks

requires

the

use

of

S

any

of

these

tasks

that

arrive

will

execute

to

completion

before

on

is

able

to

execute

and

unblock

This

creates

priority

inversion

where

is

blocked

by

a

lower

priority

task

for

a

virtually

unbounded

amount

of

time

and

the

dominant

factor

causing

this

delay

are

the

tasks

not

involved

with

the

critical

section

The

solution

to

this

problem

is

to

use

priority

inheritance

that

is

a

task

which

blocks

a

high

priority

task

inherits

the

priority

of

the

task

it

is

blocking

for

the

duration

of

the

blocking

period

In

the

above

scenario

priority

inheritance

would

call

for

on

to

elevate

its

priority

to

that

of

from

the

time

blocks

on

S

until

the

blocking

condition

is

removed

This

would

prevent

any

of

on

from

preempting

on

and

would

bound

the

duration

of

the

priority

inversion

to

the

length

of

time

that

on

holds

S

The

priority

ceiling

protocol

-LSB-

-RSB-

is

a

synchronization

protocol

that

uses

priority

inheritance

to

bound

the

duration

of

priority

inversion

It

uses

additional

synchronization

rules

to

prevent

deadlock

and

further

reduces

priority

inversion

to

the

duration

of

at

most

one

critical

section

of

lower

priority

tasks

Theorem

-LSB-

-RSB-

The

priority

ceiling

protocol

prevents

deadlocks

and

under

the

protocol

a

job

J

can

experience

priority

inversion

for

at

most

the

duration

of

one

critical

section

To

give

a

schedulability

analysis

using

the

rate

monotonic

scheduling

algorithm

in

conjunction

with

the

priority

ceiling

protocol

we

define

Bk

k

n

the

longest

duration

of

blocking

that

can

be

experienced

by

ok

Once

these

blocking

terms

have

been

determined

they

can

be

used

in

a

slightly

modified

version

of

the

completion

time

test

Analyzing

Synchronization

on

Node

First

notice

that

using

Theorem

we

can

determine

that

the

blocking

incurred

by

task

due

to

task

is

Applying

a

slightly

modified

version

of

the

completion

time

test

to

amounts

to

simply

adding

the

blocking

term

to

its

execution

time

increasing

it

to

which

is

less

than

its

deadline

of

Therefore

meets

its

deadline

even

with

the

additional

delay

due

to

synchronization

It

is

important

to

note

that

can

also

incur

blocking

The

priority

ceiling

protocol

uses

priority

inheritance

as

part

of

the

protocol

This

means

during

the

execution

of

the

critical

section

can

be

executing

at

a

priority

equal

to

the

priority

of

and

hence

can

block

for

By

adding

the

blocking

to

the

execution

time

of

and

applying

Theorem

we

can

show

that

is

schedulable

Analysis

of

a

Complex

Priority

Structure

Now

we

shift

our

attention

to

Node

The

first

thing

we

notice

about

Node

is

that

tasks

no

longer

execute

at

a

single

priority

They

have

several

subtasks

which

are

executed

in

serial

order

The

situation

in

which

tasks

are

divided

into

subtasks

which

are

executed

in

serial

order

was

treated

in

-LSB-

-RSB-

This

situation

can

arise

in

many

practical

circumstances

for

example

when

high

priority

tasks

are

blocked

by

the

interrupts

of

low

priority

tasks

-LRB-

the

interrupt

portion

of

the

low

priority

task

would

be

considered

an

initial

subtask

that

is

executed

at

an

elevated

priority

-RRB-

when

synchronization

is

required

-LRB-

and

a

task

elevates

its

priority

to

enforce

mutual

exclusion

-RRB-

or

when

operating

system

activities

-LRB-

such

as

task

swapping

or

scheduling

-RRB-

are

included

into

the

analysis

The

static

priority

schedulability

analysis

of

this

problem

is

similar

in

nature

to

the

usual

case

except

that

one

must

exercise

care

in

determining

all

the

jobs

whose

deadlines

must

be

checked

and

the

worst

case

task

phasings

These

conditions

are

fully

spelled

out

in

-LSB-

-RSB-

An

important

result

that

greatly

simplifies

the

analysis

of

tasks

with

multiple

subtasks

is

the

reduction

of

a

task

composed

of

subtasks

having

varying

execution

priorities

to

its

canonical

form

A

task

is

said

to

be

in

canonical

form

if

it

consists

of

consecutive

subtasks

that

do

not

decrease

in

priority

The

following

result

can

be

used

to

conclude

that

a

task

in

canonical

form

has

the

same

completion

time

as

the

original

task

Theorem

-LSB-

-RSB-

Suppose

oi

has

two

consecutive

subtasks

oij

and

oij

of

strictly

decreasing

priority

Pij

Pij

Then

for

any

task

set

phasing

the

completion

times

of

a

task

oi

and

its

subtasks

oik

j

k

m

-LRB-

i

-RRB-

are

unchanged

if

the

priority

of

oij

is

reduced

to

Pij

assuming

all

equal

priority

segments

are

executed

in

the

same

relative

order

The

above

theorem

can

be

used

to

simplify

the

determination

of

whether

a

particular

task

meets

its

deadline

By

applying

this

theorem

to

all

such

consecutive

subtasks

we

can

reduce

the

task

to

canonical

form

The

canonical

form

of

a

task

oi

is

another

task

o

i

that

is

obtained

by

applying

the

following

algorithm

starting

with

the

final

subtask

of

task

oi

Let

P

ij

denotes

the

priority

of

subtask

o

ij

ffl

Set

P

im

-LRB-

i

-RRB-

Pim

-LRB-

i

-RRB-

where

m

-LRB-

i

-RRB-

denotes

the

number

of

subtasks

of

task

oi

ffl

If

P

il

Pil

then

set

P

il

P

il

ffl

If

P

il

Pil

then

set

P

il

P

il

ffl

Continue

with

this

procedure

moving

from

the

last

subtask

to

the

first

After

applying

the

algorithm

consecutive

subtasks

of

the

transformed

task

with

equal

priority

can

be

combined

into

a

single

subtask

For

example

on

Node

tasks

through

in

canonical

form

become

tasks

with

only

one

subtask

having

priority

and

respectively

Task

consists

of

two

subtasks

having

priority

and

According

to

Theorem

one

can

reduce

oi

to

its

canonical

form

The

resulting

task

o

i

will

consist

of

-LRB-

i

-RRB-

subtasks

o

o

-LRB-

i

-RRB-

having

priorities

Pmini

P

P

im

-LRB-

i

-RRB-

The

canonical

form

is

useful

for

reasoning

about

the

phasing

of

other

tasks

that

create

the

worst-case

response

time

for

oi

This

phasing

will

depend

on

the

priority

levels

of

each

task

compared

to

the

priority

of

the

first

segment

of

the

canonical

form

task

This

results

in

a

classification

of

the

other

tasks

with

respect

to

o

i

Task

Classification

When

analyzing

task

oi

tasks

other

than

oi

are

placed

into

groups

based

upon

the

priorities

of

their

subtasks

relative

to

oi

A

key

criterion

is

the

priority

of

the

first

subtask

relative

to

the

minimum

priority

of

all

subtasks

of

task

oi

Pmini

For

example

a

task

that

starts

with

a

high-priority

subtask

will

eventually

be

able

to

preempt

the

subtask

of

task

oi

with

the

minimum

priority

On

the

other

hand

a

task

that

starts

with

a

lower

priority

subtask

will

never

have

this

opportunity

Since

the

task

groupings

are

relative

to

the

priority

structure

of

task

oi

the

groups

will

vary

as

a

function

of

the

task

being

analyzed

We

refer

to

a

sequence

of

consecutive

subtasks

as

a

segment

An

H

segment

comprises

a

sequence

of

consecutive

subtasks

each

of

which

has

a

priority

equal

to

or

greater

than

Pmini

Similarly

an

L

segment

refers

to

any

set

of

consecutive

subtasks

each

of

which

has

priority

strictly

less

than

Pmini

An

effect

due

to

preemption

by

a

first

segment

that

is

an

H

segment

will

be

referred

to

as

a

preemption

effect

An

effect

due

to

an

H

segment

that

occurs

after

an

L

segment

will

be

referred

to

as

a

blocking

effect

The

four

types

of

tasks

are

ffl

Type

tasks

have

a

single

H

segment

and

thus

are

able

to

preempt

task

oi

more

than

once

Each

task

in

this

group

is

used

to

determine

the

worst-case

completion

time

for

task

oi

ffl

Type

tasks

are

such

that

each

high-priority

segment

is

followed

by

a

low-priority

segment

Consequently

each

task

in

this

set

can

preempt

task

oi

only

once

because

the

low-priority

segments

will

have

to

wait

until

the

busy

period

is

complete

before

they

can

execute

ffl

Type

tasks

are

such

that

each

high-priority

segment

is

preceded

by

a

low-priority

segment

Consequently

at

most

one

task

in

this

group

can

contribute

an

effect

which

is

a

blocking

effect

ffl

Type

tasks

have

a

single

L

segment

and

thus

have

no

effect

on

the

completion

time

of

task

oi

and

can

be

ignored

A

Blocked-At-Most-Once

Property

Our

procedure

for

finding

the

worst-case

phasing

for

other

tasks

will

use

a

blocked-at-most-once

property

-LSB-

-RSB-

for

determining

the

effect

of

internal

and

final

H

segments

-LRB-

that

is

blocking

segments

-RRB-

Theorem

-LSB-

-RSB-

There

can

be

no

more

than

one

blocking

segment

delaying

the

completion

time

of

oi

Analysis

of

Node

Notice

that

the

lower

level

priorities

of

each

task

have

been

assigned

according

to

rate

monotonic

order

using

the

task

periods

Tasks

and

start

with

an

ISR

and

therefore

have

the

priorities

of

their

first

sections

fixed

by

the

system

's

hardware

Tasks

and

synchronize

with

each

other

in

their

middle

subtasks

and

execute

both

of

these

subtasks

at

the

same

elevated

priority

Tasks

and

also

synchronize

with

each

other

and

are

assumed

to

have

their

third

and

initial

subtasks

respectively

executing

at

the

same

priority

Task

's

final

subtask

must

modify

some

control

variables

and

is

therefore

executed

at

relatively

high

priority

to

prevent

interference

from

some

of

the

other

tasks

The

first

step

in

the

analysis

of

on

Node

is

to

convert

it

to

canonical

form

The

canonical

form

of

task

is

a

task

that

has

a

simpler

priority

structure

and

preserves

the

completion

time

of

the

original

task

The

canonical

task

associated

with

is

o

with

the

following

properties

ffl

C

T

P

Notice

that

o

has

a

single

subtask

whose

execution

time

is

the

sum

of

the

execution

times

of

the

original

subtasks

and

whose

priority

is

equal

to

the

priority

of

The

next

step

in

determining

the

completion

time

of

is

to

classify

each

of

the

other

tasks

on

Node

relative

to

task

as

shown

in

the

Table

Task

Priority

Task

Type

-LRB-

relative

priority

-RRB-

H

H

H

LHL

L

H

L

HL

H

L

L

L

LH

L

L

H

Table

The

Classification

of

Tasks

on

Node

relative

to

One

can

see

from

Table

and

Theorem

that

the

effects

of

and

must

be

included

in

the

completion

time

test

The

new

term

for

the

completion

time

test

is

calculated

as

follows

ffl

max

-LRB-

-RRB-

max

-LRB-

-RRB-

Using

the

completion

time

test

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

Since

the

completion

time

is

and

the

deadline

is

satisfied

Analysis

of

Network

The

key

to

analyzing

the

schedulability

of

the

network

is

to

understand

if

the

percentage

of

network

bandwidth

that

is

allocated

to

a

node

is

sufficient

to

keep

up

with

the

message

traffic

originating

from

that

node

The

strategy

for

performing

this

analysis

is

to

analyze

each

node

separately

and

to

treat

the

message

traffic

generated

by

each

node

as

a

set

of

network

tasks

-LSB-

-RSB-

Each

periodic

message

originating

from

a

specific

node

is

considered

a

network

task

This

set

of

network

tasks

is

then

augmented

by

a

higher

priority

task

accounting

for

the

network

bandwidth

that

is

not

available

to

the

node

under

analysis

We

will

illustrate

using

our

example

Task

on

Node

generates

Mbit

of

data

every

ms.

Since

FDDI

can

transmit

at

a

rate

of

Mbit

per

second

the

utilization

of

the

network

due

to

is

equivalent

to

a

network

task

that

would

execute

ms

with

a

period

of

ms.

Now

we

have

to

characterize

the

network

task

that

represents

the

bandwidth

which

is

unavailable

to

Node

Recall

that

the

target

token

rotation

time

-LRB-

TTRT

-RRB-

is

ms

the

token

walk

-LRB-

W

t

-RRB-

time

is

ms

and

that

of

the

network

bandwidth

is

dedicated

to

Node

This

means

that

the

bandwidth

of

the

network

not

available

to

Node

can

be

represented

as

a

high

priority

network

task

with

ffl

an

execution

time

equal

to

TTRT

-LRB-

TTRT

W

t

-RRB-

ms.

ffl

a

period

equal

to

ms.

Therefore

we

must

ensure

that

the

following

two

tasks

are

schedulable

and

if

so

the

messages

generated

by

Node

are

schedulable

ffl

Network

task

execution

time

equal

to

ms

and

a

period

equal

to

ms

at

a

high

priority

ffl

Network

task

execution

time

equal

to

ms

and

a

period

equal

to

ms

at

a

low

priority

Using

the

completion

time

test

one

can

show

that

these

two

tasks

are

indeed

schedulable

with

network

task

completing

within

ms

in

the

worst

case

Therefore

the

latency

attributable

to

the

network

is

less

than

the

required

ms.

Analysis

of

End-to-End

Deadline

Let

us

now

look

at

the

latencies

encountered

by

the

sensor

data

from

Node

until

its

display

on

Node

The

latencies

consist

of

the

timing

budgets

we

allocated

on

Nodes

and

the

network

as

well

as

latencies

that

can

be

incurred

if

these

activities

are

not

in

phase

ffl

ms

for

task

on

Node

to

complete

its

processing

ffl

ms

to

transmit

its

data

across

the

network

ffl

ms

on

Node

-LRB-

Task

on

Node

is

initiated

every

ms.

It

reads

data

from

the

last

time

intervals

of

the

data

sent

by

on

Node

However

since

the

task

is

polling

for

data

it

could

be

out

of

phase

by

period

from

the

arrival

of

the

oldest

data

in

its

input

buffer

This

can

introduce

an

additional

ms

of

latency

-RRB-

ffl

ms

for

task

on

Node

to

complete

its

processing

The

total

latency

adds

up

to

ms

which

is

less

than

the

ms

end-to-end

constraint

Since

there

is

some

slack

the

system

designer

can

choose

to

introduce

additional

tasks

or

use

this

slack

for

future

extensions

and

modifications

Example

Summary

The

purpose

of

the

example

is

to

illustrate

the

practical

applicability

of

rate

monotonic

analysis

to

a

simple

but

realistic

example

of

real-time

industrial

computing

It

is

very

common

for

existing

industrial

computing

applications

to

have

complex

priority

structures

Techniques

for

handling

tasks

with

a

complex

priority

structure

were

used

to

analyze

the

schedulability

of

task

on

Node

Techniques

for

analyzing

the

schedulability

of

periodic

tasks

that

synchronize

with

one

another

proved

the

schedulability

of

all

of

the

tasks

residing

on

node

Techniques

for

transforming

a

network

utilization

problem

into

a

task

schedulability

problem

were

used

to

understand

the

latency

introduced

by

the

FDDI

network

Finally

the

end-to-end

deadline

associated

with

the

sensor

data

received

on

Node

was

shown

to

be

satisfied

by

proving

that

the

timing

budgets

for

each

resource

on

its

path

-LRB-

that

is

Node

the

network

and

Node

-RRB-

were

satisfied

Further

Extensions

There

have

been

many

extensions

of

the

rate

monotonic

scheduling

algorithm

to

address

a

multitude

of

other

practical

problems

that

arise

with

real-time

systems

Some

of

these

extensions

include

ffl

Providing

excellent

response

times

to

aperiodic

tasks

using

a

periodic

server

which

is

assigned

a

period

and

a

processing

capacity

such

that

incoming

aperiodic

tasks

can

run

at

the

priority

of

the

server

when

capacity

is

available

ffl

Analyzing

the

loss

in

schedulable

utilization

due

to

a

limit

in

the

number

of

distinct

priority

levels

for

example

in

network

and

bus

scheduling

ffl

Ensuring

that

the

most

important

tasks

meet

their

timing

requirements

in

cases

of

transient

overload

when

not

all

deadlines

can

be

met

ffl

Extending

the

processor

scheduling

theory

to

communication

subsystems

ffl

Developing

a

theory

of

predictable

mode

changes

ffl

Incorporation

of

rate-monotonic

scheduling

support

into

Ada

POSIX

and

Futurebus

All

of

the

above

topics

as

well

as

many

others

with

associated

references

are

discussed

in

the

review

articles

-LSB-

-RSB-

The

reader

who

is

interested

in

the

practical

aspects

of

using

rate

monotonic

scheduling

should

consult

the

practitioner

's

handbook

for

rate

monotonic

analysis

-LSB-

-RSB-

Finally

those

interested

in

a

tutorial

on

hard

real-time

systems

should

consult

-LSB-

-RSB-

Conclusion

Industrial

computing

defines

an

increasingly

important

class

of

computer-based

systems

systems

in

which

dependability

timeliness

and

safety

are

crucial

A

very

important

aspect

of

ensuring

safety

and

dependability

is

to

understand

resource

management

techniques

such

as

generalized

rate

monotonic

analysis

which

can

be

used

to

manage

timeliness

on

a

broad

class

of

industrial

computing

applications

This

article

has

illustrated

how

generalized

rate-monotonic

analysis

can

be

used

to

analyze

a

industrial

computing

application

These

techniques

offer

the

designer

the

ability

to

use

analytical

tools

for

designing

industrial

computing

systems

to

meet

their

timing

constraints

Future

work

includes

integrating

these

techniques

for

timing

analysis

with

dependability

techniques

to

achieve

safe

operation

high

availability

and

online

upgrades

References

-LSB-

-RSB-

Burns

A.

Scheduling

hard

real-time

systems

a

review

Software

Engineering

Journal

May

-LSB-

-RSB-

Garey

M.R.

Graham

R.L.

and

D.S.

Johnson

Performance

guarantees

for

scheduling

algorithms

Operations

Research

-LRB-

-RRB-

-LSB-

-RSB-

Gonzalez

Harbour

M.

Klein

M.

and

Lehoczky

J.

P.

Analysis

of

Tasks

with

Varying

Fixed

Priorities

Proceedings

of

the

IEEE

Real-Time

Systems

Symposium

December

-LSB-

-RSB-

Klein

M.

Ralya

T.

Pollak

B.

Obenza

R.

and

Gonzalez

Harbour

M.

A

Practitioner

's

Handbook

for

Real-Time

Analysis

Guide

to

Rate

Monotonic

Analysis

for

Real-Time

Systems

Kluwer

Academic

Publishers

July

-LSB-

-RSB-

Lehoczky

J.P.

Sha

L.

Strosnider

J.K.

and

H.

Tokuda

Fixed

priority

scheduling

theory

for

hard

real-time

systems

A.M.

van

Tilborg

and

G.M.

Koob

eds.

Foundations

of

Real-Time

Computing

Scheduling

and

Resource

Management

Kluwer

Academic

Publishers

-LSB-

-RSB-

Lehoczky

J.P.

Real-Time

Resource

Management

Techniques

Marciniak

John

J.

ed.

Encyclopedia

of

Software

Engineering

John

Wiley

-LSB-

-RSB-

Leung

J.

and

Whitehead

J.

On

the

complexity

of

fixed-priority

scheduling

of

periodic

real-time

tasks

Performance

Evaluation

-LCB-

-LSB-

-RSB-

Liu

C.L.

and

Layland

J.W.

Scheduling

algorithms

for

multiprogramming

in

a

hard

real-time

environment

JACM

-LSB-

-RSB-

Rajkumar

R.

Task

Synchronization

In

Real-Time

Systems

ISBN

Kluwer

Academic

Publishers

-LSB-

-RSB-

Serlin

O.

Scheduling

of

time

critical

processes

Proceedings

of

the

Spring

Joint

Computer

Conference

-LSB-

-RSB-

Sha

L.

Rajkumar

R.

and

Lehoczky

J.

P.

Priority

inheritance

protocols

An

approach

to

real-time

synchronization

IEEE

Transactions

on

Computers

Vol

-LSB-

-RSB-

Sha

L.

Rajkumar

R.

and

Sathaye

S.

Generalized

Rate-Monotonic

Scheduling

Theory

A

Framework

for

Developing

Real-Time

Systems

To

Appear

in

IEEE

Proceedings

-LSB-

-RSB-

Stankovic

J.A.

and

K.

Ramamritham

Tutorial

Hard

Real-Time

Systems

IEEE

Press

industrial computing
rate monotonic analysis

distributed systems
real-time
real-time scheduling