TIV: A Toolset for Interactive Verification of Basic LOTOS Specifications

Transcription

1 TIV: A Toolset for Interactive Verification of Basic LOTOS Specifications Cheoljoo Jeong Kangho Kim Youngchan Kim Yeondae Chung Systems Engineering Research Institute Taejon, , Korea {cjeong,khkim,yckim,chung}@eagles.seri.re.kr Abstract LOTOS is a formal description language designed for the specification of communication protocols and concurrent systems. In this paper we introduce a toolset for the verification of Basic LOTOS specifications, currently under development at Systems Engineering Research Institute in Korea. Our toolset supports model generation, bisimilarity checking, model checking, and graphical display of models. In addition, they support interactive manipulation of Basic LOTOS specifications and their models through the use of a proof language called PAL (Proof Assistant Language). 1. Introduction Compared to the traditional system development methodologies like structured methods or objectoriented methods, formal description techniques allow us to verify the specified systems with mathematical rigor [14]. This is due to the fact that they usually provide formal description languages with mathematically sound semantics and the verification is carried out based on the semantic models of the specifications. In this paper we present a verification toolset, TIV (Tool for Interactive Verification), for Basic LOTOS specifications which enables us to verify the properties like consistency, safety, liveness, and reachability in the specified system. Through TIV, users can generate the models of Basic LOTOS specifications, check bisimulation equivalence between Basic LOTOS specifications, This research was partly supported by Ministry of Information and Communication, Korea, under contract no. N22032 perform model checking in modal µ-calculus, see the graphical output of models of Basic LO- TOS specifications, modify the Basic LOTOS specifications, and give queries on the models of Basic LOTOS specifications. TIV is a part of a LOTOS-based development environment called FORTIA, which supports syntaxdirected editing, simulation, verification, code generation, and testing of LOTOS specifications, currently under development at Systems Engineering Research Institute in Korea. In addition to the above functionalities, FORTIA supports partial mapping from OMT specifications to LOTOS specifications and automated guidance to write LOTOS specifications in objectoriented style. The formal description language LOTOS (Language of Temporal Ordering Specifications) was developed to define implementation-independent formal standards of ISO OSI services and protocols [9]. Along with SDL and Estelle, LOTOS was proved to be useful in specifying communication protocols, distributed systems, and concurrent systems. As the name LOTOS implies, this specification language allows us to model systems by specifying the temporal orderings of events. For example, Figure 1 shows a LOTOS specification process VM[10c,20c,Tea,Coffee]: noexit := 10c;Tea;VM[10c,20c,Tea,Coffee] [] 20c;Coffee;VM[10c,20c,Tea,Coffee] endproc (* VM *) Figure 1. LOTOS specification for a simple vending machine

