Simulation of Timed Input/Output Automata

Simulation of Timed Input/Output Automata M.Eng Thesis Proposal Panayiotis P. Mavrommatis December 13, 2005

Abstract This proposal describes the design of the TIOA Simulator, a vital component of the TIOA Project, which aims to provide a framework for designing and implementing dependable distributed systems. The project is based on the Timed Input/Output Automaton framework, and supports TIOA, a formal language for specifying Timed I/O Automata. Simulation of TIOA can be used to test the proposed model and find any problems associated with it, gain a better understanding of the system and its various interactions, develop strategies that would lead to proofs of correctness and extract performance predictions. The proposed TIOA Simulator will provide support for simulation of primitive automata, simultaneous simulation of two automata and validation of simulation relations, as well as simulation of composite automata.

1 Introduction 1.1 Background Designing and implementing dependable distributed systems is a challenging problem. With many mission-critical applications running in distributed environments, such as air traffic control or road traffic management, where correctness and fault-tolerance is required, as well as a range of distributed applications that may also require performance, availability and fault-tolerance guarantees, the problem becomes significant. On the other hand, as systems become increasingly complex, providing these guarantees becomes harder. To cope with these challenges researchers have developed mathematical models that provide frameworks in which formal specification as well as proofs of correctness can be performed in a structured and effective manner. One of these frameworks is the Timed Input/Output Automaton framework[6], in which the basic building blocks are state machines with both discrete and continuous actions. This framework has evolved from the Input/Output Automaton model[7], in which only discrete actions are allowed. The I/O Automaton model was used in a number of research papers and books in order to specify and verify several distributed algorithms without timing guarantees. The model has been supported by a formal language, IOA[4], and a number of software tools that aimed to check the IOA specifications, simulate IOA executions[2, 8, 3, 14, 9], connect IOA to various theorem provers[1, 13], as well as compile IOA to Java [10, 12] and thus provide a method to implement IOA in a distributed environment, while preserving the properties proved about the system. Recently a formal language in which Timed I/O Automata can be specified has been developed[5]. The language, called TIOA, is a natural extension of IOA. In an effort to provide a similar set of tools for TIOA as for IOA, we have started extending some of the IOA tools to support TIOA. The Syntax and Semantics Checker tool, the PVS Theorem Prover Translator and the Simulator are the three main tools that will first be extended for this purpose. This Master s Thesis proposal describes the design and implementation of the latter tool, the TIOA Simulator. Once available, these tools can be used to design and formally specify distributed systems. The system can be specified with the help of the TIOA Checker, tested and analyzed with the TIOA Simulator, and be verified using the interface to the PVS theorem prover. The TIOA Simulator s main purpose can be summarized as follows: The TIOA Simulator can be used to create and simulate specific test-case executions, which can provide feedback about the model s correctness and show potential pitfalls. Proposed invariants which can be used in proofs of correctness (both safety and liveness) can be verified to hold throughout the executions. 1

The TIOA Simulator can test the interaction of the various system components by either creating specific test-case executions among the components or by running each component independently. Once again, invariants can be tested to hold throughout such executions. The TIOA Simulator can be used to test proposed simulation relations, which are useful parts of many correctness proofs, especially when the system tested is proposed to simulate another, lower-level system. This is common when a high-level specification of the system is first verified, and a lower-level implementation is verified by relating the two versions of the system. Similarly, simulation relations are used to relate an optimized version of an algorithm against a simple but inefficient version, which is also easier to verify. 1.2 Mathematical Framework The essence of TIOA and its tools lies on the mathematical framework of the Timed Input/Output Automaton Model[6]. A Timed I/O Automaton is a state machine that can take both discrete transitions and follow trajectories. Discrete transitions modify the automaton s state instantly, while trajectories specify how the state evolves with time. Transitions are either internal or external; internal transitions are not visible to the automaton s environment, while external ones are. External transitions can be either output or input ones; input transitions model inputs to the system and are always enabled. Internal and output actions may have preconditions that specify under what conditions of the state they are enabled. The externally visible behavior of an automaton, its trace is a sequence of alternating external actions and time-passage steps. Composition: A complex distributed system can be represented by composing automata that model individual parts of the system. A typical client-server application, for example, can be modeled by a composition of the client automaton, the server automaton and the channel automaton that represents the network link. Abstraction: A common practice in reasoning about complex systems is to provide an abstract specification of the system along with the concrete implementation. Two separate automata can be used to specify both descriptions, and the concrete automaton can be shown to implement the abstract one using the notion of simulation relations. Simulation Relation Given a concrete automaton A and an abstract automaton B, one can show that A implements B if there exists a forward simulation from A to B, which is defined as a relation R between the states of A and B such that Every start state x of A is related to some start state y of B ( x. y.xry) 2

