Programming

Research

Group

REFINEMENT

OF

COMPLEX

SYSTEMS

A

CASE

STUDY

Gavin

Lowe

and

Hussein

Zedan

Oxford

University

Computing

Laboratory

Wolfson

Building

Parks

Road

Oxford

Refinement

of

Complex

Systems

A

Case

Gavin

Lowe

and

Hussein

Zedan

February

Abstract

We

describe

the

Temporal

Agent

Model

-LRB-

TAM

-RRB-

together

with

its

associated

refinement

calculus

The

calculus

is

based

on

a

wide-spectrum

language

within

which

functional

and

temporal

properties

can

be

expressed

in

either

abstract

-LRB-

i.e.

specification

-RRB-

or

concrete

-LRB-

i.e.

design

-RRB-

terms

The

refinement

process

transforms

abstract

specifications

to

concrete

designs

through

successive

applications

of

sound

refinement

laws

An

extension

to

the

calculus

allows

us

to

calculate

a

scheduler

for

the

resulting

design

We

present

a

specification

paradigm

based

on

splitting

the

functional

and

temporal

requirements

and

describe

refinement

techniques

based

on

this

paradigm

We

illustrate

the

calculus

via

an

example

taken

from

the

avionics

industry

Introduction

The

formal

development

of

a

computer

system

is

traditionally

separated

into

four

distinct

tasks

the

formalization

of

the

user

's

informal

requirements

the

formalization

of

the

design

verification

of

the

design

-LRB-

i.e.

proving

that

the

design

satisfies

the

specification

-RRB-

and

the

translation

of

the

design

into

an

implementation

For

real-time

systems

both

specification

and

verification

stages

must

take

into

account

the

various

non-functional

requirements

such

as

timing

and

dependability

as

well

as

the

usual

functional

requirements

This

consideration

adds

more

complexity

to

an

already

complex

task

copies

of

this

Technical

Report

may

be

obtained

from

the

Librarian

-LRB-

Oxford

University

Computing

Laboratory

Programming

Research

Group

Wolfson

Building

Parks

Road

Oxford

England

telephone

e-mail

library@comlab.ox.ac.uk

-RRB-

or

by

anonymous

ftp

from

ftp.comlab.ox.ac.uk

filename

Hussein

Zedan

is

at

the

School

of

Computing

and

Mathematical

Science

John

Moores

University

Liverpool

In

recent

years

efforts

have

been

mounted

to

construct

practical

formal

techniques

for

the

development

of

real-time

systems

In

most

existing

formal

development

methods

there

are

at

least

two

languages

involved

one

for

writing

specifications

and

the

other

for

the

design

-LRB-

The

transformation

from

design

to

actual

implementation

is

often

ignored

or

considered

trivial

-RRB-

A

common

problem

with

this

multi-language

approach

is

the

lack

of

method

by

which

a

suitable

design

can

be

found

A

combination

of

experience

and

guesswork

must

be

used

in

order

to

formulate

the

design

before

verification

can

be

undertaken

If

this

verification

fails

then

the

whole

design

and

verification

task

is

repeated

In

this

paper

we

present

the

Temporal

Agent

Model

-LRB-

TAM

-RRB-

as

an

attempt

to

overcome

these

problems

TAM

is

a

theory

centered

around

a

wide-spectrum

language

in

which

both

abstract

-LRB-

i.e.

non-implementable

-RRB-

specification

and

design

can

be

formulated

in

a

unified

manner

Both

functional

and

timing

requirements

of

a

real-time

system

are

expressed

as

a

TAM

specification

this

is

then

transformed

using

provably

correct

transformations

via

a

mixed

program

containing

both

fragments

of

abstract

specification

and

executable

code

before

eventually

reaching

pure

code

This

type

of

development

is

widely

known

as

refinement

and

is

already

in

common

use

in

untimed

systems

The

advantage

of

the

wide

spectrum

language

is

that

the

development

process

remains

within

the

framework

of

a

single

language

thus

avoiding

translation

errors

which

are

common

in

a

multi-language

approach

The

refinement

calculus

which

allows

for

the

gradual

transformation

from

abstract

specification

to

concrete

design

gives

a

verification

methodology

which

is

easy

to

follow

in

a

step

by

step

fashion

Related

work

For

untimed

systems

a

refinement

calculus

was

developed

by

Back

-LSB-

-RSB-

to

provide

a

formal

framework

for

stepwise

refinement

of

sequential

programs

It

extends

Dijkstra

's

weakest

precondition

semantics

for

total

correctness

of

programs

with

a

relation

of

refinement

between

program

statements

This

relation

is

defined

in

terms

of

the

weakest

preconditions

of

statements

and

expresses

the

requirement

that

a

refinement

must

preserve

total

correctness

of

the

statement

being

refined

The

refinement

calculus

was

extended

to

provide

a

framework

for

total

correctness

for

parallel

systems

in

-LSB-

-RSB-

Morgan

's

work

-LSB-

-RSB-

provides

a

good

overview

of

how

to

apply

the

refinement

calculus

in

practical

program

derivations

A

number

of

refinement

calculi

already

exist

for

real-time

systems

but

they

are

either

incomplete

or

use

an

unrealistic

computational

model

PLtime

-LSB-

-RSB-

is

a

real-time

design

language

which

consists

of

a

CSP-like

syntax

with

extensions

for

real-time

However

the

formalism

is

based

on

the

maximal-parallelism

hypothesis

-LRB-

i.e.

the

assumption

that

there

are

always

sufficient

resources

available

-RRB-

which

is

too

restrictive

for

most

real

time

systems

In

addition

since

PLtime

does

not

provide

a

separate

specification

statement

as

a

syntactic

entity

the

refinement

remains

purely

in

the

concrete

domain

Similarly

RT-ASLAN

-LSB-

-RSB-

is

a

refinement

calculus

which

refines

a

specification

into

concrete

code

but

this

again

relies

on

the

maximal

parallelism

model

Paper

organization

In

the

next

section

we

give

an

overview

of

the

syntax

and

semantics

of

the

Temporal

Agent

Model

In

section

we

present

a

method

of

separating

the

functional

and

temporal

parts

of

a

specification

and

also

present

some

results

that

help

transform

such

specifications

into

code

In

section

we

present

our

case

study

we

informally

describe

our

system

present

a

formal

specification

derive

a

design

meeting

this

specification

and

derive

a

scheduler

for

the

design

The

Temporal

Agent

Model

We

define

a

real-time

system

to

be

a

finite

collection

of

possibly

concurrently

executing

computation

agents

which

communicate

asynchronously

via

timestamped

shared

data

areas

called

shunts

Shunts

are

passive

shared

memory

spaces

that

contain

two

values

the

first

gives

the

time

at

which

the

most

recent

write

took

place

and

the

second

gives

the

value

that

was

most

recently

written

Systems

themselves

can

be

viewed

as

single

agents

and

composed

into

larger

systems

At

any

time

a

system

can

be

thought

of

having

a

unique

state

defined

by

the

values

in

the

shunts

and

local

variables

An

agent

is

described

by

a

set

of

computations

which

may

transform

a

local

data

space

and

may

read

and

write

shunts

during

execution

The

computation

may

be

nondeterministic

In

particular

ffl

Time

is

global

i.e.

a

single

clock

is

available

to

every

agent

and

shunt

The

time

domain

is

discrete

linear

and

modelled

naturally

by

the

natural

numbers

ffl

No

state

change

may

be

instantaneous

ffl

An

agent

may

start

execution

either

as

a

result

of

a

write

event

on

a

specific

shunt

or

as

the

result

of

some

condition

on

the

current

time

these

two

conditions

model

sporadic

and

periodic

tasks

respectively

ffl

An

agent

may

have

deadlines

on

computations

and

communication

Deadlines

are

considered

to

be

hard

i.e.

there

is

no

concept

of

deadline

priority

and

all

deadlines

must

me

met

by

the

run-time

system

We

are

currently

investigating

the

inclusion

of

prioritized

deadlines

into

the

language

ffl

A

data

space

is

created

when

an

agent

starts

execution

with

nondeterministic

initial

values

the

data

space

is

destroyed

when

the

agent

terminates

No

agent

may

read

or

write

another

agent

's

local

data

space

ffl

A

system

has

a

static

configuration

i.e.

the

shunt

connection

topology

remains

fixed

throughout

the

lifetime

of

the

system

ffl

An

agent

's

output

shunts

are

owned

by

that

agent

i.e.

no

other

agent

may

write

to

those

shunts

although

many

other

agents

may

read

them

ffl

Shunt

writing

is

destructive

but

shunt

reading

is

not

TAM

syntax

The

TAM

language

is

defined

A

w

j

skip

j

t

j

x

e

j

x

s

j

e

s

j

A

j

var

x

T

in

A

j

shunt

s

T

in

A

j

-LSB-

t

-RSB-

A

j

ift

gi

-RRB-

Ai

j

A

u

j

A

st

j

A

j

j

loop

for

n

period

t

A

where

w

is

a

set

of

computation

variables

and

shunts

is

a

predicate

in

the

TAM

Logic

Language

which

we

define

below

t

is

a

time

x

is

a

variable

of

type

T

e

is

an

expression

on

variables

s

is

a

shunt

of

type

Time

T

I

is

some

finite

indexing

set

gi

is

a

boolean

expression

and

n

is

a

natural

number

Informally

ffl

w

is

a

specification

statement

It

specifies

that

only

the

variables

in

the

frame

w

may

be

changed

and

the

execution

must

satisfy

ffl

The

agent

skip

may

terminate

after

any

delay

ffl

The

agent

t

terminates

after

t

time

units

ffl

x

e

evaluates

the

expression

e

using

the

values

found

in

variables

at

the

start

time

of

the

agent

and

assigns

it

to

x

The

expression

e

may

not

include

the

values

held

in

shunts

it

may

only

use

the

values

held

in

variables

It

may

also

include

the

distinguished

free

variable

Now

representing

the

current

time

ffl

x

s

performs

an

input

from

shunt

s

storing

the

value

in

x

the

type

of

x

must

be

a

time

-LCB-

value

pair

ffl

e

s

writes

the

current

value

of

expression

e

to

shunt

s

time-stamping

it

with

the

time

of

the

write

ffl

A

performs

a

sequential

composition

of

A

and

ffl

var

x

T

in

A

defines

x

to

be

a

new

local

variable

of

type

T

within

A

its

initial

value

is

chosen

nondeterministically

ffl

shunt

s

T

in

A

defines

s

to

be

a

new

local

shunt

of

type

Time

T

within

A

its

initial

value

is

chosen

