Interface Theories in Practice Luca de Alfaro UC Santa Cruz GDV 2006

Interface Theories in Practice

Luca de AlfaroUC Santa Cruz

GDV 2006

Theory

(In theory, many things work...)

Collaborators: Tom HenzingerMarielle Stoelinga

Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice)

• Transition systems: 1 decision

• Closed systems: 1 actor – Output: hat outputs can be generated?

• Games: 2 decisions

• Open Systems: 2 actors:

– Input: what inputs to give next?

– Output: what outputs to generate next?

• Model open systems as games, rather than transition systems.


















send!

msg?

msg? send!

ack?

nack?fail!

ok!

ack? nack?

ok! fail!

A Game Model

Input moves: the inputs that are allowed.

Output moves: the outputs that can be generated.


send!

msg?

msg? send!

ack?

nack?fail!

ok!ack?nack?

msg?

*?

*?

*?

ack? nack?

ok! fail!

send!

msg?

msg? send!

ack?

nack?fail!

ok!

ack? nack?

ok! fail!

A Game Model

Input moves: the inputs that are allowed.


A Transition-System Model


Input moves: always accepted (input enabled).


send!

msg?

msg? send!

ack?

nack?fail!

ok!ack?nack?

msg?

*?

*?

*?

ack? nack?

ok! fail!

send!

msg?

msg? send!

ack?

nack?fail!

ok!

ack? nack?

ok! fail!

A Game Model A Transition-System Model

What is the difference??

• Refinement

• Composition


Simulation as Open System Refinement?

Q¹

Pµµ



Often, it is defined as transition system refinement. However:

• If P accepts fewer inputs, it is usable in fewer ways.

• Indeed, we cannot plug P for Q in a design.

Q¹

Pµµ?



Often, it is defined as transition system refinement. However:

• If P accepts fewer inputs, it is usable in fewer ways.

• Indeed, we cannot plug P for Q in a design.

Q¹

Pµµ?

Simulation is not the proper notion of refinement for open systems!


To define open-system refinement, let’s look at type theory

Dom()

Dom()

Im()

Im()

¹ µ

µ

Subtyping is Domain/Image contravariant


Open System Refinement

¹ µ

µ

This is alternating simulation, the notion of refinement for games![Alur,K,Henzinger,V CONCUR98]


TS: Simulation

Spec

Impl


TS: Simulation

Spec

Impl


TS: Simulation

Spec

Impl

All behaviors of the implementation are allowed by the specification


Games: Alternating Simulation

Spec

Impl

Inputs Outputs

The implementation accepts all the specification inputs,

and produces a subset of the outputs.

The implementation can be substituted for the specification.


Alternating Simulation Example

send!

msg?

msg? send!

ack?

nack?fail!

ok!

ack? nack?

ok! fail!

send!

msg?

msg? send!

ack?

nack?fail!

ok!

ack? nack?

ok! fail!done!once?

once?send!

ack? done!


Types: Composition

Dom() Im()

Condition:

Dom() Im()

Im() µ Dom()


Types: Composition

Dom() Im()

What if

Dom() Im()

Im() µ Dom() ?


Types: Composition

Dom() Im()

What if

Dom() Im()

Im() µ Dom() ?

Can we restrict Dom() to Dom’(),

to ensure Im’() µ Dom() ?

YES ) Compatible, type derivationNO ) Incompatible


int x intx=0 ! y=0 int

x

yz

Types: Composition


int

Compatible?

Types: Composition


x

yz


intx 0 int

x

Compatible? Yes! Outcome:

Compatible: Are there inputs for which it works?New type: most general restrictions under which it works.

Types: Composition

int


x

yz


Behaviors: Composition

a?

b?

c?a!

b!µ



a?

b?

c?a!

b!

a!

b!



b?

c?a!

b!µ



b?

c?a!

b!


Process Algebra

b?

c?a!

b!

b!Not for us!


send! nack?

msg? ok! fail!

ack?

msg? send! send!ack?

ack?

nack?

nack?fail!

ok!

Example: Interface Automata Composition

msg!

ok?

msg! fail?ok?

Local incompatibility:Here, fail? cannot be accepted

fail! generated


send! nack?

msg! ok! fail!

ack?

msg! send! send!ack?

ack?

nack?

nack?

ok!


Local incompatibility


send! nack?

msg! ok! fail!

ack?


ack?

nack?

nack?

ok!