For each step a in A, starting from state x and ending in state x, there is a sequence of steps b in B, starting with y and ending in y such that 1.3 TIOA Language and Tools xry [trace(a) = trace(b)] x Ry The TIOA Language[5] is a formal and programming language that can be used to specify Timed I/O Automata. The basic building block in the language is the automaton, which is specified by its signature (discrete action declarations), state (state variables), transitions (discrete action definitions) and trajectories (continuous action definitions). Figure 1 shows an example automaton written in TIOA. automaton A signature output a(i: Int ) states x: Int := 0, now : Real := 0 transitions output a( i) e f f x := choose y where y > 5 y < 10 t r a j e c t o r i e s trajdef timepass invariant x > 5 stop when now = 10 evolve d( now ) = 1 Figure 1: An example of a TIOA program Once complete, the TIOA Toolkit will contains tools that support TIOA: Static and Semantic Checker The TIOA Checker, also called the TIOA Front-End can be used to check whether the specification follows the TIOA syntax and semantics, Simulator The TIOA Simulator, for simulating the system s execution and for checking invariants and simulation relations, Interface to Model Checking Tool For checking the system by exhaustive execution or execution over a finite number of steps, and Interface to Theorem Prover Tool For verifying the model s correctness and other properties. 3

2 Design The ability to simulate TIOA programs is particularly useful. First, the simulator can test the proposed model of the system and reveal any possible problems with it. Furthermore, simulations can provide a better understanding of the system, and help develop strategies about proofs of correctness. Finally, the simulator s trace can be used to extract possible performance predictions.to accomplish these goals, the TIOA Simulator should: Provide simulation of primitive automata, Provide simulation of composite automata, and Provide paired simulations of two related automata. Ideally, any TIOA program could automatically run through the Simulator without any modifications. There are, however, four main sources of problems that can be hard to automatically solve in general: 1. Differential equations in evolve predicates and existential and universal quantifiers in other predicates, 2. Nondeterminism, either from the scheduling of actions and trajectories or from choose statements, 3. Data type implementations from the abstract data type definitions, and 4. Discovering the step correspondence of two automata related by a simulation relation. Our solution to the above problems is to restrict the language to a simulatable subset and let the user resolve these problems on a case-by-case basis. In particular, we 1. Restrict TIOA to programs that can be simulated, 2. Extend TIOA with syntax that can be used to resolve nondeterminism and specify simulation relations, and 3. Provide a number of data type implementations and a way for the user to create implementations for new data types. 2.1 Restricting TIOA The TIOA Simulator admits a subset of the TIOA language as its specification language, the TIOA-sim language. TIOA-sim imposes some restrictions on the trajectory definitions and on quantifiers. In particular, we restrict the form of differential equations in evolve clauses and the predicates that are used in stopping conditions so that the simulator can compute the value of a Real variable that is reached as a result of following a trajectory and 4

detect the violation of stopping conditions. The differential equations to be supported will be of the form d(v) = c, where v is a continuous variable of type Real or AugmentedReal (same as Real with support for positive infinity) and c is a constant literal number. The predicates in the stopping conditions can only be disjunctions of (v = c) where v is a continuous variable of type Real or AugmentedReal and c is a constant literal number. Moreover, no existential or universal quantifiers are allowed in TIOA-sim, unless the quantified variables are of type enumeration. Finally, for loops are allowed only over finite sets. 2.2 Resolving Nondeterminism Nondeterminism is a significant trade-off in a distributed system framework. Allowing nondeterminism usually results in simpler verification techniques. On the other hand, nondeterminism makes automatic simulation and compilation of TIOA harder. TIOA includes three fundamental sources of nondeterminism: 1. The scheduling of actions, 2. The scheduling of trajectories, and 3. The nondeterministic choices involving choose statements, choose parameters and choose expressions in initial assignments. For example, statements like x := choose y where f( y) are in general hard to automatically compute. The TIOA Simulator provides a mechanism for resolving nondeterminism by letting the user specify which choice is made at any point explicitly. This mechanism is an extension to the TIOA Language called the Non-Determinism Resolution language (NDR), and is derived from the NDR language used in IOA[3]. NDR can be used to schedule actions and trajectories as well as to resolve choose statements. Figure 2 shows an example usage of NDR for the automaton A in Figure 1. In a later section we show that NDR is reused to specify the step correspondence for paired simulations. The Simulator executes the schedule block as one would expect, by going through the program and attempting to execute each statement. Conditionals, assignments and loops are executed as usual. fire statements are executed by checking the preconditions of the transition and then executing the effect program of the transition. follow statements are executed by computing the final values of the continuous variables at the end of the trajectory. The simulator then checks that the stopping conditions will not be violated with these values and that the invariants of the trajectory will hold with both the initial and the final values of the continuous variables. If none of the stopping conditions and invariants are violated, the final values are assigned to the continuous variables and execution resumes in the schedule block. 5