nondeterministically

but

it

is

timestamped

with

the

time

of

its

declaration

ffl

-LSB-

t

-RSB-

A

gives

agent

A

a

duration

of

t

if

the

agent

terminates

before

t

seconds

have

elapsed

then

the

agent

should

idle

to

fill

this

interval

if

the

agent

does

not

terminate

within

t

seconds

then

it

is

considered

to

have

failed

earlier

papers

TAM

was

given

a

more

abstract

syntax

whose

conciseness

helped

in

abstract

reasoning

in

this

paper

where

we

are

dealing

with

more

concrete

agents

we

adopt

a

more

user-friendly

syntax

similar

to

that

in

-LSB-

-RSB-

ffl

ift

gi

-RRB-

Ai

evaluates

all

the

boolean

guards

gi

and

executes

an

Ai

corresponding

to

a

true

guard

if

all

the

guards

evaluate

to

false

then

the

agent

terminates

correctly

The

evaluation

of

the

guards

should

take

precisely

t

time

units

if

necessary

the

agent

should

idle

to

fill

this

interval

We

shall

sometimes

omit

the

parameter

t

if

we

do

not

want

to

specify

it

We

shall

sometimes

write

this

construct

as

ift

-RRB-

-RRB-

gn

-RRB-

An

ffl

A

u

forms

a

nondeterministic

choice

between

A

and

ffl

A

st

monitors

shunt

s

for

t

time

units

if

a

write

occurs

within

this

time

then

it

executes

otherwise

it

times-out

and

executes

A.

ffl

A

j

executes

the

two

agents

concurrently

terminating

when

both

agents

terminate

ffl

loop

for

n

period

t

A

executes

A

n

times

giving

each

a

duration

of

t

We

insist

that

no

agent

may

share

its

local

state

space

with

concurrently

executing

agents

and

only

one

concurrent

agent

may

write

to

any

given

shunt

these

restrictions

will

allow

us

to

develop

a

compositional

semantics

and

refinement

calculus

Semantics

The

semantics

of

TAM

is

given

in

terms

of

a

predicate

in

the

TAM

Logic

Language

-LRB-

TAMLL

-RRB-

This

is

a

first-order

logic

with

simple

extensions

to

deal

with

times

and

the

values

held

in

variables

and

shunts

Formulae

in

the

TAM

Logic

Language

may

include

two

distinguished

variables

t

representing

the

start

time

of

the

execution

and

t

representing

the

termination

time

It

may

also

use

terms

of

the

form

x@t

and

s@t

to

refer

to

the

values

held

in

variables

and

shunts

at

time

t

We

also

use

s@t

ts

and

s@t

v

to

refer

to

the

time-stamp

and

value

of

a

shunt

We

define

a

few

useful

predicates

The

predicate

stable

-LRB-

x

t

t

-RRB-

specifies

that

the

shunt

or

variable

x

remains

constant

between

t

and

t

stable

-LRB-

x

t

t

-RRB-

b

t

-LSB-

t

t

-RSB-

x@t

x@t

We

extend

this

to

sets

of

variables

and

shunts

in

the

obvious

way

The

predicate

write

-LRB-

v

s

t

-RRB-

specifies

that

value

v

is

written

to

shunt

s

at

time

t

write

-LRB-

v

s

t

-RRB-

b

s@t

-LRB-

t

v

-RRB-

We

extend

this

to

specify

that

a

-LRB-

single

-RRB-

write

occurs

during

the

interval

-LSB-

t

t

-RSB-

write

-LRB-

v

s

-LSB-

t

t

-RSB-

-RRB-

b

t

-LSB-

t

t

-RSB-

stable

-LRB-

s

t

t

-RRB-

write

-LRB-

v

s

t

-RRB-

stable

-LRB-

s

t

t

-RRB-

Shunts

obey

the

following

axiom

t

Time

s@t

ts

t

s@t

v

s

-LRB-

t

-RRB-

v

-RRB-

s@t

ts

t

s@t

ts

t

-RRB-

s@t

s

-LRB-

t

-RRB-

The

time

stamp

represents

the

last

time

at

which

a

write

was

made

so

must

be

no

greater

than

the

current

time

if

the

value

at

time

t

is

not

the

same

as

at

time

t

then

a

write

must

have

occurred

at

t

so

the

shunt

is

time-stamped

at

t

if

the

time

stamp

at

t

is

not

equal

to

t

then

no

write

occurred

at

t

so

the

value

is

the

same

as

at

t

We

define

a

semantic

function

F

TAM

TAMLL

such

that

F?A

gives

the

semantics

of

A

The

complete

semantic

definitions

are

given

in

-LSB-

-RSB-

We

give

here

a

few

examples

The

semantics

of

the

specification

statement

is

given

by

F?w

b

stable

-LRB-

W

n

w

t

t

-RRB-

Here

and

henceforth

we

take

the

agent

's

alphabet

to

be

W

All

variables

except

those

in

w

must

remain

stable

and

the

execution

must

satisfy

Assignment

is

defined

by

F?x

e

b

stable

-LRB-

W

n

x

t

t

-RRB-

x@t!

e@t

t

t

All

variables

other

than

x

remain

stable

the

final

value

of

x

is

the

value

of

e

evaluated

at

t

and

the

agent

takes

some

strictly-positive

amount

of

time

to

perform

the

assignment

Let

and

be

the

alphabets

of

and

respectively

Parallel

composition

is

defined

by

j

b

-LSB-

t

-RSB-

stable

-LRB-

t

-RRB-

-LSB-

t

-RSB-

stable

-LRB-

t

-RRB-

t

g

If

terminates

at

and

terminates

at

then

the

parallel

composition

terminates

at

g

each

agent

's

variables

are

stable

after

that

agent

terminates

We

define

refinement

in

TAM

as

follows

A

vF

b

F?A

-LRB-

If

is

more

fully

defined

than

A

then

refines

A.

-LRB-

We

drop

the

subscript

F

where

this

will

not

lead

to

confusion

-RRB-

It

is

easily

shown

that

refinement

is

a

pre-congruence

that

is

if

A

v

then

C

-LRB-

A

-RRB-

v

C

-LRB-

-RRB-

for

any

context

C

-LRB-

-RRB-

written

in

terms

of

the

TAM

language

This

means

that

if

we

refine

one

part

of

a

program

then

we

refine

the

whole

program

Scheduling-oriented

model

for

TAM

In

-LSB-

-RSB-

we

extended

the

model

covering

functionality

to

include

scheduling

and

resource

requirements

We

represent

the

use

of

resource

r

at

time

t

by

the

pair

-LRB-

t

r

-RRB-

Resource

b

Time

Resource

Name

We

alter

the

syntax

so

that

all

constructs

requiring

a

scheduling

decision

are

labelled

A

w

j

skip

j

t

j

L

x

e

j

L

x

s

j

L

e

s

j

A

j

var

x

T

in

A

j

shunt

s

T

in

A

j

-LSB-

t

-RSB-

A

j

L

ift

gi

-RRB-

Ai

j

A

u

j

L

A

st

j

A

j

j

loop

for

n

period

t

A

where

L

ranges

over

the

space

Lbl

of

labels

We

define

a

scheduler

to

be

a

function

OE

that

takes

a

label

and

the

time

at

which

the

program

reaches

that

label

and

returns

the

set

of

resources

upon

which

the

corresponding

agent

should

be

scheduled

Sch

b

Time

Label

P

-LRB-

Resource

-RRB-

For

example

if

the

labelled

assignment

L

x

is

encountered

at

time

with

scheduler

OE

such

that

OE

-LRB-

L

-RRB-

f

-LRB-

r

-RRB-

-LRB-

r

-RRB-

g

then

the

assignment

will

be

scheduled

on

resource

r

at

times

and

Designing

a

scheduler

then

amounts

to

defining

the

function

OE

for

each

label

i.e.

deciding

when

and

upon

which

resources

each

atomic

construct

should

be

scheduled

We

consider

a

system

to

be

either

a

specification

statement

or

a

concrete

agent

with

a

scheduler

S

w

j

A

j

OE

In

order

to

model

scheduling

and

resource

requirements

we

extended

the

TAM

Logic

Language

We

allow

our

predicates

to

include

a

distinguished

free

variable

Rreq

representing

the

resources

required

by

the

agent

We

also

add

a

boolean-valued

variable

fail

which

is

true

precisely

when

an

execution

fails

this

failure

could

be

because

-LRB-

-RRB-

the

agent

tries

to

use

a

resource

for

two

different

purposes

or

-LRB-

-RRB-

a

deadline

is

not

met

We

define

a

semantic

function

R

giving

the

representation

of

an

agent

in

this

model

R

System

TAMLL

For

example

the

specification

statement

is

extended

to

specify

that

the

system

does

not

fail

R?w

b

stable

-LRB-

W

n

w

t

t

-RRB-

fail

For

most

agents

the

semantic

definition

is

similar

to

the

definition

in

the

model

without

scheduling

extended

to

include

the

resource

requirements

For

example

R?L

x

e

j

OE

b

stable

-LRB-

W

n

x

t

t

-RRB-

x@t!

e@t

Rreq

OE

-LRB-

t

L

-RRB-

t

end

Rreq

fail

If

the

labelled

assignment

is

encountered

at

time

t

then

it

requires

resources

Rreq

OE

-LRB-

t

L

-RRB-

it

terminates

when

it

has

used

all

these

resources

it

does

not

fail

Consider

the

parallel

composition

j

Suppose

requires

resources

Rreq

and

requires

resources

Rreq

then

the

parallel

composition

will

require

Rreq

-LSB-

Rreq

The

composition

will

fail

if

-LRB-

-RRB-

either

component

fails

or

-LRB-

-RRB-

both

components

try

to

access

the

same

resource

simultaneously

j

j

OE

b

Time

Bool

Rreq

Rreq

Resources

j

OE

-LSB-

t

fail

Rreq

Rreq

-RSB-

j

OE

-LSB-

t

fail

Rreq

Rreq

-RSB-

stable

-LRB-

t

-RRB-

stable

-LRB-

t

-RRB-

t

t

Rreq

Rreq

-LSB-

Rreq

fail

Rreq

Rreq

The

semantic

definitions

satisfy

the

following

condition

namely

that

agents

only

use

resources

during

their

execution

time

R?A

j

OE

-RRB-

-LRB-

t

r

-RRB-

Rreq

-RRB-

t

-LSB-

t

t

-RRB-

We

can

use

the

above

model

to

define

another

semantic

model

which

models

the

fact

that

there

may

be

limited

resources

available

We

add

another

free

variable

to

the

TAM

Logic

