Resource

Freshness

in

Real

Time

Scheduling

Shyhtsun

F.

Wu

Gail

E.

Kaiser

y

Columbia

University

Department

of

Computer

Science

New

York

NY

Tel

Fax

fwu

kaiserg@cs.columbia.edu

Technical

Report

April

c

Shyhtsun

Felix

Wu

and

Gail

E.

Kaiser

All

Rights

Reserved

Abstract

We

define

and

study

a

real-time

producers/consumers

problem

where

the

production/consumption

relations

are

nondeterministic

In

other

words

a

consumer

can

get

one

unit

of

resources

from

any

one

of

the

producers

and

one

producer

can

provide

one

unit

of

resources

for

any

one

of

the

consumers

Furthermore

a

producer

for

one

type

of

resources

might

be

the

consumer

for

another

type

of

resources

A

class

of

fresh

resource

allocation

policies

is

developed

not

only

to

make

resources

available

for

periodic

real-time

tasks

but

also

to

control

the

resource

freshness

We

first

model

the

real-time

scheduling

problem

as

a

feasible

minimum

cost

flow

-LRB-

MCF

-RRB-

problem

Then

by

defining

the

linear

cost

function

differently

we

get

resource

allocation

policies

for

making

trade-offs

between

resource

freshness

and

task

schedulability

Finally

we

show

that

our

result

can

be

used

to

extend

the

priority

ceiling

protocol

-LRB-

PCP

-RRB-

to

work

with

general

unbounded

semaphores

where

W

ait

and

Signal

operations

need

not

be

in

pairs

in

one

task

Wu

is

supported

in

part

by

an

IBM

Fellowship

and

in

part

by

the

Center

for

Telecommunication

Research

y

Kaiser

is

supported

by

National

Science

Foundation

grants

and

by

grants

from

AT&T

BNR

DEC

IBM

and

SRA

by

the

New

York

State

Center

for

Advanced

Technology

in

Computers

and

Information

Systems

and

by

the

NSF

Engineering

Research

Center

for

Telecommunications

Research

SensorPerformance

Manager

Fault

Manager

Period

usecPeriod

usecPeriod

usec

TaskPeriod

usec

TaskTaskTaskHigh-Speed

Network

Figure

A

Simple

Network

Monitoring

System

-LRB-

Tasks

-RRB-

Introduction

Imagine

that

having

breakfast

is

a

real-time

task

for

an

employee

because

he

wo

n't

wake

up

until

a.m.

each

day

he

has

to

attend

an

important

group

meeting

at

a.m.

and

he

gets

less

than

an

hour

to

drink

some

coffee

and

to

swallow

two

donuts

Here

he

has

to

worry

about

two

things

first

he

should

not

miss

the

meeting

-LRB-

i.e.

he

should

make

sure

that

he

could

finish

the

breakfast

before

a.m.

-RRB-

second

both

coffee

and

donuts

are

fresh

i.e.

the

time

between

the

production

and

the

consumption

of

the

coffee

and

donuts

is

bounded

Furthermore

the

production

processes

for

both

coffee

and

donuts

themselves

have

these

two

concerns

too

first

they

have

to

beat

the

deadline

to

match

the

production

plan

second

they

need

fresh

materials

to

make

fresh

products

We

encounter

a

similar

problem

in

real-time

network

monitoring

-LSB-

-RSB-

In

this

domain

a

network

sensor

is

set

up

to

trace

different

status

variables

of

one

high-speed

network

switch

periodically

for

several

network

controllers

For

example

a

performance

manager

is

interested

in

knowing

whether

the

number

of

rejected

packets

is

crossing

the

pre-set

threshold

or

not

in

every

two

micro-seconds

A

fault

manager

wants

to

know

the

operational

status

every

one

micro-second

Therefore

four

periodic

tasks

are

involved

in

this

real-time

monitoring

system

as

shown

in

figure

Here

the

network

information

sent

to

the

network

managers

is

treated

as

resources

Thus

the

freshness

of

resources

is

important

because

out-of-date

information

is

not

useful

in

monitoring

a

high-speed

network

In

a

more

complicated

network

monitoring

system

as

in

figure

the

decisions

made

by

one

manager

may

also

be

treated

as

information

resources

by

other

managers

We

observe

two

properties

about

resources

for

both

problems

Resources

must

be

available

Resources

must

be

fresh

We

transform

these

two

properties

into

two

optimization

problems

Given

a

set

of

tasks

with

certain

resource

constraints

what

is

the

optimal

schedule

to

achieve

the

highest

processor

utilization

factor

-LSB-

-RSB-

Given

a

set

of

tasks

with

certain

resource

dependency

relations

what

is

the

optimal

schedule

to

achieve

the

best

freshness

for

all

relations

under

the

assumption

that

the

set

of

tasks

is

schedulable

Fault

Manager

Performance

Manager

SensorSensorPerformance

Manager

Period

usec

TaskPeriod

usec

TaskTaskPeriod

usec

TaskPeriod

usec

TaskTaskHigh-Speed

Network

Period

usecPeriod

usec

Figure

A

More

Complex

Network

Monitoring

System

-LRB-

Tasks

-RRB-

These

two

problems

can

not

be

optimized

simultaneously

and

optimizing

one

goal

would

usually

hurt

the

other

For

example

if

the

employee

wants

to

get

the

optimally

fresh

donuts

he

would

wait

in

the

donut

shop

for

about

minutes

for

the

newly

baked

donuts

However

if

the

employee

wants

to

do

a

lot

of

other

things

from

a.m.

to

a.m.

each

day

he

should

buy

the

donuts

the

day

before

and

swallow

two

hard

and

cold

donuts

from

his

own

refrigerator

in

the

morning

Thus

in

this

paper

we

develop

a

class

of

fresh

resource

allocation

policies

that

would

allow

us

to

play

the

trade-off

between

these

two

conflicting

goals

In

the

next

section

we

formally

define

this

real-time

producers/consumers

problem

Then

we

explain

why

the

priority

ceiling

protocol

does

n't

work

in

this

situation

In

the

following

section

this

problem

is

transformed

into

a

minimum

cost

flow

-LRB-

MCF

-RRB-

problem

After

defining

a

resource

balance

condition

we

show

under

that

particular

condition

this

special

MCF

problem

is

feasible

i.e.

there

is

at

least

one

solution

Next

a

class

of

freshness

resource

allocation

policies

associated

with

the

MCF

problem

are

described

Finally

we

show

that

our

result

can

be

used

to

extend

the

priority

ceiling

protocol

-LRB-

PCP

-RRB-

to

work

with

general

unbounded

semaphores

where

W

ait

and

Signal

operations

are

not

in

pairs

in

one

task

The

Real-Time

Producers/Consumers

Problem

In

this

section

we

formally

define

the

problem

as

well

as

a

few

related

concepts

resource

vector

task

occurrence

production/consumption

relations

and

resource

freshness

Tasks

and

Occurrences

A

periodic

task

in

a

real-time

producers/consumers

problem

with

M

types

of

resources

has

the

following

properties

ffl

Every

occurrence

of

the

task

must

be

finished

before

its

deadline

note

that

the

producers/consumers

problem

we

discuss

here

is

different

from

the

one

in

-LSB-

-RSB-

We

address

the

difference

in

section

Type

Resource

Type

Resource

Task

Consumer

Resource

Task

Consumer

Figure

An

Example

of

Real-Time

Producers

and

Consumers

ffl

If

the

task

needs

to

consume

some

resources

to

finish

its

work

it

must

get

the

resources

before

it

can

finish

the

entire

work

ffl

If

the

task

would

produce

some

resources

for

the

system

it

would

produce

them

before

finishing

the

entire

work

ffl

The

resource

buffer

size

is

infinite

and

initially

a

buffer

could

either

be

empty

or

have

a

finite

amount

of

resources

For

example

in

figure

we

have

three

types

of

resource

and

four

periodic

tasks

Task

is

a

producer

of

resource

types

and

while

Task

is

a

consumer

of

resource

types

and

as

well

as

a

producer

of

resource

type

Given

these

three

properties

we

can

formally

define

what

a

periodic

task

is

in

a

producers/consumers

system

Definition

-LRB-

Resource

Vector

RV

-RRB-

In

a

real-time

system

if

there

are

M

distinct

types

of

resource

then

a

resource

vector

RV

-LSB-

RVm

RVM

-RSB-

is

an

M-tuple

vector

where

RVm

is

the

number

of

type

m

resources

in

RV

and

RVm

for

m

M

-LRB-

you

can

not

consume

or

produce

a

negative

amount

of

resources

-RRB-

Definition

-LRB-

Task

oi

-RRB-

In

a

real-time

producers/consumers

system

a

periodic

task

oi

is

characterized

with

the

following

attributes

the

starting

time

of

oi

's

first

occurrence

-LRB-

phase

differences

-RRB-

Ti

the

periodic

cycle

length

of

oi

PRIi

the

priority

of

oi

WCETi

the

worst

case

execution

time

of

oi

Pi

an

RV

for

the

resources

produced

by

oi

Ci

an

RV

for

the

resources

consumed

by

oi

Definition

-LRB-

k-th

occurrence

of

Task

oi

Jki

-RRB-

oi

has

a

sequence

of

occurrences

If

k

is

the

index

of

the

sequence

then

Jki

is

the

k-th

occurrence

of

oi

Furthermore

the

starting

time

of

Jki

tki

-LSB-

-LRB-

k

-RRB-

Ti

-RSB-

For

instance

in

figure

we

have

only

three

different

types

of

resource

which

means

all

the

RV

's

are

vectors

Thus

since

consumes

both

type

and

type

resource

and

only

produces

one

unit

of

type

resource

-LSB-

-RSB-

and

-LSB-

-RSB-

Similarly

we

have

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

and

-LSB-

-RSB-

Production/Consumption

Relations

and

Resource

Freshness

The

key

in

a

producer/consumer

problem

is

the

production/consumption

relations

between

two

tasks

For

example

and

have

such

a

relation

based

on

type

resource

At

the

same

time

and

also

have

the

same

relation

We

describe

these

relations

in

the

following

definition

Definition

-LRB-

Production/Consumption

Relation

ssr

-LRB-

oi

oj

-RRB-

-RRB-

j

r

ssr

-LRB-

oi

oj

-RRB-

-LRB-

-RRB-

-LRB-

Pi

-LSB-

r

-RSB-

-RRB-

-LRB-

Cj

-LSB-

r

-RSB-

-RRB-

where

oi

oj

are

tasks

-LRB-

they

could

be

the

same

task

-RRB-

and

r

is

the

resource

type

Thus

-LRB-

-RRB-

because

-LSB-

-RSB-

but

-LSB-

-RSB-

Similarly

-LRB-

-RRB-

because

-LSB-

-RSB-

and

-LSB-

-RSB-

However

ssr

-LRB-

oi

oj

-RRB-

does

n't

necessarily

imply

that

one

occurrence

Jki

must

consume

the

type

r

resource

produced

by

another

occurrence

J

lj

where

k

and

l

are

occurrence

indices

It

only

implies

the

possibility

that

the

production/consumption

relation

is

positive

For

example

-LRB-

-RRB-

-LRB-

-RRB-

but

the

occurrence

would

consume

the

resource

from

either

J

or

but

not

both

This