automaton A signature output a(i: Int ) states x: Int := 0, now : Real := 0 transitions output a( i) e f f x := choose y where y > 5 y < 10 yield 7 t r a j e c t o r i e s trajdef timepass invariant x > 5 stop when now = 10 evolve d( now ) = 1 schedule do f i r e output a (0); follow timepass duration 10 od Figure 2: Example of NDR extension to TIOA for automaton A of Figure 1. NDR is used to resolve the choose statement (with an explicit yield statement) and to resolve the scheduling of transitions and trajectories with the schedule block. In this particular example, action a will be fired first, with the value 0 for its i parameter, and with the value 7 for x. Then trajectory timepass will be followed for 10 time units. Note that checking that the invariants hold only at the beginning and at the end of the time-passage event does not guarantee that the invariant holds throughout the event. In general it is impossible to guarantee this unless we restrict the form of the invariants. Instead, we have chosen to allow arbitrary invariants and warn the user that the invariants are tested only at the beginning and at the end of each time-passage event. For simple invariants of the type v op c where v is a continuous variable, c is a constant and op is a comparison operator such as <, <=, =, >=, >, testing only the beginning and the end of the event actually does guarantee that the invariant holds. Scheduling inputs There are two alternatives to the scheduling of input actions. The first one, which is what the IOA Simulator has been following, allows for input actions to be scheduled, and acts differently depending on whether the action has a corresponding output one in another component. If it does not, then the action is executed normally. If it does, then the input action is simply ignored, because it will be executed automatically when the corresponding output action will be scheduled. The second alternative is to disallow firing of input actions overall. This makes the semantics of composite simulation simpler, since the simulator will not ignore any scheduled actions. On the other hand, this restriction will almost always require composition of every automaton with input actions with an Environment automaton with the corresponding actions as output ones and a schedule for when to fire these actions. This is not an unreasonable requirement since it fits 6

well with the theoretical model and with the notion that input actions are always enabled and not controlled by the automaton itself; allowing input actions to be scheduled by an automaton can be considered a violation of this principle. In this Master s thesis I plan to evaluate the two alternatives based on their fitness to the theoretical model and usability, before choosing and implementing one of them. 2.3 Implementing Data Types The Toolkit provides a large number of standard data types, from Integer, Real, String, to more complex data types such as Map, Array, Sequence, Queue, Stack, Binary Search Tree, Enumerations, Unions, Tuples etc. The supplied data types are sufficient for most situations, and can be easily modified to fit more specific purposes. Moreover, TIOA provides syntax for specifying new (non built-in) data types and operators, and the TIOA Simulator provides a way for the user to implement these data types in Java, and instruct the Simulator to find these implementations. 2.4 Providing Step Correspondences The TIOA Simulator can be used to test simulation relations. For this purpose, the TIOA Simulator allows the user to specify a candidate simulation relation between two automata A and B, as well as a set of step correspondences, of the following form: For each transition a of the low-level automaton, execute a sequence of actions of the high-level one. For each trajectory t of the low-level automaton, execute sequence of trajectories and internal transitions of the high-level one. The Simulator will then execute the automata together, check that the simulation relation holds and that the external behavior of the two automata is the same. A schedule block in the low-level automaton drives the execution. For each action and trajectory about to be executed in the low-level automaton, the corresponding sequence of actions and trajectories is found (with the help of the step correspondence) and executed in the high-level automaton as well. Figure 3 shows an example of a simulation relation from an automaton Low to an automaton High which is actually identical to Low in functionality. 2.5 Composite Simulation The ability to simulate a system that consists of more than one component is essential in the process of evaluating the correctness, fault tolerance and availability of a system. In other words, the TIOA Simulator must provide a way in which a composite automaton is simulated. One possibility is to require the users to expand a composite automaton, 7

