Presentation is loading. Please wait.

Presentation is loading. Please wait.

Interface-based Design of Embedded Systems Thomas A. Henzinger University of California, Berkeley.

Similar presentations


Presentation on theme: "Interface-based Design of Embedded Systems Thomas A. Henzinger University of California, Berkeley."— Presentation transcript:

1 Interface-based Design of Embedded Systems Thomas A. Henzinger University of California, Berkeley

2 Interface-based Design

3

4

5

6 Compositional Component Models If A||B is defined and A  a and B  b, then a||b is defined and A||B  a||b. enable independent component verification Compositional Interface Models If a||b is defined and A  a and B  b, then A||B is defined and A||B  a||b. enable independent interface implementation

7 x  Nat  y  Nat\{0}  z = x  y A Component Model x  Nat  y  Nat\{0}  z  Nat An Interface Model -constrains the environment -example: type declaration -(mis)behaves in every environment -examples: circuit; executable code

8  x,y.  z. ( x  Nat  y  Nat\{0}  z = x  y ) The Component Model input-universal (adversarial environment)  x,y.  z. ( x  Nat  y  Nat\{0}  z  Nat ) The Interface Model input-existential (helpful environment)

9 The Interface Model x  Nat y  Nat\{0} z  Nat Prescriptive: “How can the component be put together with other components?” Input assumptionOutput guarantee

10 x y z x=0  y=0 true Propagation of Environment Constraints

11 x y z x=0  y=0 true Propagation of Environment Constraints

12 x y z x=0  y=0 true y = 0  x,z. ( true  x=z  ( x=0  y=0 )) Propagation of Environment Constraints

13 y z true y = 0 The resulting interface. Propagation of Environment Constraints

14 y z true y = 0 Illegal connection. Propagation of Environment Constraints

15 Stateless interface models (traditional “types”): value constraints Stateful interface models (“behavioral types”): temporal ordering constraints, real-time constraints, etc. open_file? close_file? get_block? get_blockclose_fileopen_file put_block! put_block

16 a! b! a? b? a b

17 a! b! a? ?

18 a! b! a? A Component Model: I/O Automata This is an illegal component, because it is not prepared to accept input b. [ Lynch, also Lamport, Alur/H ]

19 a! b! a? a Another Component Model: CSP Composition may lead to deadlocks, and requires verification if this is undesirable. [ Hoare, also Milner, Harel ]

20 a! b! a? An Interface Model: Interface Automata These interfaces are incompatible, because the receiver expects the environment to provide input b. [ de Alfaro/H, also Dill ]

21 Component Models -composition || is conjunction/product -abstraction  is covariant Interface Models -composition || is game-theoretic -implementation  is contravariant

22 2 2 4042 msg?send! nack?fail! ok!ack? acksend msgfailok ack?

23 2 2 4042 msg?send! fail! ok!ack? send msgfailok msg! ok? msgokfail ack? ack

24 2 4042 msgsend! fail! okack? acksend Incompatible product state, but environment can prevent this state. ack?

25 2 4042 msgsend! fail! okack? send The Composite Interface. ack? ack

26 44 send! send The Composite Interface. ack? ack send!

27 Computing the Composite Interface 1.Construct product automaton. 2.Mark deadlock states as incompatible. 3.Until no more incompatible states can be added: mark state q as incompatible if the environment cannot prevent an incompatible state to be entered from q. 4.If the initial state is incompatible, then the two interfaces are incompatible. Otherwise, the composite interface is the product automaton without the incompatible states. This computes the states from which the environment has a strategy to avoid deadlock. The propagated environment constraint is that it will apply such a strategy.

28 x  Odd  y = 2x x  Nat y y = 2x y Component Abstraction Abstraction is implication (simulation; trace containment). x  Nat  

29 x  Odd Interface Implementation Implementation is I/O contravariant. x  Nat    x  Even

30 x  Nat Interface Implementation Implementation must obey output guarantee. x  Nat    x  Oddx  Nat X X

31 Interface Implementation Implementation must accept all permissible inputs. x  Even    x  Nat X X

32 2 2 4042 msg?send! fail! ok!ack? acksend msgfailok ack?

33 2 2 4042 msg?send! fail! ok!ack? acksend msgfailok 1 1 6061 msg?send! fail! ok!ack? acksend msgfailok 28 send!once? 2 2 fail! ok!ack? once  ack?

34 Alternating Simulation Q  q iff 1. for all inputs i, if q –i?-> q’, then there exists Q’ such that Q –i?-> Q’ and Q’  q’, and 2. for all outputs o, if Q –o!-> Q’, then there exists q’ such that q –o!-> q’ and Q’  q’. If there is a helpful environment at q, then there is a helpful environment at Q [Alur/H/Kupferman/Vardi].

35 Algorithms & Tools -interface compatibility (reachability game) can be checked in linear time -interface implementation (alternating simulation) can be checked in quadratic time We are currently implementing this in JBuilder [Chakrabarti/de Alfaro/H/Jurdzinski/Mang].


Download ppt "Interface-based Design of Embedded Systems Thomas A. Henzinger University of California, Berkeley."

Similar presentations


Ads by Google