1 / 35

Interface-based Design of Embedded Systems

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

guy-jenkins
Download Presentation

Interface-based Design of Embedded Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Interface-based Design

  3. Interface-based Design

  4. Interface-based Design

  5. Interface-based Design

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

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

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

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

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

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

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

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

  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 put_block open_file? get_block? close_file? put_block!

  16. a! a b! b a? b?

  17. a! b! ? a?

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

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

  20. An Interface Model: Interface Automata a! These interfaces are incompatible, because the receiver expects the environment to provide input b. b! a? [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. msg ok fail 2 ok! ack? ack? msg? send! send! 2 4 0 4 fail! nack? 2 send ack

  23. msg! ok? msg ok fail msg ok fail 2 ok! ack? ack? msg? send! send! 2 4 0 4 fail! 2 send ack

  24. 2 ok ack? ack? msg send! send! 2 4 0 4 fail! send ack Incompatible product state, but environment can prevent this state.

  25. 2 ok ack? ack? msg send! send! 2 4 0 4 fail! send ack The Composite Interface.

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

  27. Computing the Composite Interface • Construct product automaton. • Mark deadlock states as incompatible. • 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. • 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. Component Abstraction x  Odd  y = 2x x  Nat y   y = 2x y x  Nat Abstraction is implication (simulation; trace containment).

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

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

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

  32. msg ok fail 2 ok! ack? ack? msg? send! send! 2 4 0 4 fail! 2 send ack

  33. msg ok fail 2 ok! ack? ack? msg? send! send! 2 4 0 4 fail! 2 send ack  once msg ok fail 1 2 ack? ok! ok! ack? ack? send! once? msg? send! send! 8 2 1 6 0 6 fail! fail! 2 1 send 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].

More Related