Causality for General LTL-definable Properties
Georgiana Caltais (University of Konstanz), Sophie Linnea Guetlein, (University of Konstanz), Stefan Leue (University of Konstanz)

TL;DR
This paper extends causality analysis to infinite counterexamples in LTL properties, enabling better understanding of violations in complex temporal logic specifications.
Contribution
It introduces a causality notion for infinite LTL counterexamples, building on previous finite-trace approaches, and aims for implementation in a causality checking tool.
Findings
Causality for infinite LTL counterexamples is characterized.
Loop unfolding in lasso-shaped traces reveals causal event sequences.
Framework is designed for integration with LTL model checking tools.
Abstract
In this paper we provide a notion of causality for the violation of general Linear Temporal Logic (LTL) properties. The current work is a natural extension of the previously proposed approach handling causality in the context of LTL-definable safety properties. The major difference is that now, counterexamples of general LTL properties are not merely finite traces, but infinite lasso-shaped traces. We analyze such infinite counterexamples and identify the relevant ordered occurrences of causal events, obtained by unfolding the looping part of the lasso shaped counterexample sufficiently many times. The focus is on LTL properties from practical considerations: the current results are to be implemented in QuantUM, a tool for causality checking, that exploits explicit state LTL model checking.
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
Causality for General LTL-definable Properties
Georgiana Caltais
[email protected] Department for Computer and Information Science
University of Konstanz, Germany
Sophie Linnea Guetlein
[email protected] Department for Computer and Information Science
University of Konstanz, Germany
Stefan Leue Department for Computer and Information Science
University of Konstanz, Germany [email protected]
Abstract
In this paper we provide a notion of causality for the violation of general Linear Temporal Logic (LTL) properties. The current work is a natural extension of the previously proposed approach handling causality in the context of LTL-definable safety properties [21, 20]. The major difference is that now, counterexamples of general LTL properties are not merely finite traces, but infinite lasso-shaped traces. We analyze such infinite counterexamples and identify the relevant ordered occurrences of causal events, obtained by unfolding the looping part of the lasso shaped counterexample sufficiently many times. The focus is on LTL properties from practical considerations: the current results are to be implemented in QuantUM, a tool for causality checking, that exploits explicit state LTL model checking.
1 Introduction
The importance and complexity of software driven systems is steadily increasing. Software plays a central rôle in daily used objects, such as computers and mobile phones, but also in other areas, for example medical systems, aircraft and automobiles. Particularly in these latter areas, software failures may entail major environmental harm and/or serious injuries of humans. Software systems whose malfunction has such serious consequences are also called safety-critical systems. This paper addresses methods to analyze models of such systems for the detection of ordered sequences of events that can be considered causal for the malfunctioning of such a system. Of particular importance in this setting is the identification of actual causes, i.e., sequences of events that are indispensable for the malfunctioning to occur and not just mere “noise” in the system execution.
Model-checking [2] is a formal verification technique for systematically checking whether certain temporal requirements are satisfied by a system model. Given a state-based model of the considered system and a property specification , model checkers return a counterexample if is not satisfied by . This counterexample typically is an execution trace that includes a violation of the property and can be used to understand the cause of the property violation and to fix the problem. However, counterexamples can be very long and often contain numerous events that are of no relevance to the violation of . Furthermore, there can be a very large number of counterexample traces in that all lead to the violation of .
In precursory work [21, 20], model checking of reachability properties has been extended to causality checking by considering all traces in a model that violate a system safety property expressed by a reachability property . Inspired by the actual cause conditions defined in the Structural Equation Model (SEM) for causality in systems [16, 15] the work in [21, 20] defines actual cause conditions on ordered sequences of events that correspond to computations in a Transition System model.
In this paper we provide a notion of causality for the violation of general Linear Temporal Logic (LTL) properties. Counterexamples of such properties can always be represented by -regular expressions of the form , where and are regular expressions [23]. Counterexamples of this type are also often referred to as “lasso-shaped”. They consist of an initial path fragment that can witness the violation of a “something bad never happens”-kind of property (i.e., a safety property) followed by a loop that can witness the violation of a “something good eventually happens”-kind of property (i.e., a liveness property). In particular, for the case of “pure” safety properties, the lasso ends in a self-loop state where the property is violated.
Consider, for an example, the behaviour of an elevator system as follows:
Example 1** (Elevator).**
The elevator can commute between three floors (0,1,2). On each floor there is a button that can be pressed in order to call the elevator. Whenever a button on some floor is pressed, the elevator will try to go to that floor immediately. If two buttons are pressed, the elevator will go to the lower floor first. We use the identifier to denote the event “elevator is on floor ”, and to denote “button on floor is pressed”, for .
A liveness property is, for example, that whenever a button on the second floor is pressed, the elevator will go there eventually. Assume we are interested in finding those sequences of events that lead to a hazard in which the button on the second floor is pressed, but the elevator never arrives at the second floor. A corresponding counterexample is a lasso-shaped execution in which can be observed, whereas occurs neither along the initial path fragment after , nor in the loop.
In this paper, causality checking for general definable LTL properties is done by identifying the counterexample of a temporal property with a so-called Event Order Logic formula. This formula encodes the relevant ordered occurrences of causal events, and is obtained by unfolding the loop-counterexample “sufficiently many times”.
Related work.
The idea of exploiting counterexamples as a debugging aid, in order to understand what determined a certain system failure, has been addressed by other works as well. We refer, for instance, to the results in [3] that uses the notion of causality in [16, 15] and provides the user a visual explanation of the failure by marking causes as red dots along the counterexample trace. In [3], causes for the violation of an LTL property are computed via an over-approximation algorithm. For another example, we refer to the work in [18], where errors in system models are elicited from similar counterexamples witnessing the violation of liveness properties.
It is certain that imposing minimality conditions on the size of causal explanations is desirable. In our work, we adapt the approach from [16, 15], and formalise a notion of causality that is minimal with respect to the number of events (i.e., system actions) it encompasses. In a similar spirit, [24] proposes a methodology for computing shortest counterexamples for symbolic model checking of so-called LTL with past formulae. Other “nice to have” properties of causality such as, compositionality, for instance, were addressed in [11, 10, 12, 13, 6].
For a more comprehensive survey on principles, algorithms and applications of counterexample analysis, we refer to [7].
Contributions.
In this paper we introduce a notion of causality with respect to the violation of general LTL properties. This is an extension of the work in [20], where causality was handled in the context of safety LTL properties. Our main contributions include an adaptation of the so-called Event Order Logic (EOL) in [20] in order to enable compact (finite) descriptions of what caused the violation of a system failure. The proposed notion of causality incorporates a series of properties to be satisfied by the EOL formulae characterising property violations. A notion of soundness and completeness depending on a complete enumeration of all bad traces (i.e., counterexamples) and good traces is also established. We show that causality in the sense of [20] is equivalent with causality in the current paper, for the case of safety LTL properties.
Structure of paper.
Section 2 briefly introduces the formal framework for analysing counterexamples witnessing the violation of LTL system properties in the context of transition system models. The corresponding extension of EOL to describe such counterexamples is provided in Section 3. Section 4 introduces the proposed notion of causality. In Section 5 we discuss soundness and completeness of our approach. Section 6 draws the conclusions and provides pointers to future work.
2 Preliminaries
In this section we introduce the formal framework for analysing counterexamples witnessing he violation of Linear Temporal Logic [17] system properties in the context of transition systems.
Definition 1** (Transition Systems (TS’s)).**
A TS is a tuple , where is a finite set of states, is a set of actions, is a transition relation, is a set of initial states, is a set of atomic propositions, and is a function associating to states in a set of atomic propositions in .
For we also write . In the remainder of this paper, for each , we consider an atomic proposition or event variable such that: given , it holds that whenever there exists with .
We define an execution, or execution trace of , as a possibly infinite sequence with and for all . Moreover, for all we write to represent the execution . Additionally, for all we write to represent the finite execution .
Given an execution trace , we write as a shorthand for the execution trace . For simplicity of notation, we sometimes write , or to equivalently represent .
Remark 1**.**
*In this paper, we consider TS’s without terminal states, i.e., TS’s for which all executions are infinite. Observe that this is not a limitation. Finite executions ending in a terminal state can be straightforwardly extended to infinite executions via a transition such that has a self-loop labelled , i.e., . *
We further focus on formalising properties of TS’s. A safety property can be seen as a requirement that some bad event never happens. More formally, a property is a safety property if and only if every path, or execution that violates has a finite prefix that can not be extended to a path satisfying . Intuitively, this means that if a safety property is violated, this violation already happens after the model has passed a finite sequence of states and after this finite sequence the violation is unrecoverable. Consequently, if we want to check whether a safety property is satisfied or not, it suffices to only look at finite paths of the system. A well known approach for reasoning on the violation of safety properties is model-checking implemented via simple depth first search (DFS) algorithms [2]. These algorithms check whether starting from an initial state we can find a path to some state of the model where the bad event specified by the safety property happens. If such a path can be found, the property is violated.
A liveness property requires that some good event eventually happens. It follows that when checking whether a liveness property is satisfied or not it does not suffice to only look at finite execution fragments of the system. Orthogonally to the model-checking of safety properties, reasoning on the violation of liveness properties is performed via nested depth first search (NDFS) [8]. This algorithm searches for an infinite path in the model, such that the good event described by the liveness property does not hold along that path. If such a path can be found, the property is violated.
Linear time (LT) properties can be expressed in terms of a safety and a liveness property, based on the Decomposition Theorem in [2]. Consequently, reasoning on the violation of LT properties requires an NDFS-based approach.
We further provide a brief overview on Linear Temporal Logic (LTL) [17] – a formalism to describe system properties. Intuitively, LTL formulae range over the atomic proposition , that holds in any state of a transition system and, respectively, over atomic propositions satisfied within a state whenever the labelling function indicates so. Recursively, LTL formulae are defined as disjunctions (), conjunctions () and negations () of formulae. The next () operator indicates the satisfiability of a property starting with the “next” state, whereas the until () operator indicates the satisfiability of a formula all the time until a formula is finally satisfied. The eventually () and generally () operators indicate the satisfiability of a formula “at some point” in the future and, respectively, “all the time”.
Definition 2** (Linear Temporal Logic (LTL)).**
LTL formulae over the set of atomic propositions are built according to the following grammar:
[TABLE]
LTL formulae are interpreted over transition systems without terminal states . Let be an execution trace in . The following hold:
- •
**
- •
* iff *
- •
* iff not *
- •
* iff or *
- •
* iff and *
- •
* iff *
- •
* iff and *
- •
* iff *
- •
* iff *
We write as a syntactic sugar for , and as a syntactic sugar for .
We say that a transition system satisfies a LTL formula , written as , if and only if for all executions of it holds that .
If a system model, or TS in our setting, does not satisfy some given LTL-definable property , there must be an execution witnessing the violation of the property. Such executions are called counterexamples. For safety properties, counterexamples are finite execution fragments that start in an initial state of the system and lead to an undesired state where “something bad” actually happens. For liveness properties, counterexamples must be infinite executions, because every finite path can still be extended to a path satisfying the liveness property and does, therefore, not suffice as an example for the violation of the property. An infinite path that violates a liveness property is lasso-shaped.
3 Event Order Logic
The work in [20] introduces the so-called Event Order Logic (EOL). Intuitively, formulae in EOL are used to express causality classes for counterexamples. Causality classes can be seen as generalized counterexamples. A causality class represents several counterexamples, all leading to the property violation in the “same way”. Such counterexamples may only differ in some other events that are not essential for the property violation.
In the case of liveness properties, our counterexamples must be lasso shaped, that is, they contain a loop at the end. The sequence “” is a counterexample of in the elevator model. In words, the elevator is stuck between the ground floor and the first floor, as indicates that the sequence keeps repeating forever. We can say that the cause of the property violation is that the buttons on the ground floor and the first floor are pressed repeatedly and between that, the elevator never has the chance to go to the second floor.
We see that the cause of a liveness property violation must consist of some events happening at the beginning and then some other events happening again and again (in the loop). Hence, in what follows, we propose an extension of EOL in [20] with so-called infinite formulae to express infinite causal behaviours.
The work in [20] introduces two kinds of EOL formulae: simple and complex. Intuitively, simple EOL formulae, usually denoted by , are built over event variables that are atomic propositions witnessing the execution of actions at some point in the future. The satisfiability of atomic propositions is different within the frameworks of EOL and LTL: the latter assumes satisfiability with respect to the initial state of a trace, whereas the former has an “eventually” component. This difference is formalized in Definition 4 providing the semantics of EOL.
Similarly to the case of LTL, simple EOL formulae are inductively defined using negation (), conjunction () and disjunction (). As a consequence of the observation above, formulae of shape (respectively, ) read as: eventually will hold and (respectively, or) eventually will hold.
For technical reasons related to the semantics of the aforementioned infinite EOL formulae, we split the complex EOL formulae in [20] into: I-complex and G-complex, respectively. We refer to Remark 2 for a more detailed explanation.
I-complex formulae, usually denoted by , include simple EOL formulae, conjunctions () and disjunctions () of I-complex formulae. An I-complex formula has an “ordered-and”-like semantics and reads: first holds and then . Last, but not least, an I-complex formula reads: first holds, then holds and in between the “interval” determined by the satisfiability of and the simple EOL formula holds all the time.
G-complex formulae, usually denoted by , range over I-complex formulae and encompass two more temporal operators: that has an “until”-like semantics, and that has an “after”-like semantics. More precisely, reads: will hold at some point in the future and until then, the simple EOL formula holds all the time. Orthogonally, reads: at some point holds, and after that, holds all the time.
Observe that the simple and, respectively, G-complex formulae in this paper have the same expressive power as the simple and, respectively, complex EOL formulae originally proposed in [20].
To express infinite causal behaviour, we extend the EOL in [20] with the so-called infinite formulae, usually denoted by . These are formulae built over the new logical symbol . For a G-complex formula and an I-complex formula we write to express that first holds and then happens infinitely many times.
Formally, as the new EOL we obtain the following:
Definition 3** (Extended Event Order Logic (EOL) – Syntax).**
Simple EOL formulae* over a set of event variables are formed according to the following grammar:*
[TABLE]
Complex EOL formulae* are of two kinds:*
- •
I-complex EOL formulae*, formed according to the following grammar:*
[TABLE]
where is a simple EOL formula.
- •
G-complex EOL formulae*, formed according to the following grammar:*
[TABLE]
where is a simple EOL formula and an I-complex EOL formula.
Infinite EOL formulae* are formed according to the following grammar:*
[TABLE]
where is a G-complex EOL formula and is an I-complex formula.
We want an infinite execution to satisfy an infinite EOL formula if and only if (a) the events in occur in in the order specified by , and (b) the events of occur in in the order specified by , infinitely many times.
As an example, consider the following execution in a TS:
[TABLE]
It is easy to see that satisfies the formula
[TABLE]
where is the event variable corresponding to for . We see that contains a finite part determining the event variable to occur, and a finite part in the loop where and occur. Thus, an intuitive approach to decide whether an infinite execution trace satisfies an infinite EOL formula is to split into an initial final trace and finite trace inside of the loop, and check if satisfies and if satisfies , respectively.
The following example shows that it is not enough to split the lasso shaped execution trace into a first part that contains all states up to the loop and a second part that consists of the loop executed only once. Consider the execution in (1) and the EOL formula Our execution also satisfies because in the event happens before and after that, happens after infinitely many times. Hence, in this case, the finite traces guaranteeing the satisfiability of are as follows:
[TABLE]
is obtained by concatenating the sequence in up to the loop, with one unfolding of the loop, whereas
[TABLE]
is the unfolding of the loop twice.
By following a similar pattern, consider in (1) and the EOL formula
[TABLE]
We want to satisfy this formula as well, but in (2) and in (3) do not satisfy their corresponding EOL formulae in . We have to extend until the loop has been executed three times, while is defined by unfolding the loop four times. Hence, we get:
[TABLE]
Intuitively, satisfies an infinite EOL formula whenever can be split into two finite executions and , “large enough” to satisfy and , respectively.
Remark 2**.**
As can be seen in Definition 3, we choose to classify the complex EOL formulae in [20] into I-complex formulae and G-complex formulae . This is because we want to allow only interval-like formulae as right-hand side of the operator. The occurrence of or in a cycle does not make sense unless , case in which the corresponding formulae can be equivalently expressed in terms of formulae , where stands for finite ordered conjunctions () of simple formulae .
The EOL semantics is translated to the setting of general LTL- properties and infinite loop-traces as follows:
Definition 4** (EOL – Semantics).**
Let be a transition system without terminal states. Let be simple EOL formulae, let be complex EOL formulae, let be a G-complex EOL formula, and let be an infinite EOL formula. Let be a set of event variables and let range over arbitrary event variables in .
The satisfiability of EOL formulae () is defined over execution traces in .
For simple EOL formulae we define:
- •
, i.e., (true) is trivially satisfied by all traces
- •
* iff iff *
- •
* iff not *
- •
* iff iff and *
- •
* iff iff or *
For I-complex EOL formulae we define:
- •
* iff iff*
* and *
- •
* iff iff*
* and and s.t. *
- •
* iff iff and *
- •
* iff iff or *
For G-complex EOL formulae we define:
- •
* iff and s.t. *
- •
* iff and s.t. *
- •
* iff and s.t. *
- •
* iff and s.t. *
Let be an infinite execution trace of with a loop consisting of states and starting with . Let be the unfolding of the loop for times.
For infinite EOL formulae we define:
- •
* iff and and and .*
Definition 5** (EOL Formulae over Executions).**
Let be an infinite execution trace of with a loop consisting of states and starting with . The EOL formula over is defined as:
The following definition will give us a possibility of comparing two EOL formulae. Whenever we have an EOL formula and extend it to an EOL formula by adding some events to the formula, the set of executions that satisfy the EOL formula will be a subset of those executions that satisfy the EOL formula . Intuitively, this holds as in we have more constraints on the represented execution traces. Therefore, for two infinite EOL formulae and we will use the notation to express that every execution that satisfies also satisfies . In that case, can be seen as a generalized form of .
Definition 6** (EOL Formulae Subset Relationship).**
Let be infinite EOL formulae.
- •
* iff every execution that satisfies also satisfies . Intuitively, this means that the set of events in is a subset of the events in .*
- •
* iff and .*
As an example we consider the EOL formulae and . In every execution that satisfies , the events , and will happen one after the other (but there can be other events happening between them). Therefore, every execution that satisfies also satisfies . Hence, it holds that .
4 Causality for general LTL-definable properties
In this section, we formally define the notion of actual causality (AC) for general LTL-definable properties. The definition follows its counterpart in [20]. The latter is an adoption of the actual causality in [16], to the context of concurrent systems. Next, we provide a brief reminder of the causal setting in [16].
In [16], systems under analysis are formalized as structural equation models. Intuitively, structural equations are used to describe causal influence of variables in the system. The set of all variables is partitioned into the set of exogenous variables that are irrelevant with respect to the causal effect, and the set of endogenous variables that are considered to have a meaningful, potentially causal effect. The set contains all events that jointly might represent a cause. A signature is defined as a tuple , where is a finite set of exogenous variables, is a finite set of endogenous variables, and associates with every variable a nonempty set of possible values for Y. A structural equation model over a signature is defined in [16] as tuple , where associates with each variable a function denoted that defines the values of all variables in X given the values of all other variables in . Consider a structural equation model , a vector of variables in , and vectors and of values for the variables in and . denotes the structural equation model for which variables in are set to . Given a signature , a formula of the form , for and , is called a primitive event. A basic causal formula over is one of the form where stands for the effect, or hazard, and and X are variables in . The formula is abbreviated as . Intuitively, states that holds in a setting in which the values of the variables in are set to the values in . A causal formula is a Boolean combination of basic causal formulae. We write whenever is true in the structural model , given the context defined by . Additionally, stands for a conjunction of primitive events of the form .
An actual cause with respect to the hazard, or effect is defined in [16] as follows:
Definition 7** (Actual cause [16]).**
* is an actual cause of in if the following three actual cause conditions (AC) hold:*
AC1:
.
AC2:
There exists a partition of with and some setting of the variable in such that:
- 1.
** 2. 2.
* for all subsets of *
AC3:
* is minimal, in the sense that no subset of satisfies conditions AC1 and AC2. *
Intuitively, in [16], condition AC1 states that there is a setting in which both the cause and the effect occur. AC2(1) expresses a necessity condition. It says that for to be a cause of , there must be a setting such that if is set to , would not have occurred. However, as stated in [16], AC2(1) might be too permissive as it allows to change the values of the variables in both and . Hence, the change of form true to false could be caused by a change of a variable in or . The set enables expressing so-called “contingent dependencies”. For an intuition, consider two events “Alice presses button B2” and “Bob presses button B2” that enable the elevator to reach the second floor of a building. We say that the elevator reaching the second floor depends on Alice pressing the button, under the contingency that Bob did not press the button. AC2(2) constrains AC2(1) by keeping the values of the variables in at their original values and only changing the variables in . AC2(2) corresponds to a sufficiency condition. Intuitively, setting to , guarantees that holds. The minimality condition in AC3 ensures that only those elements that are essential with respect to are part of the cause.
Actual causality in the context of TS’s and LTL-definable properties is defined as an adoption of [16] to the setting of concurrent systems, in the spirit of [20]. In our setting, represents the hazard, or the effect.
Definition 8** (Causality for LTL).**
Let be a transition system without terminal states. An EOL formula is considered a cause for the violation of the LTL specifiable property , if the following conditions are satisfied:
- •
AC1: There exists an infinite execution in such that and
- •
AC2(1): There exists an infinite execution in such that and
- •
AC2(2): For all infinite executions in with it holds that .
- •
AC3: The EOL formula is minimal, i.e., there does not exist an EOL formula with that also satisfies conditions AC1 and AC2.
AC1 above resembles its counterpart in Definition 7 in the sense that it identifies a setting that satisfies both the cause and the effect . AC2(1) entails a necessity condition that identifies a setting witnessed by in which the violation of would not occur. We fully formalise necessity as a completeness result in Theorem 1, Section 5. AC2(2) is a sufficiency result, stating that satisfying the cause is enough to guarantee the violation of . AC3 is the minimality condition which states that no true subset of satisfies conditions AC1 and AC2. Intuitively, is in the “most general form possible”. Moreover, note that our definition of causality does not employ a notion of “contingency”. This is because our approach to causality checking is based on a complete exploration of the traces within a TS model and enables the explicit identification of all potential causes.
Example 2**.**
If we want to show that is causal with respect to the violation of the LTL property , we need to show that AC1, AC2 and AC3 are fulfilled for .
Consider the infinite execution:
[TABLE]
Informally, (5) states that when at floor , after pressing button , only alternations of actions press and reach are possible, where . Note that is never reached, even if was pressed.
Moreover, consider a behaviour in which the elevator stops at floor infinitely many times after being pressed once:
[TABLE]
At this point, we can infer the following:
- •
AC1 is satisfied as, for in (5), and hold.
- •
AC2(1) holds for , for instance.
- •
AC2(2) is not fulfilled as, for instance, for in (6), and hold.
Hence, is not causal, as it does not prohibit the occurrence of .
We observe that in order to compute causes for a property violation according to Definition 8 it is not sufficient to start with an execution trace that is a counterexample for the property , build the EOL formula over and generalize it (in the sense of Definition 6) until it satisfies conditions AC1-AC3. Example 2 shows that also the non-occurrence of events can be causal for the violation of a general LTL-property. We further introduce a method to compute the events over whose non-occurrence is causal for the violation of , and encode this information within the cause .
We proceed by first defining a valuation function with respect to a set of event variables . This function maps an execution trace to the subset of event variables of occurring in .
Definition 9** (Valuation Function).**
Given a transition system and a finite set of event variables , we define the valuation function as a function on the set of execution traces of to the set – the powerset of . Let be an execution trace of . Then:
[TABLE]
Definition 10** (Non-Occurrence of Events).**
Let be a transition system without terminal states, an LTL-definable property, an execution trace over with and the EOL formula built over . Let be the set of event variables, let be the set of event variables occurring in and let . We say that that is the subset of event variables whose non-occurrence in is causal for the property violation of , if
* satisfies AC1 and AC2(1).* 2. 2.
There exists an execution trace with ,
, and . 3. 3.
* is the smallest set s.t. for all execution traces with and and we have .*
As above, let be a counterexample for the property , let be the EOL formula built over and assume satisfies the first two conditions of the definition above.
We can now compute the subset and determine the location of the event variables in the EOL formula built over a which we choose as in condition 2 above. We then compare to and prohibit the occurrence of in in the same locations as they occur in . We repeat the procedure for all as in 2 above, and build in an incremental fashion. This way we obtain a new EOL formula that also satisfies condition AC2(2).
If, based on Definition 6, there is a generalization of that also satisfies AC1 and AC2, we replace by . We repeat this procedure until is in the most general form possible and, therefore, also satisfies AC3. Since satisfies AC1-AC3 by construction, it is a cause for the violation of .
In the context of Example 2, from traces satisfying condition 2, we obtain intermediate formulae of shape:
[TABLE]
On top of the formula incrementally derived as in (7), the repeated generalisation procedure entails the EOL formula:
[TABLE]
which is semantically equivalent with . Observe that satisfies AC1 for in (5) and AC2. also satisfies AC3, because every superset of will either violate AC1 or AC2. Thus, the EOL formula satisfies AC1-AC3 .
Conditions AC1-AC3 do not imply that the order of the occurring events is causal. Whether the order of events occurring in an EOL formula that satisfies AC1-AC3 is causal or not, can be checked by the following Order Condition (OC). Note that can be causal even if the OC is not satisfied.
Definition 11** (Order Condition (OC)).**
Let be a transition system without terminal states. Let be an infinite execution trace violating an LTL-definable property . Let be the EOL formula built over . Let be the set of event variables occurring in and let . Consider a set of pairs of event variables over :
[TABLE]
Let be the formula obtained by replacing the occurrences in with .
The order condition (OC) states that the order of events and as above is not causal if the following holds:
Note that for the EOL formula in (8) the following holds: . As a consequence, the order of events in is causal. We say that satisfies OC.
The following result states the equivalence with the original notion of causality in [20], for the case of safety LTL properties.
Corollary 1**.**
Let be a transition system without terminal states. Let be a safety LTL property. A G-complex EOL formula is a cause in the sense of Definition 8 if and only if it is a cause in the sense of [20].
Proof Sketch..
First, recall that counterexamples witnessing the violation of safety properties are finite. Hence, in [20], the satisfiability of EOL formulae (characterising such counterexamples) was established based on finite traces. Nevertheless, as can be seen from Definition 4, satisfiability of G-complex formulae can be defined via finite traces as well. In fact, the semantics of G-complex formulae and EOL formulae as in [20] coincide. These being said, the equivalence of the two notions of causality in the context of safety properties follows immediately by case analysis on AC1–AC3. AC1 and, respectively, AC3 in Definition 8 are identical to their counterparts in [20]. From AC2(1) and AC2(2) in Definition 8 we can infer AC2(1) in [20]. AC2(2) in Definition 8 implies AC2(2) in [20], whereas AC2(1) and AC2(2) in [20] imply their counterparts in Definition 8. ∎
We further introduce a definition of causality classes for general LTL-properties. Intuitively, causality classes can be interpreted as “generalized counterexamples”.
Definition 12** (Causality Class).**
Let be a transition system without terminal states and let be a general LTL formula. Every infinite EOL formula that is considered a cause for the violation of , i.e., every infinite EOL formula that satisfies AC1-AC3 and OC, defines a causality class is defined as the set of all valid execution traces in that satisfy .
For example, the EOL formula in (8) satisfies AC1–AC3 and OC and, therefore, defines a causality class. Moreover, note that one execution can belong to more than one causality class.
5 Completeness and Soundness
We say that causality checking is complete whenever for each possible execution trace that violates an LTL property in the transition system under analysis, there exists a causality class representing this trace. Therefore, completeness can be seen as a necessity condition. The completeness of causality checking depends on a complete enumeration of all bad and good traces in the system.
Theorem 1** (Completeness).**
Let be a transition system without terminal states. Let range over infinite execution traces in violating an LTL-definable property , i.e., . For each such there exists a causality class of containing this trace.
Proof.
Let be a general LTL property and let be the disjunction of all EOL formulae that satisfy AC1–AC3 and OC. Let be a trace such that . We have to show that for some . Assume that is not contained in any causality class, that is for all EOL formulae that satisfy the conditions AC1–AC3 and OC.
Let be the EOL formula representing , and let and be the corresponding event variable partitioning, with respect to . Since it follows that is excluded from by one of the AC1–AC3 tests. We will show that this is not the case for any of the conditions AC1–AC3 or OC.
- •
AC1 is satisfied because for it holds that and .
- •
AC2(1) holds given the assumption that there exist EOL formulae in that satisfy AC1–AC3 and OC.
- •
If AC2(2) fails, then there exists an infinite execution with (and, hence, ) but . Let be the EOL formula derived from . We can now transform to a new formula by prohibiting the occurrence of in , in the same locations as they occur in . Consequently, we still have and but now, . Thus, does not influence the satisfaction of AC2(2) by . If still doesn’t satisfy AC2(2), i.e., if there is another with and but , we repeat the procedure from above. Since the action alphabet is finite and the EOL formulae are finitely representable, this procedure will stop after finitely many steps. The resulted EOL formula satisfies AC2(2).
- •
If AC3 excludes , then there must be some that satisfies AC1 and AC2. We still have by Definition 8 .
In all cases we obtain an EOL formula that satisfies AC1-AC3 and OC, such that . Thus, is contained in the causality class ∎
We define a causality checking result to be sound if whenever the events described by a causality class occur, the property violation occurs.
Theorem 2** (Soundness).**
Let be a transition system without terminal states. Each execution trace of contained in a causality class of a general LTL property is a bad trace, i.e. .
Proof.
Let be contained in the causality class for some EOL formula . Since defines a causality class, it must, by definition, satisfy AC1-AC3 and OC. In particular, must satisfy AC2(2). Since we have by definition of causality classes. It follows from AC2(2) that . ∎
6 Conclusions
We have presented an approach for extending causality checking towards general LTL-definable properties. To this end, we have reconsidered the actual cause conditions AC1-AC3 and OC, and adapted them to the lasso-shaped counterexamples that general LTL properties entail.
For practical reasons related to the implementation of the causality checking procedure, our current results are limited to LTL-definable properties. Nevertheless, in the future, we consider extending the formal framework of causality checking to the more general case of regular linear-time properties [2]. It should be pointed out that the described adaption can be straightforwardly extend to general -regular properties, corresponding to the expressiveness of Büchi automata, which are a strictly larger class of properties than LTL [26].
As already mentioned, we consider implementing the current causality checking approach in an automated tool. Of particular interest is QuantUM [19], a tool that enables the semi-formal specification of systems in terms of SysML [22] and applies LTL model-checking for determining what caused the violation of a safety LTL property. Recall that our notion of causality relies on the complete enumeration of system traces. Hence, the main challenge is to determine all (lasso-shaped) counterexamples in an efficient way (e.g., on-the-fly [9, 25, 4, 5]). Further future research comprises significant case studies in order to asses the scalability of our approach.
**Acknowledgements. **The authors are grateful for the useful comments received from the anonymous reviewers of CREST 2018.
The reference list from the paper itself. Each links out to its DOI / PubMed record.
- 1[1]
- 2[2] Christel Baier & Joost-Pieter Katoen (2008): Principles of model checking . MIT Press.
- 3[3] Ilan Beer, Shoham Ben-David, Hana Chockler, Avigail Orni & Richard J. Trefler (2009): Explaining Counterexamples Using Causality . In Ahmed Bouajjani & Oded Maler, editors: Computer Aided Verification, 21st International Conference, CAV 2009, Grenoble, France, June 26 - July 2, 2009. Proceedings , Lecture Notes in Computer Science 5643, Springer, pp. 94–108. Available at https://doi.org/10.1007/978-3-642-02658-4_11 . · doi ↗
- 4[4] Vincent Bloemen, Alfons Laarman & Jaco van de Pol (2016): Multi-core on-the-fly SCC decomposition . In Rafael Asenjo & Tim Harris, editors: Proceedings of the 21st ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, P Po PP 2016, Barcelona, Spain, March 12-16, 2016 , ACM, pp. 8:1–8:12. Available at http://doi.acm.org/10.1145/2851141.2851161 .
- 5[5] Vincent Bloemen & Jaco van de Pol (2016): Multi-core SCC-Based LTL Model Checking . In Roderick Bloem & Eli Arbel, editors: Hardware and Software: Verification and Testing - 12th International Haifa Verification Conference, HVC 2016, Haifa, Israel, November 14-17, 2016, Proceedings , Lecture Notes in Computer Science 10028, pp. 18–33. Available at https://doi.org/10.1007/978-3-319-49052-6_2 . · doi ↗
- 6[6] Georgiana Caltais, Stefan Leue & Mohammad Reza Mousavi (2016): (De-)Composing Causality in Labeled Transition Systems . In Gregor Gößler & Oleg Sokolsky, editors: Proceedings First Workshop on Causal Reasoning for Embedded and safety-critical Systems Technologies, CREST@ETAPS 2016, Eindhoven, The Netherlands, 8th April 2016. , EPTCS 224, pp. 10–24. Available at https://doi.org/10.4204/EPTCS.224.3 . · doi ↗
- 7[7] Edmund M. Clarke & Helmut Veith (2003): Counterexamples Revisited: Principles, Algorithms, Applications . In Nachum Dershowitz, editor: Verification: Theory and Practice, Essays Dedicated to Zohar Manna on the Occasion of His 64th Birthday , Lecture Notes in Computer Science 2772, Springer, pp. 208–224. Available at https://doi.org/10.1007/978-3-540-39910-0_9 . · doi ↗
- 8[8] Costas Courcoubetis, Moshe Y. Vardi, Pierre Wolper & Mihalis Yannakakis (1992): Memory-Efficient Algorithms for the Verification of Temporal Properties . Formal Methods in System Design 1(2/3), pp. 275–288. Available at https://doi.org/10.1007/BF 00121128 . · doi ↗