Can we restrict the inputs to avoid the local incompatibility?


send! nack?

msg! ok! fail!

ack?


ack?

nack?

nack?

ok!


Can we restrict the inputs to avoid the local incompatibility?

YES.


send! nack?

msg! ok! fail!

ack?


ack?

nack?

ok!


The resulting interface automaton.


Practice:

The Ticc Tool

GPL licencehttp://dvlab.cse.ucsc.edu/Ticc

Collaborators:

Marco FaellaVishwanath RamanPritam RoyAxel LegayBo AdlerLeandro Dias Da Silva

Intended Application:

?

Intended Application:

Compatibility checking.

Modeling - Desiderata

• Synchronization (actions)• one-to-one, one-to-many, many-to-many

• Shared state (local + global variables)

• Communication (actions can update variables)

• one-to-one, one-to-many, many-to-many

) Sociable Interfaces [FROCOS 2005] Implemented in Ticc.

Many-to-One Synchronization does not work in Interface Automata

a? a! a!

Many-to-One Synchronization does not work in Interface Automata

a!a!

Incompatible: neither can accept a!.

Ticc usesSociable Interfaces

For a in the language:

a?

a!

a is not generated as output, buta can be accepted as input.

a can be generated as output,but it cannot be accepted as input.

a can neither be generated as output,nor accepted as input.

[dA, Faella, et al.FROCOS 05]

Ticc usesSociable Interfaces

For a in the language:

a?

a!

a?

a!

a can be generated as output, and a can be accepted as input.

a is not generated as output, buta can be accepted as input.

a can be generated as output,but it cannot be accepted as input.

a can neither be generated as output,nor accepted as input.

[dA, Faella, et al.FROCOS 05]

new in sociable interfaces

Product of sociable interfaces

1

3

a?

A

B

a?

1A

3B

a?

1

2

a!

A

B

a?

1A

2B

a!


1

3

a?

2

a!

A

B

a?

1A

3B

a?

2B

a!


1

3

a?

2

a!

A

C

a!

1A

3C

a!

a! from 1 has no corresponding a? from A

locally incompatible

state


1

3

a?

2

a!

A

B

a?

C

a!

1A

3B

a?

3C

a!

2B

a!


X Incompatible

fire?

fd!

smoke1?

fire!

Controlunit

Detector 1

smoke2?

fire!

Detector 2

X Incompatible

fire?

fd!

smoke1?

fire!

Controlunit

Detector 1

smoke2?

fire!

Detector 2

Not accepted

by all other components

X Compatible

fire?

fd!

smoke1?

fire!

Controlunit

Detector 1

smoke1?fire?

smoke1?fire?

fire?

smoke2?

fire!

Detector 2

smoke2?fire?

smoke2?fire?

fire?

fire?

fire?

Ticc Model

t=0

t=1

t=2

smoke2?

fire!

Detector 2

smoke2?fire?

smoke2?fire?

fire?module FireDetector2: var t: [0..2] initial: t=0

input smoke2: { local: t=0 ==> t':=1 else true ==> // do nothing }

output fire: { t=1 ==> t'=2 }

input fire: { } // disregard

endmodule

What feedback should Ticc give?

Naive belief:

“Ticc will tell us when components are incompatible”.

Reality:

Most components are compatible: in an environment that does nothing, often nothing (bad) happens.

) We need more diagnostic information...


Example: A detector that can be disabled

s=0

s=1

s=2

fire?

fd!

t=0

t=1

t=2

smoke1?

fire!

Detectors=3

disable?

Control Unit

disable?

disable?


What happens if we forget the disable?

s=0

s=1

s=2

fire?

fd!

t=0

t=1

t=2

smoke1?

fire!

Detectors=3

disable?

Control Unit

disable?

disable?


s=0

s=1

s=2

fire?

fd!

t=0

t=1

t=2

smoke1?

fire!

Detector

s=3

disable?

Control Unit

s=0, t=0

s=0, t=1

s=1, t=2

smoke1?

fire!

fd!

s=3, t=0

s=3, t=1

smoke1?

disable?

disable?

fire!

The controlunit cannot accept fire!

once disabled

(s=3)



s=0, t=0

s=0, t=1

s=1, t=2

smoke1?

fire!

fd!

s=3, t=0

s=3, t=1

smoke1?

disable?

disable?

fire!

Is there an environmentwhere the components work together?

) does Input have astrategy s.t., whateverOutput does, the incompatibility does notoccur?