2 for a very simple vending machine. VM system specifies the orderings of relevant events 10c, 20c, Tea, and Coffee. In this specification, event Coffee can occur only after 20c and event Tea can occur only after 10c. LOTOS consists of two parts: the first part is based on process algebras like CCS [12] and CSP [8], and the second part is based on algebraic specification language ACT ONE [4]. The former part is called Basic LOTOS and is used to specify the behavior of the system to be modeled. And the latter part is used to specify the abstract data types used in the system. The two parts altogether are called Full LOTOS. TIV supports verification of specifications written only in Basic LOTOS. In our project, a verification toolset for the verification of LOTOS abstract data types are also under development and will be combined with TIV by the end of There are several tools supporting verification of LOTOS specifications: Lite toolset [7], CADP toolset [6], and so on. In designing TIV, we have adopted the interactive verification model of Concurrency Workbench [2] or Concurrency Factory instead of above tools since interactivity and flexibility were what we have aimed at in developing of our toolset. For this purpose, TIV provides a proof language, called PAL (Proof Assistant Language), to assist users in carrying out verifications. PAL includes constructs for specifying CCS-like process expressions, µ-calculus formulas and numerous library functions to help users to get information on the specifications. Additionally, TIV provides a versatile graphical display which shows the current model of the processes 1, the results of bisimulation equivalence checking, the results of model checking, and other useful information. The organization of this paper is as follows. In section 2 we present overview of our toolset and in section 3 we present syntax, semantics, and usage of our verification language, PAL. In section 4, we present some verification techniques used in our toolset. In section 5, we present conclusions and our further research directions. 2. Overview of TIV 2.1. Three modules of TIV TIV consists of three modules: model generator module, model verification module, and graphical display module. 1 Throughout the paper, the terms specifications, processes, and process expressions will be used interchangeably. Model generator module The semantic model of a Basic LOTOS specification is the labeled transition system (LTS), which is defined to be a 4-tuple (S, A,, s 0 ), where S is a set of states, A is a set of actions (or events), S A S is a transition relation, and s 0 S is a start state. Figure 2 shows the model of the specification given in Figure 1. Tea A 10c 20c B C Coffee Figure 2. Semantic model (LTS) of Figure 1 Model generation module supports the generation of LTS s as semantic models of Basic LOTOS specifications. In fact, this module accepts PAL expressions as its input. PAL (Proof Assistant Language) is a language designed to support interactive verification of Basic LOTOS processes. PAL will be discussed in detail in section 3. Model generator module generates a minimized LTS. A minimized LTS of an LTS T is defined to be an LTS that is bisimulation equivalent to T with minimum number of states. This minimization procedure enhances the performance of bisimilarity checking and model checking algorithms. Model verification module Model verification module supports bisimilarity checking and model checking of LTS s. Given two specifications, S 1 and S 2, we may want to prove that S 1 has exactly the same behavior as S 2, or S 2 has at least the behavior of S 1. To prove the former we need some equivalence relations on the set of LTS s and we need some preorder relations to prove the latter. Bisimilarity is the most widely accepted equivalence relation that has been proposed as behavioral equivalence. Model verification module provides several equivalence and preorder checking facilities including strong (weak) bisimulation equivalence checking, strong (weak) preorder checking, ready simulation equivalence checking, simulation equivalence checking, and so on. Model checking let users prove whether some properties hold of each state or state transition of the system. TIV supports model checking in modal µ- calculus. Modal µ-calculus [11], which is an extension of Hennessy-Milner logic, is a powerful modal logic that provides greatest and least fixed point operators. We can express various properties such as safety,

3 liveness, and reachability in µ-calculus. For example, property Y will eventually satisfied is represented by the formula µx.y τ X and [10c]( Tea tt [Coffee]ff) denotes that after inserting 10c we can get Tea but cannot get Coffee. Graphical display module Graphical display module shows the current model in a visual manner. If user modifies the current process, the model generator module evaluates the new process, sends the model to the graphical display module, and the new model is shown in the graphic window. Users can see the location of a specific state or transition in a window by invoking appropriate function. It also shows the result of verification. After the model checking function is invoked, the states that satisfy the given µ-calculus formula are highlighted to show the result of model checking Data flow model of TIV TIV accepts Basic LOTOS specifications as its input. There are two ways to provide input specification to TIV: one is through the invocation of TIV from the LOTOS editor and the other is through typing PAL expressions directly in TIV. In the former case, since TIV cannot understand Basic LOTOS specifications but only PAL expression, the specification is translated into PAL expressions. PAL expressions are evaluated to LTS s by model generation module and these LTS s are used by bisimilarity checker and model checker. Model checker also needs µ-calculus formulas given by the user. Basic LOTOS spec(s) Transform PAL expr(s) PAL expr(s) Model Generation LTS s LTS Bisimilarity Check Model Check Figure 3. Data flows in TIV µ-calculus formula > process P = 10c.tea.P; - P : process > process Q = 20c.B; - Q : process > process X = P Q; - X : process > process B = coffee.q; - B : process > sbisimilar(p, Q); - false; > formula f = [10c](<tea>tt * [coffee]ff); - F: formula > model_check(x, f); - true > aset A = action(x); - A = {10c, 20c, coffee, tea}: aset; Figure 4. Sample session of TIV execution 3. PAL Interpreter (Model Generator) PAL (Proof Assistant Language) is a kind of interpreted language designed for interactive verification procedure and the use of PAL has the following advantages. 1. PAL allows flexible reuse of previously defined process expressions and µ-calculus formulas. Since, each expression can be bound to a name, these can be used later though this name. In Figure 4, process X was defined using processes P and Q. 2. Using PAL saves typing efforts of users. Since LOTOS is a kind of compiled language with type checking, there are non-essential constructs for the specification. In PAL, we can type more brief expressions than using Basic LOTOS. For example, Basic LOTOS specification in Figure 1 is represented as the following PAL expression. process VM = 10c.Tea.VM + 20c.Coffee.VM; 3. PAL interpreter can generate the models of process expressions efficiently based on the denotational semantics of PAL process expressions. If a process Q is defined using previously defined expressions {P i }, PAL interpreter uses the already constructed models of {P i } to generate the model of Q. 4. Using PAL function commands, users can define user-defined functions. Function