nondeterministic

situation

as

we

will

point

out

in

the

next

section

makes

it

hard

for

the

scheduler

to

decide

which

task

should

go

first

Therefore

in

section

we

show

how

to

remove

some

relations

and

make

the

whole

system

deterministic

The

removal

process

is

based

on

a

resource

freshness

property

attached

to

each

ssr

-LRB-

oi

oj

-RRB-

Please

note

that

ssr

-LRB-

oi

oj

-RRB-

states

only

the

resource

dependency

relation

between

oi

and

oj

It

does

not

specify

which

occurrences

of

both

tasks

could

potentially

have

this

relation

and

in

general

this

relation

can

be

applied

to

ANY

two

occurrences

in

oi

and

oj

Definition

-LRB-

Resource

Freshness

of

fssr

-LRB-

oi

oj

-RRB-

Jki

J

lj

g

RF

r

-LRB-

Jki

J

lj

-RRB-

-RRB-

j

k

l

r

ssr

-LRB-

oi

oj

-RRB-

=-RRB-

RF

r

-LRB-

Jki

J

lj

-RRB-

t

-LRB-

r

Jlj

-RRB-

t

-LRB-

Jki

r

-RRB-

where

t

-LRB-

r

Jlj

-RRB-

is

the

time

J

lj

consumes

r

and

t

-LRB-

Jki

r

-RRB-

is

the

time

Jki

produces

r.

Why

does

n't

PCP

Work

The

Priority

Ceiling

Protocol

-LRB-

PCP

-RRB-

was

developed

for

solving

the

reusable

resource

sharing

problem

where

the

total

number

for

any

type

of

resource

existing

in

the

system

is

static

over

time

For

example

if

the

total

number

is

one

then

that

unit

of

resource

must

either

be

free

or

held

by

one

particular

task

and

this

is

true

at

any

time

In

other

words

if

a

task

grabs

certain

units

of

type

m

resource

then

it

must

release

the

same

amount

of

type

m

resource

before

the

end

of

the

task

-LRB-

in

order

to

make

sure

the

static

property

is

true

at

ANY

time

-RRB-

The

original

PCP

-LSB-

-RSB-

was

proposed

for

binary

semaphores

which

implies

the

total

number

for

any

type

of

resource

is

statically

one

Baker

-LSB-

-RSB-

and

Chen

and

Lin

-LSB-

-RSB-

provide

protocols

for

total

numbers

greater

than

one

The

real-time

producers/consumers

problem

defined

in

section

does

not

have

that

static

property

because

a

task

is

not

required

to

produce

the

same

amount

of

resources

it

has

consumed

earlier

Similarly

a

task

does

not

have

to

consume

the

same

type

of

resources

it

produces

It

can

consume

either

NOTHING

or

SOMETHING

ELSE

before

it

produces

a

particular

type

of

resources

The

lack

of

the

static

resource

property

makes

it

difficult

to

use

PCP

to

solve

this

real-time

producers/consumers

scheduling

problem

because

the

priority

inheritance

relationship

is

nondeterministic

For

example

task

oi

with

priority

PRIi

is

blocked

waiting

for

S

type

of

resource

when

both

oj

and

ok

with

priority

PRIj

and

PRIk

respectively

can

produce

S

and

PRIi

PRIj

PRIk

So

should

oj

or

ok

RSTask

jConsumer

QProducer

STask

lConsumer

RProducer

QTask

iConsumer

STask

kProducer

R

S

Consumer

QQInitial

resource

Figure

An

Example

with

Four

Tasks

inherit

the

priority

PRIi

In

-LSB-

-RSB-

it

is

proposed

that

the

higher

priority

task

-LRB-

i.e.

oj

-RRB-

should

inherit

the

priority

successfully

However

this

strategy

would

work

only

when

the

static

resource

property

holds

For

instance

in

figure

oj

would

consume

fQg

and

produce

fSg

while

ok

would

consume

fQg

and

produce

fR

Sg

Now

if

we

assume

that

initially

the

system

has

only

one

unit

of

Q

then

ok

should

inherit

PRIi

Otherwise

ok

and

ol

can

never

be

executed

because

the

only

unit

of

Q

would

have

been

consumed

by

oj

and

neither

oj

nor

oi

produce

Q.

Tranforming

into

a

Minimum

Cost

Flow

Problem

In

order

to

solve

the

real-time

producers/consumers

problem

we

transform

it

into

a

minimum

cost

flow

problem

first

Then

we

develop

solutions

for

that

transformed

problem

In

this

section

we

show

how

to

translate

all

the

task

occurrences

in

one

hyper-cycle

-LRB-

denoted

as

Thyper

-RRB-

into

an

AND/XOR

graph

Then

the

MCF

constraints

about

the

AND/XOR

graph

are

built

Finally

we

prove

that

the

MCF

setting

is

always

feasible

This

implies

all

the

existing

results

about

MCF

can

be

used

to

solve

our

problem

AND/XOR

Graphs

An

AND/XOR

graph

contains

four

types

of

nodes

-LRB-

figure

-RRB-

This

type

of

node

has

m

input

arcs

and

output

arc

The

node

will

output

one

unit

of

resource

to

the

only

output

arc

if

and

only

if

all

the

input

arcs

have

one

unit

coming

in

Otherwise

the

output

flow

is

zero

We

will

use

to

model

the

situation

that

a

task

occurrence

needs

m

units

of

different

types

of

resources

to

generate

unit

of

resource

for

the

system

This

type

of

node

has

input

arc

and

m

output

arcs

The

node

will

output

one

unit

of

resource

to

each

of

the

output

arcs

if

and

only

if

the

only

input

arc

has

one

unit

coming

in

Otherwise

each

of

the

output

flows

are

zero

We

will

use

to

model

the

situation

that

a

task

occurrence

needs

unit

of

resource

to

generate

m

units

of

different

types

of

resources

for

the

system

This

type

of

node

has

m

input

arcs

and

output

arc

The

node

will

output

one

unit

of

resource

to

the

only

output

arc

if

and

only

if

exactly

one

of

the

input

arcs

has

one

unit

coming

in

Otherwise

the

output

flow

is

zero

We

will

use

to

model

the

situation

that

a

task

occurrence

needs

unit

of

one

particular

type

of

resource

while

m

other

different

task

occurrences

can

provide

that

kind

of

resource

to

generate

unit

of

resource

for

the

system

This

type

of

node

has

input

arc

and

m

output

arcs

The

node

will

output

one

unit

of

resource

to

exactly

one

of

its

output

arcs

if

and

only

if

the

only

input

arc

has

one

unit

coming

in

vvvAND

XOR

Figure

Four

types

of

Nodes

in

an

AND/XOR

graph

Otherwise

all

the

output

flows

are

zero

We

will

use

to

model

the

situation

that

a

task

occurrence

needs

unit

of

resource

to

generate

unit

of

one

particular

type

of

resource

while

m

other

different

task

occurrences

would

possibly

need

this

generated

resource

Given

a

set

of

tasks

we

can

use

these

four

types

of

nodes

to

model

all

the

task

occurrences

in

one

hyper-cycle

The

reason

for

modeling

only

one

hyper-cycle

is

that

if

this

hyper-cycle

can

be

scheduled

then

all

the

hyper-cycles

in

the

system

can

be

scheduled

The

AND/XOR

graph

transformation

process

is

described

as

the

following

Algorithm

AND/XOR

Graph

Transformation

INPUT

j

k

r

k

Thyper

Ti

Jki

ssr

-LRB-

oi

oj

-RRB-

OUTPUT

an

AND/XOR

graph

G

-LRB-

V

E

-RRB-

METHOD

-LRB-

Sketched

-RRB-

For

each

task

occurrence

Jki

-LRB-

a

-RRB-

We

create

a

node

where

m

is

the

number

of

non-zero

elements

in

the

Pi

vector

-LRB-

i.e.

m

P

Pi

-LSB-

r

-RSB-

-RRB-

-LRB-

b

-RRB-

Furthermore

we

create

a

node

where

m

is

the

number

of

non-zero

elements

in

Ci

-LRB-

i.e.

m

P

Ci

-LSB-

r

-RSB-

-RRB-

-LRB-

c

-RRB-

The

and

nodes

link

together

using

the

sides

-LRB-

Please

note

that

these

two

nodes

may

have

different

m.

-RRB-

-LRB-

d

-RRB-

Then

for

each

of

the

non-zero

elements

in

Pi

Pi

-LSB-

r

-RSB-

we

create

a

node

with

a

label

r

where

m

P

ssr

-LRB-

oi

oj

-RRB-

Thyper

Tj

-LRB-

e

-RRB-

All

the

nodes

link

to

the

m

side

of

the

node

-LRB-

f

-RRB-

Similarly

for

each

of

the

non-zero

elements

in

Ci

Ci

-LSB-

r

-RSB-

we

create

a

node

with

a

label

r

where

m

P

ssr

-LRB-

oj

oi

-RRB-

Thyper

Tj

-LRB-

g

-RRB-

All

the

nodes

link

to

the

m

side

of

the

node

For

each

pair

of

and

nodes

in

task

occurrences

Jki

and

J

lj

respectively

we

will

put

an

edge

if

and

only

if

-LRB-

a

-RRB-

the

resource

label

of

both

nodes

are

the

same

and

-LRB-

b

-RRB-

assuming

that

the

resource

label

is

r

then

ssr

-LRB-

oi

oj

-RRB-

Example

Consider

the

four

tasks

in

figure

where

we

assume

that

and

Then

since

Thyper

i

and

have

two

occurrences

in

one

hyper-cycle

while

and

have

only

one

Therefore

the

input

set

of

occurrences

is

g

We

get

the

AND/XOR

graph

in

figure

on

we

assume

the

elements

in

any

resource

vector

RV

are

either

or

However

our

result

can

be

easily

extended

to

drop

the

assumption

Resource

Label

Figure

The

AND/XOR

Graph

for

all

the

Occurrences

MCF

Problem

Setting

The

minimum

cost

flow

problem

-LSB-

-RSB-

is

to

find

a

set

of

arc

flows

that

would

optimize

a

linear

cost

function

under

two

types

of

constraints

simultaneously

ffl

The

conservation

of

flow

constraints

for

one

particular

node

the

difference

between

the

input

and

output

flow

is

fixed

ffl

The

capacity

constraints

for

one

particular

edge

the

flow

put

on

that

edge

is

bounded

Definition

-LRB-

Minimum

Cost

Flow

Problem

-RRB-

minimized

P

-LRB-

i

j

-RRB-

aijxij

subject

to

X

fjj

-LRB-

i

j

-RRB-

xij

X

fjj

-LRB-

j

i

-RRB-

xji

si

V

bij

xij

cij

-LRB-

i

j

-RRB-

E

where

aij

bij

cij

and

si

are

given

scalars

Our

plan

is

to

build

an

MCF

problem

on

the

AND/XOR

graph

we

get

in

the

previous

section

The

modeling

is

done

the

following

way

j

bij

cij

If

a

node

i

is

then

si

-LRB-

m

-RRB-

If

a

node

i

is

then

si

-LRB-

m

-RRB-

If

a

node

i

is

either

or

then

si

The

first

item

in

our

modeling

restricts

the

flow

on

each

edge

between

and

However

in

the

AND/XOR

graph