Language

Rav

representing

the

resources

available

to

the

system

We

then

define

a

semantic

function

L

System

TAMLL

by

L?S

b

R?S

-LSB-

fail

-RSB-

-LRB-

fail

Rreq

Rav

-RRB-

Thus

systems

in

this

model

can

fail

if

they

require

resources

that

are

not

available

Refinement

in

this

model

is

defined

in

the

obvious

way

A

vL

iff

L?A

-LRB-

In

-LSB-

-RSB-

we

proved

the

following

theorem

Theorem

Suppose

we

are

given

a

set

of

available

resources

Rav

and

suppose

the

variables

Rav

and

Rreq

do

not

appear

free

in

the

predicate

Then

if

agent

meets

specification

in

the

non-resource

model

agent

can

be

obtained

from

by

adding

labels

and

the

composition

of

with

the

scheduler

does

not

fail

i.e.

w

vF

labels

j

OE

-RRB-

fail

then

the

system

meets

the

specification

in

the

resource

model

w

vL

A

j

OE

This

theorem

allows

us

to

split

the

development

of

a

system

into

two

stages

ffl

In

the

first

stage

we

use

the

standard

model

and

refinement

rules

to

derive

an

initial

design

i.e.

a

program

without

a

scheduler

ffl

In

the

second

stage

we

design

a

scheduler

for

the

system

The

theorem

says

that

if

the

scheduling

is

done

correctly

i.e.

the

system

never

fails

then

the

complete

system

derived

in

the

second

stage

still

meets

the

functional

specification

as

in

the

first

stage

The

following

lemma

will

be

very

useful

in

proving

the

third

of

the

above

conditions

Lemma

If

the

agents

and

with

scheduler

OE

use

resources

and

respectively

and

do

not

fail

j

OE

-RRB-

Rreq

fail

j

OE

-RRB-

Rreq

fail

such

that

and

-LSB-

Rav

then

j

j

OE

-RRB-

fail

Specification

macros

Earlier

we

introduced

the

write

and

stable

macros

In

this

section

we

present

some

more

specification

macros

for

helping

in

structuring

specifications

The

idea

is

that

the

macros

are

quite

close

to

natural

language

and

so

are

easily

understood

but

are

completely

formal

The

macros

have

many

similarities

with

the

specification

macros

for

Timed

CSP

presented

in

-LSB-

-RSB-

We

will

often

want

to

say

that

a

particular

shunt

s

is

written

to

at

some

time

t

we

write

s

at

t

to

specify

this

which

is

formally

defined

by

s

at

t

b

s@t

ts

t

We

can

generalize

this

to

specify

that

s

is

written

to

at

some

time

during

interval

I

s

at

I

b

t

I

s

at

t

We

will

also

want

to

be

able

to

talk

about

the

sequence

of

values

written

to

s

which

we

define

using

a

sequence

comprehension

trace

s

b

hs@t

v

j

t

-LSB-

t

t

-RSB-

s

at

ti

We

generalize

this

to

talk

about

the

values

written

before

some

time

t

trace

s

before

t

b

hs@t

v

j

t

-LSB-

t

t

-RSB-

t

t

s

at

t

i

It

will

often

be

useful

to

make

an

environmental

assumption

that

inputs

to

shunts

do

not

occur

too

frequently

constancy

-LRB-

s

t

-RRB-

is

true

if

successive

writes

to

s

are

separated

by

an

interval

of

at

least

t

constancy

-LRB-

s

t

-RRB-

b

s

at

s

at

-RRB-

j

t

This

can

be

generalized

to

a

set

of

shunts

constancy

-LRB-

S

t

-RRB-

b

S

at

at

-RRB-

j

t

The

following

predicate

states

that

the

values

written

on

shunt

s

are

the

same

as

those

written

on

s

except

they

are

delayed

by

up

to

time

d

s

d-delayed

s

b

s@t

s

@t

t

-LSB-

t

t

-RSB-

write

-LRB-

v

s

t

-RRB-

-RRB-

write

-LRB-

v

s

-LSB-

t

t

d

-RSB-

-RRB-

trace

s

before

t

trace

s

before

t

Note

that

s

d-delayed

s

-RRB-

t

-LSB-

t

t

-RSB-

t

-LSB-

t

d

t

-RSB-

s@t

v

s

@t

v

t

-LSB-

t

t

d

-RSB-

t

-LSB-

t

t

d

-RSB-

s

@t

v

s@t

v

We

can

prove

a

few

lemmas

concerning

the

delayed

macro

Lemma

-LRB-

delay

-RRB-

s

delayed

s

t

-LSB-

t

t

-RSB-

s@t

s

@t

Lemma

-LRB-

Increase

delays

-RRB-

If

d

d

then

s

d-delayed

s

-RRB-

s

d

delayed

s

Lemma

-LRB-

Delays

with

constancy

-RRB-

If

constancy

-LRB-

s

d

-RRB-

then

s

d-delayed

s

s@t

s

@t

t

-LSB-

t

t

-RSB-

write

-LRB-

v

s

t

-RRB-

-RRB-

write

-LRB-

v

s

-LSB-

t

t

d

-RSB-

-RRB-

write

-LRB-

v

s

t

-RRB-

-RRB-

write

-LRB-

v

s

-LSB-

t

d

t

-RSB-

-RRB-

Lemma

-LRB-

Chain

delays

-RRB-

s

d-delayed

s

s

d

delayed

s

-RRB-

s

-LRB-

d

d

-RRB-

delayed

s

A

technique

for

writing

timed

specifications

In

this

section

we

develop

a

technique

for

specifying

systems

based

upon

separating

the

functional

and

temporal

parts

of

the

specification

We

believe

that

this

makes

specifying

systems

easier

We

will

also

present

results

that

help

to

transform

such

specifications

into

code

We

begin

with

an

example

Suppose

we

want

to

specify

a

system

that

inputs

natural

numbers

on

channel

in

and

outputs

their

squares

on

channel

out

within

seconds

Specifying

this

formally

yet

concisely

is

remarkably

difficult

many

plausible

looking

specifications

prove

incorrect

under

closer

examination

For

example

one

naive

attempt

at

specifying

this

would

be

t

-LSB-

t

t

-RSB-

write

-LRB-

n

in

t

-RRB-

-RRB-

write

-LRB-

out

-LSB-

t

t

-RSB-

-RRB-

However

this

specification

allows

the

agent

to

generate

spurious

outputs

An

improvement

would

be

to

add

a

conjunct

t

-LSB-

t

t

-RSB-

write

-LRB-

out

t

-RRB-

-RRB-

write

-LRB-

n

in

-LSB-

t

t

-RSB-

-RRB-

However

this

is

still

not

right

if

two

inputs

may

occur

very

close

in

time

to

one

another

the

specification

allows

the

corresponding

outputs

to

occur

in

the

opposite

order

it

also

allows

two

identical

inputs

to

be

combined

to

give

a

single

output

Our

approach

will

be

to

consider

a

virtual

-LRB-

i.e.

imaginary

-RRB-

channel

out

which

always

holds

the

square

of

the

current

input

without

any

delay

Our

specification

then

consists

of

two

parts

ffl

out

always

holds

the

square

of

the

value

on

in

ffl

out

is

a

delayed

copy

of

out

Formally

out

-LRB-

t

-LSB-

t

t

-RSB-

out

@t

v

in@t

v

-RRB-

out

delayed

out

This

form

of

specification

will

be

sufficiently

useful

that

we

introduce

a

specification

macro

for

it

Definition

-LRB-

Delay

-RRB-

Let

spec

be

a

specification

over

two

channels

in

and

out

Then

Delay

-LRB-

spec

in

out

d

-RRB-

b

out

spec

-LRB-

in

out

-RRB-

out

d-delayed

out

For

example

the

above

specification

can

be

written

as

Delay

-LRB-

spec

in

out

-RRB-

where

spec

-LRB-

in

out

-RRB-

b

t

-LSB-

t

t

-RSB-

out

@t

v

in@t

v

This

specification

technique

allows

us

to

separate

the

functional

and

timeliness

parts

of

the

specification

It

can

be

thought

of

as

firstly

specifying

how

we

would

like

our

system

to

behave

if

we

had

an

infinitely

fast

computer

-LRB-

or

equivalently

if

our

time

granularity

were

very

large

-RRB-

and

then

introducing

the

possibility

of

delays

In

the

above

example

we

would

ideally

like

inputs

to

be

squared

and

output

immediately

as

specified

by

spec

but

this

is

unfeasible

so

we

allow

a

delay

of

up

to

seconds

introduced

by

the

Delay

macro

The

following

lemma

allows

us

to

decrease

delays

or

to

strengthen

the

delayed

specification

Lemma

-LRB-

Monotonicity

of

Delay

-RRB-

If

d

d

and

spec

-RRB-

then

Delay

-LRB-

spec

in

out

d

-RRB-

-RRB-

Delay

-LRB-

in

out

d

-RRB-

The

following

theorem

allows

two

delayed

specifications

to

be

chained

together

Theorem

-LRB-

Chaining

of

Delays

-RRB-

If

d

is

such

that

-LRB-

in

mid

-RRB-

-LRB-

mid

out

-RRB-

mid

d-delayed

mid

-RRB-

out

-LRB-

mid

out

-RRB-

out

d

delayed

out

-LRB-

-RRB-

then

Delay

-LRB-

in

mid

d

-RRB-

Delay

-LRB-

mid

out

d

-RRB-

-RRB-

Delay

-LRB-

in

out

d

d

-RRB-

where

-LRB-

-RRB-

-LRB-

in

out

-RRB-

b

mid

-LRB-

in

mid

-RRB-

-LRB-

mid

out

-RRB-

The

condition

-LRB-

-RRB-

says

that

if

the

shunts

in

and

mid

satisfy

and

mid

and

out

satisfy

and

mid

is

a

d-delayed

copy

of

mid

then

out

is

a

d

delayed

version

of

some

shunt

out

such

that

mid

and

out

satisfy

We

will

normally

take

d

d

but

sometimes

we

will

be

able

to

take

d

or

some

other

value

This

theorem

follows

from

the

more

general

rule

for

chaining

Delays

given

below

We

can

generalize

the

Delay

macro

to

more

than

one

input

Delay

-LRB-

spec

inn

out

d

-RRB-

b

out

spec

-LRB-

inn

out

-RRB-

out

d-delayed

out

Here

spec

takes

n

inputs

and

gives

one

output

Henceforth

we

will

write

in

as

shorthand

for

inn

etc.

Suppose

we

have

a

vector

of

input

shunts

in

a

vector

of

