I/O & Interface Automata

1. I/O & Interface Automata By Josh Lessard, Josh Taylor, Real Xu

2. Presenters’ Intro

3. Presenters’ Problem

4. Agenda • Components & Automata • Interface Automata • Single-Threaded Interface Automata • Conclusion

5. Components & Automata By Real Xu, r4xu@uwaterloo.ca User Interface Group, School of Computer Science, University of Waterloo

6. Objective • Understand Components & Framework • Discover relationship between Component-Based Design and Embedded Systems • Introduction to Component-Based Model of Computation • Review evolvement • Understand why we use automata

7. Components & Framework • What is component? • subroutines • processes/threads • distributed objects • review of lecture 1 • any kind of building block

10. Components & Framework • What is framework? • Subroutines libraries?  No structure • Operating systems?  Yes, but weak • CORBA, DCOM?  Yes, but confined to software • Interaction mechanisms?  Yes, incorporate hardware and software • We want: constraints + benefits

11. Framework A class library and policies Programming Languages Operating System DS & Middleware Body System Social/political System Components Already existed methods Language primitives (a,c) Single processes/programs Distributed components Organs Companies and organizations Components & Framework

12. Framework JavaBeans, COM, CORBA Publish and Subscribe, Linda, JavaSpaces Asynchronous message passing Synchronous message passing Discrete events Continuous time Interaction Mechanism Unstructured events, no built-in synchronization Event notification, Processes send message through channels that buffer msgs Processes communicate in atomic instantaneous actions Components communicate via signals that carry events placed in time, which is globally known by all components Processes communicate via continuous-time signals, which are functions on the real numbers. Components & Framework

13. Component-Based Model of Computation • Which framework is best? • Your component • States of knowledge • Interaction mechanisms • Specialized, domain dependent!

14. Component-Based Model of Computation • Framework problem for embedded system? • We want: as unspecified as possible • Union all?  too complex • Choose one?  not using all advantages • Use an ADL  may get a poor design match • Need a design language, not a descriptive language!

15. Component-Based Model of Computation • The Type System • Ensure software correctness: good! OOP works, but not for larger structure. • Constrains interface: good! • Ensure compatibility when composing: good! • Static syntax: bad!

16. Component-Based Model of Computation • Automata • Use automata to get interface assumptions • Capture dynamic interface properties • Automata give protocols for component communication • Characterize services that each domain provides • Use composition and hierarchy of automata

17. Conclusions • Components • Frameworks • Framework for embedded system • Type System • Automata

18. Interface Automata By Josh Taylor, jtaylor@math.uwaterloo.ca

19. What is an Interface Automaton? • It is an automaton that can be used to determine if two interfaces are compatible • For simplicity, I will refer to an Interface Automaton as P or Q

20. An Interface Automaton P = <VP, VPInit, AIP, AOP, AHP, P>  : • VP is a set of states • VPInit VP is a set of initial states. • AIP, AOP, and AHP are mutually disjoint sets of input, output, and internal actions. Let AP = AIP  AOP AHP • P VP  AP VP is a set of steps.

21. Example Interface Automaton • Vcomp = {0, 1, 2, 3, 4, 5, 6} • VcompInit = {0} • AIcomp = {msg, nack, ack} (?) • AOcomp = {send, ok, fail} (!) • AHcomp =  (;) • comp = { (0,msg,1), (1,send,2), (2,ack,5), … }

22. Properties • An action aAP is enabled at a state vVP if there is a step (v,a,v)P for some vVP • AIP(v), AHP(v), AOP(v) are the subsets of actions that are enabled at state v • Interface automata are not required to be input-enabled, that is we do not require AIP(v) = AIP for all states vVP • Shared(P,Q) = AP  AQ

23. Composition • Two interface automata P and Q are composable if AIP  AIQ =  , AOP  AOQ =  AHP  AQ =  , AHQ  AP =  • The composition P||Q of the two interface automata is obtained by restricting the product P  Q to its compatible (non-illegal) states

24. User and Comp Consider the product of User and Comp…

25. Black Box Gives: User  Comp 6 is an illegal state. Why? …