since

all

the

inputs

are

integers

the

optimal

feasible

solution

would

contain

only

integers

Therefore

the

values

of

all

the

xij

's

are

either

or

The

rest

of

the

items

in

the

modeling

follow

the

definitions

of

an

AND/XOR

graph

For

example

for

a

node

there

are

m

input

arcs

and

output

arc

Since

this

node

must

be

executed

we

need

all

the

input

arcs

to

have

a

flow

with

one

unit

of

resource

i.e.

the

in-flow

is

m

and

the

out-flow

is

Thus

the

flow

difference

is

m

as

described

in

item

above

The

intuition

for

xij

in

the

real-time

producers/consumers

problem

is

whether

job

i

is

the

producer

of

job

j

If

xij

then

the

answer

is

yes

And

the

constraints

in

the

MCF

setting

guarantee

that

all

the

resource

dependency

relations

are

deterministic

i.e.

one

producer

matches

one

consumer

Furthermore

if

xij

xjk

we

call

job

i

is

the

transitive

producer

of

job

k.

Definition

-LRB-

Transitive

Producer

x

ik

-RRB-

Job

i

is

the

transitive

producer

of

job

k

i.e.

x

ik

if

and

only

if

xik

or

-LRB-

x

ij

-RRB-

-LRB-

x

jk

-RRB-

Resource

Balance

We

have

shown

how

to

translate

a

set

of

real-time

tasks

into

an

AND/XOR

graph

as

well

as

how

to

model

an

MCF

problem

on

that

particular

graph

Before

considering

the

linear

cost

function

we

check

whether

this

MCF

problem

is

feasible

In

this

subsection

we

introduce

a

sufficient

condition

for

the

MCF

's

feasibility

Definition

-LRB-

Type

r

Resource

Balance

Condition

-RRB-

A

set

of

tasks

T

ong

is

type

r

resource

balanced

if

and

only

if

P

-LRB-

Thyper

Ti

-LRB-

Pi

-LSB-

r

-RSB-

Ci

-LSB-

r

-RSB-

-RRB-

-RRB-

Definition

-LRB-

Global

Resource

Balance

Condition

-RRB-

T

is

globally

resource

balanced

if

and

only

if

T

is

type

r

resource

balanced

The

type

r

resource

balance

condition

states

that

if

we

have

k

units

of

type

r

resource

then

after

one

hyper-cycle

we

still

have

k

units

Furthermore

if

for

all

types

of

resource

we

have

this

property

we

get

the

global

resource

balance

condition

In

the

following

theorem

we

show

that

this

strong

condition

is

sufficient

for

the

MCF

's

feasibility

Theorem

-LRB-

Feasibility

of

MCF

-LRB-

T

-RRB-

-RRB-

T

is

globally

resource

balanced

=-RRB-

MCF

-LRB-

T

-RRB-

is

feasible

proof

A

node

is

marginal

if

m

Intuitively

a

task

oi

T

has

one

marginal

node

if

and

only

if

oi

consumes

nothing

Similarly

a

is

marginal

if

m

The

intuition

is

if

oi

has

one

such

node

then

oi

produces

nothing

Furthermore

one

task

must

have

either

exactly

one

marginal

node

exactly

one

marginal

node

or

no

marginal

nodes

The

marginal

nodes

are

all

feasible

because

they

are

independent

from

all

other

nodes

The

marginal

nodes

are

feasible

if

all

the

nodes

are

feasible

In

algorithm

we

know

that

if

the

outputs

of

nodes

are

all

then

the

inputs

as

well

as

the

outputs

of

all

the

non-marginal

nodes

are

also

In

steps

and

of

algorithm

we

further

know

that

the

following

statements

are

also

true

ffl

the

inputs

and

outputs

of

all

the

non-marginal

nodes

are

ffl

the

inputs

of

all

the

nodes

are

Now

we

only

need

to

prove

the

following

two

statements

to

prove

the

feasibility

of

MCF

-LRB-

T

-RRB-

ffl

exactly

one

input

arc

of

any

node

is

ffl

exactly

one

output

arc

of

any

node

is

Please

note

in

steps

and

of

algorithm

both

and

nodes

have

a

resource

label

Therefore

we

can

partition

the

nodes

into

M

classes

where

M

is

the

number

of

total

resource

types

Then

for

each

resource

type

r

because

of

the

type

r

resource

balance

condition

we

know

that

the

number

of

r-labeled

nodes

is

equal

to

the

number

of

r-labeled

nodes

Furthermore

by

steps

and

of

algorithm

from

every

node

there

are

edges

to

all

the

nodes

i.e.

we

have

a

clique

of

size

m.

Thus

this

subproblem

becomes

a

feasible

assignment

problem

Since

the

global

balance

condition

implies

the

type

r

resource

balance

condition

the

above

two

statements

are

true

For

example

in

figure

the

set

of

tasks

represented

by

the

AND/XOR

graph

is

globally

resource

balanced

We

can

easily

check

the

following

individual

type

resource

balance

conditions

Occurrence

Number

Thyper

Thyper

Thyper

Thyper

Type

Resource

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

=-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

Type

Resource

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

=-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

Type

Resource

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

=-RRB-

-LRB-

-RRB-

Since

all

three

individual

resource

balance

conditions

are

true

the

set

of

tasks

is

globally

balanced

Furthermore

one

possible

feasible

solution

of

figure

is

shown

in

figure

However

we

do

not

know

whether

this

solution

is

optimal

unless

we

know

the

values

of

the

aij

's

In

practice

we

can

make

the

MCF

still

feasible

even

if

the

resource

balance

condition

does

not

hold

However

this

requires

that

the

production

rate

is

higher

than

the

consumption

rate

The

trick

is

to

insert

some

pseudo

consumers

into

the

system

and

make

the

whole

system

balanced

Then

when

we

define

the

value

aij

's

we

can

put

uniformally

on

those

edges

connecting

these

pseudo

consumers

Fresh

Resource

Allocation

Policies

or

Playing

aij

We

have

just

shown

a

feasible

MCF

setting

for

the

real-time

producers/consumers

problem

The

major

purpose

of

this

setting

is

to

remove

the

nondeterministic

resource

dependency

relations

from

the

AND/XOR

graph

-LRB-

i.e.

from

figure

to

figure

-RRB-

After

having

such

deterministic

relations

the

scheduler

can

decide

the

priorities

among

real-time

periodic

tasks

In

this

section

we

develop

two

resource

allocation

policies

based

on

the

MCF

setting

The

first

policy

pessimistically

assumes

the

scheduler

is

vicious

and

therefore

we

can

not

rely

on

the

scheduler

to

achieve

anything

In

other

words

we

play

a

non-cooperative

game

with

the

scheduler

to

optimize

our

own

interest

resource

freshness

The

second

policy

optimistically

assumes

a

cooperative

scheduler

would

help

in

achieving

optimal

resource

selectedselected

Figure

One

Possible

Feasible

Solution

freshness

Thus

in

order

to

make

the

consumed

resources

as

fresh

as

possible

this

policy

would

minimize

the

time

period

between

the

producer

's

starting

time

and

the

consumer

's

ending

time

For

both

policies

discussed

here

we

assume

that

is

known

OFUOS

Optimized

Freshness

Under

Optimal

Schedulability

Consider

two

job

occurrences

Jki

and

J

lj

where

ssr

-LRB-

oi

oj

-RRB-

In

Algorithm

there

is

an

edge

between

these

two

occurrences

because

oj

needs

to

consume

r

and

oi

can

produce

r.

Furthermore

the

edge

connects

one

node

and

one

node

with

the

resource

label

r.

Now

let

's

consider

how

to

assign

the

value

for

aJki

Jlj

in

the

following

cases

ffl

If

the

earliest

possible

time

for

J

lj

to

consume

r

i.e.

-LRB-

l

-RRB-

Tj

is

later

than

the

latest

possible

time

for

Jki

to

produce

r

i.e.

k

Ti

then

it

is

obvious

that

the

r

generated

by

Jki

can

be

consumed

by

J

lj

Since

we

assume

that

the

scheduler

is

vicious

the

worst

case

freshness

of

this

particluar

r

is

the

time

between

the

earliest

possible

time

for

Jki

to

produce

r

i.e.

-LRB-

k

-RRB-

Ti

and

the

latest

possible

time

for

J

lj

to

consume

r

i.e.

l

Tj

Therefore

in

this

case

aJki

Jlj

the

freshness

of

r

-LRB-

l

Tj

-RRB-

-LSB-

-LRB-

k

-RRB-

Ti

-RSB-

ffl

If

-LRB-

-LRB-

l

-RRB-

Tj

-RRB-

is

earlier

than

-LRB-

k

Ti

-RRB-

then

the

r

generated

by

Jki

might

not

be

able

to

be

consumed

by

J

lj

Remember

we

assume

that

the

scheduler

is

vicious

and

it

could

schedule

these

two

occurrences

in

this

worst

case

Furthermore

we

can

not

ask

J

lj

to

wait

for

Jki

because

we

do

n't

want

to

rely

on

the

scheduler

at

all

It

turns

out

that

J

lj

may

consume

one

of

the

r

's

generated

by

Jki

in

previous

hyper-cycles

i.e.

J

-LRB-

k?n?Thyper

Ti

-RRB-

i

where

n

is

the

number

of

hyper-cycles

that

we

need

to

roll-back

in

order

to

make

-LRB-

-LRB-

l

-RRB-

Tj

-RRB-

-LSB-

k

-LRB-

n

Thyper

Ti

-RRB-

-RSB-

Tig

Similarly

the

worst

case

freshness

in

this

case

would

be

aJki

Jlj

-LRB-

l

Tj

-RRB-

-LSB-

k

-LRB-

n

Thyper

Ti

-RRB-

-RSB-

Tig

order

to

have

a

simple

design

for

the

scheduler

we

make

sure

that

the

producer

's

starting

time

must

be

earlier

than

the

consumer

's

starting

time

-LRB-

i

-RRB-

kiJJljHyper-CycleFreshness

-LRB-

ii

-RRB-

JljkiJHyper-CycleFreshness

The

same

occurrence

in

previous

hyper-cycle

Figure

Two

Cases

in

OFUOS

We

summarize

these

two

cases

-LRB-

figure

-RRB-

in

the

following

policy

Policy

-LRB-

Optimized

Freshness

Under

Optimal

Schedulability

OFUOS

-RRB-

j

k

l

aJki

Jlj

-LRB-

l

Tj

-RRB-

-LSB-

k

-LRB-

NJki

Jlj

Thyper

Ti

-RRB-

-RSB-

Tig

where

NJki

Jlj

minfn

j

-LRB-

n

-RRB-

-LSB-

-LRB-

-LRB-

l

-RRB-

Tj

-RSB-

-LSB-

-LRB-

k

-LRB-

n

Thyper

Ti

-RRB-

-RRB-

Ti

-RRB-

-RSB-

g

Example

Consider

three

tasks

and

and

produce

one

unit

of

r

in

each

of

their

occurrences

while

consumes

one

unit

of

r

periodically

Assume

that

and

Since

Thyper

in

one

hyper-cycle

has

one

occurrence

has

two

occurrences

and

and

has

three

occurrences

and

So

we

totally

have

occurrences

and

the

corresponding

AND/XOR

graph