4 PrintSymDiff returns the symmetric difference of the action sets of two non-bisimilar processes. fun PrintSymDiff(process A, process B): aset = if (not sbisimlar(a, B)) cup(setminus(sort(a),sort(b)), setminus(sort(b), sort(a))) else EmptySet 5. PAL provides various library functions to get information on the models of specifications. Using these functions, users can manipulate and give queries on the LTS s. 6. PAL is a typed language and type checking procedure helps users prevent unexpected errors in programs. TIV contains an interpreter for PAL which reads a PAL command, evaluates it, and prints the result of evaluation Syntax of PAL The syntax of PAL (Figure 5) can be decomposed largely into two classes: the class of expressions and the class of commands. PAL expressions There are four kinds of PAL expressions. The most important expressions are process expressions (E) which are used to specify the processes. These expressions are evaluated to LTS s. The syntax of process expressions are very similar to that of CCS expressions without value passing. The only difference is the introduction of exit ([>) operator, which is a Basic LOTOS operator. This operator, in fact, does not add any additional expressive power to the algebra and can be seen as a syntactic sugar. The next important expressions are formula expressions (F ) to specify the property we want to prove though model checking. These expressions are evaluated to a set of states of the LTS that satisfy the formula. Boolean expressions (B) and arithmetic expressions (N) are similar to those commonly encountered in programming languages. PAL commands There are four kinds of commands in PAL. Sequences are of the form C 1 ; C 2, where C i are commands and this means that C 1 is evaluated first and C 2 is evaluated after that. Variable declarations are of the form type id = expr and this means that expr is evaluated to a value of type type and then the value is bound to the name id. Conditionals have the same semantics as those commonly encountered in functional languages like ML or Scheme. Finally, function declarations are of the form fun id(args) : type = expr, which means that a new function with args as its formal parameter and expr of type type as its body is bound to the name id. Variable declarations and function declarations are the only commands in PAL that modifies the environment of PAL interpreter Semantics of PAL expressions In this section, we give denotational semantics of process expressions and formula expressions, which were used to implement our PAL interpreter. Semantics of process expressions Figure 6 shows the semantics of process expressions, which is a labeled transition system. This semantics show how to construct an LTS, when semantics of the subexpressions are given (Given that L is the set of all LTS s, e : I L is an environment and ran(e) is the range of e. In the semantics of E 1 E 2, the operator T1 needs some explanation. Given two labeled transition systems, L 1 = (S 1, A 1, 1, s 1 ) L 2 = (S 2, A 2, 2, s 2 ), and T i = {(s, a, s ) S i (A 1 A 2 ) S i }, L 1 T1 L 2 denotes the set of labeled transition systems that can be obtained by identifying 1) s and s, 2) one a-derivative 2 of s and one a-derivative of s, and 3) two transitions (s, a, t) and (s, a, t ). As mentioned above, this denotational semantics can be used to generate the models of PAL process expressions. Semantics of formula expressions The meaning of a µ-calculus formula Φ, [Φ], which is determined with respect to an LTS is the set of states that satisfy Φ [5, 3]. [Φ] : Φ 2 S depends on a specific LTS (S, A,, s) and an environment e : I 2 S maps each identifiers to a subset of S, where I is the set of identifiers of type formula. The semantics of formula expressions are given in Figure 7. In the figure, e[x S] denotes the environment that agrees with e on all variables except X, which is bound to S. As you will see later, the semantics of formula expressions plays a central role in the model checking algorithm we use. 2 a-derivative of a state s is defined to be the set of states that can be reached from s through a transition labeled with a, i.e., {s s a s }.