Locallyincompatible

state


s=0, t=0

s=0, t=1

s=1, t=2

smoke1?

fire!

fd!

s=3, t=0

s=3, t=1

smoke1?

disable?

disable?

Is there an environmentwhere the components work together?

) does Input have astrategy s.t., whateverOutput does, the incompatibility does notoccur?

YES.

(Compatibility does notgive us information here)


Locallyincompatible

state


s=0, t=0

s=0, t=1

s=1, t=2

smoke1?

fire!

fd!

s=3, t=0

s=3, t=1

smoke1?

disable?

disable?

The interesting question is:

What has becomeimpossible?

(What environment inputsare no longer enabled?)

What question should we ask?

Locallyincompatible

state


s=0, t=0

s=0, t=1

s=1, t=2

smoke1?

fire!

fd!

s=3, t=0

s=3, t=1

smoke1?

disable?

disable?

Given an action, e.g., smoke?, Ticc gives a path such that:

Ticc Feedback

1. Starts from an initial state

2. Goes to the action taking only “good” steps.

3. Takes an instance of the action that has become prohibited.

4. Continues, taking only output steps, until an incompatibility is reached.


Ticc Feedback

Restriction of action a:

a?

Input and output actions,in the “good” states.

Output actions only,in the pruned states.

Locallyincompatible

state


send!msg!

ok!

ack?

nack?

Ticc Feedback

s=0 s=1 s=2 s=3 s=4

s=6

s=5

send!

ack?

nack?


Games and Global Variables are a difficult mix

• a! may want to update a global variable x.

The module emitting a! can communicate a value to other modules by writing into x.

• a? may want to update a local variable y.

The module receiving a? may want to update its internal state as a consequence.

• But, when a! and a? synchronize, only one of Input/Output should be able to take decisions (otherwise, not a game).

) Updates by input actions are deterministic.


Output Actions: Global + Local Update

local global

local global

Current state

Next state

a!

updates updates


Input Actions: Global Assumptions

Current state local global

Next state local global

Assumption on how action a!, emitted from another module, can update the global variables.

assumption

a?


Current state local global

Next state local global

The module receiving a? can look at the current state, and at the new values of the global variables, to update its local variables (communication). The update must be deterministic.

a?

Input Actions: Local Update

update(det)


I/O Synchronization and Communication

local of P global

local of P global

local of Q

local of Q

Check that gupd implies gasm

(the output update satisfies the input assumption)

P || Q

a!

gupd gasm

a?

lupd


I/O Synchronization and Communication

local of P global

local of P global

local of Q

local of Q

P || Q

a!

gupd gasm

a?

lupd update (det)

All new values are determined by the emitter of a!(the result is an Output move).


A House Repair Example

• Many things can break, repair-people are called to fix them.

• Repair people want to work alone in a room: before starting, they check that the room is not busy, and assume others do the same.

• Except, a rude electrician does not care if anyone is already working on the kitchen.

Kitchen

LivingRmBathRm

BedRmElectricalFloorsWallsDirt

Plumbing

bre

aks

fixes


Ticc: Features and Capabilities

• Additional features: CTL model-checking, (soon ATL), simulation, ...

• The tool is written in Ocaml, it relies on the MDD package cudd/glu [Somenzi et al.]

• Efficient: uses saturation techniques for symbolic exploration [Ciardo, Yu CHARME 2005]

• GPL licence, lots (we hope) of documentation.

http://dvlab.cse.ucsc.edu/Ticc


Does it work in practice?• Certainly better than not having input assumptions.

– One can use *: { } as the everything-goes assumption.– Gives guidance, very little to lose.

• Efficient– Many problems reduce to reachability, saturation works

great.

• Sometimes weak guidance– When Ticc complains, there is a good reason. – But at times, it does not catch problems until several

components are composed.

• Uses its own input language.– The language is flexible for composition, but poor (right

now) for datatype support (boolean and integer range).– Will anyone code in it? If the ideas are useful, others will

implement them in industrial tools.


Future work• Better guidance• Local checks

– Check compatibility pairwise, or in small groups of components.

• Real-time implementation– It’s in the works...

• Sat-based algorithms – They would be a good fit!

Come and use the tool, hack its code, modify it, etc etc! It’s fun!

http://dvlab.cse.ucsc.edu/Ticc

Documents

Interface Theories in Practice Luca de Alfaro UC Santa Cruz GDV 2006