is

depicted

in

figure

Let

's

calculate

two

aij

's

with

OFUOS

Since

produces

r

before

time

and

consumes

r

as

early

as

time

too

Therefore

-LRB-

-RRB-

-LRB-

-LRB-

-RRB-

-RRB-

This

implies

that

if

we

let

consume

the

r

produced

by

the

worst

case

freshness

is

Intuitively

the

answer

is

correct

as

shown

in

figure

because

may

produce

r

at

the

very

beginning

while

potentially

might

consume

that

resource

at

the

end

of

's

cycle

Thus

the

time

difference

is

Since

produces

r

before

time

and

consumes

r

as

early

as

time

too

is

Therefore

-LRB-

-RRB-

-LRB-

-LRB-

-RRB-

-RRB-

-LRB-

-RRB-

This

implies

that

if

we

let

consume

the

r

produced

by

the

worst

case

freshness

is

In

figure

it

is

not

always

possible

that

can

consume

the

r

produced

by

because

of

the

vicious

scheduler

Therefore

for

safety

has

to

consume

r

produced

by

in

the

previous

hyper-cycle

Under

the

worst

case

the

time

difference

between

the

production

and

consumption

is

After

calculating

all

the

aij

's

and

running

an

MCF

algorithm

we

get

the

optimal

solution

as

in

figure

r

r

r

Figure

The

AND/XOR

Graph

in

the

Second

Example

Hyper

Hyper

Cycle

a

token

at

time

-LRB-

-RRB-

consumes

that

token

at

time

-LRB-

-RRB-

produces

a

token

at

time

consume

that

token

at

time

-LRB-

-RRB-

Figure

The

Timing

Diagram

for

the

Second

Example

Figure

The

Solution

under

OFUOS

OWCF

Optimal

Worst-Case

Freshness

If

one

unit

of

resource

r

is

consumed

immediately

after

its

production

then

r

is

optimally

fresh

In

reality

such

freshness

is

hard

to

achieve

because

ffl

the

scheduler

does

n't

know

exactly

when

the

resource

will

be

produced

and

when

the

consumer

will

be

ready

to

consume

that

resource

-LRB-

it

only

knows

the

earliest

and

latest

possible

time

epochs

-RRB-

ffl

if

A

depends

on

B

and

B

depends

on

C

sometimes

it

is

impossible

to

schedule

these

three

jobs

at

the

same

time

Alternatively

let

's

consider

the

time

interval

between

the

producer

's

starting

and

the

consumer

's

ending

This

interval

represents

the

worst

case

freshness

for

one

resource-dependency

relation

because

ffl

the

resource

can

not

be

produced

before

the

starting

time

of

the

producer

and

ffl

the

resource

can

not

be

consumed

after

the

ending

time

of

the

consumer

Policy

-LRB-

Optimal

Worst

Case

Freshness

OWCF

-RRB-

j

k

l

aJki

Jlj

-LRB-

l

Tj

-RRB-

-LSB-

k

-LRB-

NJki

Jlj

Thyper

Ti

-RRB-

-RSB-

Tig

where

NJki

Jlj

minfn

j

-LRB-

n

-RRB-

-LSB-

-LRB-

-LRB-

l

-RRB-

Tj

-RSB-

-LSB-

-LRB-

k

-LRB-

n

Thyper

Ti

-RRB-

-RRB-

Ti

-RRB-

-RSB-

g

Please

note

that

Policy

OWCF

is

the

same

as

Policy

OFUOS

except

its

definition

of

NJki

Jlj

The

right

hand

side

of

the

inequality

in

OWCF

's

NJki

Jlj

has

a

while

the

one

in

OFUOS

does

not

The

reason

for

this

difference

is

that

OFUOS

does

not

allow

the

consumer

to

start

before

its

producer

finishes

Example

Let

's

try

the

three

tasks

and

in

Example

The

AND/XOR

graph

is

still

the

same

one

in

figure

Let

's

calculate

two

aij

's

with

OWCF

In

figure

since

the

starting

time

of

is

earlier

than

the

starting

time

of

Thus

by

OWCF

-LRB-

-RRB-

-LRB-

-LRB-

-RRB-

-RRB-

This

answer

is

exactly

the

same

as

in

OFUOS

because

and

do

n't

overlap

Since

starts

earlier

than

consumes

r

as

early

as

time

too

is

still

Therefore

-LRB-

-RRB-

-LRB-

-LRB-

-RRB-

-RRB-

-LRB-

-RRB-

This

implies

that

if

we

let

consume

the

r

produced

by

the

worst

case

freshness

is

However

the

scheduler

has

to

cooperate

to

achieve

this

bound

because

it

has

to

let

go

first

then

let

consume

that

unit

of

fresh

resource

After

calculating

all

the

aij

's

and

running

an

MCF

algorithm

we

get

one

optimal

solution

shown

in

figure

r

r

r

In

this

example

the

optimal

solution

is

not

unique

Figure

The

Solution

under

OWCF

Extending

the

Priority

Ceiling

Protocol

In

previous

sections

an

MCF

setting

is

presented

with

two

different

fresh

resource

allocation

policies

In

this

section

we

show

how

to

apply

this

MCF

setting

to

extend

the

priority

ceiling

protocol

to

work

with

general

unbounded

semaphores

From

now

on

in

order

to

avoid

confusion

between

binary

semaphores

and

general

unbounded

semaphores

we

use

the

word

semaphore

for

binary

semaphores

and

the

word

resource

for

general

unbounded

semaphores

PCP/OFUOS

Since

the

OFUOS

is

independent

of

what

scheduling

policy

we

pick

it

can

work

with

the

orginal

PCP

except

we

need

to

put

a

certain

amount

of

resources

into

the

system

at

the

initialization

phase

The

reason

for

these

initial

resources

is

that

some

of

the

production/consumption

relations

selected

by

the

MCF

setting

require

the

producer

and

the

consumer

to

be

in

two

different

hyper-cycles

-LRB-

as

shown

in

figure

-RRB-

This

implies

that

the

consumer

in

the

first

hyper-cycle

would

not

get

the

resource

because

no

previous

hyper-cycle

exists

Therefore

the

system

has

to

put

some

amount

of

initial

resources

to

solve

this

problem

Let

's

intuitively

introduce

this

problem

in

the

following

example

Example

Consider

the

three

tasks

and

in

Example

The

AND/XOR

graph

is

still

the

same

one

as

in

figure

and

using

policy

OFUOS

the

optimal

solution

is

depicted

in

figure

Since

only

one

type

of

resource

is

in

the

system

we

consider

how

many

units

of

type

r

resources

do

we

need

to

put

into

the

resource

buffer

INITIALLY

Let

's

consider

the

first

hyper-cycle

of

ffl

needs

the

resource

from

in

the

previous

hyper-cycle

So

for

we

should

definitely

put

one

unit

of

r

into

the

buffer

initially

This

one

is

equal

to

the

in

OFUOS

because

means

that

has

to

consume

the

resource

from

in

the

previous

hyper-cycle

However

the

in

the

first

hyper-cycle

can

not

depend

on

anybody

Therefore

we

need

to

put

one

unit

of

r

initially

ffl

needs

the

resource

from

in

the

same

hyper-cycle

Therefore

zero

units

of

resource

is

needed

initially

for

-LRB-

-RRB-

general

unbounded

semaphore

is

a

semaphore

with

an

infinite

buffer

The

operation

Signal

-LRB-

-RRB-

can

be

treated

as

a

produce

action

while

W

ait

-LRB-

-RRB-

is

a

consume

action

In

this

paper

these

two

operations

need

not

be

paired

in

one

task

However

we

assume

that

all

the

binary

semaphores

are

used

as

critical

sections

ffl

needs

the

resource

from

also

in

the

same

hyper-cycle

Similarly

zero

units

of

resource

is

needed

initially

for

-LRB-

-RRB-

Since

in

any

one

hyper-cycle

do

not

need

resource

r

and

need

one

unit

of

r

we

have

IrOFUOS

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

Totally

one

unit

of

r

is

needed

initially

Formally

the

number

of

initial

resources

for

a

set

of

tasks

is

computed

by

the

following

lemma

Lemma

-LRB-

Initial

Resources

IrOFUOS

-RRB-

The

initial

number

of

type

r

resources

IrOFUOS

X

f

X

-LSB-

xJki

Jlj

NJki

Jlj

ssr

-LRB-

oi

oj

-RRB-

-RSB-

g

where

V

is

the

AND/XOR

graph

constructed

by

Algorithm

xJki

Jlj

's

are

the

results

from

the

MCF

setting

under

OFUOS

and

NJki

Jlj

's

are

defined

in

OFUOS

proof

The

equation

for

IrOFUOS

is

the

summation

of

all

the

directed

arcs

in

V

First

the

term

xJki

Jlj

is

to

decide

whether

that

particular

arc

is

in

the

MCF

optimal

solution

Second

the

term

NJki

Jlj

is

to

compute

the

hyper-cycle

difference

for

one

pair

of

job

occurrences

-LRB-

Jki

J

lj

-RRB-

Third

the

term

ssr

-LRB-

oi

oj

-RRB-

is

to

select

all

the

arcs

with

resource

label

r

because

arcs

without

label

r

have

ssr

-LRB-

oi

oj

-RRB-

PCP/OWCF

Two

key

concepts

in

the

priority

ceiling

protocol

are

priority

inheritance

and

priority

ceiling

The

purpose

of

priority

inheritance

among

jobs

is

to

avoid

the

priority

inversion

problem

And

the

priority

ceiling

of

binary

semaphores

is

defined

to

prevent

deadlocks

as

well

as

to

reduce

the

blocking

time

due

to

lower

priority

jobs

In

this

subsection

both

concepts

are

extended

for

OWCF

Furthermore

the

schedulability

analysis

is

done

for

this

extended

PCP

Extended

Priority

Inheritance

In

PCP

a

job

Jki

inherits

the

priority

Pj

where

Pj

Pi

if

and

only

if

Jki

is

holding

one

binary

semaphore

and

there

exists

an

active

job

J

lj

which

needs

This

inheritance

makes

no

jobs

with

priorities

between

Pi

and

Pj

preempt

Jki

and

thus

indirectly

preempt

J

lj

We

have

also

inheritance

relations

among

jobs

through

general

unbounded

semaphores

After

computing

the

resource

dependency

relations

on

the

AND/XOR

graph

we

can

determine

that

J

lj

would

consume

the

resource

from

Jki

transitively

if

x

Jki

Jlj

Therefore

in

this

case

Jki

should

inherit

the

priority

from

J

lj

after

J

lj

starts

i.e.

after

-LRB-

l

-RRB-

Tj

Definition

-LRB-

Extended

Inherited-Priority

for

Jki

-RRB-

i

j

k

l

EIP

ki

max

ae

IPi

max

j

i

ae

Pj

-LRB-

x

Jki

Jlj

-RRB-

-LSB-

tcurrent

-LRB-

-LRB-

l

-RRB-

Tj

-RRB-

-RSB-

oeoe

where

IPi

is

the

inherited

priority

of

Jki

through

binary

semaphores

The

Definition

implies

that

a

job

Jki

inherits

a

higher

priority

through

a

transitive

production/consumption

relation

from

J

lj

if

and

only

if

Jki

and

J

lj

would