automaton High signature output high states u: Bool := false, now : Real := 0 transitions output high e f f u := true t r a j e c t o r i e s trajdef t_high evolve d( now ) = 1 automaton Low signature output low states t: Bool := false, now : Real := 0 transitions output low e f f t := true t r a j e c t o r i e s trajdef t_low evolve d( now ) = 1 schedule do f i r e output low ; follow t_low duration 2 od forward simulation from Low to High : Low.t = High.u proof i n i t i a l l y u := t for output low do f i r e output high od f o r trajectory t_low duration x do follow t_high duration x od Figure 3: A trivial forward simulation from automaton Low to High. Apart from the specifications of the two automata and the schedule block in the low-level one, the simulation relation is specified along with a step correspondence inside the proof block. 8

either manually or by using an automatic tool, so that the automaton becomes a primitive one that simply encapsulates its components. Josh Tauber demonstrates an automatic tool for expanding composite IOA automata[11, 10]. An extension of that tool could be used for this purpose, for example. Simulation of this expanded automaton can be done simply by writing a schedule block for the automaton and using the existing TIOA Simulator. On the other hand, this process has some disadvantages. First, even automatic expansion is sometimes difficult to get right, and its semantics around the combination of transitions with different where clauses are hard to understand. Second, the ability to provide a schedule block for every component independently is ruled out. As we discuss below, this option can be very helpful. Finally, fixing a bug in the expanded automaton would also require to manually trace the bug back in the individual components and perform the change there as well. Overall, the ability to simulate composite automata without requiring the user to expand the automata first is very useful. The TIOA Simulator will provide two alternative ways to simulate composite automata: The user will provide a single schedule block for the composition, but no schedule blocks for individual components. This option can be useful if it is easier to reason about system as a whole, or if a specific test case execution for system is desirable. The user will provide a schedule block for each individual component, and no schedule block for the composition. This option can be useful if it is easier to specify a single components schedule rather than the whole system s schedule. The simulator will give turns to the components in a non-deterministic way, thus this method can be used to test the system over multiple test case executions. 2.5.1 Schedule block for the Composition As mentioned above, the user will provide a single schedule block for the composition. The composition automaton is specified by its components, which are given a name and a parametrization of their formal parameters. Figure 4 shows an example of a composite automaton. The schedule block has very similar syntax with the normal schedule blocks. The main difference is that the component s name must precede the name of the transition or trajectory. automaton Composition components C: Channel (1,2) schedule do f i r e output C. send (m,i,j) od Figure 4: A composite automaton with a schedule block for the composition. 9

The simulator will attempt to execute the schedule block similar to the execution of primitive automaton schedule blocks. One important note is that all components must follow one of their trajectory definitions together. Thus, the NDR syntax can be modified slightly to allow a simultaneous follow statement in composite schedule blocks, as shown below: follow A. traj, B. traj, C. traj duration 10 Whenever a follow statement is encountered in the composition s schedule block, the simulator will check that exactly one trajectory definition from each component is included in the statement, and will attempt to execute them (as usual by checking the trajectory definition s the stopping conditions and invariant before and after the time passage). 2.5.2 Schedule block for the components Another option in composite simulation is to allow users to specify a schedule block for each individual component of the system, instead of the composition itself. The simulator will then give turns to the components (for example, in a simple Round-Robin or weighted Round-Robin way). One important difference in this case is that connected actions (output and input actions with the same name) among different components must be fired at the same time. Thus, for every output action the Simulator is about to execute in one component, it looks for the set of corresponding input actions in other components and fires them as well. As in the previous case where the scheduler is in the composition, we must ensure that all components follow their time-passage events at the same time. We propose a method for achieving this below: Composite Simulation Algorithm For every component C of the system, we maintain two variables: (a) trajectory-waiting, a boolean, indicating whether or not the component is ready to follow a trajectory, and (b) duration, a Real, indicating the amount of time that must pass for the component to move on to the next statement in its schedule block. The algorithm then executes as follows: For each component C in the system: Let s be the next statement in its schedule block. If s is a conditional, loop, or assignment statement, then execute s normally. If s is a fire statement, execute s normally and if the transition is an output one, fire the corresponding input ones as well. Finally, if s is afollow statement, then: Pause the execution of C; Indicate that C is in a trajectory-waiting status with a duration left equal to the one indicated by the statement s duration keyword. Let W be the set of all the system s components that are not in a trajectory-waiting status. If W is not empty, this means that there is at least one (other) component not waiting for a trajectory. We then exit C s execution and yield the turn to one of the components in W. Otherwise, all components are waiting for their trajectories. Then, let d be the maximum duration that 10