intermediate

shunts

mid

and

an

output

shunt

out

such

that

each

intermediate

shunt

midi

is

related

to

the

inputs

by

speci

delayed

by

di

and

the

output

is

related

to

the

intermediate

values

by

spec

delayed

by

d

The

following

theorem

relates

the

output

to

the

inputs

directly

Theorem

-LRB-

Chaining

of

Delays

-RRB-

If

d

is

such

that

spec

-LRB-

mid

out

-RRB-

i

n

speci

-LRB-

in

mid

i

-RRB-

midi

di

delayed

mid

i

-RRB-

out

spec

-LRB-

mid

out

-RRB-

out

d

delayed

out

-LRB-

-RRB-

then

i

n

Delay

-LRB-

speci

in

midi

di

-RRB-

Delay

-LRB-

spec

mid

out

d

-RRB-

-RRB-

Delay

-LRB-

d

spec

in

out

d

d

-RRB-

where

-LRB-

d

spec

-RRB-

-LRB-

in

out

-RRB-

b

mid

-LRB-

i

n

speci

-LRB-

in

midi

-RRB-

-RRB-

spec

-LRB-

mid

out

-RRB-

We

will

often

take

d

maxfdi

j

i

ng

Proof

Assume

condition

-LRB-

-RRB-

We

have

i

n

Delay

-LRB-

speci

in

midi

di

-RRB-

Delay

-LRB-

spec

mid

out

d

-RRB-

-RRB-

D

definition

of

Delay

E

out

mid

i

n

speci

-LRB-

in

mid

i

-RRB-

midi

di

delayed

mid

i

spec

-LRB-

mid

out

-RRB-

out

d-delayed

out

-RRB-

D

condition

-LRB-

-RRB-

E

out

mid

out

i

n

speci

-LRB-

in

mid

i

-RRB-

spec

-LRB-

mid

out

-RRB-

out

d

delayed

out

out

d-delayed

out

-RRB-

D

definition

of

d

spec

lemma

E

out

d

spec

-LRB-

in

out

-RRB-

out

-LRB-

d

d

-RRB-

delayed

out

-RRB-

D

definition

of

Delay

E

Delay

-LRB-

d

spec

in

out

d

d

-RRB-

Note

that

in

the

above

we

have

assumed

that

each

intermediate

value

midi

is

related

to

all

the

inputs

by

some

specification

speci

in

practice

speci

will

mention

only

some

of

the

inputs

but

we

can

still

use

the

above

theorem

by

implicitly

adding

extra

arguments

to

speci

Note

also

that

the

theorem

assumes

that

there

is

a

specification

speci

for

every

midi

in

practice

some

of

the

midi

s

will

themselves

be

inputs

and

used

to

calculate

some

other

intermediate

values

When

this

happens

we

can

still

use

the

theorem

if

s

is

such

a

shunt

used

both

as

an

input

and

an

intermediate

value

then

we

treat

s

as

an

input

and

introduce

another

intermediate

shunt

s

such

that

Delay

-LRB-

EQUAL

s

s

-RRB-

where

EQUAL

-LRB-

s

s

-RRB-

b

t

s@t

s

@t

We

then

replace

references

to

s

in

spec

by

s

But

from

the

above

we

know

that

t

s@t

s

@t

so

we

can

treat

s

and

s

as

equal

We

will

not

bother

to

explicitly

state

when

we

use

this

trick

The

case

study

Our

case

study

concerns

the

software

requirements

of

the

aircraft

's

Operational

Flight

Program

-LSB-

-RSB-

This

system

exhibits

hard

real-time

behaviour

in

processing

of

pilot

data

entry

and

the

control

of

a

screen

and

confirmation

lights

It

has

already

been

studied

in

detail

and

we

are

therefore

able

to

compare

our

results

with

alternative

solutions

We

take

our

informal

requirements

from

Heitmeyer

and

Labaw

's

specification

in

RTL

-LSB-

-RSB-

The

Operational

Flight

Program

is

concerned

with

five

elements

an

alphanumeric

keyboard

which

is

used

for

data

entry

a

data

entry

button

which

is

used

by

the

pilot

to

signal

that

he

is

about

to

start

entering

data

a

data

accept

button

used

to

signal

the

end

of

data

entry

a

screen

on

which

input

is

echoed

and

a

confirmation

light

used

to

signal

to

the

pilot

that

he

may

input

data

The

pilot

is

required

to

follow

a

strict

protocol

designed

to

reduce

the

risk

of

invalid

or

spurious

data

entry

Firstly

he

must

press

the

data

entry

button

the

system

will

then

respond

by

turning

on

the

confirmation

light

and

clearing

the

screen

The

pilot

may

now

enter

the

data

which

will

appear

on

the

screen

as

he

types

When

the

pilot

has

completed

entry

he

must

read

it

before

pressing

the

data

accept

button

at

which

stage

the

confirmation

light

will

go

out

If

the

pilot

does

not

leave

a

sufficient

pause

between

typing

the

last

key

and

pressing

the

accept

button

-LRB-

at

least

time

tacpt

-RRB-

then

pressing

the

accept

button

is

invalid

and

will

be

ignored

Formal

specification

We

will

model

each

of

the

inputs

and

outputs

as

shunts

For

the

data

entry

button

accept

button

and

screen

clear

we

are

not

interested

in

the

values

passed

only

their

time

stamps

we

therefore

assume

that

they

are

of

type

Unit

a

type

containing

only

one

value

We

have

three

input

shunts

the

data

entry

button

the

accept

button

and

the

keyboard

DEB

Time

Unit

-LRB-

data

entry

button

-RRB-

ACPT

Time

Unit

-LRB-

accept

button

-RRB-

KYBD

Time

Key

-LRB-

keyboard

-RRB-

We

do

not

further

specify

the

type

Key

of

keyboard

entries

except

that

it

is

finite

We

have

three

output

shunts

the

confirmation

light

the

display

and

the

screen

clear

CONF

Time

Bool

-LRB-

confirmation

light

-RRB-

DSPLY

Time

Key

-LRB-

display

-RRB-

SCLR

Time

Unit

-LRB-

screen

clear

-RRB-

We

now

formalize

our

specification

We

assume

that

the

informal

requirements

are

to

be

met

after

some

warming-up

period

of

length

tinit

We

would

like

the

requirements

to

be

met

for

ever

but

the

models

of

TAM

deal

only

with

finite

executions

so

we

will

specify

that

the

requirements

are

to

be

met

until

some

time

T

which

we

can

take

to

be

arbitrarily

large

Hence

each

specification

will

include

a

quantification

t

-LSB-

t

tinit

T

-RSB-

We

define

a

predicate

that

indicates

whether

the

system

is

currently

willing

to

receive

keyboard

input

This

is

true

if

there

is

some

time

t

in

the

past

at

which

the

data

entry

button

was

pressed

such

that

the

accept

button

has

not

been

validly

pressed

since

t

-LRB-

a

press

of

the

accept

button

is

invalid

if

it

occurs

within

tacpt

of

the

previous

key

press

i.e.

if

insufficient

time

was

allowed

for

checking

the

data

-RRB-

acc

-LRB-

DEB

ACPT

KYBD

-RRB-

-LRB-

t

-RRB-

b

t

t

DEB

at

t

t

-LRB-

t

t

-RSB-

ACPT

at

t

KYBD

at

-LSB-

t

tacpt

t

-RSB-

We

will

choose

to

drop

the

arguments

DEB

ACPT

KYBD

where

this

will

not

cause

confusion

Valid

key

presses

should

be

echoed

on

the

screen

within

tdsply

-LRB-

DEB

ACPT

KYBD

DSPLY

-RRB-

b

t

-LSB-

t

tinit

T

-RSB-

write

-LRB-

v

KYBD

t

-RRB-

acc

-LRB-

t

-RRB-

write

-LRB-

v

DSPLY

t

-RRB-

b

Delay

-LRB-

DEB

ACPT

KYBD

DSPLY

tdsply

-RRB-

specifies

that

the

key

presses

are

echoed

immediately

then

introduces

a

delay

of

up

to

tdsply

Here

and

henceforth

we

adopt

the

convention

of

writing

etc.

for

untimed

specifications

and

etc.

for

the

corresponding

timed

specifications

Note

that

is

a

function

of

the

shunts

DEB

ACPT

and

KYBD

because

acc

is

The

keyboard

light

should

be

turned

off

within

tconf

of

leaving

accepting

mode

-LRB-

DEB

ACPT

KYBD

CONF

-RRB-

b

t

-LSB-

t

tinit

T

-RSB-

acc

-LRB-

t

-RRB-

acc

-LRB-

t

-RRB-

write

-LRB-

false

CONF

t

-RRB-

b

Delay

-LRB-

DEB

ACPT

KYBD

CONF

tconf

-RRB-

The

keyboard

light

should

be

turned

on

within

tconf

of

entering

accepting

mode

-LRB-

DEB

ACPT

KYBD

CONF

-RRB-

b

t

-LSB-

t

tinit

T

-RSB-

acc

-LRB-

t

-RRB-

acc

-LRB-

t

-RRB-

write

-LRB-

true

CONF

t

-RRB-

b

Delay

-LRB-

DEB

ACPT

KYBD

CONF

tconf

-RRB-

The

screen

should

be

cleared

within

tsclr

of

entering

accepting

mode

-LRB-

DEB

ACPT

KYBD

SCLR

-RRB-

b

t

-LSB-

t

tinit

T

-RSB-

acc

-LRB-

t

-RRB-

acc

-LRB-

t

-RRB-

SCLR

at

t

b

Delay

-LRB-

DEB

ACPT

KYBD

SCLR

tsclr

-RRB-

In

order

to

achieve

the

above

requirements

it

will

be

necessary

to

make

an

assumption

about

the

environment

in

which

it

operates

namely

that

inputs

occur

with

frequency

no

greater

than

once

every

tkmin

EA

b

constancy

-LRB-

fDEB

ACPT

KYBDg

tkmin

-RRB-

We

assume

that

the

time

parameter

tacpt

is

specified

by

the

customer

but

he

does

not

specify

the

values

tinit

tdsply

tconf

tsclr

and

tkmin

except

that

he

wants

them

as

small

as

possible

during

the

development

of

the

system

we

will

calculate

values

for

the

time

parameters

the

customer

will

then

have

to

decide

whether

these

times

are

acceptable

to

him

We

can

now

write

our

complete

specification

We

may

alter

the

values

held

on

the

output

shunts

and

assuming

the

environmental

assumption

holds

we

must

ensure

to

are

met

SPEC

b

fDSPLY

CONF

SCLRg

