A New Rule for LTL Tableaux
Abstract
Propositional linear time temporal logic (LTL) is the standard temporal logic for computing applications and many reasoning techniques and tools have been developed for it. Tableaux for deciding satisfiability have existed since the 1980s. However, the tableaux for this logic do not look like traditional treeshaped tableau systems and their processing is often quite complicated.
In this paper, we introduce a novel style of tableau rule which supports a new simple traditionalstyle treeshaped tableau for LTL. We prove that it is sound and complete. As well as being simple to understand, to introduce to students and to use, it is also simple to implement and is competitive against state of the art systems. It is particularly suitable for parallel implementations.
D. Cantone and G. Delzanno (Eds.): Seventh Symposium on Games, Automata, Logics and Formal Verification (GandALF’16) EPTCS 226, 2016, pp. A New Rule for LTL Tableaux–LABEL:LastPage, doi:10.4204/EPTCS.226.20 © M. Reynolds This work is licensed under the Creative Commons Attribution License.
A New Rule for LTL Tableaux
Mark Reynolds \IfArrayPackageLoaded  




mark.reynolds@uwa.edu.au 
1 Introduction
Propositional linear time temporal logic, LTL, is important for hardware and software verification [22]. LTL satisfiability checking (LTLSAT) is receiving renewed interest with advances in computing power, several industry ready tools, some new theoretical techniques, studies of the relative merits of different approaches, implementation competitions, and benchmarking: [13, 24, 22]. Common techniques include automatabased approaches [29] and resolution [20] as well as tableaux [14, 31, 18]. Each type of approach has its own advantages and disadvantages and each can be competitive at the industrial scale (albeit within the limits of what may be achieved with PSPACE complexity). State of the art systems such as [23] often incorporate a variety of previous approaches working in parallel and thus piggyback on the fastest existing tableaux and fastest versions of other approaches.
Traditionally tableaux present as treeshaped [5, 27, 12]. For temporal logic, tableaux tend to be declarative, which means that the definition of a node is as a set of formulas (so a particular set appears at most once), and the successor relation is determined by those formulas; and they tend to be graphshaped. Figure 1 shows a typical graphstyle tableau, a more general graph rather than treeshaped (this from [9]). In general, these tableau constructions need the whole graph to be present before a second phase of discarding nodes takes place.
Figure 2 shows the treestyle tableau from [26] which is unusual: now nodes are independent objects arranged in a tree and although they are labelled by sets of formulas, the same label may appear on different nodes. This stands out in being treeshaped (not a more general graph), and in being onepass, i.e., not relying on a twophase building and pruning process. It also stands out in speed (i.e., faster than other tableau approaches) [13] and is thus the state of the art in tableau approaches to LTL. Construction of treeshaped tableaux can be local as we do not need to check if the same label has already been constructed somewhere else. However, there are still elements of communication between separate branches and a slightly complicated annotation of nodes with depth measures that needs to be managed as it feeds in to the tableau rules. So it is not in the traditional style of classical tableaux [2].
The following is a new simpler tableau for LTL. While many of the rules are unsurprising given earlier LTL tableaux [31, 26], the new rule to curtail the construction of repetitive loops is interesting. Loop checking is a common concern in tableau approaches modal logics and there have been many strange rules proposed. There is a loop checker (for a branching logic) in [3] which cuts construction after a label appears three times: but this would cause incompleteness in LTL. For logic S4, [15] require that boxes must accumulate. For LTL we have loop checkers in [11] and [7] but these have not proven practical because they involve collecting unwieldy annotations (of conjuncts from a doubly exponentiallysized closure set) or sets of sets of contextual formulas (see [30] for a more detailed account). The new PRUNE rule presented here is instead simple and very intuitive: don’t return to a label for a third time unless there is progress on fulfilling eventualities after the second time.
Perhaps the most similar previous work is that in [6] which presents a tableau for linear time calculus in which there are several rules operating on the sequence of labels in a branch. One rule called (v) classifies a branch as successful if a label is repeated three times with the same fixed point being unwound first in each intervening interval. This corresponds roughly to having the same eventuality postponed first in each interval: so not quite as easy to define or check in temporal logic. As far as the author knows this tableau has neither been implemented, nor translated to work with LTL.
Thus the PRUNE rule is completely novel and a surprisingly simple way to curtail repetitive branch extension. It may be applicable in other contexts. The overall tableau is thus novel and it is unique in that it is wholly traditional in style (labels are sets of formulas), tree shaped tableau construction, no extraneous recording of calculated values, contexts or annotations, just looking at the labels. It is also unique in allowing separate parallel development of branches.
Because of the tree shape, the tableau search allows completely independent searching down separate branches and so lends itself to parallel computing. In fact, this approach is “embarrassingly parallel” [10]. Thus there is also potential for quantum implementations. Developing a parallel implementation is ongoing work, however: even though only formula set labels need to be recorded down a branch, there is a need to work out an efficient way for memory of the sequence of labels to be managed below nodes where two branches separate.
Solid experimental work in [4] (see section 7) shows that the new tableau is competitive but that is not the task of this paper.
The interesting completeness and termination of the tableau search is proved here. The proofs are mostly straightforward. However, the completeness proof with the PRUNE rule is interesting, new and quite complicated. The main task of this paper is to present that proof.
In this paper we briefly remind the reader of the wellknown syntax and semantics for LTL in Section 2, describe our tableau approach in general terms in Section 3, present the rules in Section 4, comment on the use of the rules and provide some motivation for our approach in Section 5, discuss soundness and prove completeness in Section 6, and briefly discuss implementation issues in Section 7, before a conclusion in Section 9. Full versions of the (short) proofs can be found in an online technical report [21].
2 Syntax and Semantics
We assume a countable set of propositional atoms, or atomic propositions.
A (transition) structure is a triple with a finite set of states, a binary relation called the transition relation and labelling tells us which atoms are true at each state: for each , . Furthermore, is assumed to be serial: every state has at least one successor .
Given a structure , an long sequence of states from is a fullpath (through ) iff for each , . If is a fullpath then we write , (also a fullpath).
The (well formed) formulas of LTL include the atoms and if and are formulas then so are , , , and . We will also include some formulas built using other connectives that are often presented as abbreviations instead. However, before detailing them we present the semantic clauses.
Semantics defines
truth of formulas
on a fullpath through a structure.
Write iff the
formula is true of the fullpath
in the structure defined recursively by:
iff
, for ;
iff
;
iff
and
;
iff
; and
iff
there is some s.t.
and
for each ,
if then
.
Standard abbreviations in LTL include the classical , , , , . We also have the temporal: , read as eventually and always respectively.
A formula is satisfiable iff there is some structure with some fullpath through it such that . A formula is valid iff for all structures for all fullpaths through we have . A formula is valid iff its negation is not satisfiable.
For example, , , , , are each satisfiable. However, , , , are each not satisfiable.
We will fix a particular formula, say, and describe how a tableau for is built and how that decides the satisfiability or otherwise, of . We will use other formula names such as , , e.t.c., to indicate arbitrary formulas which are used in labels in the tableau for .
3 General Idea of the Tableau
The tableau for is a tree of nodes (going down the page from a root) each labelled by a set of formulas. To lighten the notation, when we present a tableau in a diagram we will omit the braces around the sets which form labels. The root is labelled .
Each node has 0, 1 or 2 children: it is the parent of its children. A node is called a leaf if it has 0 children. A leaf determines a branch, being itself, its parent, its parent’s parent e.t.c.. A leaf may be crossed (), indicating its branch has failed, or ticked (), indicating the branch is successful. Otherwise, a leaf indicates an unfinished branch and having an unfinished branch means that the tableau is unfinished. In that case there will be a way to use one if the rules below to extend the branch and the tableau.
The whole tableau is successful if there is a successful branch. This indicates a “yes” answer to the satisfiability of . It is failed if all branches are failed: indicating “no”. Otherwise it is unfinished. Note that you can stop the algorithm, and report success if you tick a leaf even if other branches have not reached a tick or cross yet.
A small set of tableau rules (see below) determine whether a node has one or two children or whether to cross or tick it. This depends on the label of the parent, and also, for some rules, on labels on ancestor nodes, higher up the branch towards the root. The rule also determines the labels on the children.
The parentchild relation is indicated by a vertical arrow in some diagrams but otherwise just by vertical alignment. However, to indicate use of one particular rule (coming up below) called the TRANSITION rule we will use a vertical arrow () with two strikes across it, or just an equals sign.
A node label may be the empty set, although it then can be immediately ticked by rule EMPTY below.
A formula which is an atomic proposition, a negated atomic proposition or of the form or is called elementary. If a node label is nonempty and there are no direct contradictions, that is no and amongst the formulas in the label, and every formula it contains is elementary then we call the label (or the node) poised.
Most of the rules consume formulas. That is, the parent may have a label , where is disjoint union, and a child may have a label so that has been removed, or consumed. In diagrams, if it is useful we sometimes indicate such a formula, known as a pivot formula, by underlining it.
See the example given in Figure 3 of a simple successful tableau. Note that if one was building, or searching, the tableau in a depthfirst lefttoright manner then the tableau could be judged as successful after the leftmost ticked branch was found and we could terminate the search without constructing quite as much as shown. However, we are not assuming that tableaux need to be constructed in that order.
As usual, a tableau node is an ancestor of a node precisely when or is a parent of or a parent of a parent of , e.t.c. Then is a descendent of and we write . Node is a proper ancestor of , written , iff it is an ancestor and . Similarly proper descendent. When we say that a node is between node and its descendent , , then we mean that is an ancestor of and is an ancestor of .
A formula of the form (or or ) appearing in a poised label of a node , say, also plays an important role. We will call such a formula an eventuality because (or or ) is often called an eventuality, and its truth depends on (or in the case) being eventually true in the future (if not present). If the formula appears in the label of a descendent node of then we say that the eventuality at has been fulfilled by by being satisfied there.
4 Rules
There are twentyfive rules altogether. We would only need ten for the minimal LTLlanguage, but recall that we are treating the usual abbreviations as firstclass symbols, so they each need a pair of rules. In this conference paper we skip the rules for abbreviations.
Most of the rules are what we call static rules. They tell us about formulas that may be true at a single state in a model. They determine the number, , or , of child nodes and the labels on those nodes from the label on the current parent node without reference to any other labels. These rules are unsurprising to anyone familiar with any of the previous LTL tableau approaches.
To save repetition of wording we use an abbreviated notation for presenting each rule: the rule relates the parent label to the child labels . The parent label is a set of formulas. The child labels are given as either a representing the leaf of a successful branch, a representing the leaf of a failed branch, a single set being the label on the single child or a pair of sets separated by a vertical bar being the respective labels on a pair of child nodes.
Thus, for example, the rule, means that if a node is labelled , if we choose to use the rule and if we choose to decompose using the rule then the node will have two children labelled and respectively.
Often, several different rules may be applicable to a node with a certain label. If another applicable rule is chosen, or another formula is chosen to be decomposed by the same rule, then the child labels may be different. We discuss this nondeterminism later.
The four (static) termination rules:
EMPTYrule:
;
rule:
;
CONTRADICTIONrule:
;
rule:
.
These are the positive static rules:
rule:
.
rule:
.
rule:
.
There are also static rules
for negations:
rule:
.
rule:
.
rule:
.
Although the following rules can be derived from the above,
and although we are trying to abbreviate the explanation here,
the following derived rules may be useful
for the reader to better understand
the brief examples presented in this paper.
They are static rules for and and their
negations:
rule:
.
rule:
.
rule:
.
rule:
.
The remaining four nonstatic rules are only applicable when a label is poised (which implies that none of the static rules will be applicable to it). In presenting them we use the convention that a node has label . More than one of the following rules may apply to a particular leaf node at any time: in that case, we apply the rule which is listed here first.
[LOOP]: If a node with poised label has a proper ancestor (i.e., not itself) with poised label such that , and for each eventuality or in we have a node such that and then should be a ticked leaf.
[PRUNE]: Suppose that and each of , and have the same poised label . Suppose also that for each eventuality or in , if there is with and then there is such that and . Then should be a crossed leaf.
[PRUNE]: Suppose that share the same poised label and contains at least one eventuality. Suppose that there is no eventuality or in with a node such that and . Then should be a crossed leaf.
[TRANSITION]: If none of the other rules above do apply to it then a node labelled by poised say, can have one child whose label is: .
The tableau is extended at each stage by choosing the leaf node on any unfinished branch and attempting to apply a rule: if no other rules apply, the TRANSITION rule will. The choice of unfinished branch is arbitrary. If there are no unfinished branches, so the tableau is finished, then clearly it will either be successful or failed.
5 The motivation for the tableaux rules
A traditional classical logic style tableau starts with the formula in question and breaks it down into simpler formulas as we move down the page. The simpler formulas being satisfied should ensure that the more complicated parent label is satisfied. Alternatives are presented as branches. See the example given in Figure 4.
We follow this style of tableau as is evident by the classical look of the tableau rules involving classical connectives. The and rules are also in this vein, noting that temporal formulas such as also gives us choices: Figure 5.
Eventually, we break down a formula into elementary ones. The atoms and their negations can be satisfied immediately provided there are no contradictions, but to reason about the formulas we need to move forwards in time. This is where we use the TRANSITION step: see Figure 3. Reasoning switches to the next time point and we carry over only information nested below and .
With just these rules we can now do the whole example. See Figure 3.
This example is rather simple, though, and we need additional rules to deal with infinite behaviour. Consider the example which, in the absence of additional rules, gives rise to the very repetitive infinite tableau in Figure 6.
Notice that the infinite fullpath that it suggests is a model for as would be a fullpath just consisting of the one state with a selfloop (a transition from itself to itself).
This suggests that we should allow the tableau branch construction to halt if a state is repeated. However the example shows that we can not just accept infinite loops as demonstrating satisfiability: the tableau for this unsatisfiable formula would have an infinite branch if we did not use the PRUNE rule to cross it (Figure 7). Note that the optional PRUNE rule can be used to cross the branch one TRANSITION earlier.
Notice that the infinite fullpath that the tableau suggests is this time not a model for . Constant repeating of being made true does not satisfy the conjunct . We have postponed the eventuality forever and this is not acceptable.
If appears in the tableau label of a node then we want to appear in the label of some later (or equal node) . In that case we say that the eventuality is satisfied by .
Eventualities are eventually satisfied in any (actual) model of a formula: by the semantics of .
This motivates the LOOP rule. If a label is repeated along a branch and all eventualities are satisfied in between then we can build a model by looping states. In fact, the ancestor can have a superset and it will work (see the soundness proof in [21]).
Examples like (in Figure 7) and which have branches that go on forever without satisfying eventualities, still present a problem for us. We need to stop and fail branches so that we can answer “no” correctly and terminate and so that we do not get distracted when another branch may be successful. In fact, no infinite branches should be allowed.
The final rule that we consider, and the most novel, is based on observing that these infinite branches are just getting repetitive without making a model. The repetition is clear because there are only a finite set of formulas which can ever appear in labels for a given initial formula . The closure set for a formula is as follows:
Here we use to mean that is a subformula of . The size of closure set is where is the length of the initial formula. Only formulas from this finite set will appear in labels. So there are only possible labels.
The PRUNE rule is as follows. If a node at the end of a branch (of an unfinished tableau) has a label which has appeared already twice above, and between the second and third appearance there are no new eventualities satisfied that were not already satisfied between the first and second appearances then that whole interval of states (second to third appearance) has been useless. The PRUNE rule applies similar reasoning to an initial repeat in which no eventualities are fulfilled. In Figure 7, the PRUNE rule crosses the right hand branch as the only eventuality remains unfulfilled as does not appear in a label despite three repeats of the same label.
It should be mentioned that the tableau building process we describe above is nondeterministic in several respects and so really not a proper description of an algorithm. However, we will see in the correctness proof below that the further details of which formula to consider at each step in building the tableau are unimportant.
Finally a suggestion for a nice example to try. Try .
6 Proof of Correctness: Soundness and Completeness
In the long technical report [21], we show full details of the proof of soundness, completeness and termination for the tableau search. Termination is guaranteed because there can be no infinitely long branches. Soundness presents no novelty to those familiar with soundness proofs for similar tableaux: construct a model from the successful tableau branch. Completeness, however, is novel, because of the novel rules and we present that here.
Note that the completeness proof we present here seems to be entirely novel: using a model of a satisfiable formula to find a successful branch in a tableau, and having to backtrack in general. Ideas of relating a tableau branch to a model appear in many places (eg. [30]) but here we have to backtrack up the tableau while continuing in the model and use a subtle progress argument to show that we can not do this forever. An interesting aspect here compared to some other completeness proofs such as that in [7] is that we see that with the new PRUNE rule there is no need to rely on any “fair” expansion strategy amongst eventualities: being unfair for too long falls fowl of the PRUNE rules. Note also that there does not seem to be a simpler completeness proof based on the idea of a shortest lasso model of a formula and a claim that the PRUNE rule will not apply.
Note also that the completeness proof gives us the rather strong result that for a satisfiable formula we will find a successful tableau regardless of the order in which we use the rules and regardless of the order in choosing unfinished branches to extend.
LEMMA:[Completeness] Suppose that is a satisfiable formula of LTL. Then any finished tableau for will be successful.
PROOF: Suppose that is a satisfiable formula of LTL. It will have a model. Choose one, say . In what follows we (use standard practice when the model is fixed and) write when we mean .
Also, build a finished tableau for in any manner as long as the rules are followed. Let be the formula set label on the node in . We will show that has a ticked leaf.
To do this we will construct a sequence of nodes, with being the root. This sequence may terminate at a tick (and then we have succeeded) or it may hypothetically go on forever (and more on that later). In general, the sequence will head downwards from a parent to a child node but occasionally it may jump back up to an ancestor.
As we go we will make sure that each node is associated with an index along the fullpath and we guarantee the following invariant for each . The relationship is that for each , .
Start by putting when is the tableau root node. Note that the only formula in is and that . Thus holds at the start.
Now suppose that we have identified the sequence up until . Consider the rule that is used in to extend a tableau branch from to some children. Note that we can also ignore the cases in which the rule is EMPTY or LOOP because they would immediately give us the ticked branch that is sought.
It is useful to define the sequence advancement procedure in the cases apart from the PRUNE rule separately. Thus we now describe a procedure, call it , that is given a node and index satisfying and, in case that the node has children via any rule except PRUNE, the procedure will give us a child node and index which is either or , such that holds. The idea will be to use procedure on and to get and in case the PRUNE rule is not used at node . We return to deal with advancing from in case that the PRUNE rule is used later. So now we describe procedure with assumed.
In this conference paper only the most interesting rules are shown: see [21] for the rest.
[EMPTY] If then we are done. is a successful tableau as required.
[CONTRADICTION] Consider if it is possible for us to reach a leaf at with a cross because of a contradiction. So there is some with and in . But this can not happen as then and .
[rule] So and there are two children. One is labelled and the other, , is labelled . We know . Thus, there is some such that and for all , if then . If then we can choose (even if other choices as possible) and otherwise choose any such . Again there are two cases, either or .
In the first case, when , we put and otherwise we will make . In either case put .
Let us check the invariant. Consider the first case. We have .
In the second case, we know that we have and . Thus .
Also, in either case, for every other we still have . So we have the invariant holding.
[rule] So and there are two children. One is labelled and the other, , is labelled . We know . So for sure .
Furthermore, possibly as well, but otherwise if then we can show that we can not have . Suppose for contradiction that and . Then there is some such that and for all , if then . Thus . Contradiction.
So we can conclude that there are two cases when the rule is used. CASE 1: and . CASE 2: and .
In the first case, when , we put and otherwise we will make . In either case put .
Let us check the invariant. In both cases we know that we have . Now consider the first case. We also have . In the second case, we know that we have . Thus . Also, in either case, for every other we still have . So we have the invariant holding.
[OTHER STATIC RULES]: similar.
[TRANSITION] So is poised and there is one child, which we will make and we will put .
Consider a formula .
CASE 1: Say that . Thus, by the invariant, . Hence, . But this is just as required.
CASE 2: Say that and . Thus, by the invariant, . Hence, . But this is just as required.
So we have the invariant holding.
[LOOP] If, in , the node is a leaf just getting a tick via the LOOP rule then we are done. is a successful tableau as required.
So that ends the description of procedure that is given a node and index satisfying and, in case that the node has children via any rule except PRUNE (or PRUNE) the procedure will give us a child node and index , which is either or , such that holds. We use procedure to construct a sequence of nodes, with being the root. and guarantee the invariant for each .
The idea will be to use procedure on and to get and in case the PRUNE rule is not used at node . Start by putting when is the tableau root node. We have seen that holds at the start.
In the conference paper version of the rest of the proof we ignore the PRUNE rule. It can be dealt with in a similar way.
[PRUNE ] Now, we complete the description of the construction of the sequence by explaining what to do in case is a node on which PRUNE is used. Suppose that is a node which gets a cross in via the PRUNE rule. So there is a sequence such that and no extra eventualities of are satisfied between and that were not already satisfied between and .
What we do now is to undertake a sort of backtracking exercise in our proof. We choose some such , and , there may be more than one triple, and proceed with the construction as if was instead of . That is we use the procedure on with to get from to one of its children and define . Procedure above can be applied because and so holds. The procedure gives us as well.
If we find from in this way when is a tableau node on which PRUNE is applied then we say that is obtained from via the jump tuple .
Thus we keep going with the new child of , and . We have made the subtle move of backtracking up the tableau to find our but simultaneously continued progress to without backtracking in our journey through the model.
That ends our complete description of how to find the matching sequences of and . We have seen that the sequences either finish at a ticked node of the tableau or can go on another step.
To finish the proof we need to consider whether the above construction goes on for ever. Clearly it may end finitely with us finding a ticked leaf and succeeding. However, at least in theory, it may seem possible that the construction keeps going forever even though the tableau will be finite. The rest of the proof is to show that this actually can not happen. The construction can not go on forever. It must stop and the only way that we have shown that that can happen is by finding a tick.
Suppose for contradiction that the construction does go on forever. Thus, because there are only a finite number of nodes in the tableau, and because procedure defines as a child of , then we must meet the PRUNE rule and jump back up the tableau infinitely often.
There are only a finite number of nodes in so only a finite number of jump tuples so there must be some that are used to obtain for infinitely many . Call these recurring jump tuples.
Say that is one such recurring tuple. Choose so that for no other recurring jump triple do we have being a proper ancestor of .
As we proceed through the construction of and see a jump every so often, eventually all the jump tuples which only cause a jump a finite number of times stop causing jumps. After that index, say, will still cause a jump every so often.
Thus will never appear again as for and all for that we choose will be descendants of . This is because by choice of we will never jump up to or above it (closer to the root) via any jump tuple that is used after . Say that is the very last that is equal to .
Now consider any that appears in . (There must be at least one eventuality in as it is used to apply rule PRUNE and not the LOOP rule).
A simple induction shows that or will appear in every from up until at least when appears in some for (if that ever happens). This is because if is in then it will also be in any child node unless the UNTIL rule is used. If the UNTIL rule is used on and is not in and does not get put in then will be put in . The subsequent temporal TRANSITION rule will thus put into the new label. Finally, in case the sequence meets a PRUNE jump then the new will be a child of which is a descendent of which is a descendent of so will also contain or .
Now just increases by or with each increment of , We also know that from onwards until (and if) gets put in . Since is a fullpath we will eventually get to some with . In that case our construction makes us put in the label (to keep the invariant holding). Thus we do eventually get to some with . Let be the first such . Note that all the nodes between and in the tableau also appear as for so that they all have and not in their labels .
Now let us consider if we ever jump up above at any TRANSITION of our construction (after ). In that case there would be a PRUNE jump triple of tableau nodes , and governing the first such jump. Since is not above and is above , we must have with in them and not satisfied in between. But will be below at the first such jump, meaning that is satisfied between and . That is a contradiction to the PRUNE rule being applicable to this triple.
Thus the sequence stays within descendants of forever after .
The above reasoning applies to all eventualities in . Thus, after they are each satisfied, the construction does not jump up above any of them. When the next supposed jump involving with some and happens after that it is clear that all of the eventualities in are satisfied above . Thus the LOOP rule would have applied between and .
This is a contradiction to such a jump ever happening. Thus we can conclude that there are not an infinite number of jumps after all. The construction must finish with a tick. This is the end of the completeness proof.
7 Implementations
Tableau search here, even in a nonparallel implementation, should (theoretically) be able to be implemented to run a little faster than that the state of the art tableau technique of [26]. This is because there is less information to keep track of and no backtracking from potentially successful branches when a repeated label is discovered.
A fast implementation of the new tableau written by Matteo Battelo of Udine University is available from https://github.com/Corralx/leviathan and described in [4]. Experiments run using this implementation, on the full set of 3723 standard benchmark formulas [24], show comparative speed performance with five state of the art tools (Aalta [19], TRP++ [17], LS4 [28], NuSMV [8], and PLTL) based on automata, resolution, resolution(again), symbolic model checking, the Schwendimann tableau technique respectively. Interestingly the memory usage for the new tableau is significantly less. See [4] for the details of the implementation and experiments.
For now, as this current paper is primarily about the theory behind the new rules, we have provided a demonstration Java implementation to allow readers to experiment with the way that the tableau works. The program allows comparison with a corresponding implementation of the Schwendimann tableau. The demonstration Java implementation is available at http://staffhome.ecm.uwa.edu.au/~00054620/research/Online/ltlsattab.html. This allows users to understand the tableau building process in a step by step way. It is not designed as a fast implementation. However, it does report on how many tableau construction steps were taken.
Detailed comparisons of the running times across 24 typical benchmark formulas are available in [21]. In Figure 8, we give a small selection to give the idea of the experimental results. This is just on two quite long formulas, “Rozier 6” and “Rozier 9” and one very long formula “anzu amba amba 6” from the socalled Rozier counter example series of [24]. Shown is formula length, running time in seconds (on a standard laptop), number of tableau steps and the maximum depth of a branch in poised states. As claimed, the new tableau needs roughly the same number of steps but saves time on each step (at least as the formulas get longer). Indeed there are only three formulas presented but they are each part of important series which each show the same pattern: the two approaches are comparable in terms of number of steps taken. Future heavy duty implementation should then be able to deliver on a faster implementation for the new approach as we know each step is simpler than a step for the Schwendimann approach.
fmla  Reynolds  Schwendimann  

