Linear vs. Branching Time: A Complexity-Theoretic Perspective

Linear vs. Branching Time: A Complexity-Theoretic Perspective Moshe Y. Vardi Rice University Abstract The discussion of the relative merits of linear versus branching time frameworks goes back to early 1980s. One of the beliefs dominating this discussion has been that “while specifying is easier in LTL (linear-temporal logic), verification is easier for CTL (branching-temporal logic)”. Indeed, the restricted syntax of CTL limits its expressive power and many important behaviors (e.g., strong fairness) can not be specified in CTL. On the other hand, while model checking for CTL can be done in time that is linear in the size of the specification, it takes time that is exponential in the specification for LTL. A closer examination of the the issue reveals, however, that the computational superiority of the branching time framework is perhaps illusory. In this talk we will compare the complexity of branching-time verification vs. linear-time verification in many scenarios, and show that linear-time verification is not harder and often is even easier than branching-time verification. This suggests that the tradeoff between branching and linear time is not a simple tradeoff between complexity and expressiveness. 1 Introduction Temporal logics, which are modal logics geared towards the description of the temporal ordering of events, have been adopted as a powerful tool for specifying and verifying open programs [MP92a, MP95]. Two possible views regarding the nature of time induce two types of temporal logics [Lam80]. In linear temporal logics, time is treated as if each moment  Address: CS Department, Rice University, Houston TX 77005-1892, U.S.A. Email: [email protected], URL: http://www.cs.rice.edu/ vardi. Supported in part by NSF grants CCR-9628400 and CCR-9700061, and by a grant from the Intel Corporation. in time has a unique possible future. Thus, linear temporal logic formulas are interpreted over linear sequences and we regard them as describing a behavior of a single computation of a program. In branching temporal logics, each moment in time may split into various possible futures. Accordingly, the structures over which branching temporal logic formulas are interpreted can be viewed as infinite computation trees, each describing the behavior of the possible computations of a nondeterministic program. In the linear temporal logic LTL, formulas are composed from the set of atomic propositions using the usual Boolean connectives as well as the temporal operators G (“always”), F (“eventually”), X (“next”), and U (“until”). For example, the LTL formula = G(req F grant) refers to the atomic propositions req and grant and is true in a computation iff every state in the computation in which req hold is followed by some state in the future in which grant holds. The branching temporal logic CTL? augments LTL by the path quantifiers E (“there exists a computation”) and A (“for all computations”). For example, the CTL? formula ' = AG(req EF grant) is true in a computation tree iff in all its computations, every state in which req holds branches to at least one computation in which grant eventually holds. The branching temporal logic CTL is a fragement of CTL? in which every temporal operator is preceded by a path quantifier. For example, while ' above is a CTL formula, F grant) is not a CTL the CTL? formula AG(req formula. The expressive powers of LTL and CTL are incomparable [Lam80], while CTL? is more expressive than both LTL and CTL [EH86]. The discussion of the relative merits of linear versus branching temporal logics is by now almost 20years old [Lam80, CE81, QS81, Pnu81, BMP83, ! ! ! Pnu85b, EH86, Sti87]. One of the most frequent arguments in this discussion relates to the computational complexity of algorithmic verification. The discovery of algorithmic methods for verifying temporal-logic properties of finite-state programs [CE81, QS81, LP85, VW86] is one of the most significant developments in the area of formal verification in the last two decades. This discovery derives its significance both from the fact that many synchronization and communication protocols, as well as many digital systems, can be modeled as finite-state systems, and from the great ease of use of fully algorithmic methods [BBG+ 94]. Finite-state systems can be modeled by transition systems where each state has a bounded description, and hence can be characterized by a fixed number of Boolean atomic propositions. In temporallogic model checking, we verify the correctness of a finite-state system with respect to a desired behavior by checking whether the labeled transition system satisfies a temporal logic formula that specifies this behavior. When the model checker fails to verify the behavior, it produces a counterexample, which is in essence a trace of an incorrect behavior. Indeed, model checkers have demonstrated their ability to discover very subtle flaws in designs of considerable complexity [CK86]. Given a transition system M and a linear temporal logic formula , the model-checking problem for M and is to decide whether holds in all the comis a branching temporal putations of M . When logic formula, the problem is to decide whether holds in the computation tree of M . The complexity of model checking for both linear and branching temporal logics is well understood: suppose we are given a transition system of size n and a temporal logic formula of size m. For the branching temporal logic CTL, model-checking algorithms run in time O(nm) [CES86], while, for the linear temporal logic LTL, and even for the more expressive CTL?, model-checking algorithms run in time n2O(m) [LP85, EL85]. Since LTL model checking is PSPACE-complete [SC85], the latter bound probably cannot be improved. Because of these results, one of the beliefs dominating the linear-vs.-branching-time discussion has traditionally been that “model checking for CTL is easy, while model checking for LTL is hard”. Furthermore, the fact that the complexity of model checking is the same for LTL and CTL? was taken as evidence that “branching is free”. Our goal in this overview paper is to show that the belief that CTL is superior to LTL from the computational-complexity perspective is rather simplistic. We will show that in certain verfication scenarios CTL does not dominate LTL computationaly. As a simple example of what we mean by “verification scenario” consider a designer who just completed a design M and is trying to verify it against a specification '. Since the design is rather “fresh”, the designer fully expects the verification to fail and is using the model checker as a sophisticated debugger. What should the designer conclude if, surprisingly, the model checker succeeded in verifying M against '? A plausible conclusion is that the specification ' is flawed. For example, if ' is a valid formula, then every design satisfies '. Thus, the designer may prudently want to check that ' is not valid before concluding that the design M is correct. This argument suggests that a model checker ought to include also the functionality of validity checking. Note, however, that while the validity problem for LTL is PSPACE-complete [SC85], the validity problem for CTL is EXPTIME-complete [FL79, EH85], and the validity problem for CTL? is 2EXPTIMEcomplete [VS85, EJ88]. In the rest of this paper we examine four additional verification scenarios: modular verification [KV95], verification of open systems [KV96, KVW98], verification of concurrent systems [BVW94, Kup95], and automata-theoretic verification [KV98]. In each case we show that CTL does not dominate LTL computationally. In the concluding section of the paper we discuss the implication of these results on the linearvs.-branching-time discussion. We assume familiarity with the syntax and semantics of temporal logic [Eme90, KT90, Sti92]. 2 Modular Model Checking Model checking is known to suffer from the socalled state-explosion problem. In a concurrent setting, the system under consideration is typically the parallel composition of many modules. As a result, the size of the state space of the system is the prod- uct of the sizes of the state spaces of the participating modules. This gives rise to state spaces of exceedingly large sizes, which makes even linear-time algorithms impractical. This issue is one of the most important ones in the area of computer-aided verification and is the subject of active research (cf. [BCM+ 92]). Modular verification is one possible way to address the state-explosion problem, cf. [CLM89]. In modular verification, one uses proof rules of the following form: 9 M1 j= 1 > = M2 j= 2 > M1kM2 j= C ( 1; 2; ) ; Here M j=  means that the module M satisfies the formula , the symbol “k” denotes parallel composition, and C ( 1; 2; ) is some logical condition re- lating 1, 2, and . The advantage of using modular proof rules is that it enables one to apply model checking only to the underlying modules, which have much smaller state spaces. A key observation, see [MC81, Lam83, Jon83], is that in modular verification the specification should include two parts. One part describes the desired behavior of the module. The other part describes the assumed behavior of the system within which the module is interacting. This is called the assume-guarantee paradigm, as the specification describes what behavior the module is guaranteed to exhibit, assuming that the system behaves in the promised way. For the linear temporal paradigm, an assumeguarantee specification is a pair h'; i, where both ' and are linear temporal logic formulas. The meaning of such a pair is that all the computations of the module are guaranteed to satisfy , assuming that all the computations of the environment satisfy '. As observed in [Pnu85a], in this case the assume-guarantee pair h'; i can be combined to a single linear temporal logic formula ' ! . Thus, model checking a module with respect to assume-guarantee specifications in which both the assumed and the guaranteed behaviors are linear temporal logic formulas is essentially the same as model checking the module with respect to linear temporal logic formulas. The situation is different for the branching temporal paradigm, where assumptions are taken to apply to the computation tree of the system within which the module is interacting [GL94]. In this framework, a module M satisfies an assume-guarantee pair h'; i iff whenever M is part of a system satisfying ', the system also satisfies . (As is shown in [GL94], this is not equivalent to M satisfying ' ! .) We call this branching modular model checking. Furthermore, it is argued in [GL94], as well as in [DDGJ89, Jos89, GL94, DGG93], that in the context of modular verification it is advantageous to use only universal branching temporal logic, i.e., branching temporal logic without existential path quantifiers. In a universal branching temporal logic one can state properties of all computations of a program, but one cannot state that certain computations exist. Consequently, universal branching temporal logic formulas have the helpful property that once they are satisfied in a module, they are satisfied also in every system that contains this module. The focus in [GL94] is on using 8CTL, the universal fragment of CTL, for both the assumption and the guarantee. In this paper, we focus on the branching modular model-checking problem, where assumptions and guarantees are in both 8CTL and in the more expressive 8CTL? , the universal fragment of CTL?. A module M = hAP; W; R; W0; Li consists of a set AP of atomic propositions, a set W of states, a transition relation R  W  W , a set W0 of initial states, and a labeling function L : W ! 2AP that maps each state to a set of atomic propositions that hold in this state. A computation of a module is a sequence of states,  = w0 ; w1; : : : such that for every i  0, we have that hwi; wi+1i 2 R. We use M; w j= ' to denote that the state w in M satisfies the formula '. A module M satisfies a formula ' if ' holds in all initial states of M . The size of M is the sum of the number of states in W and the number of transitions in R. Let M and M 0 be two modules with sets AP and AP 0 of atomic propositions. The composition of M and M 0, denoted M kM 0, is a module that has exactly these behaviors which are joint to M and M 0. We define M kM 0 to be the module hAP 00; W 00; R00; W0 ; L00i, where AP 00 = AP [ AP 0 , W 00 = fhw; w0i : L(w) \ AP 0 = L0(w0) \ AP g, W0 = (W0  W0 ) \ W 00, R00 = fhhw; w0i; hs; s0ii : hw; si 2 R and hw0; s0i 2 R0g, and L00(hw; w0i) = 00 00 0 L(w) [ L (w ) for hw; w i 2 W 0 0 0 00 . In modular verification, one uses assertions of the form h'iMh i to specify that whenever M is part of a system satisfying the universal branching temporal logic formula ', the system satisfies the universal branching temporal logic formula too. Formally, h'iMh i holds if MkM 0 j= for all M 0 such that MkM 0 j= '. Here ' is an assumption on the behavior of the system and is the guarantee on the behavior of the module. Assume-guarantee assertions are used in modular proof rules of the following form: h'1 iM1h 1i htrueiM1h'1 i h'2 iM2h 2i htrueiM2h'2 i 9 >>= >> htrueiM1kM2h 1 ^ 2i ; Thus, a key step in modular verification is checking that assume-guarantee assertions hold, which we called the branching modular model-checking problem. Theorem 2.1 [KV95] (1) The branching modular model-checking problem for 8CTL is PSPACE-complete. (2) The branching modular model-checking problem for 8CTL? is EXPSPACE-complete. Thus, in the context of modular model checking, 8CTL has the same computational complexity as LTL, while 8CTL? is exponentially harder. 3 Verification of Open Systems In computer system design, we distinguish between closed and open systems. A closed system is a system whose behavior is completely determined by the state of the system. An open system is a system that interacts with its environment and whose behavior depends on this interaction. Such systems are called also reactive systems [HP85]. As an example of closed and open systems, consider two drink-dispensing machines. One machine, which is a closed system, repeatedly boils water, makes an internal nondeterministic choice, and serves either coffee or tea. The second machine, which is an open system, repeatedly boils water, asks the environment to choose between coffee and tea, and deterministically serves a drink according to the external choice [Hoa85]. Both machines induce the same infinite tree of possible executions. Nevertheless, while the behavior of the first machine is determined by internal choices the behavior of the second machine is determined also by external choices, made by its environment. Formally, in a closed system, the environment can not modify any of the system variables. In contrast, in an open system, the environment can modify some of the system variables. We model finite-state open systems by open modules. An open module is simply a module with a partition of the states into two sets. One set contains system states and corresponds to locations where the system makes a transition. The second set contains environment states and corresponds to locations where the environment makes a transition. Consider the open module M presented below. It has three system states (boil, tea, and coffee), and it has one environment state (choose). It models the second drinkdispensing machine described above. When M is in the system state boil, we know exactly what its possible next states are. It can either stay in the state boil or move to the state choose. In contrast, when M is in the environment state choose, there is no certainty with respect to the environment and we can not be sure that both tea and coffee are possible next states. For example, it might be that for some users of the machine, coffee is not a desirable option. If we ignore the partition of M ’s states to system and environment states and regard it as a (standard) module P , then it models the first drink-dispensing machine described above. M: s boil e choose s tea s coffee To see the difference between the semantics of modules and open modules, let us consider two questions. Is it always possible for the first machine to eventually serve tea? This is equivalent to asking whether P satisfies the CTL formula AGEF tea, and the answer is positive. Is it always possible for the second machine to eventually serve tea? Here, the answer is negative. Indeed, if the environment always choose coffee, the second machine will never serve tea. Suppose now that we check with current modelchecking tools whether it is always possible for the second machine to eventually serve tea, what will the answer be? Unfortunately, model-checking tools do not distinguish between closed and open systems and they will say that M does satisfy AGEF tea. As discussed in [MP92b], when the specification is given in linear temporal logic, there is indeed no need to worry about uncertainty with respect to the environment; since all the possible interactions of the system with its environment have to satisfy a linear temporal logic specification in order for M to satisfy the specification, the program P and the module M satisfy exactly the same linear temporal logic formulas. From the example above we learn that when the specification is given in branching temporal logic, we do need to take into account the uncertainty about the environment. There is a need to define a different model-checking problem for open systems, and there is a need to adjust current model-checking tools to handle open systems correctly. We now specify formally the problem of model checking of open modules (module checking, for short). As with usual model checking, the problem has two inputs: an open module M and a temporal logic formula . For an open module M , let VM denote the unwinding of M into an infinite tree. We say that M satisfies iff holds in all the trees obtained by pruning from VM subtrees whose root is a successor of an environment state. The intuition is that each such tree corresponds to a different (and possible) environment. We want to hold in every such tree, since, of course, we want the open system to satisfy its specification no matter how the environment behaves. For example, an environment for the second drink-dispensing machine is an infinite line of thirsty people waiting for their drinks. Since each person in the line can either like both coffee and tea, or like only coffee, or like only tea, there are many different possible environments to consider. Each environment induces a different tree. For example, an environment in which all the people in line do not like tea, induces a tree that has the left subtree of all its choose nodes pruned. Similarly, environments in which the first person in line like both coffee and tea induce trees in which the first choose node has two successors. Formally, we model an open system by an open module M = hAP; Ws ; We; R; W0; Li, where hAP; Ws [ We ; R; W0; Li is a module, Ws is a set of system states, and We is a set of environment states. We use W to denote Ws [ We . For each state w 2 W , let succ(w) be the set of w’s R-successors; i.e., succ(w) = fw0 : R(w; w0)g. Consider a system state ws and an environment state we. When the current state is ws , all the states in succ(ws ) are possible next states. In contrast, when the current state is we , there is no certainty with respect to the environment transitions and not all the states in succ(we) are necessarily possible next states. The only thing guaranteed is that not all the environment transitions are impossible, since the environment can never be blocked. For a state w 2 W , let step(w) denote the set of the possible sets of w’s next successors during an execution. By the above, step(ws ) = fsucc(ws)g and step(we ) contains all the nonempty subsets of succ(we ). An infinite tree is a set T  IN such that if x
c 2 T where x 2 IN and c 2 IN, then also x 2 T , and for all 0  c0 < c, we have that x
c0 2 T . In addition, if x 2 T , then x
0 2 T . The elements of T are called nodes, and the empty word  is the root of T . Given an alphabet , a -labeled tree is a pair hT; V i where T is a tree and V : T !  maps each node of T to a letter in . An open module M can be unwound into an infinite tree hTM ; VM i in a straightforward way. When we examine a specification with respect to M , it should hold not only in hTM ; VM i (which corresponds to a very specific environment that does never restrict the set of its next states), but in all the trees obtained by pruning from hTM ; VM i subtrees whose root is a successor of a node corresponding to an environment state. Let exec(M ) denote the set of all these trees. Formally, hT; V i 2 exec(M ) iff the following holds:    T and V () = w0. For all x T with V (x) = w, 2 2 there exists w0; : : :; wn step(w) such that T INjxj+1 = x 0; x 1; : : :; x n and for all 0 c n we have V (x c) = wc. Intuitively, each tree in exec(M ) corresponds to a diff f g 2