overlap

The

reason

is

that

if

these

two

jobs

do

not

overlap

then

Jki

's

deadline

is

earlier

than

the

starting

time

of

J

lj

Thus

in

this

case

-LRB-

the

same

as

OFUOS

-RRB-

Jki

will

not

block

J

lj

as

long

as

it

does

not

miss

its

deadline

However

if

they

overlap

we

call

Jki

an

overlap

transitive

producer

of

J

lj

The

following

lemma

computes

the

overlap

time

period

for

any

two

jobs

Lemma

-LRB-

Overlap

between

Jki

and

J

lj

-RRB-

Given

two

jobs

Jki

and

J

lj

the

overlap

time

period

betweem

them

OL

-LRB-

Jki

J

lj

-RRB-

is

equal

to

fTj

-LSB-

-LRB-

-LRB-

k

-RRB-

Ti

-RRB-

-LRB-

-LRB-

l

-RRB-

Tj

-RRB-

-RSB-

-LSB-

-LRB-

l

Tj

-RRB-

-LRB-

k

Ti

-RRB-

-RSB-

g

where

-LRB-

-RRB-

-LRB-

if

otherwise

If

OL

-LRB-

Jki

J

lj

-RRB-

then

Jki

and

J

lj

do

not

overlap

Extended

Priority

Ceiling

In

PCP

the

priority

ceiling

-LRB-

PC

-RRB-

attached

to

one

binary

semaphore

is

the

highest

priority

among

the

set

of

tasks

that

would

need

With

priority

ceilings

two

nice

properties

about

PCP

are

retained

deadlock

free

and

one

longest

block

only

After

introducing

general

unbounded

semaphores

with

extended

priority

inheritance

-LRB-

Definition

-RRB-

and

priority

ceilings

the

first

property

is

still

true

but

the

second

one

no

longer

holds

-LRB-

Please

note

that

a

high

priority

consumer

waiting

for

a

low

priority

producer

is

not

considered

as

blocking

because

there

is

no

way

to

avoid

this

waiting

time

-RRB-

Example

Five

tasks

Ja

Jb

Jc

Jd

and

Je

with

Pa

Pb

Pc

Pd

Pe

Assume

Jb

and

Jd

share

a

binary

semaphore

while

Jc

and

Je

share

another

binary

semaphore

Also

Ja

is

a

consumer

of

one

unit

of

and

one

unit

of

where

Jd

is

the

producer

of

and

Je

is

the

producer

of

By

the

definition

of

priority

ceiling

in

-LSB-

-RSB-

PC

-LRB-

-RRB-

Pb

and

PC

-LRB-

-RRB-

Pc

because

Jb

and

Jc

are

the

highest

priority

jobs

that

would

access

and

respectively

Now

Jc

starts

at

time

and

gets

and

at

time

Jb

gets

and

preempts

Jc

because

Pb

Pc

PC

-LRB-

-RRB-

Then

Ja

Jd

and

Je

start

at

time

and

Jd

preempts

Jb

because

by

Definition

EP

I

-LRB-

Jd

-RRB-

Ja

However

at

time

Jd

is

blocked

by

Jb

because

of

Then

Jb

resumes

and

finishes

and

Jd

finishes

at

time

Now

Je

resumes

and

at

time

it

is

blocked

by

Jc

because

of

Finally

after

both

Jc

and

Je

finish

Ja

finishes

at

time

We

can

see

that

Ja

could

possibly

be

blocked

by

two

lower

priority

jobs

that

are

not

its

producers

In

the

worst

case

the

number

of

blockings

is

proportional

to

the

number

of

low

priority

transitive

producers

a

job

has

The

time

diagram

is

shown

in

figure

In

order

to

reduce

the

blocking

time

due

to

lower

priority

jobs

we

define

an

extended

priority

ceiling

-LRB-

EPC

-RRB-

for

all

the

binary

semaphores

The

extended

priority

ceiling

of

for

example

would

consider

not

only

all

the

tasks

that

would

share

but

also

all

the

tasks

with

lower

priority

transitive

producers

that

would

share

Also

we

only

consider

those

transitive

producers

that

would

overlap

with

the

high

priority

consumer

In

Example

the

EPC

of

is

Pa

not

Pb

because

Ja

's

producer

Jd

would

share

Similarly

the

EPC

of

is

Pa

but

not

Pc

Now

with

EPC

only

Jc

can

indirectly

block

Ja

because

at

time

when

Jb

tries

to

get

Jb

can

not

be

granted

-LRB-

EPC

-LRB-

-RRB-

Pa

Pb

-RRB-

Definition

-LRB-

Extended

Priority

Ceiling

for

-RRB-

p

EPC

-LRB-

-RRB-

max

fPC

-LRB-

-RRB-

max

j

fPj

k

l

-LRB-

x

Jki

Jlj

-RRB-

-LRB-

OL

-LRB-

Jki

J

lj

-RRB-

-RRB-

-LRB-

oi

-RRB-

gg

where

PC

-LRB-

-RRB-

is

the

priority

ceiling

of

and

-LRB-

oi

-RRB-

means

that

oi

needs

by

by

Blocked

byIndirectly

Blocked

by

Figure

Sequence

of

Events

in

the

example

The

Properties

of

PCP/OWCF

As

we

mentioned

before

two

nice

properties

about

PCP

are

deadlock

free

and

one

longest

block

only

i.e.

Theorem

and

in

-LSB-

-RSB-

We

now

show

these

two

properties

still

hold

for

PCP/OWCF

Lemma

-LRB-

Transitive

Blocking

-RRB-

PCP/OWCF

prevents

transitive

blocking

proof

Suppose

that

transitive

blocking

is

possible

Let

Ja

block

Jb

and

let

Jb

block

Jc

and

Pa

Pb

Pc

Ja

blocks

Jb

first

In

this

case

by

Definition

EPC

-LRB-

-RRB-

Pb

Thus

later

Jb

can

not

lock

anything

unless

Ja

releases

We

reach

a

contradiction

Jb

blocks

Jc

first

It

is

clear

that

Ja

can

not

lock

anything

later

because

Jb

has

locked

and

EPC

-LRB-

-RRB-

Pc

We

also

reach

a

contradiction

Theorem

-LRB-

Deadlock

Free

-RRB-

PCP/OWCF

is

deadlock

free

proof

We

consider

three

cases

deadlocks

among

general

unbounded

semaphores

among

binary

semaphores

and

between

general

and

binary

semaphores

General

unbounded

semaphores

Since

the

OWCF

policy

forces

the

producer

to

start

earlier

than

the

consumer

the

resource

dependency

relations

always

go

forward

in

the

time

diagram

Therefore

it

is

impossible

to

form

a

deadlock

Binary

semaphores

First

we

assume

a

job

can

not

deadlock

with

itself

By

Lemma

the

number

of

jobs

in

a

blocking

cycle

must

be

two

and

we

call

them

Ja

and

Jb

In

order

to

make

a

deadlock

both

Ja

and

Jb

need

at

least

two

binary

semaphores

and

respectively

This

implies

both

the

priority

ceilings

are

equal

to

or

higher

than

Pa

-LRB-

Pa

Pb

-RRB-

Thus

after

one

of

the

binary

semaphore

e.g.

is

locked

it

is

impossible

for

Jb

to

lock

Binary

and

general

unbounded

semaphores

The

consumer

locks

first

and

the

producer

needs

later

to

provide

the

resource

However

this

is

impossible

with

OWCF

which

forces

the

producer

to

start

earlier

Thus

the

producer

inherits

the

consumer

's

priority

and

the

consumer

can

not

run

until

the

producer

finishes

Theorem

-LRB-

Blocking

in

PCP/OWCF

-RRB-

If

a

job

Jki

has

m

transitive

producers

that

would

overlap

with

Jki

Jki

can

be

blocked

for

the

production

time

of

those

m

resources

plus

at

most

the

duration

of

one

critical

section

in

any

other

jobs

with

priorities

lower

that

Pi

proof

It

is

obvious

that

Jki

has

to

wait

until

the

m

units

of

resources

are

produced

The

only

thing

left

to

prove

is

that

Jki

and

its

overlap

transitive

producers

would

together

be

blocked

at

most

once

by

other

lower

priority

jobs

Assume

that

Jki

would

be

blocked

by

both

Ja

and

Jb

through

and

respectively

Case

I

Assume

that

both

and

are

needed

by

either

Jki

or

one

producer

By

Definition

both

EPC

-LRB-

-RRB-

and

EPC

-LRB-

-RRB-

is

greater

than

or

equal

to

Pi

If

Ja

locks

earlier

than

Jb

locks

then

Jb

can

not

lock

because

Pb

Pi

EPC

-LRB-

-RRB-

Similarly

if

Jb

goes

first

Ja

can

not

lock

Thus

we

have

a

contradiction

Case

II

Assume

that

is

needed

by

one

transitive

producer

Jp

of

J

-LRB-

k

ffl

-RRB-

i

where

ffl

In

other

words

Jp

produces

one

unit

of

resource

for

another

job

occurrence

of

oi

transitively

but

not

Jki

Now

if

is

held

by

Ja

then

Jb

can

not

get

Furthermore

even

after

Ja

releases

Jp

can

not

get

to

block

Jki

because

Jp

can

not

inherit

Pi

at

that

moment

by

Definition

This

is

also

a

contradiction

Schedulability

for

PCP/OWCF

In

this

section

we

construct

two

theorems

for

the

schedulability

for

PCP/OWCF

These

two

theorems

and

the

scheduability

theorems

in

-LSB-

-RSB-

are

analogous

However

there

is

a

difference

in

defining

Bi

the

duration

of

the

worst

case

blocking

time

of

a

job

occurrence

in

task

oi

In

PCP

Bi

only

concerns

the

binary

semaphores

needed

by

oi

and

all

the

tasks

with

priority

higher

than

Pi

With

PCP/OWCF

it

is

necessary

to

consider

also

the

binary

semaphores

needed

by

all

the

producers

that

would

have

inherited

priority

higher

than

Pi

Thus

we

define

the

binary

semaphores

needed

by

oi

as

all

the

binary

semaphores

in

oi

as

well

as

all

the

overlap

transtive

producers

Definition

-LRB-

Bi

with

PCP/OWCF

-RRB-

Bi

Pj

Pj

PkfTimeInterval

-LRB-

j

k

-RRB-

gg

where

j

k

is

the

longest

critical

section

where

ok

can

block

either

oj

or

one

of

its

overlap

transitive

producers

Another

concern

in

PCP/OWCF

is

the

time

spent

by

a

consumer

task

waiting

on

its

producers

In

OWCF

we

assume

that

the

starting

time

of

a

producer

must

be

earlier

than

the

starting

time

of

its

consumer

If

the

producer

and

the

consumer

do

overlap

then

in

the

worst

case

we

have

to

schedule

both

of

them

after

the

starting

time

of

the

consumer

-LRB-

Please

note

if

they

do

not

overlap

then

there

is

no

waiting

time

caused

by

this

producer

-RRB-

Thus

we

can

define

the

producer

blocking

time

for

a

consumer

as

the

sum

of

the

WCET

's

-LRB-

worst

case

execution

time

-RRB-

for

all

the

producers

that

have

lower

priorities

and

do

overlap

with

the

consumer

PCP/OFUOS