length  sec  steps  depth  sec  steps  depth  
r6  190  0.871  20k  353  0.855  20k  353 
r9  277  113  239k  4353  120  242k  4353 
as6  1864  0.003  54k  2  0.015  61k  2 
8 Example
In order to illustrate the differences in approach very briefly we include two diagrams from the long paper. See Figure 9 and 10 for the overall shape of the two tableaux applied to the example
Roughly, there are two eventualities which need respectively state and to fulfil them but we must return to state in between. There are some similar observations on the Schwendiman approach in [16].
9 Conclusion
We have introduced a new type of tableau rule for temporal logics, in particular for LTL. This allows the operation of a novel but traditionally treeshaped, onepass tableau system for LTLSAT. It is simple in all aspects with no extra notations on nodes, neat to introduce to students, amenable to manual use and can be implemented efficiently with competitive performance.
In searching or constructing the tableau one can explore down branches completely independently and further break up the search down individual branches into separate somewhat independent processes. Thus it is particularly suited to parallel implementations.
Because of the simplicity, it also seems to be a good base for more intelligent and sophisticated algorithms: including heuristics for choosing amongst branches and ways of managing sequences of label sets. The idea of the PRUNE rules potentially have many other applications.
References
 [1]
 [2] Mordechai BenAri (2012): Propositional Logic: Formulas, Models, Tableaux. In: Mathematical Logic for Computer Science, Springer London, pp. 7–47, doi:http://dx.doi.org/10.1007/9781447141297˙2.
 [3] Mordechai BenAri, Amir Pnueli & Zohar Manna (1983): The Temporal Logic of Branching Time. Acta Inf. 20, pp. 207–226, doi:http://dx.doi.org/10.1007/BF01257083.
 [4] Matteo Bertello, Nicola Gigante, Angelo Montanari & Mark Reynolds (2016): Leviathan: A New LTL Satisfiability Checking Tool Based on a OnePass TreeShaped Tableau. In Subbarao Kambhampati, editor: Proceedings of the TwentyFifth International Joint Conference on Artificial Intelligence, IJCAI 2016, New York, NY, USA, 915 July 2016, IJCAI/AAAI Press, pp. 950–956. Available at http://www.ijcai.org/Abstract/16/139.
 [5] E. Beth (1955): Semantic Entailment and Formal Derivability. Mededelingen der Koninklijke Nederlandse Akad. van Wetensch 18.
 [6] Julian C. Bradfield, Javier Esparza & Angelika Mader (1996): An Effective Tableau System for the Linear Time Calculus. In Friedhelm Meyer auf der Heide & Burkhard Monien, editors: Automata, Languages and Programming, 23rd International Colloquium, ICALP96, Paderborn, Germany, 812 July 1996, Proceedings, Lecture Notes in Computer Science 1099, Springer, pp. 98–109, doi:http://dx.doi.org/10.1007/3540614400˙120.
 [7] Kai Brünnler & Martin Lange (2008): Cutfree sequent systems for temporal logic. J. Log. Algebr. Program. 76(2), pp. 216–225, doi:http://dx.doi.org/10.1016/j.jlap.2008.02.004.
 [8] Alessandro Cimatti, Edmund M. Clarke, Enrico Giunchiglia, Fausto Giunchiglia, Marco Pistore, Marco Roveri, Roberto Sebastiani & Armando Tacchella (2002): NuSMV 2: An OpenSource Tool for Symbolic Model Checking. In Ed Brinksma & Kim Guldstrand Larsen, editors: Computer Aided Verification, 14th International Conference, CAV 2002,Copenhagen, Denmark, July 2731, 2002, Proceedings, Lecture Notes in Computer Science 2404, Springer, pp. 359–364, doi:http://dx.doi.org/10.1007/3540456570˙29.
 [9] Edmund M. Clarke, Orna Grumberg & Kiyoharu Hamaguchi (1997): Another Look at LTL Model Checking. Formal Methods in System Design 10(1), pp. 47–71, doi:http://dx.doi.org/10.1023/A:1008615614281.
 [10] Ian T. Foster (1995): Designing and building parallel programs  concepts and tools for parallel software engineering. AddisonWesley.
 [11] Joxe Gaintzarain, Montserrat Hermo, Paqui Lucio & Marisa Navarro (2008): Systematic Semantic Tableaux for PLTL. Electr. Notes Theor. Comput. Sci. 206, pp. 59–73, doi:http://dx.doi.org/10.1016/j.entcs.2008.03.075.
 [12] Rod Girle (2000): Modal Logics and Philosophy. Acumen, Teddington, UK.
 [13] Valentin Goranko, Angelo Kyrilov & Dmitry Shkatov (2010): Tableau Tool for Testing Satisfiability in LTL: Implementation and Experimental Analysis. Electronic Notes in Theoretical Computer Science 262(0), pp. 113 – 125, doi:http://dx.doi.org/10.1016/j.entcs.2010.04.009. Proceedings of the 6th Workshop on Methods for Modalities (M4M6 2009).
 [14] G. Gough (1989): Decision procedures for temporal logics. Technical Report UMCS89101, Department of Computer Science, University of Manchester.
 [15] Alain Heuerding, Michael Seyfried & Heinrich Zimmermann (1996): Efficient LoopCheck for Backward Proof Search in Some Nonclassical Propositional Logics. In Pierangelo Miglioli, Ugo Moscato, Daniele Mundici & Mario Ornaghi, editors: TABLEAUX, Lecture Notes in Computer Science 1071, Springer, pp. 210–225. doi:http://dx.doi.org/10.1007/3540612084˙14.
 [16] Jacob M. Howe (1997): Two Loop Detection Mechanisms: A Comparision. In Didier Galmiche, editor: Automated Reasoning with Analytic Tableaux and Related Methods, International Conference, TABLEAUX ’97, PontàMousson, France, May 1316, 1997, Proceedings, Lecture Notes in Computer Science 1227, Springer, pp. 188–200, doi:http://dx.doi.org/10.1007/BFb0027414.
 [17] Ullrich Hustadt & Boris Konev (2003): TRP++2.0: A Temporal Resolution Prover. In Franz Baader, editor: Automated Deduction  CADE19, 19th International Conference on Automated Deduction Miami Beach, FL, USA, July 28  August 2, 2003, Proceedings, Lecture Notes in Computer Science 2741, Springer, pp. 274–278, doi:http://dx.doi.org/10.1007/9783540450856˙21.
 [18] Yonit Kesten, Zohar Manna, Hugh McGuire & Amir Pnueli (1993): A Decision Algorithm for Full Propositional Temporal Logic. In Costas Courcoubetis, editor: CAV, Lecture Notes in Computer Science 697, Springer, pp. 97–109. doi:http://dx.doi.org/10.1007/3540569227˙9.
 [19] Jianwen Li, Yinbo Yao, Geguang Pu, Lijun Zhang & Jifeng He (2014): Aalta: an LTL satisfiability checker over Infinite/Finite traces. In ShingChi Cheung, Alessandro Orso & MargaretAnne D. Storey, editors: Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, (FSE22), Hong Kong, China, November 16  22, 2014, ACM, pp. 731–734, doi:http://dx.doi.org/10.1145/2635868.2661669.
 [20] Michel Ludwig & Ullrich Hustadt (2010): Implementing a fair monodic temporal logic prover. AI Commun. 23(23), pp. 69–96. doi:http://dx.doi.org/10.3233/AIC20100457.
 [21] Mark Reynolds (2016): A traditional treestyle tableau for LTL. CoRR abs/1604.03962. Available at https://arxiv.org/abs/1604.03962.
 [22] Kristin Y. Rozier & Moshe Y. Vardi (2007): LTL Satisfiability Checking. In Dragan Bosnacki & Stefan Edelkamp, editors: SPIN, Lecture Notes in Computer Science 4595, Springer, pp. 149–167. doi:http://dx.doi.org/10.1007/9783540733706˙11.
 [23] Kristin Y. Rozier & Moshe Y. Vardi (2011): A Multiencoding Approach for LTL Symbolic Satisfiability Checking. In Michael J. Butler & Wolfram Schulte, editors: FM 2011: Formal Methods  17th International Symposium on Formal Methods, Limerick, Ireland, June 2024, 2011. Proceedings, Lecture Notes in Computer Science 6664, Springer, pp. 417–431, doi:http://dx.doi.org/10.1007/9783642214370˙31.
 [24] Viktor Schuppan & Luthfi Darmawan (2011): Evaluating LTL Satisfiability Solvers. In Tevfik Bultan & PaoAnn Hsiung, editors: ATVA’11, Lecture Notes in Computer Science 6996, Springer, pp. 397–413. doi:http://dx.doi.org/10.1007/9783642243721˙28.
 [25] Stefan Schwendimann (1998): Aspects of Computational Logic. PhD, Institut für Informatik und angewandte Mathematik. Available at http://www.iam.unibe.ch/ltgpub/1998/sch98b.ps.
 [26] Stefan Schwendimann (1998): A New OnePass Tableau Calculus for PLTL. In Harrie C. M. de Swart, editor: Automated Reasoning with Analytic Tableaux and Related Methods, International Conference, TABLEAUX ’98, Oisterwijk, The Netherlands, May 58, 1998, Proceedings, Lecture Notes in Computer Science 1397, Springer, pp. 277–292, doi:http://dx.doi.org/10.1007/3540697780˙28.
 [27] R. Smullyan (1968): Firstorder Logic. Springer. doi:http://dx.doi.org/10.1007/9783642867187.
 [28] Martin Suda & Christoph Weidenbach (2012): A PLTLProver Based on Labelled Superposition with Partial Model Guidance. In Bernhard Gramlich, Dale Miller & Uli Sattler, editors: Automated Reasoning  6th International Joint Conference, IJCAR 2012, Manchester, UK, June 2629, 2012. Proceedings, Lecture Notes in Computer Science 7364, Springer, pp. 537–543, doi:http://dx.doi.org/10.1007/9783642313653˙42.
 [29] Moshe Y. Vardi & Pierre Wolper (1994): Reasoning About Infinite Computations. Inf. Comput. 115(1), pp. 1–37, doi:http://dx.doi.org/10.1006/inco.1994.1092.
 [30] Florian Rainer Widmann (2010): Tableauxbased decision procedures for fixed point logics. Thesis. Available at http://users.cecs.anu.edu.au/~rpg/software.htm. Thesis (Ph.D.) – ANU, 2010.
 [31] P. Wolper (1985): The tableau method for temporal logic: an overview. Logique et Analyse 28, pp. 110–111.