EA

-RRB-

Decomposition

The

quantity

acc

-LRB-

t

-RRB-

is

of

central

importance

so

it

seems

sensible

to

introduce

a

shunt

ACC

which

will

hold

its

value

SPEC

v

D

introduce

variable

-LRB-

law

B.

-RRB-

E

shunt

ACC

in

fDSPL

CONF

SCLR

ACCg

EA

-RRB-

Here

and

henceforth

following

Morgan

's

conventions

-LSB-

-RSB-

we

use

the

symbol

to

mark

the

part

of

the

program

that

we

will

continue

to

refine

the

rest

of

the

program

-LRB-

in

the

above

the

shunt

ACC

in

part

-RRB-

is

implicitly

carried

forward

around

it

If

we

want

to

refine

parts

of

the

program

separately

we

will

mark

those

parts

-LRB-

i

-RRB-

-LRB-

ii

-RRB-

etc.

We

will

strengthen

the

specification

to

insist

that

the

shunt

ACC

holds

the

correct

value

however

we

will

of

course

have

some

delay

in

calculating

this

value

so

we

write

a

delayed

specification

Racc

-LRB-

DEB

ACPT

KYBD

ACC

-RRB-

b

t

-LSB-

t

tinit

T

-RSB-

ACC@t

v

acc

-LRB-

DEB

ACPT

KYBD

-RRB-

-LRB-

t

-RRB-

TRacc

b

Delay

-LRB-

Racc

DEB

ACPT

KYBD

ACC

tacc

-RRB-

We

rewrite

the

untimed

requirements

-LCB-

to

use

the

value

of

ACC

-LRB-

ACC

KYBD

DSPLY

-RRB-

b

t

-LSB-

t

tinit

T

-RSB-

write

-LRB-

v

KYBD

t

-RRB-

ACC@t

v

write

-LRB-

v

DSPLY

t

-RRB-

-LRB-

ACC

CONF

-RRB-

b

t

-LSB-

t

tinit

T

-RSB-

ACC@t

v

ACC

-LRB-

t

-RRB-

v

write

-LRB-

false

CONF

t

-RRB-

-LRB-

ACC

CONF

-RRB-

b

t

-LSB-

t

tinit

T

-RSB-

ACC@t

v

ACC

-LRB-

t

-RRB-

v

write

-LRB-

true

CONF

t

-RRB-

-LRB-

ACC

SCLR

-RRB-

b

t

-LSB-

t

tinit

T

-RSB-

ACC@t

v

ACC

-LRB-

t

-RRB-

v

SCLR

at

t

And

we

lift

these

to

timed

specifications

b

Delay

-LRB-

ACC

KYBD

DSPLY

t

dsply

-RRB-

b

Delay

-LRB-

ACC

CONF

t

conf

-RRB-

b

Delay

-LRB-

ACC

CONF

t

conf

-RRB-

b

Delay

-LRB-

ACC

SCLR

t

sclr

-RRB-

We

refine

our

specification

to

use

these

v

fDSPLY

CONF

SCLR

ACCg

EA

-RRB-

TRacc

In

order

to

verify

this

refinement

step

-LRB-

using

law

B.

-RRB-

we

must

prove

EA

TRacc

-RRB-

We

prove

this

in

appendix

A

under

the

conditions

t

dsply

tdsply

t

conf

tacc

tconf

t

sclr

tacc

tsclr

tacc

tkmin

-LRB-

These

conditions

arise

very

naturally

during

the

proof

-RRB-

We

now

split

the

specification

into

four

components

one

controlling

each

of

the

four

shunts

in

the

frame

-LRB-

using

law

B.

-RRB-

v

fDSPLY

g

-LRB-

EA

-RRB-

-RRB-

j

fCONFg

-LRB-

EA

-RRB-

-RRB-

j

fSCLRg

-LRB-

EA

-RRB-

-RRB-

j

fACCg

-LRB-

EA

-RRB-

TRacc

-RRB-

Design

of

components

We

now

exploit

some

symmetry

between

the

conditions

we

have

to

ensure

Each

of

the

four

conditions

and

Racc

satisfies

an

equation

of

the

form

R

-LRB-

M

t

-LSB-

t

tinit

T

-RSB-

Cm

-LRB-

in

t

-RRB-

write

-LRB-

vm

out

t

-RRB-

-LRB-

-RRB-

for

some

disjoint

conditions

CM

For

example

if

we

take

Key

fkm

j

m

M

g

then

can

be

written

as

M

t

-LSB-

t

tinit

T

-RSB-

KYBD@t

-LRB-

t

km

-RRB-

ACC@t

v

write

-LRB-

km

DSPLY

t

-RRB-

Also

there

are

related

conditions

C

m

such

that

by

testing

the

C

m

periodically

we

can

tell

whether

Cm

were

true

at

some

intermediate

time

for

any

times

tn

such

that

ti

-LRB-

t

i

:p

t

-LRB-

i

-RRB-

p

-RSB-

-LRB-

for

suitable

n

and

p

-RRB-

Cm

is

true

at

some

time

between

ti

and

ti

iff

C

m

is

true

when

applied

to

the

values

of

the

inputs

at

ti

and

ti

if

i

n

ti

-LRB-

t

i

:p

t

-LRB-

i

-RRB-

p

-RSB-

then

M

i

n

-LRB-

t

-LRB-

ti

ti

-RSB-

Cm

-LRB-

in

t

-RRB-

-RRB-

C

m

-LRB-

in@ti

ti

ti

-RRB-

-LRB-

-RRB-

For

example

for

we

can

write

C

m

as

KYBD@ti

v

km

KYBD@ti

ts

ti

ACC@ti

v

Further

the

inputs

vary

infrequently

constancy

-LRB-

in

tsep

-RRB-

-LRB-

-RRB-

For

example

the

inputs

KYBD

and

ACC

vary

at

must

every

tkmin

tacc

Lastly

the

Cm

are

true

only

when

an

input

changes

and

so

outputs

must

occur

infrequently

Cm

-LRB-

in

t

-RRB-

-LRB-

in

t

-RRB-

-RRB-

m

m

t

t

jt

t

j

tsep

-LRB-

-RRB-

We

exploit

these

facts

in

the

following

theorem

Theorem

If

equations

-LCB-

are

satisfied

then

foutg

Delay

-LRB-

R

in

out

d

-RRB-

v

var

current

previous

current

ts

previous

ts

in

-LSB-

p

-RSB-

current

ts

Now

currentk

ink

current

ts

maxfcurrent

ts

ts

currentk

tsg

loop

for

n

period

p

previousk

currentk

previous

ts

current

ts

current

ts

Now

currentk

ink

current

ts

maxfcurrent

ts

ts

currentk

tsg

if

ss

M

C

m

-LRB-

current

previous

current

ts

previous

ts

-RRB-

-RRB-

vm

out

endloop

provided

tsep

d

tinit

p

n

:p

T

t

and

d

:p

Proof

We

have

Delay

-LRB-

R

in

out

d

-RRB-

-LRB-

D

definition

of

Delay

condition

E

out

t

-LSB-

t

tinit

T

-RSB-

Cm

-LRB-

in

t

-RRB-

write

-LRB-

vm

out

t

-RRB-

out

d-delayed

out

-LRB-

D

lemma

using

condition

and

the

condition

tsep

d

E

out

t

-LSB-

t

tinit

T

-RSB-

Cm

-LRB-

in

t

-RRB-

write

-LRB-

vm

out

t

-RRB-

out

t

-LSB-

t

T

-RSB-

write

-LRB-

v

out

t

-RRB-

-RRB-

write

-LRB-

v

out

-LSB-

t

t

d

-RSB-

-RRB-

write

-LRB-

v

out

t

-RRB-

-RRB-

write

-LRB-

v

out

-LSB-

t

d

t

-RSB-

-RRB-

-LRB-

D

predicate

calculus

taking

out

as

defined

by

the

first

two

lines

E

t

-LSB-

t

tinit

T

-RSB-

Cm

-LRB-

in

t

-RRB-

-RRB-

write

-LRB-

vm

out

-LSB-

t

t

d

-RSB-

-RRB-

write

-LRB-

vm

out

t

-RRB-

-RRB-

t

-LSB-

t

d

t

-RSB-

Cm

-LRB-

in

t

-RRB-

-LRB-

D

see

below

E

out

at

-LSB-

t

t

p

-RSB-

j

n

tj

-LSB-

t

j

:p

t

-LRB-

j

-RRB-

p

-RRB-

i

n

C

m

-LRB-

in@ti

ti

ti

-RRB-

write

-LRB-

vm

out

-LSB-

ti

t

-LRB-

i

-RRB-

p

-RSB-

-RRB-

out

at

-LRB-

t

i

:p

ti

-RSB-

For

the

last

step

assume

the

right

hand

side

we

will

show

the

left

hand

side

Suppose

for

some

t

-LSB-

t

tinit

T

-RSB-

Cm

-LRB-

in

t

-RRB-

Then

because

tinit

p

and

n

:p

T

t

we

have

t

-LRB-

ti

ti

-RSB-

for

some

i

n

Then

from

condi

tion

C

m

-LRB-

in@ti

ti

ti

-RRB-

so

write

-LRB-

vm

out

-LSB-

ti

t

-LRB-

i

-RRB-

p

-RSB-

-RRB-

from

the

assumption

hence

write

-LRB-

vm

out

-LSB-

t

t

d

-RSB-

-RRB-

because

d

:p

Now

suppose

for

some

t

-LSB-

t

tinit

T

-RSB-

write

-LRB-

vm

out

t

-RRB-

Then

as

above

t

-LRB-

ti

ti

-RSB-

for

some

i

n

But

out

at

-LRB-

t

i

:p

ti

-RSB-

so

t

-LRB-

ti

t

i

:p

-RSB-

also

out

at

-LSB-

t

t

p

-RSB-

so

i

Hence

taking

j

i

we

have

C

m

-LRB-

in@tj

tj

tj

-RRB-

from

the

assumption

and

so

from

condition

there

exists

some

t

-LRB-

tj

tj

-RSB-

such

that

Cm

-LRB-

in

t

-RRB-

but

t

-LSB-

t

d

t

-RSB-

because

d

:p

as

required

Hence

we

have

foutg

Delay

-LRB-

spec

in

out

d

-RRB-

v

D

strengthen

specification

E

foutg

out

at

-LSB-

t

t

p

-RSB-

j

n

tj

-LSB-

t

j

:p

t

-LRB-

j

-RRB-

p

-RRB-

i

n

C

m

-LRB-

in@ti

ti

ti

-RRB-

write