26. Illegal States • Illegal(User, Comp) = { (v,u)  Vuser  Vcomp |  a Shared(User,Comp) such that : ( a AOuser(v) and a ! AIcomp(u)) or (aAOcomp(u) and a !AIuser(v)) } • In User  Comp, the output step (6,fail,0) of Comp has no corresponding input in User

27. User || Comp User  Comp with illegal states removed, we need an environment so that no input will be generated, that will lead to an illegal state

28. Legal Environment • Given two composable interface automata P and Q, a legal environment for the pair (P,Q) is an environment for P  Q such that no state in Illegal(P,Q) VE is reachable in (P  Q)  E • The existence of a legal environment for the composition of two interfaces indicates that the interfaces are compatible

29. Environment for User  Comp • Channel is a legal environment for User  Comp because the state (6,u), uVChannel is not reachable

30. In Closing • There are algorithms to generate the composition of two interface automata • Two automata are compatible if there exists a legal environment for the composition • Interface automata provide a concise and formal notation that parallels the natural way of evolving a component-based design

31. Single-Threaded Interface Automata By Josh Lessard, jrlessard@math.uwaterloo.ca Programming Languages Group, School of Computer Science, University of Waterloo

32. Introduction • For uniprocessor systems, interface automata are unnecessarily complex • Take advantage of single active thread of control • Single-threaded version of interface automata • Greatly reduces state space and gives rise to smaller automata

33. Definition • A single-threaded interface automaton (STIA) P is an interface automaton that satisfies two conditions:

34. STIA Condition #1 The set VP of states is partitioned into two disjoint sets VP = VOP VIP. The states in VOP are called running, because only internal and output actions are enabled: for all v VOP, we have AIP(v) = . The states in VIP are called waiting, because only input actions are enabled: for all v  VIP, we have AOP(v) = AHP(v) = .

35. STIA Condition #2 All output steps must lead to waiting states: for all (u, a, v)  OP, we have v  VIP. Conversely, only output steps can lead to waiting states: for all v  VIP and all (u, a, v)  P, we have a  AOP.

36. STIA Conditions • Condition 1 eliminates choice between output/internal actions (ie this automaton advancing thread) and input actions (ie some other automaton advancing thread) • Running states indicate ownership of the single thread of control; waiting states indicate non-ownership • Condition 2 ensures that an STIA waits for an input precisely after issuing an output action because if there is only a single thread of control, then each output step relinquishes that thread

37. Single-Threaded Composition • Special version of composition for STIAs • Prunes input actions that occur at states where internal or output actions are also enabled • Can do this because when in a running state, input for this automaton cannot be produced by other automata

38. Single-Threaded Composition Consider two composable STIAs P and Q. The single-threaded composition P|||Q is obtained from P||Q by first removing all steps (v, a, u) IP||Q for which AOP||Q(v)  AHP||Q(v)  , and then removing all states that become unreachable from VinitP||Q.

39. Example

40. Example Invalid input steps removed:

41. Example Unreachable states removed:

42. Conclusion • Four of the nine states were eliminated (nearly 50%)!!! • Complexity was greatly reduced • When modelling for uniprocessor systems, STIAs are a good way to remove clutter from diagrams by doing away with states that are unreachable due to the nature of single threaded systems

43. Summary of our talk By Real Xu, r4xu@uwaterloo.ca User Interface Group, School of Computer Science, University of Waterloo

44. Summary of our talk • Why Interface Automata? • What is Interface Automata? • How to Use Interface Automata Efficiently? • Why?- What?- How? • Future work

45. Why?- What?- How?

46. Why?- What?- How?

47. Why?- What?- How? • I/O Automata [N. Lynch, M.Tuttle 1989] • A labelled transition system model • Asynchronous concurrent systems • Actions classified: input (labelled), output, internal

48. Why?- What?- How?

49. I/O Automata What does it do? Component Input universal Pessimistic: compatible if no error can arise Based on transition systems Interface Automata How it can be used? Interface Input existential Optimistic: compatible if errors can be avoided Based on game theory Why?- What?- How?

50. I/O Automata Composition is easy: simply compute the product Verification is complex: need to verify that the interface are compatible Interface Automata Composition is complex: requires compatibility check Verification is easy: none needed generally Why?- What?- How?