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

2. Theory (In theory, many things work...) Collaborators: Tom Henzinger Marielle Stoelinga

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

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

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

6. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) send! 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.

7. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) send! msg? send! ack? nack? fail! ok! ack? nack? msg? *? ack?nack? ok!fail! send! 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. A Transition-System Model Output moves: the outputs that can be generated. Input moves: always accepted (input enabled).

8. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) send! msg? send! ack? nack? fail! ok! ack? nack? msg? *? ack?nack? ok!fail! send! msg? send! ack? nack? fail! ok! ack?nack? ok! fail! A Game Model A Transition-System Model What is the difference?? Refinement Composition

9. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Refinement (closed systems) ¹ µ Classical definition: behavioral subset (trace containment, simulation) choices µ

10. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) (Closed) Refinement applied to open systems ¹ µ Often used for input-enabled systems. = input enabled choices µ no choices here

11. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) ¹ * Whoops, it does not hold... = input enabled (Closed) Refinement applied to open systems - in practice

12. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) ¹ Whoops, it does not hold... We forgot an environment assumption! Env µ (Closed) Refinement applied to open systems - in practice

13. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) ¹ In practice, transition system refinement is used between closed systems. Env µ (Closed) Refinement applied to open systems - in practice

14. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Simulation as Open System Refinement? Q ¹ P µ µ

15. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) 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. Q ¹ P µ µ ?

16. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) 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. Q ¹ P µ µ ? Simulation is not the proper notion of refinement for open systems!

17. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) To define open-system refinement, lets look at type theory Dom( ) Im( ) ¹ µ µ Subtyping is Domain/Image contravariant

18. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Open System Refinement ¹ µ µ This is alternating simulation, the notion of refinement for games! [Alur,K,Henzinger,V CONCUR98]

19. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) TS: Simulation Spec Impl

20. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) TS: Simulation Spec Impl

21. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) TS: Simulation Spec Impl All behaviors of the implementation are allowed by the specification

22. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Games: Alternating Simulation Spec Impl InputsOutputs The implementation accepts all the specification inputs, and produces a subset of the outputs. The implementation can be substituted for the specification.

23. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Alternating Simulation: Example send!nack? msg? ok! fail! ack? msg?send! ack? nack? fail! ok! send!nack? msg? ok! fail! ack? msg?send! ack? nack? fail! ok! once? send! ack? done! once?

24. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Alternating Simulation Example send! msg? send! ack? nack? fail! ok! ack?nack? ok! fail! send! msg? send! ack? nack? fail! ok! ack?nack? ok! fail! done! once? send! ack? done!

25. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Types: Composition Dom( ) Im( ) Condition: Dom( ) Im( ) Im( ) µ Dom( )

26. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Types: Composition Dom( ) Im( ) What if Dom( ) Im( ) Im( ) µ Dom( ) ?

27. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Types: Composition Dom( ) Im( ) What if Dom( ) Im( ) Im( ) µ Dom( ) ? Can we restrict Dom( ) to Dom( ), to ensure Im( ) µ Dom( ) ? YES ) Compatible, type derivation NO ) Incompatible

28. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) int x int x=0 ! y=0 int x y z Types: Composition

29. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) int Compatible? Types: Composition int x int x=0 ! y=0 int x y z

30. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) int x 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 int x int x=0 ! y=0 int x y z

31. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Behaviors: Composition a? b? c? a! b! c! µ

32. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Behaviors: Composition a? b? c? a! b! µ

33. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Behaviors: Composition a? b? c? a! b! a! b!

34. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Behaviors: Composition b? c? a! b! µ

35. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Behaviors: Composition b? c? a! b!

36. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Process Algebra b? c? a! b! Not for us!

37. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) send!nack? msg? ok! fail! ack? msg?send! ack? nack? fail! ok! Example: Interface Automata Composition msg! ok? msg!fail?ok? Local incompatibility: Here, fail? cannot be accepted fail! generated

38. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) send!nack? msg! ok! fail! ack? msg!send! ack? nack? ok! Example: Interface Automata Composition Local incompatibility

39. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) send!nack? msg! ok! fail! ack? msg!send! ack? nack? ok! Example: Interface Automata Composition Can we restrict the inputs to avoid the local incompatibility?

40. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) send!nack? msg! ok! fail! ack? msg!send! ack? nack? ok! Example: Interface Automata Composition Can we restrict the inputs to avoid the local incompatibility? YES.

41. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) send!nack? msg! ok! fail! ack? msg!send! ack? nack? ok! Example: Interface Automata Composition The resulting interface automaton.

42. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Game composition propagates constraints The top-level game could not accept failure Therefore, in the composite game, the network layer cannot fail twice in a row. send!nack? msg! ok! fail! ack? msg!send! ack? nack? ok! msg! ok? send! fail? ok?

43. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Transition SystemsGames (interfaces) ModelOutputInput, Output RefinementSimulation Alternating simulation Composition Input enabled, Consensus Game composition (Ouput does, Input must accept) Verification Does it work? LTL, CTL,... Can it work? LTL, CTL, control ¶ I O I O ¶ ClosedOpen I O I O = ¶

44. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Practice: The Ticc Tool GPL licence http://dvlab.cse.ucsc.edu/Ticc Collaborators: Marco Faella Vishwanath Raman Pritam Roy Axel Legay Bo Adler Leandro Dias Da Silva

45. Intended Application:

47. ? Compatibility checking.

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

49. A Simple Fire-Detector Example fire? fd! smoke1? fire! smoke1? fire! fd! Control unit Detector 1

50. Many-to-One Synchronization? fire? fd! smoke1? fire! smoke2? fire! ? Control unit Detector 1 Detector 2

51. Many-to-One Synchronization? smoke2? fire! ? smoke1? fire! fd! Detector 2

52. Many-to-One Synchronization? smoke2? fire! smoke1? fire! fd! Incompatible: fire! can be generated by both, accepted by neither.

53. Many-to-One Synchronization does not work in Interface Automata a?a!

54. Many-to-One Synchronization does not work in Interface Automata a! Incompatible: neither can accept a!.

55. Ticc uses Sociable Interfaces For a in the language: a? a! a is not generated as output, but a 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]

56. Ticc uses Sociable 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, but a 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

57. Product of sociable interfaces 1 3 a? A B 1A 3B a?

58. 1 2 a! A B a? 1A 2B a! Product of sociable interfaces

59. 1 3 a? 2 a! A B a? 1A 3B a? 2B a! Product of sociable interfaces

60. 1 3 a? 2 a! A C 1A 3C a! a! from 1 has no corresponding a? from A locally incompatible state Product of sociable interfaces

61. 1 3 a? 2 a! A B a? C a! 1A 3B a? 3C a! 2B a! Product of sociable interfaces

62. X Incompatible fire? fd! smoke1? fire! Control unit Detector 1 smoke2? fire! Detector 2

63. X Incompatible fire? fd! smoke1? fire! Control unit Detector 1 smoke2? fire! Detector 2 Not accepted by all other components

64. X Compatible fire? fd! smoke1? fire! Control unit Detector 1 smoke1? fire? smoke1? fire? smoke2? fire! Detector 2 smoke2? fire? smoke2? fire?

65. Ticc Model t=0 t=1 t=2 smoke2? fire! Detector 2 smoke2? fire? smoke2? 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

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

67. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Example: A detector that can be disabled s=0 s=1 s=2 fire? fd! t=0 t=1 t=2 smoke1? fire! Detector s=3 disable? Control Unit disable?

68. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) What happens if we forget the disable? s=0 s=1 s=2 fire? fd! t=0 t=1 t=2 smoke1? fire! Detector s=3 disable? Control Unit disable?

69. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) s=0 s=1 s=2 fire? fd! t=0 t=1 t=2 smoke1? fire! Detector s=3 disable? Control Unit What happens if we forget the disable?

70. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) 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? fire! The control unit cannot accept fire! once disabled (s=3) What happens if we forget the disable?

71. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) 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? fire! Is there an environment where the components work together? ) does Input have a strategy s.t., whatever Output does, the incompatibility does not occur? What happens if we forget the disable? Locally incompatible state

72. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) 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? Is there an environment where the components work together? ) does Input have a strategy s.t., whatever Output does, the incompatibility does not occur? YES. (Compatibility does not give us information here) What happens if we forget the disable? Locally incompatible state

73. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) 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? The interesting question is: What has become impossible? (What environment inputs are no longer enabled?) What question should we ask? Locally incompatible state

74. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) 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? 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.

75. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Ticc Feedback Restriction of action a: a? Input and output actions, in the good states. Output actions only, in the pruned states. Locally incompatible state

76. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) send!msg! ok! ack? nack? Ticc Feedback s=0s=1s=2s=3s=4 s=6 s=5 send! ack? nack?

77. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) 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.

78. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Output Actions: Global + Local Update localglobal localglobal Current state Next state a! updates

79. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Input Actions: Global Assumptions Current state localglobal Next state localglobal Assumption on how action a!, emitted from another module, can update the global variables. assumption a?

80. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Current state localglobal Next state localglobal 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)

81. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) I/O Synchronization and Communication local of Pglobal local of Pglobal local of Q Check that gupd implies gasm (the output update satisfies the input assumption) P || Q a! gupdgasm a? lupd

82. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) I/O Synchronization and Communication local of Pglobal local of Pglobal local of Q P || Q a! gupdgasm a? lupdupdate (det) All new values are determined by the emitter of a! (the result is an Output move).

83. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) 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. K itchen L ivingRm B athRm Bed R m Electrical Floors Walls Dirt Plumbing breaks fixes

84. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) 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

85. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) 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.

86. Taormina, June 30, 2003L. de Alfaro - Intl. Symp. on Verification (Theory and Practice) Future work Better guidance Local checks –Check compatibility pairwise, or in small groups of components. Real-time implementation –Its in the works... Sat-based algorithms –They would be a good fit! Come and use the tool, hack its code, modify it, etc etc! Its fun! http://dvlab.cse.ucsc.edu/Ticc