-LRB-

vm

out

-LSB-

ti

t

-LRB-

i

-RRB-

p

-RSB-

-RRB-

out

at

-LRB-

t

i

:p

ti

-RSB-

v

D

introduce

variables

-LRB-

law

B.

-RRB-

strengthen

specification

E

var

current

previous

current

ts

previous

ts

in

fout

current

previous

current

ts

previous

tsg

out

at

-LSB-

t

t

p

-RSB-

j

n

tj

-LSB-

t

j

:p

t

-LRB-

j

-RRB-

p

-RRB-

i

n

C

m

-LRB-

in@ti

ti

ti

-RRB-

write

-LRB-

vm

out

-LSB-

ti

t

-LRB-

i

-RRB-

p

-RSB-

-RRB-

out

at

-LRB-

t

i

:p

ti

-RSB-

current

-LRB-

t

i

:p

-RRB-

current

ts

-LRB-

t

i

:p

-RRB-

ti

v

D

strengthen

specification

E

fout

current

previous

current

ts

previous

tsg

out

at

-LSB-

t

t

p

-RSB-

-LSB-

t

t

p

-RRB-

current

-LRB-

t

p

-RRB-

current

ts

-LRB-

t

p

-RRB-

i

n

ti

-LSB-

t

i

:p

t

-LRB-

i

-RRB-

p

-RRB-

C

m

-LRB-

in@ti

current

-LRB-

t

i

:p

-RRB-

ti

current

ts

-LRB-

t

i

:p

-RRB-

-RRB-

write

-LRB-

vm

out

-LSB-

ti

t

-LRB-

i

-RRB-

p

-RSB-

-RRB-

out

at

-LRB-

t

i

:p

ti

-RSB-

current

-LRB-

t

-LRB-

i

-RRB-

p

-RRB-

in@ti

current

ts

-LRB-

t

-LRB-

i

-RRB-

:p

-RRB-

ti

v

D

introduce

sequential

composition

-LRB-

law

B.

-RRB-

introduce

loop

-LRB-

law

B.

-RRB-

E

fcurrent

current

tsg

t

t

p

-LSB-

t

t

-RRB-

current@t!

current

ts@t!

-LRB-

i

-RRB-

loop

for

n

period

p

fout

current

previous

current

ts

previous

tsg

t

-LSB-

t

t

-RRB-

C

m

-LRB-

in@t

current@t

t

current

ts@t

-RRB-

write

-LRB-

vm

out

-LSB-

t

t

-RSB-

-RRB-

out

at

-LRB-

t

t

-RSB-

current@t!

in@t

current

ts@t!

t

endloop

v

D

introduce

sequential

composition

-LRB-

law

B.

-RRB-

E

fprevious

previous

tsg

previous@t!

current@t

previous

ts@t!

current

ts@t

-RRB-

-LRB-

ii

-RRB-

fcurrent

current

tsg

t

-LSB-

t

t

-RRB-

current@t!

in@t

current

ts@t!

t

-RRB-

-LRB-

iii

-RRB-

foutg

C

m

-LRB-

current@t

previous@t

current

ts@t

previous

ts@t

-RRB-

write

-LRB-

vm

out

-LSB-

t

t

-RSB-

-RRB-

v

D

introduce

alternation

-LRB-

law

B.

-RRB-

E

if

ss

M

C

m

-LRB-

current

previous

current

ts

previous

ts

-RRB-

-RRB-

foutg

write

-LRB-

vm

out

-LSB-

t

t

-RSB-

-RRB-

v

D

introduce

shunt

write

-LRB-

law

B.

-RRB-

E

if

ss

M

C

m

-LRB-

current

previous

current

ts

previous

ts

-RRB-

-RRB-

vm

out

The

final

step

is

to

refine

-LRB-

i

-RRB-

-LCB-

-LRB-

iii

-RRB-

above

using

laws

B.

B.

B.

and

B.

-LRB-

i

-RRB-

v

-LSB-

p

-RSB-

current

ts

Now

currentk

ink

current

ts

maxfcurrent

ts

ts

currentk

tsg

-LRB-

ii

-RRB-

v

previousk

currentk

previous

ts

current

ts

-LRB-

iii

-RRB-

v

current

ts

Now

currentk

ink

current

ts

maxfcurrent

ts

ts

currentk

tsg

Note

that

the

shunt

reads

are

correct

even

if

one

of

the

input

shunts

is

written

to

sometime

in

the

middle

by

assumption

-LRB-

condition

-RRB-

at

most

one

shunt

is

written

to

if

a

shunt

is

written

to

at

some

time

t

before

it

is

read

then

each

currenti

ends

up

holding

the

value

of

ini

@t

and

current

ts

ends

up

holding

t

if

no

shunt

is

written

to

before

it

is

read

then

each

currenti

ends

up

holding

the

initial

value

of

the

corresponding

ini

and

current

ts

ends

up

holding

a

corresponding

time

Collecting

code

gives

us

the

desired

program

We

now

apply

the

above

theorem

to

each

of

the

components

of

the

system

Display

As

explained

above

we

assume

that

the

set

of

keyboard

inputs

is

given

by

Key

fkm

j

m

M

g

and

define

Cm

-LRB-

KYBD

ACC

t

-RRB-

b

KYBD@t

-LRB-

t

vm

-RRB-

ACC@t

v

vm

b

km

C

m

-LRB-

KYBD@ti

ACC@ti

ti

ti

-RRB-

b

KYBD@ti

v

vm

KYBD@ti

ts

ti

ACC@ti

v

It

is

easily

seen

that

these

definitions

satisfy

the

conditions

-LCB-

if

we

take

tsep

b

tkmin

tacc

so

by

theorem

fDSPLY

g

EA

-RRB-

v

var

current

kybd

current

acc

previous

kybd

previous

acc

current

ts

previous

ts

in

-LSB-

p

-RSB-

B

current

ts

Now

current

kybd

KYBD

current

acc

ACC

current

ts

maxfcurrent

ts

current

kybd

ts

current

acc

tsg

CA

loop

for

n

period

p

previous

kybd

current

kybd

previous

acc

current

acc

previous

ts

current

ts

current

ts

Now

current

kybd

KYBD

current

acc

ACC

current

ts

maxfcurrent

ts

current

kybd

ts

current

acc

tsg

if

ss

M

B

current

kybd

v

vm

current

kybd

ts

previous

ts

current

acc

v

CA

-RRB-

vm

out

endloop

This

program

can

be

further

refined

in

two

ways

Firstly

the

indexed

alternation

can

obviously

be

simplified

to

the

single

test

if

current

kybd

ts

previous

ts

current

acc

v

-RRB-

current

kybd

v

out

Secondly

the

variables

previous

kybd

and

previous

acc

are

never

used

so

can

be

removed

from

the

program

v

Display

Manager

where

Display

Manager

b

var

current

kybd

current

acc

current

ts

previous

ts

in

-LSB-

p

-RSB-

current

ts

Now

current

kybd

KYBD

current

acc

ACC

current

ts

maxfcurrent

ts

current

kybd

ts

current

acc

tsg

loop

for

n

period

p

previous

ts

current

ts

current

ts

Now

current

kybd

KYBD

current

acc

ACC

current

ts

maxfcurrent

ts

current

kybd

ts

current

acc

tsg

if

current

kybd

ts

previous

ts

current

acc

v

-RRB-

current

kybd

v

DSPLY

endloop

Confirmation

light

We

define

-LRB-

ACC

t

-RRB-

b

ACC@t

v

ACC

-LRB-

t

-RRB-

v

-LRB-

ACC

t

-RRB-

b

ACC@t

v

ACC

-LRB-

t

-RRB-

v

b

false

b

true

C

-LRB-

ACC@ti

ti

ti

-RRB-

b

ACC@ti

v

v

C

-LRB-

ACC@ti

ti

ti

-RRB-

b

ACC@ti

v

v

The

conditions

of

theorem

are

satisfied

if

we

take

tsep

b

tkmin

tacc

The

resulting

program

does

not

use

the

variables

current

ts

and

previous

ts

so

we

may

remove

them

to

give

fCONFg

-LRB-

EA

-RRB-

-RRB-

v

Confirmation

Light

Manager

where

Confirmation

Light

Manager

b

var

current

acc

previous

acc

in

-LSB-

p

-RSB-

current

acc

ACC

loop

for

n

period

p

previous

acc

current

acc

current

acc

ACC

if

current

acc

v

previous

acc

v

-RRB-

false

CONF

current

acc

v

previous

acc

v

-RRB-

true

CONF

endloop

Screen

clear

This

is

very

similar

to

the

previous

case

We

define

-LRB-

ACC

t

-RRB-

b

ACC@t

v

ACC

-LRB-

t

-RRB-

v

b

C

-LRB-

ACC@ti

ti

ti

-RRB-

b

ACC@ti

v

v

And

fCONFg

-LRB-

EA

-RRB-

-RRB-

v

Screen

Clear

Manager

where

Screen

Clear

Manager

b

var

current

acc

previous

acc

in

-LSB-

p

-RSB-

current

acc

ACC

loop

for

n

period

p

previous

acc

current

acc

current

acc

ACC

if

current

acc

v

previous

acc

v

-RRB-

CONF

endloop

Accepting

mode

manager

We

define

-LRB-

DEB

ACPT

KYBD

t

-RRB-

b

DEB

at

t

-LRB-

DEB

ACPT

KYBD

t

-RRB-

b

ACPT

at

t

KYBD@t

ts

t

tacpt

b

true

b

false

C

DEB@ti

ACPT@ti

KYBD@ti

ti

ti

b

DEB@ti

ts

ti

C

DEB@ti

ACPT@ti

KYBD@ti

ti

ti

b

ACPT@ti

ts

ti

KYBD@ti

ts

ACPT@ti

ts

tacpt

to

give

fACCg

v

Accepting

Mode

Manager

where

Accepting

Mode

Manager

b

var

current

deb

current

acpt

current

kybd

current

ts

previous

ts

in

-LSB-

p

-RSB-

BBB

current

ts

Now

current

deb

DEB

current

acpt

ACPT

current

kybd

KYBD

current

ts

max

fcurrent

ts

current

deb

ts

current

acpt

ts

current

kybd

tsg

CCCA

loop

for

n

period

p

previous

ts

current

ts

current

ts

Now

current

deb

DEB

current

acpt

ACPT

current

kybd

KYBD

current

ts

max

fcurrent

ts

current

deb

ts

current

acpt

ts

current

kybd

tsg

if

current

deb

ts

previous

ts

-RRB-

true

ACC

current

acpt

ts

ti

current

kybd