a

task

would

never

have

to

wait

for

the

completion

of

its

producers

Definition

-LRB-

Producer

Blocking

Time

for

oi

PTi

-RRB-

PTi

max

k

Thyper

Ti

X

j

CETj

-LRB-

Pj

Pi

-RRB-

Thyper

Tj

X

l

-LRB-

x

Jlj

Jki

-LRB-

OL

-LRB-

J

lj

Jki

-RRB-

-RRB-

-RRB-

where

-LRB-

-RRB-

-LRB-

if

is

TRUE

otherwise

Theorem

-LRB-

A

Sufficient

Condition

for

Schedulability

with

PCP/OWCF

-RRB-

Using

PCP/OWCF

a

set

of

n

periodic

tasks

can

be

scheduled

by

the

rate

monotonic

algorithm

-LSB-

-RSB-

if

the

following

conditions

are

satisfied

i

n

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

WCETi

PTi

-RRB-

Ti

Bi

Ti

i

-LRB-

-RRB-

where

PTi

is

the

production

time

of

resources

for

oi

and

Bi

is

the

worst

case

blocking

time

for

oi

The

proof

is

similar

to

Theorem

in

-LSB-

-RSB-

except

we

treat

WCET

i

-LRB-

WCETi

PTi

Bi

-RRB-

-LRB-

they

treated

WCET

i

-LRB-

WCETi

Bi

-RRB-

and

their

definition

of

Bi

is

different

from

ours

as

indicated

in

Definition

-RRB-

Theorem

-LRB-

Exact

Characterization

for

Schedulability

with

PCP/OWCF

-RRB-

Using

PCP/OWCF

a

set

of

n

periodic

tasks

can

be

scheduled

by

the

rate

monotonic

algorithm

if

the

following

conditions

are

satisfied

i

n

min

-LRB-

k

l

-RRB-

i

X

j

Uj

Tj

lTk

lTk

Tj

ss

-LRB-

WCETi

PTi

-RRB-

lTk

Bi

lTk

where

Ri

n

-LRB-

k

l

-RRB-

k

i

l

j

TiTk

ko

and

Uj

is

the

utilization

of

oj

The

proof

is

similar

to

Theorem

in

-LSB-

-RSB-

Initial

Resources

Similarly

the

number

of

initial

resources

for

a

set

of

tasks

is

computed

by

the

following

lemma

Lemma

-LRB-

Initial

Resources

IrOWCF

-RRB-

The

initial

number

of

type

r

resources

IrOWCF

X

f

X

-LSB-

xJki

Jlj

NJki

Jlj

ssr

-LRB-

oi

oj

-RRB-

-RSB-

g

where

V

is

the

AND/XOR

graph

constructed

by

Algorithm

xJki

Jlj

's

are

the

results

from

the

MCF

setting

under

OWCF

and

NJki

Jlj

's

are

defined

in

OWCF

The

proof

is

similar

to

Lemma

except

the

value

of

NJki

Jlj

is

from

OWCF

not

OFUOS

OFUOS

versus

OWCF

In

general

OFUOS

achieves

higher

process

utilization

factor

while

OWCF

provides

fresher

resources

It

is

possible

to

define

other

kinds

of

fresh

resource

allocation

policies

by

defining

the

linear

cost

function

in

our

MCF

setting

differently

Here

we

consider

a

special

case

for

any

given

production/consumption

relation

the

producer

has

a

higher

priority

than

the

consumer

This

is

the

case

in

real-time

monitoring

where

the

low-level

sensors

have

very

short

periods

And

if

we

use

rate

monotonic

scheduling

then

the

shorter

cycle

time

means

higher

priority

Under

this

special

case

we

find

out

that

PCP/OFUOS

and

PCP/OWCF

have

the

same

process

utilization

factor

under

rate-monotonic

scheduling

while

PCP/OWCF

still

gets

fresher

resources

This

implies

that

PCP/OWCF

is

definitely

better

in

both

aspects

and

should

be

preferred

first

if

the

system

fits

this

case

Theorem

-LRB-

Higher

Rate

Producer

Theorem

-RRB-

j

k

l

if

-LRB-

xJki

Jlj

-RRB-

-LRB-

Pi

Pj

-RRB-

then

PCP/OWCF

and

PCP/OFUOS

are

the

same

in

processor

utilization

but

PCP/OWCF

would

achieve

better

resource

freshness

proof

If

xJki

Jlj

and

Pi

Pj

then

by

Definition

EIP

lj

IP

lj

also

by

Definition

EPC

-LRB-

-RRB-

PC

-LRB-

-RRB-

This

further

implies

two

things

ffl

the

definition

of

our

Bi

becomes

the

same

as

defined

in

-LSB-

-RSB-

ffl

PTi

If

we

substitute

these

two

items

into

Theorems

and

we

get

exactly

the

same

results

as

in

Theorem

and

in

-LSB-

-RSB-

Thus

OWCF

and

OFUOS

achieve

the

same

processor

utilization

factor

but

by

their

definitions

the

resources

allocated

with

OWCF

are

fresher

In

general

the

schedulability

of

PCP/OWCF

is

better

if

the

ratio

between

high-priority

and

lowpriority

producers

is

higher

This

relation

is

not

true

for

PCP/OFUOS

Related

Work

The

real-time

producers/consumers

problem

but

without

the

concern

of

resource

freshness

was

pointed

out

as

an

open

problem

in

Rajkumar

's

thesis

-LSB-

-RSB-

The

same

problem

with

deterministic

production/consumption

relations

has

been

developed

in

various

forms

e.g.

-LSB-

-RSB-

Here

the

word

deterministic

means

that

the

employee

has

to

eat

the

donuts

from

the

same

shop

-LRB-

s

-RRB-

EVERYDAY

We

would

like

to

point

out

that

if

the

production/consumption

relations

are

deterministic

then

the

resource

freshness

can

be

purely

controlled

by

the

production

and

consumption

rates

of

periodic

tasks

For

example

if

we

ask

Dunkin

donuts

to

produce

donuts

more

frequently

then

all

Dunkin

donut

's

periodic

and

static

customers

would

get

fresher

donuts

However

in

the

nondeterministic

version

of

this

problem

the

employee

has

the

freedom

to

choose

from

different

donut

shops

to

optimize

the

donut

's

freshness

In

-LSB-

-RSB-

the

consumers

and

producers

are

represented

in

an

acyclic

dataflow

graph

model

Since

the

dataflow

graph

is

deterministic

it

is

transformed

into

a

process

model

which

can

be

used

to

perform

schedulability

analysis

The

goal

of

-LSB-

-RSB-

as

well

as

-LSB-

-RSB-

is

to

avoid

data

loss

i.e.

a

customer

has

the

responsibility

to

eat

the

previous

donut

before

the

next

donut

is

baked

Therefore

the

consumption

rate

has

to

be

fast

enough

to

match

the

production

rate

and

the

freshness

of

each

consumed

donut

is

bounded

by

the

producer

's

cycle

length

However

in

our

problem

because

we

allow

many

donuts

in

the

shelf

simultaneously

the

freshness

can

not

be

simply

bounded

by

the

production

rate

Our

idea

of

constructing

an

AND/XOR

graph

is

partially

from

-LSB-

-RSB-

Assuming

that

every

task

has

the

same

cycle

time

i.e.

Tn

K

Orlin

-LSB-

-RSB-

models

the

resource

minimization

problem

as

a

minimum

cardinality

chain-covers

problem

in

a

periodic

partial

ordered

set

-LRB-

periodic

POSET

-RRB-

Burkard

-LSB-

-RSB-

analyzed

the

optimal

phasing

to

optimize

maximal

waiting

time

minimal

safety

interval

and

average

waiting

time

simultaneously

with

two

periodic

tasks

with

different

cycle

time

Unfortunately

no

uniform

results

exist

for

when

the

number

of

tasks

with

different

cycle

length

are

greater

than

two

In

-LSB-

-RSB-

the

AND/OR

precedence

constraint

scheduling

problem

is

discussed

with

the

goal

to

minimize

the

completion

time

of

all

the

jobs

In

this

paper

we

use

the

AND/XOR

graph

instead

of

the

AND/OR

graph

in

order

to

get

a

feasible

MCF

setting

Remarks

In

this

paper

we

define

and

study

a

real-time

producers/consumers

problem

where

the

production/consumption

relations

are

nondeterministic

Under

a

sufficient

condition

resource

balance

we

map

this

problem

into

a

feasible

minimum

cost

flow

problem

on

an

AND/XOR

graph

We

further

develop

two

fresh

resource

allocation

policies

by

simply

defining

different

linear

cost

functions

The

first

policy

OFUOS

assumes

the

scheduler

is

vicious

and

it

plays

a

non-cooperative

game

with

the

scheduler

to

optimize

the

freshness

for

all

the

consumed

resources

The

strong

point

about

OFUOS

is

that

it

can

work

with

any

scheduler

without

sacrificing

the

schedulability

On

this

other

hand

the

second

policy

OWCF

assumes

that

the

scheduler

would

cooperatively

schedule

a

set

of

deterministic

production/consumption

relations

Potentially

with

OWCF

the

consumed

resources

are

fresher

But

the

weak

point

is

that

we

have

to

compromise

the

schedulability

Both

OFUOS

and

OWCF

can

work

together

with

the

priority

ceiling

protocol

-LRB-

with

rate-monotonic

scheduling

-RRB-

to

schedule

a

set

of

tasks

with

both

binary

semaphores

and

general

unbounded

semaphores

For

OFUOS

we

need

to

do

nothing

but

calculate

the

amount

of

initial

resources

With

OWCF

the

definitions

of

priority

inheritance

and

priority

ceiling

are

extended

Under

this

extension

we

prove

that

PCP/OWCF

is

deadlock

free

and

a

job

can

only

be

blocked

for

at

most

the

duration

of

one

longest

critical

section

Furthermore

schedulability

analysis

for

PCP/OWCF

is

done

-LRB-

For

PCP/OFUOS

the

schedulability

analysis

is

identical

to

the

one

for

the

PCP

in

-LSB-

-RSB-

-RRB-

Finally

in

high-speed

network

monitoring

applications

we

find

that

the

sensor

's

-LRB-

information

producer

-RRB-

cycle

time

is

usually

shorter

than

the

manager

's

-LRB-

information

consumer

-RRB-

With

rate-monotic

scheduling

this

implies

that

producers

have

higher

priority

than

consumers

Under

this

special

case

we

showed

that

PCP/OWCFand

PCP/OFUOS

are

the

same

in

schedulability

but

PCP/OWCF

is

better

in

freshness

This

theorem

strongly

supports

PCP/OWCF

in

the

domain

of

real-time

network

monitoring

Acknowledgments

Dr.

Ragunathan

Rajkumar

had

provided

many

valuable

suggestions

References

-LSB-

-RSB-

T.P.

Baker

Stack-based

scheduling

of

realtime

processes

The

Journal

of

Real-Time

Systems

-LRB-

-RRB-

March

-LSB-

-RSB-

Mokhtar

S.

Bazaraa

John

J.

Jarvis

and

Hanif

D.

Sherali

Linear

Programming

and

Network

Flows

John

Wiley

Sons

-LSB-

-RSB-

Rainer

E.

Burkard

Optimal

schedules

for

