LTL is a popular choice for expressing properties in model-checking tools. Computational Tree Logic (CTL) [39] is another candidate, but we feel that LTL makes a better choice for comparison of expressive power. The reasons for this are manifold.
LTL and CTL have very different kinds of logical expressiveness. Since CTL allows for explicit existential quantification over paths, it is more expressive in some cases in which we want to reason about the possibility of the existence of a specific path through the transition system model M, such as when M is best described as a computation tree. For example, there are no LTL equivalents of the CTL formulas (EX p) and (AG EF p), since LTL cannot express the possibility of p happening on some path (but not necessarily all paths) next time, or in the future. LTL describes executions of the system, not the way in which they can be organized into a branching tree. Intuitively, it is difficult (or impossible) to express in LTL situations in which distinct behaviors occur on distinct branches at the same time. Conversely, it is difficult (or impossible) to express in CTL some situations where the same behavior may occur on distinct branches at distinct times, a circumstance in which the ability of LTL to describe individual paths is quite useful. In fact, situations in which CTL is more suitable are rare, so LTL turns out to be more expressive from a practical point of view than CTL.
From a system design point of view, it is important to be able to write clear and correct spec- ifications to input into the model checker. Usually, we want to describe behavioral, rather than structural, properties of the model, making LTL the better choice for specification, since such properties are easily expressed in LTL but may not be expressible in CTL. For example, we may want to say that p will happen within the next two time steps, (X p ∨ X X p), or that if p ever happens, q will happen too, (F p → F q), neither of which is expressible in CTL. Similarly, we
cannot state in CTL that if p happens in the future, q will happen in the next time step after that, which is simply F (p ∧ X q) in LTL. Worst of all, CTL’s nature is such that it takes some effort to determine that these useful properties are not expressible in CTL. Indeed, a thorough compar- ison of the two logics concludes that CTL is unintuitive, hard to use, ill-suited for compositional reasoning, and fundamentally incompatible with semiformal verification, while LTL suffers from none of these inherent limitations and in general is better suited to model-checking.
LTL is a fair language, whereas CTL is not. That is to say that LTL can express properties of fairness, including both strong fairness and weak fairness, whereas CTL cannot (though CTL model checkers generally allow users to specify fairness statements separately to compensate for this shortcoming). For example, the LTL formula (G F p → F q), which expresses the property that infinitely many p’s imply an eventual q, is the form of a common fairness statement: a contin- uous request will eventually be acknowledged. Yet this sentiment is not expressible in CTL. Since fairness properties occur frequently in the specifications we wish to verify about real-life reactive systems, this adds to the desirability of LTL as a specification language.
For another example, the common invariance property F G p, meaning “at some point, p will hold forever” cannot be expressed in CTL. It is difficult to see why this formula is not equivalent to the CTL formulaA FA G p; after all, we are basically claiming that on all paths, there’s a point in which p holds in all future states. (The standard semantic interpretation of LTL corresponds to the “for all paths” syntax of CTL. For that reason, we consider there to be an implicitA operator in front of all LTL formulas when we compare them to CTL formulas.)
Another frequently cited example of the nonintuitiveness of CTL is the fact that the CTL formula A X A F p is not equivalent to the formula (A FA X p). Again, the distinction is subtle. The former formula states that, as of the next time step, it is true that p will definitely hold at some point in the future or, in other words, p will hold sometime in the strict future. That formula is equivalent to the LTL formulasX F p and F X p. On the other hand, the meaning of (A FA X p) is the strictly stronger (and actually quite strange) assertion that on all paths, in the future, there is some point in which p is true in the next time step on all of the branches from that point.
Those examples illustrate why LTL is frequently considered a more straightforward language, better suited to specification and more usable for verification engineers and system designers. LTL is the preferred logic of the two for general property specification and on-the-fly verification. Ver-
ification engineers have found expression of specifications in LTL to be more intuitive, and less error-prone, than in CTL, particularly for verification of concurrent software architectures. The vast majority of CTL specifications used in practice are equivalent to LTL specifications; it is rare that the added ability to reason over computation tree branches is needed, and it frequently requires engineers to look at their designs in an unnatural way. The expressiveness, simplicity, and usabil- ity of LTL, particularly for practical applications like compositional verification, or specification debugging, make it a good choice for industrial verification.