5 id Identifier int Integer bool {true, false} formula {tt, ff} type {process, aset, action, formula, boolean, int} E ::= id stop id.e E E E + E E E E \ id E [> E (E) F ::= id formula F F F F [id]f id F mu(id, F ) nu(id, F ) (F ) B ::= id bool B and B B or B not B N < N N = N (B) N ::= id num N + N N N N N N/N N (N) arg ::= id : type args ::= arg arg, args ɛ expr ::= E F B N command ::= command; command type id = expr if B then C else C fi fun id(args) : type = expr Figure 5. Lexical categories and abstract syntax of PAL [stop]e = ({s},,, s) (! (S, A,, s 0 ) ran(e))[s S] [a.e ]e = (S {t}, A {a}, (t, a, s 0 ), t) where [E ]e = (S, A,, s 0 ) [E 1.E 2 ]e = (S 1 S 2, A 1 A 2 {τ}, 1 2 {(s, τ, s 2 ) s S 1 ( t S 1 )( a A 1 )[(s, a, t) 1 ]}, s 1 ) where [E i ]e = (S i, A i, i, s i ) [E 1 + E 2 ]e = (S 1 S 2 {s}, A 1 A 2 {τ}, 1 2 {(s, τ, s 1 ), (s, τ, s 2 )}, s) where [E i ]e = (S i, A i, i, s i ) [E 1 E 2 ]e = (S 1 S 2, A 1 A 2 {τ}, T 1 T 2, (s 1, s 2 )) where [E i ]e = (S i, A i, i, s i ), T 1 = {(s, t) a (s, t ) (s a s t = t ( t S 2 )[t a t ]) (t a t s = s ( s S 1 )[s a s ])}, and {(s, t) τ (s, t ) s a s t a t } [E \ a]e = (S S, A {a}, {(s, a, s ) s, s S} {(s, b, s ) a b ( s S )[s a s s b s ]}, s 0 ) where [E ]e = (S, A,, s 0 ) and S = {s S ( s)[s a s ]} [E 1 [> E 2 ] = (S 1 S 2 {s}, A 1 A 2 {τ}, 1 2 {(s, τ, s 2 ) s S 1 }, s 1 ) where [E i ] = (S i, A i, i, s i ) Figure 6. Semantics of process expressions

6 [tt]e = S [ff]e = [id]e = e(id) [Φ 1 Φ 2 ]e = [Φ 1 ]e [Φ 2 ]e [Φ 1 Φ 2 ]e = [Φ 1 ]e [Φ 2 ]e [[a]φ]e = {s ( s )[(s a s ) (s [Φ]e)]} [ a Φ]e = {s ( s )[(s a s ) (s [Φ]e)]} [mu(x, Φ)]e = {S S [Φ]e[X S ] S } [nu(x, Φ)]e = {S S S [Φ]e[X S ]} Figure 7. Semantics of formula expressions 4. Model Verification Tools 4.1. Bisimulation checker A lot of equivalence relations have been proposed as behavioral equivalences. Among them, one of the most notable relations is (strong) bisimulation equivalence proposed by Milner [12], which is defined as follows. Definition 1 Given an LTS (S, A,, s 0 ), binary relation R S S is a bisimulation if for all a A, (P, Q) R implies, 1. if P a P, then there exists Q such that Q a Q and (P, Q ) R, and 2. if Q a Q, then there exists P such that P a P and (P, Q ) R. When (P, Q) R, P and Q are said to be bisimilar and this is denoted by P Q. Intuitively, P and Q are bisimilar means that if P has a-transition for some action a (or P can observe action a), then Q also has a-transition and P and Q can transit to bisimilar states through a-transition. If the model of the Basic LOTOS specification is finite, the bisimilarity checking problem is reduced to the relational coarsest partition problem [10]: given a partition P of a set U and a binary relation E on U, find the coarsest refinement Q of P such that for each pair of blocks B 1, B 2 of Q, either B 1 E 1 (B 2 ) or B 1 E 1 (B 2 ) =. Kanellakis and Smolka [10] has devised an algorithm that solves the relational coarsest partition problem in O(mn) time (n is the number of states and m is the number of transitions) and Paige and Tarjan [13] has given a O(m log n)-time algorithm for the same problem. TIV uses the Kanellakis-Smolka algorithm to decide the bisimilarity, and these equivalence/preorder checking facilities are provided through a series of library functions. When the two specifications are bisimulation inequivalent, we can devise a Hennessy-Milner logical formula that distinguishes the specifications using Cleaveland s algorithm [1]. This formula distinguishes the two inequivalent specifications in the sense that it is satisfied by one but not satisfied by the other. When the input LTS s are not bisimilar, TIV outputs a µ-calculus formula that distinguishes the start states of two LTS s Model checker As it may be clear from the semantics of µ-calculus formulas, when the LTS of discourse is finite, the model checking problem can be seen as the following set membership problem. Model Checking Problem: Given a µ-calculus formula Φ and and LTS (S, A,, s 0 ), determine if s 0 [Φ]. TIV uses the model checking algorithm of Cleaveland and Steffen [3]. Their algorithm requires that the input formula has at most one alternation of least and greatest fixed operators. In the paper, it is claimed that this is not a severe restriction on the class of properties we can describe. 5. Conclusion In this paper, we have described a toolset, TIV (Toolset of Interactive Verification), for interactive verification of Basic LOTOS specifications. TIV supports model generation, bisimilarity checking, model checking, and graphical display of models. TIV includes a PAL (Proof Assistant Language) interpreter which enables interactive and flexible manipulation and verification of specifications. Two major research directions that we have in mind are as follows: Verification of Full LOTOS specifications Most verification problems are known to be either PSPACE-hard or EXPTIME-complete when it comes to the verification of Full LOTOS specification that involves value passing. We are seeking for efficient algorithms that partially solves these problems.

7 Verification of infinite state systems TIV supports verification of specifications that have finite models. Active research on infinite-state system verification are in progress in the concurrency theory community. We are going to adopt the results to our toolset. References [1] R. Cleaveland. On automatically distinguishing inequivalent processes. In Proceedings of 1990 Workshop on Computer-Aided Verification, number 531 in Lecture Notes in Computer Science, pages Springer-Verlag, [2] R. Cleaveland, J. Parrow, and B. Steffen. The concurrency workbench. In J. Sifakis, editor, Proceedings of the International Workshop on Automatic Verficiation Methods for Finite State Systems, number 407 in Lecture Notes in Computer Science, pages Springer-Verlag, [3] R. Cleaveland and B. Steffan. A linear-time model checking algorithm for the alternation-free modal mu-calculus. Formal Methods in System Design, 2: , [9] ISO8807. Information processing systems open systems interconnection LOTOS a formal description technique based on the temporal ordering of observational behavior. ISO 8807: 1989 (E), February [10] P. C. Kanellakis and S. A. Smolka. CCS expressions, finite state processes, and three problems of equivalence. In Proceedings of the 2nd ACM Symposium on Principles of Distributed Computing, pages , [11] D. Kozen. Results on the propositional mucalculus. Theoretical Computer Science, 27: , [12] R. Milner. Communication and Concurrency. Prentice-Hall, Englewood Cliffs, NJ, [13] R. Paige and R. E. Tarjan. Three partition refinement algorithms. SIAM Journal on Computing, 16(6): , December [14] J. M. Wing. A specifier s introduction to formal methods. IEEE Computer, pages 8 24, September [4] H. Ehrig and B. Mahr. Fundamentals of Algebraic Specification 1: Equations and Initial Semantics, volume 6 of EATCS Monographs on Theoretical Computer Science. Springer-Verlag, New York, NY, [5] E. A. Emerson and C. Lei. Model checking in the propositional mu-calculus. Technical Report TR , Department of Computer Science, University of Texas at Austin, Austin, TX, [6] J. Fernandez, H. Garavel, A. Kerbrat, R. Mateescu, L. Mounier, and M. Sighireanu. CADP (Cæsar/Aldebaran Development Package): A protocol validation and verification toolbox. In Rajeev Alur and Thomas A. Henzinger, editors, Proceedings of the 8th Conference on Computer- Aided Verification, August [7] S. Gnesi, E. Madelaine, and G. Ristori. An exercise in protocol verification. In T. Bolognesi et al., editor, LOTOSphere: Software Development with LOTOS, chapter 13, pages Kluwer Academic Publishers, [8] C. A. R. Hoare. Communicating Sequential Processes. Prentice-Hall International, Hertfordshire, 1985.