periodically

recurring

events

Discrete

Applied

Mathematics

-LSB-

-RSB-

Min-In

Chen

and

Kwei-Jay

Lin

Dynamic

priority

ceilings

A

concurrency

control

protocol

for

real-time

systems

The

Journal

of

Real-Time

Systems

-LRB-

-RRB-

December

-LSB-

-RSB-

Min-Ih

Chen

and

Kwei-Jay

Lin

A

priority

ceiling

protocol

for

multiple-instance

resources

In

IEEE

Real-Time

Systems

Symposium

pages

San

Antonio

TX

December

-LSB-

-RSB-

Donald

W.

Gillies

and

Jane

W.-S

Liu

Scheduling

tasks

with

and/or

precedence

constraints

In

IEEE

Symposium

on

Parallel

and

Distributed

Processing

pages

Dallas

TX

December

-LSB-

-RSB-

Kevin

Jeffay

and

Dan

Poirier

The

real-time

producer/consumer

paradigm

a

paradigm

for

the

construction

of

efficient

predictable

real-time

systems

Technical

report

CS

Department

U.

of

North

Carolina

at

Chapel

Hill

September

-LSB-

-RSB-

C.

L.

Liu

and

James

W.

Layland

Scheduling

algorithms

for

multiprogramming

in

a

hardreal-time

environment

Journal

of

the

ACM

-LRB-

-RRB-

January

-LSB-

-RSB-

John

P.

Lehoczky

Lui

Sha

and

Ye

Ding

The

rate

monotonic

scheduling

algorithm

Exact

characterization

and

average

case

behavior

In

IEEE

Real-Time

Systems

Symposium

pages

Santa

Monica

CA

December

-LSB-

-RSB-

Aloysius

K.

Mok

Prasanna

Amerasinghe

and

Moyer

Chen

Synthesis

of

a

real-time

message

processing

system

with

data-driven

timing

constraints

In

IEEE

Real-Time

Systems

Symposium

pages

San

Jose

CA

December

-LSB-

-RSB-

James

B.

Orlin

Minimizing

the

number

of

vehicles

to

meet

a

fixed

periodic

schedule

An

application

of

periodic

posets

Operations

Research

-LRB-

-RRB-

July-August

-LSB-

-RSB-

Ragunathan

Rajkumar

Task

Synchronization

in

Real-Time

Systems

Kluwer

Academic

Publishers

-LSB-

-RSB-

R.T.

Rockafellar

Network

Flows

and

Monotropic

Optimization

John

Wiley

Sons

-LSB-

-RSB-

Lui

Sha

Ragunathan

Rajkumar

and

John

P.

Lehoczky

Priority

inheritance

protocols

An

approach

to

real-time

synchronization

IEEE

Transactions

on

Computers

-LRB-

-RRB-

September

-LSB-

-RSB-

Shyhtsun

F.

Wu

and

Gail

E.

Kaiser

Network

management

with

consistently

managed

objects

In

IEEE

Global

Telecommunications

Conference

Communications

Connecting

the

Future

volume

pages

San

Diego

CA

December

resource allocation
resource freshness
semaphores