\
g  
ferent behaviour of the environment. Note that a single environment state with more than one successor suffices to make exec(M ) infinite. Given an open module M and a CTL? formula , we say that M satisfies , denoted M j=o , if all the trees in exec(M ) satisfy . The problem of deciding whether M satisfies is called module checking. We use M j= to indicate that when we regard M as a module (thus refer to all its states as system states), then M satisfies . The problem of deciding whether M j= is the usual model-checking problem. Note that while M j=o entails M j= , all that M j= entails is that M 6j=o : . Indeed, M j=o requires all the trees in exec(M ) to satisfy . On the other hand, M j= means that the tree hTM ; VM i satisfies . Finally, M 6j=o : only tells us that there exists some tree in exec(M ) that satisfies . We can define module checking also with respect to linear-time specifications. We say that a module M satisfies an LTL formula iff M j=o A . Theorem 3.1 [KV96, KVW98] (2) The module-checking problem for LTL is PSPACE-complete. (2) The module-checking problem for CTL is EXPTIME-complete. (3) The module-checking problem for CTL? is 2EXPTIME-complete. Thus, module checking for LTL is easier than for CTL (assuming that EXPTIME is different than PSPACE), which is, in turn, easier than for CTL ?. When analyzing the complexity of model checking, a distinction should be made between complexity in the size of the input structure and complexity in the size of the input formula; it is the complexity in size of the structure that is typically the computational bottleneck [LP85]. Let us now consider the program complexity [VW86] of module checking; i.e., the complexity of this problem in terms of the size of the input module, assuming the formula is fixed. It is known that the program complexity of LTL, CTL, and CTL? model checking is NLOGSPACE [VW86, BVW94]. This is very significant since it implies that if the system to be checked is obtained as the product of the components of a concurrent program (as is usually the case), the space required is polynomial in the size of these components rather than of the order of the exponentially larger composition. We have seen that for CTL and CTL? , module checking is much harder than model checking. We now claim that when we consider program complexity, module checking is still harder (assuming that PTIME is different than NLOGSPACE). Theorem 3.2 The program complexity of CTL and CTL? module checking is PTIME-complete. 4 Verification of Concurrent Systems As noted earlier, a common cause of the stateexplosion problem is that fact that the system under consideration is typically the concurrent composition of many modules. As a result, the size of the state space of the system is the product of the sizes of the state spaces of the participating modules. This gives rise to state spaces of exceedingly large sizes, which makes even algorithms with linear running time impractical. This difficulty, however, is hidden in the standard way of reporting the complexity of model checking, which is as a function of the size of the state space of the system under consideration. A better way to report this complexity is perhaps in term of the size of the state spaces of the underlying modules. In a concurrent setting, we assume that have have k modules M1; : : :; Mk and a formula . We have to verify that M1k : : : kMk j= . We define the complexity of model checking here with respect to the sizes of the components Mi ’s and the length of the formula being checked. Analogously, the program complexity of model checking for concurrent systems is defined in terms of the size of the components of the concurrent system. Theorem 4.1 [BVW94, Kup95] (1) The complexity of LTL, CTL and CTL model checking for concurrent systems is PSPACEcomplete. (2) The program complexity of LTL, CTL and CTL model checking for concurrent programs is PSPACE-complete. Thus, in a concurrent setting model checking of LTL, CTL, and CTL? have the same complexity, as the complexity is completely dominated by the “explosion” of the concurrent state space. 5 Automata-Theoretic Verification In design verification one checks that an implementation meets its specification. So far we used different formalisms to describe implementations and specification; we used an automata-theoretic formalism to describe implementations and we used a logical formalism to describe specifications. It is sometimes more natural to express both implementations and specifications using the same formalism. Both the specification and the implementation describe the possible behaviors of the system, but the implementation is more concrete than the specification, or, equivalently, the specification is more abstract than the implementation (cf. [AL91]). This basic notion of verification suggests a top-down method for design development. Starting with a highly abstract specification, we can construct a sequence of “behavior descriptions”. Each description refers to its predecessor as a specification, so it is less abstract than its predecessor. The last description contains no abstractions, and constitutes the final implementation. Hence the name hierarchical refinement for this methodology (cf. [LS84, LT87, Kur94]). Here we use the automata-theoretic approach and describe both specifications and implementations as modules [Kur94]. We distinguish between two approaches to implementation of specifications. The first approach is trace-based implementation, where we require every computation of the implementation to correlate to some computation of the specification. The second approach is tree-based implementation, where we require every computation tree embodied in the implementation to correlate to some computation tree embodied in the specification. The exact notion of correct implementation then depends on how we interpret correlation. We can, for example, interpret correlation as identity. Then, correct trace-based implementation is one in which every computation is also a computation of the specification, and correct tree-based implementation is one in which every embodied computation tree is also embodied in the specification. Numerous interpretations of correlation are suggested and studied in the literature (see [Hen85, Mil89, AL91]). Here, we consider a very simple definition of correlation and interpret it as equivalence with respect to the variables joint to the implementation and the specification, as the implementation is typically defined over a wider set of variables, reflecting the fact that it is more concrete than the specification. The tree-based approach is stronger in the following sense. If I is a correct tree-based implementation of the specification S , then I is also a correct tracebased implementation of S . As shown by Milner [Mil80], the opposite direction is not true. The two approaches to implementation are strongly related to the linear- versus branching-time dichotomy in temporal logic [Pnu85b]. The temporal-logic analogy to the strength of the tree-based approach is the expressiveness superiority of 8CTL? over LTL [CD88]. Indeed, while a correct trace-based implementation is guaranteed to satisfy all the LTL formulas satisfied in the specification, a correct tree-based implementation is guaranteed to satisfy all the 8CTL? formulas satisfied in the specification [GL94]. Here we consider and compare the complexity of the problem of determining whether I is a correct trace-based implementation of S , and the problem of determining whether I is a correct tree-based implementation of S . The different levels of abstraction in the implementation and the specification are reflected in their sizes. The implementation is typically much larger than the specification and it is its size that is the computational bottleneck. Therefore, of particular interest to us is the implementation complexity of these problems; i.e., their complexity in terms of I , assuming S is fixed. This is analogous to the notion of program complexity discussed earlier. We model specifications and implementations by modules. The modulels are defined over the sets API and APS of atomic propositions used in the implementation and specification, respectively. Thus, the alphabets of the systems are 2API and 2APS . Re- call that usually the implementation has more variables than the specification. Hence, API  APS . We therefore interpret correlation as equivalence with respect to APS . In other words, associating computations and computation trees of the implementation with these of the specification, we first projet them on APS . Within this framework, correct trace-based implementation corresponds to language containment and correct tree-based implementation corresponds to simulation [Mil71]. Since simulation can be checked in polynomial time, whereas the trace containment problem is PSPACE-complete, it seems that the treebased approach is more efficient than the trace-based approach. This is reminiscent of the computational advantage of branching-time model checking over linear-time model checking. Once, however, we want our implementations and specifications to describe behaviors that satisfy both liveness and safety properties, modules are too weak. Then, we need the framework of fair modules. We consider unconditional fairness (also known as impartiality) [LPS81]. Within this framework, correct trace-based implementation corresponds to fair containment and correct tree-based implementation corresponds to fair simulation [BBLS92, ASB+ 94, GL94]. Hence, it is the complexity of these problems that should be examined when we compare the trace-based and the tree-based approaches. A fair module M = hAP; W; R; W0; L; i consists of a module hAP; W; R; W0; Li and a fairness condition . An unconditionl fairness condition is simply a subset of W . Recall that a computation of S is a sequence  = w0; w1; w2; : : : of states such that for every i  0 we have R(wi; wi+1). In order to determine whether a computation is fair, we refer to the set Inf ( ) of states that  visits infinitely often. We say that  is fair if Inf ( ) \ 6= ;. It is easy to see is that fair modules essentially constitute a notational variant of Büchi automata [Tho90]. Trace-based and tree-based implementations are formalized in terms of (fair) containment and (fair) simulation between an implementation I and a specification S . Recall that I and S are given as fair modules over the alphabets 2API and 2APS respectively, with API  APS . For technical convenience, we as- sume that API = APS ; thus, the implementation and the specification are defined over the same alphabet. By taking, for each  2 2API , the letter  \ APS instead the letter  , our results are valid also for the case API  APS . For a state w, a w-computation is a computation w0; w1; w2; : : : with w0 = w. We use L(S w ) (resp., w ! Lf (S )) to denote the set of all words 0
1