ts

current

acpt

ts

tacpt

-RRB-

false

ACC

endloop

Scheduling

We

now

consider

the

problem

of

scheduling

our

program

We

assume

that

we

have

access

to

a

single

CPU

r

Rav

Time

frg

Before

we

can

design

a

scheduler

we

need

to

know

how

long

the

CPU

takes

to

perform

each

atomic

command

and

evaluate

each

guard

in

order

to

keep

the

numbers

fairly

simple

we

assume

that

the

CPU

can

perform

each

atomic

operation

in

one

time

unit

Label

t

Time

#OE

-LRB-

t

L

-RRB-

Formally

our

requirements

can

be

written

as

SPEC

b

fDSPL

CONF

SCLRg

EA

-RRB-

Assuming

the

environmental

assumption

we

must

ensure

to

and

the

agent

must

not

fail

From

the

above

we

know

that

SPEC

vF

Display

Manager

j

Confirmation

Light

Manager

j

Screen

Clear

Manager

j

Accepting

Mode

Manager

So

we

may

use

theorem

to

deduce

that

if

Display

Manager

labels

Display

Manager

Confirmation

Light

Manager

labels

Confirmation

Light

Manager

Screen

Clear

Manager

labels

Screen

Clear

Manager

Accepting

Mode

Manager

labels

Accepting

Mode

Manager

and

L

Display

Manager

j

Confirmation

Light

Manager

j

Screen

Clear

Manager

j

Accepting

Mode

Manager

j

OE

-RRB-

fail

then

SPEC

vL

Display

Manager

j

Confirmation

Light

Manager

j

Screen

Clear

Manager

j

Accepting

Mode

Manager

j

OE

In

designing

the

scheduler

OE

we

will

need

to

make

design

decisions

depending

upon

the

values

given

to

the

time

parameters

tdsply

tconf

and

tsclr

In

practice

our

customer

will

want

our

system

to

make

these

parameters

as

small

as

possible

but

will

have

some

priority

between

them

In

the

rest

of

this

section

we

assume

that

our

customer

is

particularly

keen

for

keyboard

input

to

be

promptly

echoed

on

the

screen

i.e.

he

is

keen

to

see

tdsply

minimised

We

will

therefore

take

the

period

on

the

main

loop

for

the

display

component

to

be

fairly

small

It

seems

important

to

also

have

a

short

period

for

the

accepting

mode

manager

because

delays

here

cause

delays

throughout

the

system

We

make

the

design

decision

to

give

the

display

and

accepting

mode

managers

periods

of

time

units

and

the

confirmation

light

and

screen

clear

managers

periods

of

time

units

By

counting

the

number

of

atomic

commands

in

each

component

we

see

that

this

will

require

time

units

of

CPU

every

time

units

so

this

strategy

appears

likely

to

succeed

We

need

to

split

up

the

CPU

time

between

the

components

which

we

do

as

follows

Component

Resources

available

Display

Manager

f

-LRB-

t

r

-RRB-

j

t

mod

-LSB-

-RRB-

g

Confirmation

Light

Manager

f

-LRB-

t

r

-RRB-

j

t

mod

-LSB-

-RRB-

g

Screen

Clear

Manager

f

-LRB-

t

r

-RRB-

j

t

mod

-LSB-

-RRB-

g

Accepting

Mode

Manager

f

-LRB-

t

r

-RRB-

j

t

mod

-LSB-

-RRB-

g

It

is

easily

seen

that

the

above

resource

sets

are

disjoint

so

by

lemma

it

is

enough

to

design

a

scheduler

OE

such

that

R?Display

Manager

j

OE

-RRB-

Rreq

f

-LRB-

t

r

-RRB-

j

t

mod

-LSB-

-RRB-

g

fail

R?Confirmation

Light

Manager

j

OE

-RRB-

Rreq

f

-LRB-

t

r

-RRB-

j

t

mod

-LSB-

-RRB-

g

fail

R?Screen

Clear

Manager

j

OE

-RRB-

Rreq

f

-LRB-

t

r

-RRB-

j

t

mod

-LSB-

-RRB-

g

fail

R?Accepting

Mode

Manager

j

OE

-RRB-

Rreq

f

-LRB-

t

r

-RRB-

j

t

mod

-LSB-

-RRB-

g

fail

We

examine

the

first

of

these

in

detail

the

rest

are

similar

We

label

the

display

manager

to

obtain

var

current

kybd

current

acc

current

ts

previous

ts

in

-LSB-

-RSB-

BBB

current

ts

Now

current

kybd

KYBD

current

acc

ACC

current

ts

maxfcurrent

ts

current

kybd

ts

current

acc

tsg

CCCA

loop

for

n

period

previous

ts

current

ts

current

ts

Now

current

kybd

KYBD

current

acc

ACC

current

ts

maxfcurrent

ts

current

kybd

ts

current

acc

tsg

if

current

kybd

ts

previous

ts

current

acc

v

-RRB-

current

kybd

v

DSPLY

endloop

And

we

define

a

scheduler

such

that

the

commands

labelled

and

are

delayed

by

seconds

so

that

they

start

at

time

for

some

k

and

schedule

each

of

the

other

commands

immediately

OE

-LRB-

t

-RRB-

b

f

-LRB-

t

r

-RRB-

g

OE

-LRB-

t

-RRB-

b

f

-LRB-

t

r

-RRB-

g

OE

-LRB-

t

-RRB-

b

f

-LRB-

t

r

-RRB-

g

OE

-LRB-

t

-RRB-

b

f

-LRB-

t

r

-RRB-

g

OE

-LRB-

t

-RRB-

b

f

-LRB-

t

r

-RRB-

g

OE

-LRB-

t

-RRB-

b

f

-LRB-

t

r

-RRB-

g

OE

-LRB-

t

-RRB-

b

f

-LRB-

t

r

-RRB-

g

OE

-LRB-

t

-RRB-

b

f

-LRB-

t

r

-RRB-

g

OE

-LRB-

t

-RRB-

b

f

-LRB-

t

r

-RRB-

g

OE

-LRB-

t

-RRB-

b

f

-LRB-

t

r

-RRB-

g

OE

-LRB-

t

-RRB-

b

f

-LRB-

t

r

-RRB-

g

It

is

easily

verified

that

the

program

uses

only

the

available

resources

and

does

not

fail

because

the

deadline

is

met

The

scheduler

we

have

defined

fits

into

the

deadline

monotonic

class

of

schedulers

-LSB-

-RSB-

Finally

we

collect

together

all

the

time

constraints

-LRB-

taking

the

minimum

possible

values

-RRB-

to

obtain

t

dsply

t

conf

t

sclr

tacc

tdsply

tconf

tsclr

tkmin

tinit

Conclusions

In

this

paper

we

have

presented

a

case

study

using

the

Temporal

Agent

Model

We

have

described

a

method

of

separating

the

functional

and

temporal

parts

of

a

specification

using

a

delayed

specification

we

believe

that

this

method

makes

formalizing

many

requirements

much

easier

and

less

error

prone

We

have

presented

a

theorem

-LRB-

theorem

-RRB-

that

allows

us

to

chain

two

such

delayed

specifications

together

this

is

useful

when

we

introduce

new

intermediate

shunts

which

themselves

satisfy

a

delayed

specification

We

have

also

presented

a

theorem

-LRB-

theorem

-RRB-

that

under

certain

circumstances

allows

us

to

refine

such

a

delayed

specification

into

code

We

have

used

delayed

specifications

to

capture

our

system

requirements

and

then

used

the

theorems

to

derive

a

correct

implementation

We

believe

that

the

TAM

refinement

calculus

particularly

using

this

method

of

delayed

specifications

provides

a

very

useful

tool

in

developing

real-time

systems

We

would

like

to

undergo

further

related

case

studies

with

the

hope

of

extending

the

underlying

theory

producing

more

useful

theorems

and

making

the

existing

theorems

easier

to

use

For

example

the

hardest

part

of

applying

theorem

is

proving

condition

it

would

be

useful

to

develop

lemmas

showing

when

this

condition

is

true

The

observant

reader

will

have

noticed

that

the

system

we

have

derived

satisfies

tighter

deadlines

than

we

have

claimed

for

it

For

example

the

component

Display

Manager

-LRB-

with

the

given

scheduler

-RRB-

satisfies

with

a

value

for

tdsply

of

whereas

we

have

only

claimed

this

with

a

value

of

The

reason

for

the

discrepancy

is

that

when

we

have

a

scheduler

there

is

much

more

structure

to

the

design

for

example

in

the

case

of

the

display

manager

the

shunt

reads

always

occur

at

times

k

and

k

and

the

write

occurs

at

time

k

-LRB-

k

n

-RRB-

Repeating

the

proof

of

theorem

including

consideration

of

the

scheduler

would

generate

these

smaller

time

parameters

The

method

of

delayed

specifications

that

we

have

introduced

in

this

paper

are

applicable

not

only

to

TAM

it

would

be

interesting

to

adapt

them

to

other

formalisms

such

as

Timed

CSP

One

weakness

with

the

current

TAM

model

is

that

it

can

deal

only

with

finite

agents

i.e.

agents

that

must

eventually

terminate

this

runs

counter

to

the

paradigm

of

reactive

systems

which

may

execute

for

ever

In

theory

we

can

get

round

this

by

specifying

that

a

system

must

operate

correctly

up

until

time

T

and

then

taking

T

arbitrarily

large

but

in

practice

this

is

awkward

for

we

must

consider

the

value

of

T

in

our

proofs

It

would

therefore

be

useful

to

extend

the

semantic

models

of

TAM

to

include

infinite

behaviour

This

question

is

considered

in

-LSB-

-RSB-

References

-LSB-

-RSB-

N.

C.

Audsely

A.

Burns

M.

F.

Richardson

and

A.

L.

Wellings

Hard

real-time

scheduling

The

deadline

monotonic

approach

In

Proc

IEEE

Workshop

on

Real-Time

Operating

Systems

and

Software

pages

-LCB-

-LSB-

-RSB-

B.

Auernheimer

and

R.

Kemmerer

RT-ASLAN

A

specification

language

for

real-time

systems

IEEE

Transactions

on

Software

Engineering

-LSB-

-RSB-

R.

J.

R.

Back

A

calculus

of

refinements

for

program

derivations

Acta

Informatica

-LCB-

-LSB-

-RSB-

R.

J.

R.

Back

Refinement

calculus

part

II

Parallel

and

reactive

programs

In

de

Baker

de

Roever

and

Rozenberg

editors

Stepwise

Refinement

of

Distributed

Systems

volume

of

LNCS