? Carnegie Mellon University This Work is sponsored by the U.S. Department of Defense Defining and Understanding Software Measurement Data1 James A. Rozum Software Engineering Institute Carnegie Mellon University Pittsburgh , PA 15213 -LRB-412-RRB- 268-7770 jar@sei.cmu.edu Abstract . For managers to effectively manage and control software development projects , they need to incorporate a measurement process into their decision making and reporting process . Measurement costs money , but it can also save money through early problem detection and objective clarification of critical software development issues . The following describes a measurement process and provides some basic concepts that managers can use to help integrate measurement into the process for managing software development . Why a Process for Measurement `` it 's not so much what I do n't know , it 's what I know that 's not so '' Dooley Dooley could never have been more right . Projects collect lots of data?most of it they do n't recognize as data . There is still more data available that projects do n't realize exist , or have n't considered using the data as information . There is little project managers do n't know about their projects , yet what always seems to cause problems are those things that projects thought they had under control . According to Deming , information is used to understand theory . Knowledge is the result of that understanding -LSB- Deming -RSB- . The problems encountered by project managers is that often their theory has been proven incorrect by information . The project manager 's theory is the plan including the schedule , budget , and expected quality of the resulting product . The information being received by the project manager are actually signals that their project is going to be late , cost more than expected , or not work quite the way it was originally planned ; sometimes all three signals are received . Why does this happen ? Oftentimes it is because of theory that is based on poor information . A defined measurement process that is integrated into the software development process will provide the reliable information and insight needed by managers to make better decisions , i.e. , their theories . With a defined software measurement process , managers have reliable 1 This paper has been previously published in the proceedings from the 5th International Applications of Software Measurement Conference . data and information that provides early insight into potential problems and can support decisions . Without a measurement process , managers do not have the information needed to identify and resolve problems . As a result , the managers react to events and problems rather than curtail those problems before they surface . A software measurement process is a systematic method of measuring , assessing , and adjusting the software development process using objective data . Within such a systematic approach , software data is collected based on known or anticipated development issues , concerns , questions , or needs . The data are analyzed with respect to the characteristics of the software development process and products , and used to assess progress , quality , and performance throughout the development . There are four key components to an effective measurement process : ? Defining clearly the software development issues and the software measures -LRB- data elements -RRB- that support insight to the issues . ? Processing the software data into graphs and tabular reports -LRB- indicators -RRB- that support the analysis of issues . ? Analyzing the indicators to provide insight into the issues . ? Using the results to implement improvements and identify new issues and questions . Each component of this process is driven by the issues and characteristics inherent to the program . For example , the decision of what specific data to collect is based on the list of issues to be addressed by measurement ; the indicators developed from the measurement data are flexible and tailored by the development issues and related questions ; and analysis techniques are chosen based on what information is desired and what question -LRB- s -RRB- need to be answered . Analysis can be directed at assessing the feasibility of development plans , identifying new issues , tracking issue improvement trends , projecting schedules based on performance to date , defining possible development tradeoffs , and evaluating the consistency and quality of development activities and products . `` The data collection process must be driven by the information from questions that we formulate based on our needs . In short , know what question is to be answered before collecting data . '' -LSB- Juran -RSB- The PDCA Measurement Process The measurement process becomes a complete Plan-Do-Check-Act -LRB- PDCA -RRB- process that is integrated into the development process and the project manager 's decision making process -LSB- Shewhart -RSB- . The PDCA cycle that a project can use is : Plan : Identify the issues or questions the project and manager has and then determine the data and measures to be collected to address them . Do : Collect data and , based on the issues identified , and using baseline data , derive graphical representations -LRB- i.e. , indicators -RRB- to better illustrate the data trends . Check : Analyze the trends , graphs , data , etc. to better understand the issues and the performance towards their resolutions . Act : Report the results , recommend improvements , and identify new issues and questions . As with the development of other system components , the key issues for software development relate to resource adequacy and expenditure , development progress and schedule , and the quality of the interim and final products . The nature of software development results in these three areas being strongly related -LSB- Rozum -RSB- . Issues with software quality , for example , can in many cases be directly attributable to schedule and resource constraints . This requires that the software measurement process address the relationships between several types of software data . For example , if a project is overrunning its planned allocations of staff hours , will the project be over the budget ? Maybe , but if the rate of completing project activities is commensurate with the rate of higher than expected expenditures of staff hours , the project could finish within the budgeted number of staff hours , and complete earlier than expected . The manager 's issues related to the adequacy and expenditure of resources usually revolve around the adequacy of and accuracy of estimates and the availability and allocation of resources when they are needed . The progress issue is simple ; will the contract be completed on schedule , and if not , when will it be completed ? However , factors that will affect determining this include : progress to date , amount of rework required , and the accuracy of earlier planning assumptions , e.g. , productivity and project complexity . Technical quality issues include both the quality of products being produced and the quality of the processes used to produce those products . Here the manager is concerned that interim products are stable and complete so that successive processes using those products do not compound mistakes -LRB- i.e. , defects -RRB- and thereby drive up cost through added rework . Issues about the technical quality that managers typically have usually relate to defects , completeness of products , adequacy of processes , and stability and volatility of the system and its mission . Collecting Data that Supports Insight to Issues The question of what data to collect and how to define that data is driven by the project 's current issues , projected issues , and characteristics of the software development process and products . The list of issues for measurement to provide insight to , is determined by the manager who identifies a list of project specific issues and concerns , sets priorities for the issues , and determine which of the issues can be addressed with the software measurement process . The manager can then determine what data is needed to support insight into the issues . However , not all issues can be predetermined or projected ; therefore , the manager also needs to include provisions that allow the process to be flexible so that it can be modified to provide insight into unforeseen issues . Change in the process is inevitable as the development proceeds and requirements become better defined : cost , performance , and schedule estimates are refined ; personnel , machine , test , and support resource requirements are identified ; and insights from the measures themselves are gained . As the issues change , the manager should use the new information to adapt the measurement process to address the changes . Once the data collection has started , measurement definitions should not be changed -LRB- e.g. , lines of code definitions should not be changed -RRB- . Changing a definition after the data collection has started will produce variations in the trends that could confuse the analyses and camouflage performance or related problems . However , sometimes definitions will change . When they do , it becomes critically important that the manager understands the change and how the change affects data that has already been collected . In Figure 1 for example , a new methodology was used to estimate the size of the project starting at month ten . This change in methodology produced a large variation in the estimated size . Not all changes will have such a dramatic impact . Still , the manager must understand the differences between the methods and the impacts those differences have on the decision making process -LSB- Rozum -RSB- . New Methodology 800 200 1200 400 1000 600 Size -LRB- KSLOC -RRB- Commerical Code New Code Reused Code Monthly Estimates M1 M3 M5 M7 M9 M11 M13 Figure 1 : Example Illustrating the Need for Understanding Data When determining what data to collect , the preferred data is that which is a direct result of the developer 's process . For example , count the number of computer software units to be developed by looking in the preliminary design documentation . Limit the use of data that is below the granularity supported by the organization 's software process . For example , when collecting software defect data and accompanying process information about the defects , use the process already in place . To do otherwise might not be cost effective and may adversely affect the productivity and schedule of the contract . If the organization 's process does not support a useful level of granularity , then the capability of management and their decisions will also limited . '' ? You can not just use numbers to control things . The numbers must properly represent the process being controlled , and they must be sufficiently well defined and verified to provide a reliable basis for action . While process measurements are essential for orderly improvement , careful planning and preparation are required or the results are likely to be disappointing . '' -LSB- Humphrey -RSB- The manager must realize that most issues will require multiple -LRB- and seemingly unrelated -RRB- data items to characterize the issues . For example , if the issue is the amount of rework and how it is affecting the project 's progress , the manager would need to have data on progress , the number of items being reworked , how much effort is being spent on rework , how effective the process is at finding items that need rework early , etc. . If an issue is how the amount of rework is affecting the budget or end quality of the product , a different set of data items might be collected . The data needed to characterize an issue is also dependent on the development phase -LRB- e.g. , requirements , design , or coding -RRB- . Using the rework example , determining what items to use for measuring rework will be different during the requirements phase than during the design phase . Measurement Data Types and Partitioning The plans , assumptions , models , and historical data provide the basis for using actual project data . There are four types of data that managers will use : ? Historical ? Plan ? Actual ? Projections A project will use historical data and assumptions to generate estimates . The estimates , along with other information and knowledge of the system and environment , are then used as the basis for planning the project . Actual data is collected by the project and used as the basis for comparing the performance to plans and for projecting future trends . The project also uses historical data to determine the realism and achieveability of the plans . Partitioning a data item can also improve the insight into the issues . For example , data could be partitioned by : ? Processor -LRB- i.e. , target platforms -RRB- ? Language ? Organization or subcontractor ? Computer software configuration item -LRB- CSCI -RRB- , computer software component -LRB- CSC -RRB- , or computer software unit -LRB- CSU -RRB- ? Configuration -LRB- e.g. , avionics of two different airplanes -RRB- ? Severity ? Incremental build ? Facility or Lab ? Work breakdown structure -LRB- WBS -RRB- element The level of partitioning will have an impact on how the data is used and how useful the data will be . For instance , if effort is collected at the organizational level rather than at lower levels of a WBS , resource allocation issues -LRB- e.g. , certain modules or units not receiving enough testing -RRB- may be disguised . The partitions should highlight the area -LRB- s -RRB- of concern so that trends from the indicators can help the program manager determine if the issues are being mitigated . For another example , SLOC can be partitioned by newly developed , modified , or reused . If only total SLOC is measured , changes to where the SLOC comes from may go undetected . These changes may reflect significant differences in the effort and schedule required to complete the project . In general , the lower the level of detail for the data , the better the probability of isolating problem areas . However , the lower the level of detail , the higher the cost of the measurement process . Therefore , tradeoffs will need to be made . Whenever data is collected , its time of collection and source should be noted . The data should be treated as proprietary to prevent abuses and reduced availability and to alleviate the concerns about how the data will be used . People will already be concerned about the use of the data and using data as a tool to quantify their performance . If measurement becomes an adversarial issue , the quality and availability of the data will probably be greatly reduced . Therefore , the data should be used as a tool for improving communications and as a basis for identifying and resolving issues . Along with the source and time , assumptions and other knowledge about the data should also be noted . Later , when analyzing the data , the project manager will need the data and all the information available about the data to completely understand the information . For example , if actual effort expended is lower than expected , there might have been uncontrollable problems such as staff awaiting security clearances or waiting for equipment to be delivered . Other types of information could signal potential problems , e.g. , changes to plans . Assistance for Defining Software Measures The SEI has developed frameworks to assist a project in identifying its issues and ensuring that its measurement definitions are crafted in such as way that the data collected is sufficient in nature to provide insight into the issues . The frameworks are based on a series of checklists that a project uses simultaneously for issue identification and measurement definition . Checklists that are available , and the characteristics they can be used to address , are shown in table 1 below . Unit of Measure Characteristics Addressed Physical source lines of code Logical source lines of code Size , reuse , rework Staff hours Effort , cost , resource allocations Calendar dates for process milestones Calendar dates for deliverables Schedule , progress Problems and defects Quality , improvement trends , rework , readiness for delivery Table 1 : SEI Core Measures In preparing the frameworks , the SEI was guided by two criteria : ? Communication : If someone uses a checklist or definition to record and report measurement results , will others know precisely what is included , what is excluded , and how the measurement unit is defined ? ? Repeatability : Would others be able to repeat the measurements and get the same results ? These properties are important if misunderstandings or misinterpretations are to be avoided . They are essential if consistency is to be achieved across projects or from organization to organization . The frameworks permit managers to identify multiple data attributes to address project issues . Although , managers would like to have a single number to characterize their programs , experienced managers search for answers using the insight that multiple measures and data attributes provide . At the organizational level , collecting data with multiple attributes also separates projects into characteristics that can then be used at a later date for comparisons such as benchmarking . For example , separating lines of code data by language , production method , and type of system . The Size Checklist The size checklist can be used to help define counts of physical and logical source lines of code . There are attributes for separating by development status -LRB- e.g. , estimated or planned -RRB- and also for separating the data by language . Other attributes include : Statement type : e.g. , executable , declarations , or comments How produced : e.g. , programmed , modified , removed , or generated Origin : e.g. , new work or prior work from a previous version or library Usage : e.g. , part of the primary product or external to the primary product Delivery : e.g. , delivered as source or executable or non delivered , but under configuration control Functionality : e.g. , operative or inoperative such as nonfunctional code Replications : e.g. , copies inserted during compile , originals only , post development replicates A portion of page one of the size checklists is shown in Figure 2 . Definition Checklist for Source Statement Counts Definition name : Physical Source Lines of Code Date : 7/9/92 -LRB- basic definition -RRB- Originator : SEI Measurement unit : Physical source lines 4 Logical source statements Statement type Definition 4 Data array Includes Excludes When a line or statement contains more than one type , classify it as the type with the highest precedence . 1 Executable Order of precedence - > 1 4 2 Nonexecutable 3 Declarations 2 4 4 Compiler directives 3 4 5 Comments 6 On their own lines 4 4 7 On lines with source code 5 4 8 Banners and nonblank spacers 6 4 9 Blank -LRB- empty -RRB- comments 7 4 10 Blank lines 8 4 11 12 How produced Definition 4 Data array Includes Excludes 1 Programmed 4 2 Generated with source code generators 4 3 Converted with automated translators 4 4 Copied or reused without change 4 5 Modified 4 6 Removed 4 7 8 Figure 2 : Portion of SEI Checklist for Defining Lines of Code The Effort Measures Checklist The Effort checklist can be used to help define counts of physical and logical source lines of code . There are attributes for : Type of labor : e.g. , direct and indirect Hour information : e.g. , regular time , overtime , salaried , or hourly Employment class : e.g. , full time , part time , contract , or consultant Labor class : e.g. , management , programmer , or support staff Activity : e.g. , development or maintenance Product-level functions : e.g. , system level functions , build level functions , Design , coding , or testing A portion of page two of the effort checklists is illustrated in Figure 3 . Totals Totals Report Product-Level Functions include exclude totals CSCI-Level Functions -LRB- Major Functional Element -RRB- Software requirements analysis Design Preliminary design Detailed design Code & development testing Code & unit testing Function -LRB- CSC -RRB- integration and testing CSCI integration & testing IV&V Management Software quality assurance Configuration management Documentation Rework Software requirements Software implementation Re-design Re-coding Re-testing Documentation 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 Figure 3 : Portion of SEI Checklist for Defining Software Effort The Problem Count Checklist The problem count checklist can be used to help define counts of defects and enhancements regarding software products . There are attributes for : Problem status : e.g. , open and closed Problem type : e.g. , software defects , hardware problems , new requirements , or enhancements Uniqueness : e.g. , original or duplicates Criticality : e.g. , how critical is the problem regarding the operation of the system Urgency : e.g. , how urgent is the problem to the customer reporting it Finding attribute : e.g. , design , code , inspections , reviews , or testing A portion of page one of the problem count checklist is shown in Figure 4 . Problem Count Definition Checklist-1 Software Product ID -LSB- -RSB- Definition Identifier : -LSB- -RSB- Date : -LSB- -RSB- Attributes/Values Definition -LSB- -RSB- Specification -LSB- -RSB- Problem Status Include Exclude Value Count Array Count Open 4 4 Recognized Evaluated 4 Resolved 4 Closed 4 4 Problem Type Include Exclude Value Count Array Count Software Defect Requirements Defect 4 4 Design Defect 4 4 Code Defect 4 4 Operational Document Defect 4 4 Test Case Defect 4 Other Work Product Defect 4 Other Problems Hardware Problem 4 Operating/System Software 4 User Mistake 4 Operations Mistake 4 New Requirement/Enhancement 4 Undetermined Not Repeatable/Cause Unkown 4 Value Not Identified 4 Figure 4 : Portion of SEI Checklist for Defining Problems and Defects The Schedule Measures Checklists The schedule measures checklists allows the project to determine what milestones and deliverables it will plan and track progress towards . In the schedule checklists there are capabilities to separate the items to be tracked by builds and overall . For each item to be tracked , there is the capability to define exit criteria on that item and to further decompose that item to track key events regarding that item . For example , when sign-off by the customer , management , and/or quality assurance is obtained . As part of the schedule series of checklists , the ability to track schedule and progress by counting completed work units is also included . Conclusion In summary , the objective is to have an understandable set of measurement data that can be processed into different reports and indicators to address and help answer different issues and questions as they occur . To accomplish this , projects should collect much of the data itself and at a low enough level so that the data can be clearly understood and represented in many different ways . To assist in identifying the issues and defining data , the SEI has developed frameworks for common software measures . Examples of those frameworks was illustrated . See -LSB- Park -RSB- for more information on counting lines of code ; , see -LSB- Goethert -RSB- for information on counting effort or tracking schedules ; and , see -LSB- Florac -RSB- for information on counting problems and defects . Bibliography -LSB- Boehm -RSB- Boehm , B. , Software Engineering Economics . Englewood Cliffs , New Jersey : Prentice-Hall , 1981 . -LSB- Demarco -RSB- DeMarco , T. , Controlling Software Projects . New York , New York : Yourdan Press , 1982 . -LSB- Deming -RSB- Deming , W. E. , `` The New Economics for Education , Government , and Industry , '' Quality Enhancement Seminars , Inc. , Los Angeles , CA , 1992 . -LSB- Florac -RSB- Florac , William , A. , Software Quality Measurement : A Framework for Counting Problems and Defects , CMU/SEI -92 - TR-22 , Software Engineering Institute - Carnegie Mellon University , Pittsburgh , Pennsylvania , September 1992 . -LSB- Goethert -RSB- Goethert , Wolfhart , B. , et . al. , Software Effort and Schedule Measurement : A Framework for Counting Staff-Hours and Reporting Schedule Information , CMU/SEI - 92-TR-21 , Software Engineering Institute - Carnegie Mellon University , Pittsburgh , Pennsylvania , September 1992 . -LSB- Humphrey -RSB- Humphrey , W. S. , Managing the Software Process . Reading , Massachusetts : Addison-Wesley Publishing Co. , 1989 . -LSB- Juran -RSB- The Juran Institute , `` The Tools of Quality ; Part V : Check Lists , '' Quality Progress , October 1990 . -LSB- Park -RSB- Park , Robert , E. , Software Size Measurement : A Framework for Counting Source Statements , CMU/SEI -92 - TR-20 , Software Engineering Institute - Carnegie Mellon University , Pittsburgh , Pennsylvania , September 1992 . -LSB- Rozum92 -RSB- Rozum , James A. , Software Measurement Concepts for Acquisition Program Managers , CMU/SEI -92 - TR-11 , Software Engineering Institute - Carnegie Mellon University , Pittsburgh , Pennsylvania , June 1992 . -LSB- Rozum94 -RSB- Rozum , James A. and William A. Florac , A DoD Software Measurement Pilot : Applying the SEI Core Measures , CMU/SEI -94 - TR-16 , Software Engineering Institute - Carnegie Mellon University , Pittsburgh , Pennsylvania , May 1995 . -LSB- Shewhart -RSB- Shewhart , W. A. , Statistical Method From the Viewpoint of Quality Control , The Graduate School - The Department of Agriculture , Washington D.C. , 1939 .

O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

data collection
measurement process
software measurement
software process