2  for which there exists a (resp., fair) w-computation w0; w1; : : : in S with L(wi) = i for all i  0. The Lf (S )) of S is then defined as SlanguageL(LS(wS)) (resp., S w (resp., w2W0 w2W0 Lf (S )). Given two 0 fair modules M and M , trace-based implementation can now be characterized in terms of language containment, i.e, L(S )  L(S 0), and fair containment, i.e., Lf (S )  Lf (S 0). This gives rise to the containment probem (decide if L(S )  L(S 0)) and the fair containment problem (decide if Lf (S )  Lf (S 0)). While containment and fair containment refer to each word in L(S ) and Lf (S ) independently, simulation refers also to the branching structure of the modules under consideration. Let M = hAP; W; R; W0; L; i and M 0 = 0 0 0 0 0 hAP; W ; R ; W0 ; L ; i be fair modules. Let w and 0 w be states in W and W 0, respectively. A relation H  W  W 0 is a simulation relation from hM; wi to hM 0; w0i iff the following conditions hold [Mil71]: (1) (2) H (w; w ). For all t and t with H (t; t ), we have L(t) = L (t ). W For all t and t with H (t; t ) and for all s such that R(t; s), there exists s W such that R (t ; s ) and H (s; s ). 0 0 0 (3) 0 0 0 0 2 0 0 0 0 2 0 0 To account for fairness, it is convenient to extend H to relate also infinite computations of M and M 0. For two computations  = w0; w1; : : : in M , and  0 = w00 ; w10 ; : : : in M 0 , we say that H (;  0) holds iff H (wi; wi0) holds for all i  0. For a pair 0 0 0 hw; w i 2 W  W , we say that hw; w i is good in H iff for every fair w-computation  in M , there exists a fair w0 -computation  0 in M 0 , such that H (;  0). The relation H is a fair simulation relation from hS; wi to 0 0 hS ; w i iff the following conditions hold [GL94]: (1) H (w; w ). 0 0 with H (t; t 0 with H (t; t (2) For all t and 0 0 L (t ). t (3) For all t and good in H . t 0 ), 0 ), we have L(t) the pair h i is t; t = 0 A (fair) simulation relation H is a (fair) simulation from M to M 0 if for every w 2 W0 there exists w0 2 W00 such that H (w; w0). If there exists a (fair) simulation from M to M 0 , we say that M (fairly) simulates M 0 and we write M  M 0 (resp., 0 M f M ). Intuitively, it means that the transition system S 0 has more behaviors than the transition system S . This gives rise to the simulation probem (decide if M  M 0 ) and the fair simulation problem (decide if M f M 0 ). It is easy to see that simulation implies containment and fair simulation implies fair containment. The opposite, however, is not true in general. Without fairness, the tree-based approach is easier than the trace-based approach (assuming that PSPACE is different than PTIME). Theorem 5.1 (1) [MS72, KV98] The containment problem is PSPACE-complete. (2) [Mil80, BGS92, KV98] The simulation problem is PTIME-complete. One we introduce fairness, however, the advantage of the tree-based approach disappears. Theorem 5.2 (1) [Wol82] The fair containment problem is PSPACE-complete. (2) [KV98] The fair simulation problem is PSPACEcomplete. (2) The implementation complexity of simulation and fair simulation is PTIME-complete Thus, with regard to implementation complexity, the trace-based approach is actually easier than the tree-based approach. 6 Concluding Remarks We examine have four verification scenarios: modular verification, verification of open systems, verification of concurrent systems, and automata-theoretic verification. In each case we showed that CTL does not dominate LTL computationally. We believe that this evidence demonstrates convingly that the assertion “model checking for CTL is easy, while model checking for LTL is hard” is rather simplistic. Furthermore, as in many of these scenarios the complexity of verifying CTL? properties is markedly higher than that for LTL properties, it is quite clear that “branching is not free”. What can we conclude from these results regarding the relative merits of the linear and branching time approaches? Our conclusion is that the debate cannot be settled by reference to complexity-based arguments, since no approach dominates the other from the worstcase-computational-complexity perspective. At the same time, the debate also cannot be settled by reference to expressiveness-based arguments, since it is known that LTL and CTL are expressively incomparable [Lam80]. Thus, it seems that the debate cannot be settled by reference to theoretical arguments solely. Rather, it is time that pragmatic arguments be brought to bear on this issue. Given the growing use of model-checking tools in industry [Goe97, Kur97], the debate might end up being decided by the marketplace rather than by the research community. References [AL91] Recall that our main concern is the complexity in terms of the (much larger) implementation. Theorem 5.3 [KV98] (1) The implementation complexity of containment and fair containment is NLOGSPACE-complete. M. Abadi and L. Lamport. The existence of refinement mappings. Theoretical Computer Science, 82(2):253–284, 1991. [ASB+ 94] A. Aziz, V. Singhal, F. Balarin, R. Brayton, and A.L. Sangiovanni-Vincentelli. Equivalences for fair kripke structures. In Proc. 21st Int. Colloquium on Automata, Languages and Programming, Jerusalem, Israel, July 1994. [BBG+ 94] I. Beer, S. Ben-David, D. Geist, R. Gewirtzman, and M. Yoeli. Methodology and system for practical formal verification of reactive hardware. In Proc. 6th Conference on Computer Aided Verification, volume 818 of Lecture Notes in Computer Science, pages 182– 193, Stanford, June 1994. [BBLS92] S. Bensalem, A. Bouajjani, C. Loiseaux, and J. Sifakis. Property preserving simulations. In Proc. 4th Conference on Computer Aided Verification, volume 663 of Lecture Notes in Computer Science, pages 260–273, Montreal, June 1992. Springer-Verlag. [CK86] E.M. Clarke and R.P. Kurshan. Computer aided verification. IEEE Spectrum, 33:61–67, 1986. [CLM89] E.M. Clarke, D.E. Long, and K.L. McMillan. Compositional model checking. In R. Parikh, editor, Proc. 4th IEEE Symposium on Logic in Computer Science, pages 353–362. IEEE Computer Society Press, 1989. [BCM+ 92] J.R. Burch, E.M. Clarke, K.L. McMillan, D.L. Dill, and L.J. Hwang. Symbolic model checking: 1020 states and beyond. Information and Computation, 98(2):142–170, June 1992. [DDGJ89] W. Damm, G. Döhmen, V. Gerstner, and B. Josko. Modular verification of Petri nets: the temporal logic approach. In Stepwise Refinement of Distributed Systems: Models, Formalisms, Correctness (Proceedings of REX Workshop), volume 430 of Lecture Notes in Computer Science, pages 180–207, Mook, The Netherlands, May/June 1989. SpringerVerlag. [BGS92] J. Balcazar, J. Gabarro, and M. Santha. Deciding bisimilarity is P-complete. Formal Aspects of Computing, 4(6):638–648, 1992. [DGG93] [BMP83] M. Ben-Ari, Z. Manna, and A. Pnueli. The temporal logic of branching time. Acta Informatica, 20:207–226, 1983. D. Dams, O. Grumberg, and R. Gerth. Generation of reduced models for checking fragments of CTL. In Proc. 5th Conf. on Computer Aided Verification, volume 697 of Lecture Notes in Computer Science, pages 479– 490. Springer-Verlag, June 1993. [BVW94] O. Bernholtz, M.Y. Vardi, and P. Wolper. An automata-theoretic approach to branchingtime model checking. In D. L. Dill, editor, Computer Aided Verification, Proc. 6th Int. Conference, volume 818 of Lecture Notes in Computer Science, pages 142–155, Stanford, June 1994. Springer-Verlag, Berlin. [EH85] E.A. Emerson and J.Y. Halpern. Decision procedures and expressiveness in the temporal logic of branching time. Journal of Computer and System Sciences, 30:1–24, 1985. [EH86] E.A. Emerson and J.Y. Halpern. Sometimes and not never revisited: On branching versus linear time. Journal of the ACM, 33(1):151– 178, 1986. [EJ88] E.A. Emerson and C. Jutla. The complexity of tree automata and logics of programs. In Proc. 29th IEEE Symposium on Foundations of Computer Science, pages 368–377, White Plains, October 1988. [EL85] E.A. Emerson and C.-L. Lei. Modalities for model checking: Branching time logic strikes back. In Proc. 20th ACM Symposium on Principles of Programming Languages, pages 84– 96, New Orleans, January 1985. [Eme90] E.A. Emerson. Temporal and modal logic. Handbook of Theoretical Computer Science, pages 997–1072, 1990. [FL79] M.J. Fischer and R.E. Ladner. Propositional dynamic logic of regular programs. Journal of Computer and Systems Sciences, 18:194– 211, 1979. [CD88] [CE81] [CES86] E.M. Clarke and I.A. Draghicescu. Expressibility results for linear-time and branchingtime logics. In Proc. Workshop on Linear Time, Branching Time, and Partial Order in Logics and Models for Concurrency, volume 354 of Lecture Notes in Computer Science, pages 428–437. Springer-Verlag, 1988. E.M. Clarke and E.A. Emerson. Design and synthesis of synchronization skeletons using branching time temporal logic. In Proc. Workshop on Logic of Programs, volume 131 of Lecture Notes in Computer Science, pages 52–71. Springer-Verlag, 1981. E.M. Clarke, E.A. Emerson, and A.P. Sistla. Automatic verification of finite-state concurrent systems using temporal logic specifications. ACM Transactions on Programming Languages and Systems, 8(2):244–263, January 1986. [GL94] O. Grumberg and D.E. Long. Model checking and modular verification. ACM Trans. on Programming Languages and Systems, 16(3):843–871, 1994. [Goe97] R. Goering. Model checking expands verification’s scope. Electronic Engineering Today, February 1997. [Hen85] M. Hennessy. Algebraic theory of Processes. MIT Press, Cambridge, 1985. [Hoa85] C.A.R. Hoare. Communicating Sequential Processes. Prentice-Hall, 1985. [HP85] D. Harel and A. Pnueli. On the development of reactive systems. In K. Apt, editor, Logics and Models of Concurrent Systems, volume F-13 of NATO Advanced Summer Institutes, pages 477–498. Springer-Verlag, 1985. [Jon83] C.B. Jones. Specification and design of (parallel) programs. In R.E.A. Mason, editor, Information Processing 83: Proc. IFIP 9th World Congress, pages 321–332. IFIP, NorthHolland, 1983. [Jos89] B. Josko. Verifying the correctness of AADL modules using model chekcing. In Stepwise Refinement of Distributed Systems: Models, Formalisms, Correctness (Proceedings of REX Workshop), volume 430 of Lecture Notes in Computer Science, pages 386–400, Mook, The Netherlands, May/June 1989. SpringerVerlag. [KT90] D. Kozen and L. Tiuryn. Logics of programs. Handbook of Theoretical Computer Science, pages 789–840, 1990. [Kup95] O. Kupferman. Model Checking for Branching-Time Temporal Logics. PhD thesis, The Technion, 1995. [Kur94] R.P. Kurshan. Computer Aided Verification of Coordinating Processes. Princeton Univ. Press, 1994. [Kur97] R.P. Kurshan. Formal verification in a commercial setting. The Verification Times, 1997. [KV95] O. Kupferman and M.Y. Vardi. On the complexity of branching modular model checking. In Proc. 6th Conferance on Concurrency Theory, volume 962 of Lecture Notes in Computer Science, pages 408–422, Philadelphia, August 1995. Springer-Verlag. [KV96] O. Kupferman and M.Y. Vardi. Module checking. In Computer Aided Verification, Proc. 8th Int. Conference, volume 1102 of Lecture Notes in Computer Science, pages 75–86. Springer-Verlag, 1996. [KV98] O. Kupferman and M.Y. Vardi. Verification of fair transition systems. Chicago Journal of Theoretical Computer Science, 1998(2), March 1998. [KVW98] O. Kupferman, M.Y. Vardi, and P. Wolper. Module checking. to appear, 1998. [Lam80] L. Lamport. Sometimes is sometimes “not never” - on the temporal logic of programs. In Proc. 7th ACM Symposium on Principles of Programming Languages, pages 174–185, January 1980. [Lam83] L. Lamport. Specifying concurrent program modules. ACM Trans. on Programming Languages and Systenms, 5:190–222, 1983. [LP85] O. Lichtenstein and A. Pnueli. Checking that finite state concurrent programs satisfy their linear specification. In Proc. 12th ACM Symposium on Principles of Programming Languages, pages 97–107, New Orleans, January 1985. [LPS81] D. Lehman, A. Pnueli, and J. Stavi. Impartiality, justice, and fairness – the ethics of concurrent termination. In Proc. 8th Colloq. on Automata, Programming, and Languages (ICALP), volume 115 of Lecture Notes in Computer Science, pages 264–277. SpringerVerlag, July 1981. [LS84] S.S. Lam and A.U. Shankar. Protocol verification via projection. IEEE Trans. on Software Engineering, 10:325–342, 1984. [LT87] N. A. Lynch and M.R. Tuttle. Hierarchical correctness proofs for distributed algorithms. In Proc. 6th ACM Symp. on Principles of Distributed Computing, pages 137–151, 1987. [MC81] B. Misra and K.M. Chandy. Proofs of networks of processes. IEEE Trans. on Software Engineering, 7:417–426, 1981. [Mil71] R. Milner. An algebraic definition of simulation between programs. In Proc. 2nd International Joint Conference on Artificial Intelligence, pages 481–489. British Computer Society, September 1971. [Mil80] R. Milner. A Calculus of Communicating Systems, volume 92 of Lecture Notes in Computer Science. Springer Verlag, Berlin, 1980. [Mil89] R. Milner. Communication and Concurrecny. Prentice-Hall, Englewood Clifs, 1989. [Sti92] Z. Manna and A. Pnueli. The Temporal Logic of Reactive and Concurrent Systems: Specification. Springer-Verlag, Berlin, January 1992. C. Stirling. Modal and temporal logics. Handbook of Logic in Computer Science, Vol. 2, pages 477–563, 1992. [Tho90] W. Thomas. Automata on infinite objects. Handbook of Theoretical Computer Science, pages 165–191, 1990. [MP92b] Z. Manna and A. Pnueli. Temporal specification and verification of reactive modules. 1992. [VS85] [MP95] Z. Manna and A. Pnueli. The Temporal Logic of Reactive and Concurrent Systems: Safety. Springer-Verlag, New York, 1995. M.Y. Vardi and L. Stockmeyer. Improved upper and lower bounds for modal logics of programs. In Proc 17th ACM Symp. on Theory of Computing, pages 240–251, 1985. [VW86] M.Y. Vardi and P. Wolper. An automatatheoretic approach to automatic program verification. In Proc. First Symposium on Logic in Computer Science, pages 322–331, Cambridge, June 1986. [Wol82] P. Wolper. Synthesis of Communicating Processes from Temporal Logic Specifications. PhD thesis, Stanford University, 1982. [MP92a] [MS72] A.R. Meyer and L.J. Stockmeyer. The equivalence problem for regular expressions with squaring requires exponential time. In Proc. 13th IEEE Symp. on Switching and Automata Theory, pages 125–129, 1972. [Pnu81] A. Pnueli. The temporal semantics of concurrent programs. Theoretical Computer Science, 13:45–60, 1981. [Pnu85a] A. Pnueli. In transition from global to modular temporal reasoning about programs. In K. Apt, editor, Logics and Models of Concurrent Systems, volume F-13 of NATO Advanced Summer Institutes, pages 123–144. SpringerVerlag, 1985. [Pnu85b] A. Pnueli. Linear and branching structures in the semantics and logics of reactive systems. In Proc. 12th Int. Colloquium on Automata, Languages and Programming, pages 15–32. Lecture Notes in Computer Science, SpringerVerlag, 1985. [QS81] J.P. Queille and J. Sifakis. Specification and verification of concurrent systems in Cesar. In Proc. 5th International Symp. on Programming, volume 137, pages 337–351. SpringerVerlag, Lecture Notes in Computer Science, 1981. [SC85] A.P. Sistla and E.M. Clarke. The complexity of propositional linear temporal logic. Journal ACM, 32:733–749, 1985. [Sti87] C. Stirling. Comparing linear and branching time temporal logics. In B. Banieqbal, H. Barringer, and A. Pnueli, editors, Temporal Logic in Specification, volume 398, pages 1–20. Lecture Notes in Computer Science, Springer-Verlag, 1987.