TIOA Front-End IL IL Parser Abstract Syntax Tree Simulator PVS Translator Figure 5: TIOA Toolkit Architecture all components can follow without violating their stopping conditions, that is, the minimum of all components duration variable. Follow the trajectories of all components for d time units. Subtract d from all components duration variables. For each component whose duration becomes 0, set trajectory-waiting to false and move their program counter to the next statement. 3 Implementation The TIOA Simulator is one of the back-end tools in the TIOA Toolkit. The current architecture of the toolkit is shown in Figure 1. The Front-End (Syntax and Static Semantics Checker) parses TIOA, checks the specification and reports any errors to the user. A correct TIOA specification is then translated to an Intermediate Language (IL). The back-end tools use a common IL Parser to get an abstract syntax tree representation as Java objects. The Simulator extends a number of these abstract syntax tree nodes to provide simulation. 4 Conclusion This Master Thesis proposal describes the design of the TIOA Simulator, a tool for testing and analyzing complex distributed systems. Based on the Timed Input/Output Automaton framework, the TIOA Simulator will execute automata written in the TIOA Language, and can be used to test the proposed model and find any problems associated with it, help the user gain a better understanding of the system, facilitate verification and extract performance predictions. The combined use of the TIOA Simulator with model checking or theorem proving tools will provide a complete framework for specifying, testing and verifying complex distributed systems. 11

References [1] Andrej Bogdanov. Formal verification of simulations between I/O automata. Master s thesis, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, Cambridge, MA, September 2001. [2] Anna E. Chefter. A simulator for the IOA language. Master s thesis, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, Cambridge, MA, May 1998. [3] Laura G. Dean. Improved simulation of Input/Output automata. Master s thesis, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, Cambridge, MA, September 2001. [4] Stephen J. Garland and Nancy A. Lynch. The IOA language and toolset: Support for designing, analyzing, and building distributed systems. Technical Report MIT/LCS/TR-762, Laboratory for Computer Science, Massachusetts Institute of Technology, Cambridge, MA, August 1998. URL http://theory.lcs.mit.edu/tds/ papers/lynch/ioa-tr-762.ps. [5] Dilsun Kaynar, Nancy Lynch, Sayan Mitra, and Stephen Garland. The TIOA language. Manuscript, October 2004. [6] Dilsun Kaynar, Nancy Lynch, Roberto Segala, and Frits Vaandrager. The theory of timed I/O automata. To appear in Synthesis Lectures on Computer Science, Morgan Claypool Publishers, 2005. [7] Nancy A. Lynch and Mark R. Tuttle. An introduction to input/output automata. CWI- Quarterly, 2(3):219 246, September 1989. Centrum voor Wiskunde en Informatica, Amsterdam, The Netherlands. Technical Memo MIT/LCS/TM-373, Laboratory for Computer Science, Massachusetts Institute of Technology, Cambridge, MA, November 1988. [8] J. Antonio Ramırez-Robredo. Paired simulation of I/O automata. Master s thesis, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, Cambridge, MA, September 2000. [9] Edward Solovey. Simulation of composite I/O automata. Master s thesis, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, Cambridge, MA, September 2003. [10] Joshua A. Tauber. Verifiable Compilation of I/O Automata without Global Synchronization. PhD thesis, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, Cambridge, MA, September 2004. 12

[11] Joshua A. Tauber and Stephen J. Garland. Definition and expansion of composite automata in IOA. Technical Report MIT/LCS/TR-959, Laboratory for Computer Science, Massachusetts Institute of Technology, Cambridge, MA, July 2004. URL http://theory.lcs.mit.edu/tds/papers/tauber/mit-lcs-tr-959.pdf. [12] Michael J. Tsai. Code generation for the IOA language. Master s thesis, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, Cambridge, MA, June 2002. [13] Toh Ne Win. Theorem-proving distributed algorithms with dynamic analysis. Master s thesis, Department of Electrical Engineering and Computer Science, Massachusetts Institute of Technology, Cambridge, MA, May 2003. [14] Toh Ne Win, Michael Ernst, Stephen Garland, Dilsun Kirli, and Nancy Lynch. Using simulated execution in verifying distributed algorithms. International Journal on Software Tools for Technology Transfer (STTT), 4:1 10, 2003. 13