Technische Universität München Institut für Informatik D-80290 München, Germany Realizability of System Interface Specifications Manfred Broy

Technische Universität MünchenInstitut für Informatik

D-80290 München, Germany

Realizability of System Interface Specifications

Manfred Broy

Manfred Broy 2Amir Pnueli Memorial Symposium, May 2010

Motivation

• State machines with input and output (generalized Mealy machines) provide a concept of implementation of discrete systems

• Behavioral abstraction by the concept of interface behavior◊ Interface abstraction for state machines with input and output

• Interface assertions◊ Specification of interface behavior

• Realizability as a condition that interface assertions have implementations by state machines

• Nonrealizable specifications◊ Safety and realizability ◊ Liveness and realizability


Types and channels

• A type is (for our purpose) a set of messages (signals, events);

Let M be the universe of all messages of all types

• A channel is a name for a communication link in a system

Typed channel set C:

• a set of names in C

• a function

typeC : C Type

where Type is the set of types;

• A snapshot valuation for a channel set C is a mapping

v: C M

where v(c) is of type type(c) for all c C;

by Val[C] we denote the set of all channel snapshot valuations


The system model: static interface

The static (syntactic) interface of a system is given by

• a set I of typed input channels

• a set O of typed output channels

The static interface then is denoted by

I » O

Fresh x: Write y: Val

z: Get


Streams and Channel Histories

• a stream s of type T is an infinite sequence of elements of type T represented by the mapping

s: IN+ T where

IN+ = IN \ {0}STREAM denotes the set of all streams

• A channel history z for the typed channel set C is a mapping that associates a stream with every channel in C

z: C STREAMBy IH[C] we denote the set of all histories

Notation:xt prefix of length t of the history or stream x


State Machines with Input and Output

A state machine (, ) with input and output for static interface I » O

is given by

• a state space , which represents a set of states,

• a set of initial states

• a state transition function: ( Val[I]) ( Val[O])

For each

• state and each

• valuation Val[I] of the input channels in I by messages we get by

(', ) (, )

a successor state ' and a valuation Val[O] of the output channels consisting of the messages produced by the state transition.

Such state machines are also called Mealy machines.


Classes of state machines

A state machine (, ) is called

• total, if for all states and all inputs IH[I] the sets (, ) and are not empty; otherwise the machine (, ) is called partial.

• deterministic, if and (, ) are sets with at most one element for all states and input Val[I].

• bounded choice, if and (, ) are finite sets for all states and input Val[I]


Computations of State Machines

• a stream x of input : x1 , x2, …

• a stream y of output : y1 , y2, …

• a stream s of states : 0 , 1, …

• A computation generated state machine (, ) on input history x IH[I] and the initial state 0 is defined choosing step by step

(i+1, yi+1) (i, xi+1)

it computes the output history y IH[O] that way.

• Comp(, ) denotes the set of pairs (x, y) where y IH[O] is an output history computed by state machine (, ) on input history x IH[I] and initial state 0

0 1 2 …

x1/y1 x2 /y2


Interface function and interface abstraction

For syntactic interface I » O an interface function

is given by

F : IH[I] (IH[O])

A state machine (, ) defines an interface abstraction

F(, ) : IH[I] (IH[O])

F(, )(x) = {y: (x, y) Comp(, )}


Interface assertions

For static interface I»O a logical formula R

• which contains the input and output channels in I and O as free variables for streams is called

interface assertion

Interface assertion R defines

• a predicate R(x, y) on histories x and y

• and an associated interface function F:y F(y) R(x, y)

A state machine (, ) is correct for interface assertion R if

(x, y) Comp(, ) R(x, y)


A Specification Example

System Fresh delivers always the newest value of xTypes

• Write = {d Data}

• Get = {get, “-”}

• Val = {d Data}

The logical specification: t:

z(t) = get y(t+1) = last(x, t) z(t) = “-” y(t+1) = “-”

where:last(x, 0) = d0

last(x, t+1) = if x(t) “-” then x(t) else last(x, t) fi

Note that this system is very difficult to describe with

shared variables and access to shared variables by assignments.

Fresh x: Write y: Val

z: Get


Causality

A functionF : IH[I] (IH[O])

that fulfils the proposition (for all t, x, y)

xt = x’t {yt+k: y F(x)} = yt+k: y F(x’)}

is called k-delayed.

• 0-delayed functions are called causal

• 1-delayed functions are called strongly causal

A causal function is also called an interface behaviour.


Definition: Realizability

Interface assertion R and associated behavior F and is called realizable,

if there exists a (strongly) causal total function

f : IH[I] IH[O]such that

R(x, f(x)) x IH[I] : f(x) F(x)

Then

• f is called a (strong) realization of F (and R)

• y F(x) is called realizable if there exists a realization f with y = f(x)

• F (and R) are called fully realizable if every y F(x) is realizable

• By [[F]] we denote the set of all realizations of F


Example: Nonrealizable causal interface assertion

Consider the interface specification

R(x, y) = [x ≠ y]

Facts:

• the behavior associated with R is strongly causal

• R is a liveness property

• R is not realizable


Realizability and state machines

Theorem

Interface assertion R and associated behavior F and are

realizable,

iff there exists a total deterministic state machine that is

correct for R.


Theorem: Realizability

For each interface specification R:

there exist a state machine that is correct for R

iff

R realizable.


Theorems on interface abstraction

An interface abstraction F(, ) of a total Mealy machine (, )

is always

• causal

• strongly causal, if (, ) is a Moore machine

• fully realizable.


Realizability of interface specification R

Questions:

• Is causality a sufficient condition for realizability

• Under which conditions is R realizable

• Realizability of contracts (assumption/commitment specifications)

• The role of safety and liveness of R for realizability


Causality and realizability

Theorem:

An interface assertion R is realizable iff there exist a

realizable causal interface assertion R’ with

R’ R


Conditions for realizability

Theorem:

If the formula x: y: R(x, y)

does not holds, then

the causal interface specification R is not realizable


Notation

Let P be a predicate about histories.

We writeP(xt)

for the formula x’: xt = x’t P(x’)


Characterizing Safety and Liveness

An interface assertion R is a safety property if for all x and y:

R(x, y) t: R(xt, yt)

Interface assertion R is a liveness property if for all x and y

t: R(xt, yt)


Safety Realizability

Theorem:

A causal safety interface specification R

is fully realizable iff the formula

x: y: R(x, y)

holds.


Bounded choice and safety

Theorem

If a total state machine (, ) is bounded choice then its associated interface assertion

(x, y) Comp(, )

is a safety property.


Liveness requires unbounded choice

Theorem

Every fully realizable liveness property can be implemented by an unbounded choice state machine.


Example. Nonrealizable Specification

Consider a system

• with only one input channel x and

• one output channel y both carrying Boolean messages with specification

R(x, y) = [ (true#x < true#y = ) (true#x = true#y < ) ]

Here true#x denotes the number of messages in stream x.Both assertions are liveness properties and so is predicate R. Obviously,

x: y: R(x, y)Note the assertion

true#x < ∞as well as its negation

true#x = ∞are both liveness conditions.


Conclusion

• Causality and realizability are mandatory properties for interface specification

• There is a difference between logical inconsistency and nonrealizability

• Safety is simple for realizability

• Liveness is tricky for realizability

• Realizability and causality provide healthy conditions for contracts

Documents

Technische Universität München Institut für Informatik D-80290 München, Germany Realizability of System Interface Specifications Manfred Broy