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.

msg? send!

nack?fail!

ack? nack?

ok! fail!

A Game Model

Input moves: the inputs that are allowed.

Output moves: the outputs that can be generated.

msg? send!

nack?fail!

ok!ack?nack?

ack? nack?

ok! fail!

msg? send!

nack?fail!

ack? nack?

ok! fail!

A Game Model

Input moves: the inputs that are allowed.

A Transition-System Model

Input moves: always accepted (input enabled).

msg? send!

nack?fail!

ok!ack?nack?

ack? nack?

ok! fail!

msg? send!

nack?fail!

ack? nack?

ok! fail!

A Game Model A Transition-System Model

What is the difference??

• Refinement

• Composition

Simulation as Open System Refinement?

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.

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.

Pµµ?

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

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

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

All behaviors of the implementation are allowed by the specification

Games: Alternating Simulation

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

msg? send!

nack?fail!

ack? nack?

ok! fail!

msg? send!

nack?fail!

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

Types: Composition

Compatible?

Types: Composition

intx 0 int

Compatible? Yes! Outcome:

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

Types: Composition

Behaviors: Composition

Process Algebra

b!Not for us!

send! nack?

msg? ok! fail!

msg? send! send!ack?

nack?fail!

Example: Interface Automata Composition

msg! fail?ok?

Local incompatibility:Here, fail? cannot be accepted

fail! generated

send! nack?

msg! ok! fail!

msg! send! send!ack?

Local incompatibility

send! nack?

msg! ok! fail!

Can we restrict the inputs to avoid the local incompatibility?

send! nack?

msg! ok! fail!

Can we restrict the inputs to avoid the local incompatibility?

send! nack?

msg! ok! fail!

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:

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

Incompatible: neither can accept a!.

Ticc usesSociable Interfaces

For a in the language:

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 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

a! from 1 has no corresponding a? from A

locally incompatible

Product of sociable interfaces

X Incompatible

smoke1?

Controlunit

Detector 1

smoke2?

Detector 2

X Incompatible

smoke1?

Controlunit

Detector 1

smoke2?

Detector 2

Not accepted

by all other components

X Compatible

smoke1?

Controlunit

Detector 1

smoke1?fire?

smoke2?

Detector 2

smoke2?fire?

Ticc Model

smoke2?

Detector 2

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

smoke1?

Detectors=3

disable?

Control Unit

disable?

What happens if we forget the disable?

smoke1?

Detectors=3

disable?

Control Unit

disable?

smoke1?

Detector

disable?

Control Unit

s=0, t=0

s=0, t=1

s=1, t=2

smoke1?

s=3, t=0

s=3, t=1

smoke1?

disable?

The controlunit cannot accept fire!

once disabled

s=0, t=0

s=0, t=1

s=1, t=2

smoke1?

s=3, t=0

s=3, t=1

smoke1?

disable?

Is there an environmentwhere the components work together?

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

Locallyincompatible

s=0, t=0

s=0, t=1

s=1, t=2

smoke1?

s=3, t=0

s=3, t=1

smoke1?

disable?

Is there an environmentwhere the components work together?

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

(Compatibility does notgive us information here)

Locallyincompatible

s=0, t=0

s=0, t=1

s=1, t=2

smoke1?

s=3, t=0

s=3, t=1

smoke1?

disable?

The interesting question is:

What has becomeimpossible?

(What environment inputsare no longer enabled?)

What question should we ask?

Locallyincompatible

s=0, t=0

s=0, t=1

s=1, t=2

smoke1?

s=3, t=0

s=3, t=1

smoke1?

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:

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

Output actions only,in the pruned states.

Locallyincompatible

send!msg!

Ticc Feedback

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

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

Current state

Next state

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

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.

Input Actions: Local Update

update(det)

I/O Synchronization and Communication

local of P global

local of Q

Check that gupd implies gasm

(the output update satisfies the input assumption)

P || Q

gupd gasm

I/O Synchronization and Communication

local of P global

local of Q

P || Q

gupd gasm

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

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

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

Documents

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

Detailed report of processing gdv images in the gdv scientific laboratory program 050709

GDV image presentation OEA Orgone Pendant

Wellness Breakthrough - GDV-USAgdvusa.org/images2/Bio-Well.pdf · Wellness Breakthrough Introduction and Training to GDV & Bio-Well Two Day Specialized Certiﬁcation Course Presented

Student Name Grade Teacher Room...Alfaro Marquez, Heidy Y 8 Rubin 140 Alfaro Ramirez, Rebecca 7 Hobbs 211 Alfaro Torres, Brandon A 7 Hobbs 211 Alfaro-Hernandez, Adriana N 6 Kerr 222

Case Study Enrique Alfaro

Acuna Alfaro 07

"Eloy Alfaro" valores principales

Detecting Wikipedia vandalism using WikiTrust · Detecting Wikipedia vandalism using WikiTrust Luca de Alfaro Google Inc and UC Santa Cruz (on leave) Ian Pye CloudFlare Inc and UC

Anastasio alfaro red

Reliable aggregation of boolean crowdsourced tasks · 2016-01-27 · Reliable aggregation of boolean crowdsourced tasks Luca de Alfaro Vassilis Polychronopoulos Michael Shavlovsky

Kirilian camera image GDV camera image€¦ · The GDV camera is based on Kirlian photography Kirilian camera image GDV camera image • Launched in 1995 by Konstantin Korotkov, Ph.D

Interpretaciones Batllismo Caetano Alfaro

ALFARO (LA RIOJA)

GDV GeoSoftware: Home

Jesus Alfaro Design Portfolio

Alfaro, Psicologia Comunitaria

David Alfaro Siqueiros Self-Portrait with Mirrormamfa.com/wp-content/uploads/Siqueiros-Self-Portrait-with-Mirror... · David Alfaro Siqueiros Self-Portrait with Mirror ... David Alfaro

Roy Alfaro Vargas - dialnet.unirioja.es

David Alfaro Siqueiros

Luca de Alfaro - citris-uc.org fileHow (much) to trust the Wikipedia? Luca de Alfaro UC Santa Cruz Joint work with Bo Adler, Ian Pye With contributions by Jason Benterou, Krishnendu