SpringerVerlag

-LSB-

-RSB-

R.

J.

R.

Back

and

J.

Wright

Refinement

concepts

formalised

in

HOL

Formal

Aspects

of

Computing

-LRB-

-RRB-

-LSB-

-RSB-

Jim

Davies

Specification

and

Proof

in

Real-Time

Systems

Cambridge

University

Press

D.

Phil

thesis

Oxford

University

-LSB-

-RSB-

Jifeng

He

Specification

oriented

semantics

for

ProCoS

programming

language

PLtime

-LSB-

-RSB-

L.

Heitmeyer

and

T.

Labaw

The

aircraft

in

RTL

Technical

Report

Washington

University

-LSB-

-RSB-

F.

Jahanian

and

A.

K.

Mok

Safety

analysis

of

timing

properties

in

real-time

system

IEEE

Transactions

on

Software

Engineering

-LSB-

-RSB-

Gavin

Lowe

Scheduling-oriented

models

for

real-time

systems

Submitted

for

publication

also

available

as

Technical

Report

PRG-TR

Oxford

University

Computing

Laboratory

-LSB-

-RSB-

Gavin

Lowe

Infinite

behaviours

in

the

temporal

agent

model

Technical

Report

Oxford

University

Computing

Laboratory

-LSB-

-RSB-

Carroll

Morgan

Programming

from

Specifications

Prentice

Hall

International

-LSB-

-RSB-

D.

Scholefield

TAM

technical

notes

and

Technical

Report

YCS

University

of

York

-LSB-

-RSB-

D.

Scholefield

H.

Zedan

and

J.

He

A

specification

oriented

semantics

for

the

refinement

of

real-time

systems

Theoretical

Computer

Science

August

A

Proof

of

the

decomposition

step

In

this

appendix

we

prove

the

decomposition

step

from

the

example

EA

TRacc

-RRB-

Proof

We

assume

the

left

hand

side

and

prove

and

the

proofs

of

and

are

very

similar

to

that

of

Proof

of

In

order

to

apply

theorem

we

must

prove

EA

-LRB-

ACC

KYBD

DSPLY

-RRB-

Racc

-LRB-

DEB

ACPT

KYBD

ACC

-RRB-

ACC

tacc-delayed

ACC

-RRB-

-LRB-

ACC

KYBD

DSPLY

-RRB-

DSPLY

d

delayed

DSPLY

Suppose

the

left

hand

side

We

will

prove

the

right

hand

side

by

taking

DSPLY

DSPLY

and

d

so

the

condition

DSPLY

d

delayed

DSPLY

follows

immediately

Note

that

the

environmental

assumption

EA

tells

us

that

if

write

-LRB-

v

KYBD

t

-RRB-

then

there

is

no

other

write

during

-LSB-

t

tkmin

t

-RSB-

so

from

Racc

the

value

of

ACC

is

constant

throughout

this

period

We

show

-LRB-

ACC

KYBD

DSPLY

-RRB-

as

follows

write

-LRB-

v

KYBD

t

-RRB-

ACC

@t

v

-RRB-

D

ACC

constant

by

above

E

write

-LRB-

v

KYBD

t

-RRB-

t

-LSB-

t

tkmin

t

-RSB-

ACC

@t

v

-RRB-

D

ACC

tacc-delayed

ACC

assuming

tacc

tkmin

E

write

-LRB-

v

KYBD

t

-RRB-

ACC@t

v

-RRB-

D

-LRB-

ACC

KYBD

DSPLY

-RRB-

E

write

-LRB-

v

DSPLY

t

-RRB-

Conversely

write

-LRB-

v

DSPLY

t

-RRB-

-RRB-

D

-LRB-

ACC

KYBD

DSPLY

-RRB-

E

write

-LRB-

v

KYBD

t

-RRB-

ACC@t

v

-RRB-

D

ACC

tacc-delayed

ACC

E

write

-LRB-

v

KYBD

t

-RRB-

t

-LSB-

t

tacc

t

-RSB-

ACC

@t

v

-RRB-

D

ACC

constant

by

above

assuming

tacc

tkmin

E

write

-LRB-

v

KYBD

t

-RRB-

ACC

@t

v

We

may

now

apply

theorem

EA

TRacc

-RRB-

D

definitions

E

EA

Delay

-LRB-

Racc

DEB

ACPT

KYBD

ACC

tacc

-RRB-

Delay

-LRB-

ACC

KYBD

DSPLY

t

dsply

-RRB-

-RRB-

D

Using

theorem

and

the

above

E

Delay

-LRB-

R

DEB

ACPT

KYBD

DSPLY

t

dsply

-RRB-

where

R

-LRB-

DEB

ACPT

KYBD

DSPLY

-RRB-

b

Racc

-LRB-

DEB

ACPT

KYBD

ACC

-RRB-

-LRB-

ACC

KYBD

DSPLY

-RRB-

Continuing

with

R

R

-LRB-

DEB

ACPT

KYBD

DSPLY

-RRB-

-RRB-

D

definitions

E

ACC

v

@t

acc

-LRB-

t

-RRB-

write

-LRB-

v

KYBD

t

-RRB-

ACC@t

v

write

-LRB-

v

DSPLY

t

-RRB-

-RRB-

D

predicate

calculus

definition

E

-LRB-

DEB

ACPT

KYBD

DSPLY

-RRB-

Thus

EA

TRacc

-RRB-

as

long

as

t

dsply

tdsply

Proof

of

In

order

to

use

theorem

we

must

prove

EA

-LRB-

ACC

CONF

-RRB-

Racc

-LRB-

DEB

ACPT

KYBD

ACC

-RRB-

ACC

tacc-delayed

ACC

-RRB-

-LRB-

ACC

CONF

-RRB-

CONF

tacc-delayed

CONF

We

define

CONF

by

CONF

write

-LRB-

true

CONF

t

-RRB-

write

-LRB-

true

CONF

t

-RRB-

write

-LRB-

false

CONF

t

-RRB-

ACC

@t

v

ACC

-LRB-

t

-RRB-

v

Clearly

-LRB-

ACC

CONF

-RRB-

In

order

to

prove

CONF

tacc-delayed

CONF

it

is

enough

to

show

write

-LRB-

false

CONF

t

-RRB-

-RRB-

t

-LSB-

t

t

tacc

-RSB-

write

-LRB-

false

CONF

t

-RRB-

write

-LRB-

false

CONF

t

-RRB-

-RRB-

t

-LSB-

t

tacc

t

-RSB-

write

-LRB-

false

CONF

t

-RRB-

We

prove

the

first

of

these

the

second

is

proved

similarly

write

-LRB-

false

CONF

t

-RRB-

-RRB-

D

definition

of

CONF

E

ACC

@t

v

ACC

-LRB-

t

-RRB-

v

-RRB-

D

ACC

tacc-delayed

ACC

E

t

-LSB-

t

t

tacc

-RSB-

ACC@t

v

ACC@t

v

-RRB-

D

-LRB-

ACC

CONF

-RRB-

E

t

-LSB-

t

t

tacc

-RSB-

write

-LRB-

false

CONF

t

-RRB-

We

can

now

use

theorem

EA

TRacc

-RRB-

D

definitions

E

EA

Delay

-LRB-

Racc

DEB

ACPT

KYBD

ACC

tacc

-RRB-

Delay

-LRB-

ACC

CONF

t

conf

-RRB-

-RRB-

D

theorem

using

the

above

E

Delay

-LRB-

R

DEB

ACPT

KYBD

CONF

t

conf

tacc

-RRB-

where

R

-LRB-

DEB

ACPT

KYBD

CONF

-RRB-

b

Racc

-LRB-

DEB

ACPT

KYBD

CONF

-RRB-

-LRB-

ACC

CONF

-RRB-

Continuing

with

R

R

-LRB-

DEB

ACPT

KYBD

CONF

-RRB-

-RRB-

D

definitions

E

t

ACC@t

v

acc

-LRB-

t

-RRB-

ACC@t

v

ACC

-LRB-

t

-RRB-

v

write

-LRB-

false

CONF

t

-RRB-

-RRB-

D

predicate

calculus

definition

E

-LRB-

DEB

ACPT

KYBD

CONF

-RRB-

Thus

EA

TRacc

-RRB-

provided

t

conf

tacc

tconf

B

Some

refinement

laws

In

this

appendix

we

list

the

refinement

laws

that

we

have

used

in

the

case

study

Law

B.

-LRB-

Strengthen

specification

-RRB-

If

-RRB-

then

w

v

w

Law

B.

-LRB-

New

shunt

-RRB-

w

v

shunt

w

in

w

-LSB-

w

Law

B.

-LRB-

New

variable

-RRB-

w

v

var

w

in

w

-LSB-

w

Law

B.

-LRB-

Parallel

composition

-RRB-

If

w

w

and

t

does

not

appear

free

in

or

then

w

-LSB-

w

v

-LRB-

w

-RRB-

j

-LRB-

w

-RRB-

Law

B.

-LRB-

Sequential

composition

-RRB-

w

t

-LSB-

t

t

-RSB-

-LSB-

t

t

-RSB-

v

-LRB-

w

-RRB-

-LRB-

w

-RRB-

Law

B.

-LRB-

Periodic

loop

-RRB-

For

p

Z

-LRB-

the

period

of

the

loop

-RRB-

w

k

-LSB-

n

-RRB-

-LSB-

p

k

t

-LRB-

p

-RRB-

k

t

-RSB-

v

loop

for

n

period

p

-LRB-

w

-RRB-

Law

B.

-LRB-

Alternation

-RRB-

If

B

t

i

I

gi

i

-LSB-

t

t

t

-RSB-

stable

-LRB-

w

t

t

t

-RRB-

i

I

gi

stable

-LRB-

w

t

t

-RRB-

t

t

CA

-RRB-

then

w

v

if

ss

gi

-RRB-

w

i

Law

B.

-LRB-

Deadline

-RRB-

w

-LRB-

t

t

t

-RRB-

v

-LSB-

t

-RSB-

-LRB-

w

-RRB-

Law

B.

-LRB-

Shunt

write

-RRB-

If

s

w

then

w

write

-LRB-

s

x

-LSB-

t

t

-RSB-

-RRB-

v

x

s.

Law

B.

-LRB-

Shunt

read

-RRB-

If

x

w

then

w

t

-LSB-

t

t

-RSB-

x@t!

s@t

v

x

s

Law

B.

-LRB-

Assignment

-RRB-

If

x

w

then

w

t

-LSB-

t

t

-RSB-

x@t!

e@t

v

x

e

design
refinement calculus
scheduling
specification
tam