Causal Reasoning for Safety in Hennessy Milner Logic

. Determining and computing root causes in system failures is a signiﬁcant issue in science and engineering. In this paper, we introduce a notion of causality for explaining counterexamples in system analysis based on formal models. The counter-examples are produced by checking for hazardous situations expressed in the Hennessy-Milner Logic, in the context of Labelled Transition System models. We also introduce CauseJMu, a tool for automatically identifying such causal computations within a system model. CauseJMu relies on encoding causality in terms of an extension of Hennessy-Milner Logic to recursive formulae with data. The encodings enable deciding whether a certain computation is causal or not, using the mCRL2 model checker.


Introduction
Explaining phenomena, particularly failures, using counterfactual causal reasoning has been a challenging line of research in science and engineering [1,2,3].An instance of this line of research in computer science has been about explaining counterexamples found in the process of system verification, and in particular model-checking, through counterfactual reasoning [4,5,6].Apart from the challenge of establishing well-behaved, expressive, and intuitive notions of causality, devising automated tools helping engineers to understand how to relate system faults and failures is not a trivial task.
A notion of causality that is frequently used in relation to technical systems relies on counterfactual reasoning.Lewis [1] formulates the counterfactual argument, which defines when an event is considered a cause for some effect (or hazardous situation) when the following constraints are satisfied: a) whenever the event that is presumed to be the cause occurs, the effect occurs as well (this corresponds to a sufficiency condition), and b) when the presumed cause does not occur, the effect will not occur either (counterfactual argument, or a necessity condition).
Counterfactual reasoning involves scrutinising alternative worlds: one world satisfying the sufficiency condition, where both the cause and the effect occur, and another world satisfying the necessity condition, in which neither the cause nor the effect occur.Nevertheless, the Lewis-style counterfactual argument is considered too simple for explaining causes within complex logical structures of multiple events.In their seminal work [2,3], Halpern and Pearl define a notion of complex logical events based on boolean equation systems and propose a number of conditions (the so-called AC conditions) under which an event can be considered causal for an effect.
The Halpern and Pearl model has been related in various forms to models of computation.Leitner-Fischer and Leue [4,5] adopt the Halpern and Pearl model of actual causation to the context of transition systems and trace models for concurrent system computations.In addition to the Halpern and Pearl model, the aforementioned approach to causality [4,5] considers the temporal order of events as well as the non-occurrence of events as being causal.The causality checking technique has been applied to various case studies in the area of analysing critical systems for safety violations [5].In this setting, an ordered sequence of events is computed as being the actual cause of a safety property violation.
Most relevant for our work are the results in [6].Caltais, Leue, and Mousavi [6] define a notion of counterfactual causal reasoning in the context of Labelled Transition Systems (LTSs) and Hennessy Milner Logic (HML) [7].In short, LTSs represent system models, whereas HML formulae specify the system hazards, or (undesired) effects.The notion of causality complies to the characteristics of causation proposed by Haplern and Pearl [2,3] and is further adapted to the setting of concurrent systems in the spirit of the earlier definition by Leitner-Fischer and Leue [5].Intuitively, an execution within an LTS is causal whenever it leads to a state where a certain effect, or hazard, is enabled.This definition of causality [6] exploits what is referred to as the "non-occurrence of events" [5], and identifies relevant system execution fragments that, whenever performed, change the occurrence of the effect from true to false.Then, similar to the earlier approaches [2,3,5], the new definition [6] emphasises that only relevant events included in the causal explanation may influence the occurrence of the effect and other events have no influence on the effect as long as the causal events are present.Finally, only minimal causal executions are considered as valid explanations with respect to a system hazard.
Considerable amount of work on fault analysis, fault localisation and software debugging techniques, such as delta debugging [8], nearest neighbor queries [9], counterexample explanation in model checking [10,11] and why-because-analysis [12] are based on counterfactual arguments.
Compositional verification of causality, has been recently addressed in the literature of causality [13,14,15,16,17,6].We later show by means of a short, but illustrative example, that the notion of causality introduced in this paper is not compositional with respect to the CCS-like parallel composition of LTSs [18].Nevertheless, reasoning about causality within an LTS model can be reduced to reasoning about causality at the level of its components, whenever the latter are interleaved, non-communicating LTSs.
Event structures [19,20] have been exploited to model causal dependencies in concurrent models.Nevertheless, in our approach we are interested in minimal traces that lead to hazardous situations and which satisfy the causal definition introduced in this paper.We do not take into consideration the order of events along these traces and, hence, we do not distinguish between interleaving and true concurrency.We intend to investigate further whether using event structures may lead to more efficient methods for calculating causes.
Our contributions.The work in this paper is an extension of the results presented in FROM 2018: -We refine the notion of causality initially introduced in [6] to more faithfully accommodate the AC conditions in [2,3].
-We provide proofs of compositionally for this new definition, for the case of interleaved, noncommunicating LTSs.We also explain why compositionally does not hold for the general case of communicating systems, by means of examples.
-We provide a revised encoding of causality in terms of modal µ-calculus with data [21], extending HML.This paves the way to the implementation of a model-checking procedure for computing causalities using the mCRL2 toolbox [22,21].
-We introduce CauseJMu, a tool exploiting the aforementioned encoding, in order to automatically compute causal explanations.CauseJMu is an application based on the interplay between mCRL2 and Java.
-We discuss the results of running CauseJMu in order to explain hazardous situations and ways to avoid them, by means of a railway level-crossing example.
Paper structure.Section 2 is dedicated to preliminaries.We provide a brief overview of LTSs (as semantic models of systems) and HML (as the logic to specify hazardous situations).We also introduce there the level-crossing as our running example.In Section 3, we provide a brief account of the definition of causality proposed by Halpern [3], and introduce our adoption of this notion in the context of LTSs and hazards expressed in HML.In Section 4 we present our compositionality results.Section 5 introduces the encoding of causality in terms of modal µ-calculus formulae with data.Implementing causality in mCRL2 and automating the causality checking procedure within CauseJMu is discussed in Section 6.In Section 7 we draw some conclusions and present the directions of our future work.

Preliminaries
In this section, we provide a brief overview of Labelled Transition Systems and Hennessy Milner Logic, used throughout the paper in order to formally model systems and associated properties describing hazardous situations.We discuss two (equivalent) ways of modelling systems: Labelled Transition Systems as a semantic model for system modelling and process algebra as a syntactic model (that can be given an LTS semantics); the latter serves as the input language for the mCRL2 model-checker.A level-crossing example is provided for a better illustration of the aforementioned concepts.

Labelled Transition Systems (LTSs)
Let A be a possibly infinite set of labels, usually referred to as alphabet.Let (−) * be the Kleene star operator.We use w, w 0 , w 1 , . . . to range over words in A * .We write ε ∈ A * for the empty word and wa for the word obtained by concatenating w ∈ A * and a ∈ A. We call a word w to be a sub-word of a word w, if q is obtained by deleting n letters (n ≥ 1) at some not-necessarily-adjacent positions in w, written w ∈ sub(w) or simply subword (w , w ).The empty sequence ε is a sub-word of any nonempty word w.As expected, we call w a supra-word of w whenever w is a sub-word of w.Naturally, ε is not a supra-word of any word in A * .We write | w | for the length of a word w, inductively defined as expected, where | ε |= 0. Consider two disjoint alphabets A and B, and assume w ∈ (A ∪ B) * .We write w A = w ↓ A, respectively, w B = w ↓ B for the maximal subwords of w such that w A ∈ A * , respectively, w B ∈ B * .Furthermore, we write w A || w B for the set of all words w A list l of type T , denoted by l : List[T ], is a function of type N → D, such that either its domain is the empty set, in which case the list is empty, or its domain is a closed interval [0, i], for some natural number i ∈ N, in which case the list is called finite, or its domain is the set of all natural numbers, in which case the list is called infinite.The cardinality of the domain of a finite list is called its size.Two lists are size compatible, when they have the same size.
For any list of type List[T ], we write [ ] to denote the empty list of that type.We write D = [w 0 , . . ., w n ] for a finite list of words w i ∈ A * , with 0 ≤ i ≤ n.A notation of shape D = [w 0 , w 1 , . ..] refers to an infinite list D of words w i ∈ A * , for i ≥ 0.Moreover, we write w : D as an alternative to a list with w as the first element, and D as the list of "remaining" elements; for instance: We say that lists D 0 , . . ., D n are size-compatible if they are finite lists of the same length, or if they are all infinite lists.
By reusing the notation, we often write Consider a computation π such that: whenever D, D 0 , . . ., D n are size-compatible, we write traces(D, (l 0 , D 0 ) . . .(l n , D n )) or, in short, traces(π), to denote the extensions of l 0 . . .l n with words from D, D 0 , . . ., D n as follows: Consider an LTS T = (S, s 0 , A, →); we say that π is a computation of T whenever the following hold: • D, D 0 , . . ., D n are size-compatible, and • for all w ∈ traces(π) there exists s ∈ S such that s 0 w − → → s.
Intuitively, a computation provides us with a rich structure in which not only singleton actions in the computation interleaved with any choice of equally indexed sequences of actions in the lists provide a trace of the LTS.This is illustrated by the following example.
Example 2.4.Computation Consider the Car LTS in Figure 1; computations ) are both valid computations for the Car LTS.
However, neither ) are valid computations for the LTS.The former computation, i.e., π 2 , is not valid because the decorations are not equally sized (the first decoration is the empty list, while the second one has two elements.The latter computation is not valid because the particular interleaving C a C c is a trace of π 3 but is not admitted as a trace of the Car LTS.

Cc Cl
Train LTS: t 0 t 1 t 2 t 3

T a out T c T l out
Gate LTS: In other words, for a computation to be valid, traces(π) should consist of traces in the LTS given by the pairwise extension of l 0 . . .l n with equally indexed elements of the decorations D, D 0 , . . ., D n .This decorations will later be used for those events (sequences of actions) that can disable the effect and hence, their absence is provided as a part of the causal explanation.In such a causal explanation, given a computation π as defined above, the sequence of actions does lead to the effect, but the sequences w ∈ traces(π) determine executions s 0 w − → → s in T , such that the effect does not occur in s.

A basic process algebra
LTSs can be specified in a process algebraic syntax.Process algebras [23,21] have been successfully exploited for the formal specification and verification of parallel and communicating reactive systems.Typically, process algebras specify a notion of syntax, which is accompanied by a corresponding (structural operational) semantics [24,25].As soon as a notion of behavioural equivalence of systems is established, reasoning on systems can be performed (a) in an equational fashion, via sound and complete axiomatisations that enable showing the equality of two terms built according to the aforementioned syntax, or (b) via equivalence checking of the state based systems (LTSs) generated according to the operational semantics, or (c) by model-checking LTSs with respect to properties expressed in a logical formalism [26,22,21].
The syntax of a simple process algebra is defined by the following grammar: Intuitively, A stands for the action alphabet of the process (e.g., described semantically by an LTS), a.p stands for action prefixing: first an action a is performed and then process p will follow, + is non-deterministic choice and || is parallel composition.δ is the empty process that has no behaviour.Communication between processes is performed based on synchronisations between actions that play a sender, respectively, receiver role.In this paper we write a in whenever the LTS is ready to receive/read action a, and a out to indicate that the LTS is ready to send action a. Depending on the context, we write either a ack or a whenever we acknowledge the successful communication based on a in and a out.Recursion is specified using recursive variables X ∈ Var and recursive equations of the form X .= p, where variable X (or any other recursive variable) may appear in p.
The operational semantics of processes associates an LTS to each process; it can be specified via the following rules in the Plotkin style of structural operational semantics [24] and follows the same principles as the semantics of the calclus of communicating systems (CCS) [18]: The semantics of a process is the LTS that has the process term as its initial state, the set of actions A and the transition relation that is the smallest relation satisfying the above-given inference rules.
When it is clear from the context instead of writing the outcome of synchronisation as a ack , we simply write a.Consider two LTSs: We abuse notation and write T || T in lieu of s 0 || s 0 , and T + T in lieu of s 0 + s 0 .
Two processes that run in parallel but do not communicate with each other (i.e., never use the last rule in (2)) are interleaved.Without loss of generality, we assume that interleaved LTSs have disjoint action alphabets.

Hennessy Milner Logic (HML)
As previously mentioned, the behaviour of LTSs can be analysed by model-checking properties given in a temporal logic [26,22,21].Of particular interest for this paper are properties formalising the occurrence of effects in terms of satisfiability of formulae in Hennessy Milner logic [7].

Definition 2.5. (Hennessy-Milner logic (HML))
The syntax of Hennessy-Milner logic (HML) [7] is given by the following grammar: We define the satisfaction relation over LTSs states and HML formulae as follows.
Let T = (S, s 0 , A, →) be an LTS.Let φ, φ range over HML formulae.It holds that: s for all s ∈ S s ¬φ whenever s does not satisfy φ; also written as s φ s φ ∧ φ if and only if s φ and s φ s a φ if and only if s a − → s for some s ∈ S such that s φ Disjunction and "box" ([a]φ) are the duals to conjunction and "diamond" ( a φ) and are defined as follows:

A level crossing example
Consider a level crossing example, where a gate is used to signal the approach/departure of a train, with the purpose of assisting the cars in the vicinity of the crossing to safely drive over the railway.The gate can send a message indicating the status of being closed (Gc out) or open (Go out), respectively, depending on whether it received a message from the train, signalling its approach to the crossing (T a in) or its departure from the crossing (T l in), respectively.The train displays a rather simple behaviour: it can send a message stating its approach to the crossing (T a out), afterwards it can actually enter the crossing (T c) and then send a message signalling its departure from the crossing (T l out).The car can approach the crossing (Ca), wait as long as the gate is closed (Gc in), eventually observe the gate being open (Go in), enter the crossing afterwards (Cc) and the leave the crossing (Cl).The LTSs describing the behaviours of the car, train and gate are illustrated in Figure 1.Note that the car can enter the crossing only after the gate is open, whereas the gate enters the state of being open only after a train signals its departure.Orthogonally, after receiving an approach message from a train, the gate enters the state of being closed, in which case the car can only observe the gate being closed without performing any further (driving related) actions.
The LTSs in Figure 1 are derived based on the structural operational semantics rules in (2), applied on the corresponding process terms (recursively) defined as follows: The level crossing system is defined as the parallel composition of the processes in (3).The associated process term is C || T || G.The corresponding LTS is illustrated in Figure 2. The initial state is the upper left node in Figure 2   The HML property formalising the collision between the train and the car inside the crossing is ϕ = T c ∧ Cc ; this property should not hold in any reachable state of the LTS.However, it is easy to see there is a design flaw in the railway system.By executing the trace Ca Go ack T a we can reach a state where the hazard, or the effect ϕ is satisfied.However, at a closer look we observe that by executing, for instance, the trace Ca Go ack Cc Cl T a, the setting shifts from a hazardous to a safe one.In other words, if the car leaves before the train approaches the crossing, the hazard cannot happen.
The work in this paper aims at automatically identifying design flaws within system models and providing ways to avoid hazardous situations as above, by exploiting a notion of causality defined in the next section.

Causality for Hennessy-Milner Logic formulae
In this section we provide an overview of the seminal work on causality by Haplern and Pearl [2,3] together with our adoption of this notion in the setting of LTSs models and effects, or hazards, specified as HML formulae.

The Halpern-Pearl (HP) defintion
Halpern and Pear [2,3] define actual causes with respect to certain effects, in the context of models (possible worlds) described by means of variables and associated values.Intuitively, the causal influence between some variables is captured by structural equations that describe how the outcome is determined by relating values to variables.
We proceed with a brief overview of causality as introduced by Halpern [3].A causal model M is a tuple (S, F) where S is a signature, which explicitly lists the so-called endogenous and exogenous variables and characterises their possible values, and F defines a set of modifiable structural equations, relating the values of the variables.Endogenous variables are those whose values are described by the structural equations [2].According to Halpern and Pearl [2], exogenous variables are taken as given.The structural equations model the effect of exogenous variables on the endogenous ones, and the effect of the endogenous variables on each other.
A signature S is a tuple (U, V, R), where U is a set of exogenous variables, V is a set of endogenous variables, and R associates with every variable Y ∈ U ∪ V a non empty set R(Y ) of possible values for Y (i.e., the set of values over which Y ranges).
F associates with each variable X ∈ V a function denoted which determines the value of X given the values of all the other variables in U ∪ V.For an example inspired by Halpern and Pearl [2,3], consider F X (u, y, z) = u + y, usually written as X = U + Y , for exogenous variable U and endogenous variables X, Y and Z .Thus, if Y = 3 and U = 2, then X = 5, regardless of how Z is set.
Given a signature S = (U, V, R), a primitive event is a formula of the form X = x, for X ∈ V and x ∈ R(X).A causal formula over S is of the form where ϕ is a Boolean combination of primitive events, Y i are distinct endogenous variables and y i ∈ R(Y i ) for all i ∈ {1, . . ., k}.Such a formula is sometimes abbreviated as [ Y ← y]ϕ and, intuitively, it states that ϕ holds if Y i is set to y i for all i ∈ {1, . . ., k}.
We call a context a setting u for the exogenous variables in U, and write (M, u) to denote the model M for which the variables U are set to u. External interventions are modelled by setting the value of some variable X to x in a causal model M = (S, F).This results in a new causal model, denoted M X←x , which is identical to M , except that the equation for X in F is replaced by X = x.Several external interventions X 1 ← x 1 , . . ., X n ← x n are abbreviated as X ← x, and the new associated model is denoted by M X← x .
We write (M, u) ϕ whenever the causal formula ϕ is true in a causal model M given the context u.The satisfiability relation is defined inductively.(M, u) X = x if the variable X has value x in the unique (since Halpern and Pearl [2,3] deal with acyclic models) solution to the equations in M in context u.Conjunctions and negations are defined in the standard way.Moreover, (M, u) The types of events allowed as actual causes are of the form X 1 = x 1 ∧ . . .∧ X k = x k , also abbreviated as X = x.Formally, an actual cause is defined in terms of three actual cause conditions (AC) as follows: Definition 3.1.(Actual Cause / The HP Definition [3]) X = x is an actual cause of ϕ in (M, u) if the following conditions hold: Intuitively, we say that both the actual cause X = x and the effect specified by ϕ can be observed in the actual world of (M, u).
AC2: There exists a partition of V into two disjoint subsets Z and W , with Z ∩ W = ∅ and X ⊆ Z such that 1.There is a setting x and w of the variables in X and W for which the following holds: Intuitively, this corresponds to a necessity condition indicating that whenever the actual cause is not observed in the world of (M, u), the effect disappears as well (i.e., ¬ϕ holds).
2. If there is z such that (M, u) |= Z = z, then, for all W ⊆ W and Z ⊆ Z the following holds: Intuitively, this corresponds to a sufficiency condition indicating that whenever the actual cause is observed, the effect holds as well.
AC3: X is minimal, in the sense that no subset of X satisfies conditions AC1 and AC2.
Intuitively, minimality ensures that only those elements that are essential with respect to the effect ϕ are part of the cause.

Adoption of HP to LTSs and HML
We next introduce an adoption of actual causes into the setting of system models encoded as LTSs, and effects specified as properties ϕ in HML.This paves the way to counterfactual causal reasoning in concurrency and serves as a basis for our compositionality results in the subsequent sections.
Our approach is based on an interpretation of the HP Definition similar to the work of Leitner-Fischer and Leue [5,27], where causes are intended to encode (minimal) explanations of counterexamples witnessing the violation of (safety) properties within state-based systems.
For a parallel with the railway crossing example in Section 2.3, we are interested in defining and computing actual causes of an effect ϕ encoded as an HML property stating that both the train and the car are in the crossing at the same time.Our causal model corresponds to the railway crossing LTS model, based on which we can analyse all possible worlds / executions of the train, car and gate components.
Exogenous variables are not controlled by the system and hence, cannot be included in the counterfactual reasoning and the causal explanation with respect to the effect that we analyse.Intuitively, for the level crossing example, an exogenous variable could be the intention of the train driver to leave the crossing; since this is not an action we can control, only its effect, i.e., the train's departure is something that we will reason about.Orthogonally, endogenous variables represent all events that can have a potentially causal effect.In our context, these could be: car being in the crossing, train being in the crossing or gate stuck open.
A special kind of endogenous variables are the so-called contingencies [2,3].A set of contingent variables, typically denoted by W ⊆ V, in Definition 3.1 enable expressing so-called "contingent dependencies".Contingencies specify the valuation of (contingent) variables not included in the causal explanation such that it becomes evident that the change of valuations in the causal explanation alone can control the occurrence and non-occurrence of hazard.For an intuition, consider two cars C 1 and C 2 that can crash with a train.We say that a collision depends on C 1 entering the crossing under the contingency that C 2 did not enter the crossing.Fixing the position of C 2 so that it is outside the crossing, makes it evident that it was C 1 alone which can influence the existence or removal of the hazard.Contingencies are given by those events that are not specified explicitly by the cause and its decoration.
We encode causalities via computations π = D, (l 0 , D 0 ), . . ., (l n , D n ) underlined by "causal traces" l 0 . . .l n and lists of decorations D, D i , with i ∈ {0, . . ., n}.Causal traces are the counterpart of actual causes X = x as in Definition 3.1, and encode the shortest sequences of events which, if executed, lead to the hazard, or effect ϕ.As we will see, causal traces comply to conditions similar to AC1-AC3 encoding necessity, sufficiency and minimality.
Enriching a causal trace with execution steps captured within decorations D, D i determines the elimination of the hazard.This property is a reminiscent of the work of Leitner-Fischer and Leue [5], and is not part of the original HP Definition.THere [5], events that can transform a hazardous situation into a safe one are called "causal by their non-occurrence".In the level crossing example, the car leaving the crossing before the train enters it, could be considered causal by its non-occurrence.
Our adoption of the HP Definition is as follows: Definition 3.2.(Causality for LTSs and HML) Consider a transition system T = (S, s 0 , A, →).Actual causes for an HML property ϕ in T , denoted by Causes(ϕ, T ), is the set of all computations π = D, (l 0 , D 0 ), . . ., (l n , D n ) such that: We call l 0 . . .l n a causal trace.
Intuitively, AAC1 identifies a scenario where both the causal trace l 0 . . .l n and the effect ϕ can be observed within the model T .AAC2.1 says that it is necessary to observe the causal trace along arbitrary executions χ in order to guarantee the effect ϕ.More precisely, whenever the effect cannot be observed, the causal trace l 0 . . .l n is not part of χ or is interleaved with events that are causal by their non-occurrence.AAC2.2 states that it is sufficient to observe the causal trace along arbitrary executions χ in order to enable the hazard ϕ, unless l 0 . . .l n is interleaved with events causal by their non-occurrence in χ .AAC2.3 requires causal traces interleaved with sequences causal by their nonoccurrence to remove the hazard.AAC3 is the minimality condition that requires π to be the shortest computation satisfying conditions AAC1 -AAC2.3.
Additionally, observe that our definition does not make use of contingent dependencies W as in Definition 3.1.Similar to the earlier work [5,27], our approach is based on a complete exploration of the LTS model and enables the explicit identification of all potential causes.We guarantee the termination of the LTS exploration, as we traverse loop-like executions only once.This approach is in accordance with the minimality of causal traces.In the same spirit, we consider loop-like decorations causal by their non-occurrence only once.Executing such loop decorations once or more than once leads to the same state and, hence, to the same non-hazardous scenario.
Observe that traces χ ∈ {ε, ah, d, deh} are not suprawords of ab, whereas χ = abh is in traces(π).Last, but not least, note that π does not satisfy the minimality condition.It can be easily verified that π = (a, [h, bh]) satisfies AAC1 -AAC2.3 and π ∈ sub(π).Hence, π is a cause.Similarly, we can show that π = (d, [ε]), (e, [h]) is another actual cause for ϕ.Note that π is entailed by de which a longer causal trace than a that is the causal trace of π .Nevertheless, de and a explain two very different witnesses with respect to ϕ.

Compositionality results
In this section, we show that the proposed notion of causality in this paper is not compositional with respect to the CCS-like operators in (2).Subsequently, we show that compositionality can be recovered if one confines the specification to a parallel composition of interleaved, non-communicating components.
We proceed by first introducing the notion of causal projection that enables expressing the compositionality results by capturing only the sub-LTSs underlying the causal traces with respect to an HML formula.

Definition 4.1. (Causal projection)
A causal projection of T = (S, s 0 , A, →) with respect to an HML property ϕ, is T = (S , s 0 , A, → ) We write T ↓ ϕ for the causal projection of T with respect to ϕ. Intuitively, a causal projection is an LTS whose traces are exactly all causal traces (formally defined as the trace l 0 . . .l n in Definition 3.2).For instance, the causal projection of the LTS in Figure 3, with respect to h , is illustrated on the right hand side of the same Figure 3.Note that ab is not a trace of causal projection, because ab does not provide a minimal cause.

(De)-composing causality in communicating LTSs
In this section we provide a small example of two LTSs illustrating that, unfortunately, causality is in general not compositional with respect to the CCS-like operators in (2).More precisely, we show that the proposed notion of causality is not compositional for communicating LTSs.
Consider the LTSs in Figure 4, and their parallel composition.Assume the effects ϕ 1 = h and ϕ 2 = h .It is easy to see based on the causal projections with respect to that reasoning on causality at the level of component LTSs does not determine causality within the composed LTS, and the other way around.In the context of the LTSs in Figure 4, this is a consequence of the fact that the effect h can be seen after acknowledging on c ack, whereas acknowledging on c ack is only possible after the effect h.
We conclude that in general causality at the level of composed LTSs cannot be equivalently expressed as an interleaving, disjunction or conjunction of causalities within the component LTSs.

(De)-composing causality in interleaved LTSs
In this section, we show that our notion of causality is compositional in the context of interleaved, non-communicating LTSs.Consider two LTSs T = (S, s 0 , A, →) T = (S , s 0 , B, → ) and two HML formulae ϕ 1 and, respectively, ϕ 2 built over A and, respectively, B. We show that computing causalities witnessing effects of shape ϕ 1 ∨ ϕ 2 and ϕ 1 ∧ ϕ 2 in the interleaving T || T can be reduced to computing causalities w.r.t.ϕ 1 in T , and ϕ 2 in T .
Let φ be an HML property over the alphabet of an LTS T = (S, s 0 , A, →).We call φ an immediate effect whenever s 0 φ.Note that we are not interested in reasoning about immediate effects that trivially reflect the hazard in the first state of the system.We are rather interested in understanding how individual components play a role in propagating the hazard within a system consisting of several interleaved LTSs.
Then, we proceed by reductio ad absurdum and show that π or, respectively, π have to satisfy AAC1 -AAC2.3 with respect to φ in T or, respectively, ψ in T .In order to show this, we exploit the construction of D, D i , D , D j , Definition 3.2 and the hypothesis as follows.
• Assume AAC1 is not satisfied by π and π .Equivalently, the following hold: also holds, which is in contradiction with the hypothesis that µ satisfies AAC1 .Therefore, either π or π have to satisfy AAC1 .
• Assume AAC2.1 is not satisfied by π and π .Consequently, the following hold: Hence, the following also holds given the construction of traces(π) and traces(π ) in steps 1.−7.above.This is in contradiction with the hypothesis that µ satisfies AAC2.1 .Therefore, either π or π have to satisfy AAC2.1 .
• Additionally, note that both π and π satisfy AAC2.3 by the construction in steps 1. − 7. above.Therefore, based on the observations so far, π and π can satisfy ( ) or falsify (×) AAC1 -AAC2.3 as illustrated in the table below.

Proof:
We first construct the decorations D, D i of µ above, for i ∈ {k, . . ., m}.The construction is as follows: Add χ , χ i to D, D i accordingly, for all χ as before and i ∈ {k, . . ., m}.
The rest of the proof follows by the construction of D, D i , Definition 3.2 and the hypothesis.Lemma 4.4.Consider two non-communicating LTSs T = (S, s 0 , A, →) and T = (S , s 0 , B, → ).Assume two HML formulae φ and ψ over A and B, respectively, that are not immediate effects in T and T , respectively.The following holds: where µ is a computation of the interleaving T || T , π is a computation of T and π is a computation of T .

Proof:
Consider: The result is a direct consequence of Lemma 4.4 and the semantics of the non-deterministic choice operator (+), where the isomorphic structure ( ) is underlined by:

(De)-composing conjunction
Theorem 4.9 formalises the compositionality result for conjunction of effects.For an intuition, Theorem 4.9 establishes an isomorphism between the causal projection of the interleaving T || T w.r.t.ϕ 1 ∧ ϕ 2 , and the interleaving of the causal projections T ↓ ϕ 1 and T ↓ ϕ 2 .
Then, we proceed by reductio ad absurdum and show that π and, respectively, π have to satisfy AAC1 -AAC2.

. , n}
The rest of the proof follows by the construction of D, D i , Definition 3.2 and the hypothesis.

Modal formulae with data
In what follows, we provide an overview of the fragment of modal µ-calculus with data [21] that is relevant for our work.This logic extending the Hennesy-Milner Logic in Definition 2.5 with data types and fixed points: In ( 6) above, atomic propositions af define a set of actions.Hence, a stands for the set consisting of action a (within an LTS system model).Additionally, true stands for the set of all actions, whereas false stands for the empty set.Any expression t of Boolean type is a formula.
Regular formulae R enable sequences of actions in modalities, and are defined in the standard way.The formula ε represents the empty sequence of actions; intuitively, by performing no action we remain in the same state of the LTS model.R 1 • R 2 refers to the sequences of actions obtained by concatenating expressions in R 1 with expressions in R 2 .R 1 + R 2 represents the union of sequences of actions, R * denotes zero or more repetitions of the sequences in R, whereas R + stands for one or more repetitions.
We can write, for instance, [true * ] a false in order to express that action a cannot be triggered in our LTS, or a.b + c.d true to say that ab or cd can be executed from the current state.
More formally: Negation (¬), conjunction (∧) and disjunction (∨) of formulae have the usual interpretation.Existential and universal quantifiers for ranging over data domains are also introduced.µ and, respectively, V stand for the minimal and, respectively, the maximal fixed point operators.As also indicated in [21], intuitively, the formula µX.φ (respectively, νX.φ) is valid for all those states in the smallest (respectively, largest) set X that satisfies the equation X = φ.
For an example, the formula νY.µX.(p ∧ a Y ) ∨ a X (7) says that on some a-path there are infinitely many states where p holds.The formula states that each sequence of a and b actions contains only finite subsequences of as.
Definition 5.1.(Quantifier-free Positive Normal Form) A modal formula with data as in ( 6) is in positive normal form if negations occur only in front of atomic propositions.Observe that any modal formula can be put into positive normal form by use of de Morgan laws and α-conversion [28].Moreover, for finite data, the ∀ and ∃ operators can be considered as short-hands for ∧ and ∨.A modal formula in positive normal form, built over finite data and without occurrences of ∀ and ∃, is called a formula in quantifier-free positive normal form.

Definition 5.2. (Alternation Depth)
The alternation depth of a formula φ in quantifier-free positive normal form, written AD(φ), is the number of alternating fixed points inductively defined as follows: For instance:

Encoding AAC1-AAC3
In this section we introduce an encoding of actual causality as in Definition 3.2, via modal formulae with data [21].This paves the way to the automatic identification of causes in the mCRL2 model checker [22,21].Some of the "ingredients" necessary for the aforementioned encoding are as follows.
over an LTS T = (S, s 0 , A, →).We write l for the underlying trace l 0 . . .l n , and LD for the list of size-compatible lists D, D 0 , . . ., D n .In our modal formulae, traceslLD stands for traces(π), whereas sizeCompatible(LD) checks whether the lists in LD are size-compatible.Additionally, recall that our approach relies on a complete exploration of our system models.We write allExec to represent the list of all valid executions within T .(According to the remarks in Section 3.2, allExec and traceslLD are finite.) We write A * for the "type" of words over actions in A (e.g., l : A * ), and List[A * ] for the "type" of lists of words over actions in A (e.g., D i : List[A * ], for i ∈ {0, . . ., n}).We write head (L) to denote the first element of a list L, and tail (L) to represent the list obtained by removing its first element.An expression of shape e ∈ L checks wether a list L contains the element e. L is the length of L.
Checking whether π in ( 10) is a cause for an effect given by the HML formula ϕ in the sense of Definition 3.2, reduces to checking the satisfiability of the modal formulae with data below, encoding AAC1 -AAC3 .(Note that PC , NEC , SUF , NOC and MIN are variable names used in the context of fixed point operators encoding a so-called "positive" causality in the spirit of AAC1, necessity, sufficiency, actions that are causal by their non-occurrence and the minimality condition, respectively.) The encoding of AAC1 is: In accordance with AAC1 in Definition 3.2, the formula in (11) identifies a setting in which by executing the causal trace l a state satisfying the effect ϕ is reached.The fixed point notation µPC in ( 11) is used for consistency reasons.The formula in (11) can be equivalently rewritten as l ϕ.
The encoding of AAC2.1 is: Formula ( 12) encodes a necessity condition.It states that whenever an execution of the LTS leads to a state where the effect ϕ cannot be observed (i.e., head (allExec) ¬ϕ), one of the following holds: (a) The causal trace l is not part of the aforementioned execution (i.e., ¬subword (l, head (allExec)).(b) The execution is interleaved with events causal by their non-occurrence which shift the setting from a hazardous one to a safe one (i .e., head (allExec) ∈ traceslLD)).The recursive call on tail (allExec) guarantees all executions within the LTS are checked in the spirit of AAC2.1 .
The encoding of AAC2.2 is: Formula (13) encodes a sufficiency condition, and is the dual of (12).Intuitively, it states that whenever the causal trace occurs within an execution exec ∈ allExec of the LTS, and exec is not interleaved with events causal by their non-occurrence, it must be the case that exec always leads to a hazard.
The encoding of AAC2.3 is: Formula ( 14) encodes the events causal by their non-occurrence that shift the context from a hazardous to a non-hazardous one.More precisely, all executions exec that are obtained by interleaving the causal trace l with events causal by their non-occurrence (i.e., exec ∈ traceslLD) always lead to states where the effect ϕ cannot be observed (i.e., [exec]¬ϕ).
The encoding of AAC3 is: In (15) we write, for instance, PC (l ) to represent the modal formula in (11) for the execution l .Formula (15) encodes the minimality condition for π in (10).It fails whenever all conditions AAC1− AAC2.3 are satisfied by a sub-computation of π, built over an arbitrary execution l and the arbitrary size-compatible lists of events causal by their non-occurrence in LD .

Proof:
Condition AAC1 refers to the existence of a trace that satisfies ϕ; condition AAC3 requires the existence of an execution underlined by π ∈ sub(π) that violates at least one of AAC1-AAC3.Hence, we encode AAC1 and AAC3 as least fixed points in (11) and (15), respectively.It is trivial to see that AAC1 is satisfied if and only if the least fixed point in (11) is satisfied.In case of AAC3, the encoding of minimality in (11) is achieved by ensuring that all subword s of the cause at hand l violate at least one of the conditions encoded below.Symmetrically, AAC2.1-AAC2.3require the satisfaction of some conditions for all χ of a certain shape.Hence, we encode AAC2.1-AAC2.3 as greatest fixed points in ( 12), ( 13) and ( 14), respectively.Universal quantifications (∀χ ) in AAC2.1-AAC2.3 are handled within the associated modal formulae via recursive calls parametrised over all executions or decorated traces of the system under analysis.The rest of the translation is purely syntactic.

Causality at work
In this section, we present our approach to causality checking from a more practical perspective.We introduce the automated tool CauseJMu built on top of mCRL2 and Java, and discuss its performance w.r.t.causality checking in the context of the level crossing example in Section 2.3.We proceed by first discussing the mCRL2 toolset, used in order to actually encode the LTS system models, the associated safety properties and the modal formulae capturing causality as in Definition 3.2.The mCRL2 model-checker is then invoked within CauseJMu to compute causalities.
6.1.The mCRL2 toolset mCRL2 [22,21] is a formal toolset successfully exploited for the modelling, validation and verification of concurrent systems and protocols.In this section we provide a brief overview of mCRL2, relevant for our work on causality checking.Namely, we discuss how concurrent systems can be specified and model-checked in mCRL2.
Systems are specified in mCRL2 in a process algebraic fashion [23], according to the approach in Section 2.1.The keyword act introduces the actions of the LTSs, whereas proc introduces the LTS process terms built according to the grammar in (1).The keyword comm specifies the communicating actions a in, a out and the name of the action a ack (or a, depending on the context) acknowledging the communication as in (2).allow introduces the actions the LTS is allowed to perform.Moreover, allow can be used in order to disable the independent (not synchronised) execution of communicating actions a in, a out.init defines (the composition of) the LTSs we want to model-check.
Actions Ta_out, Ta_in, Go_out, etc., are the actions of the LTSs formalizing the models of the car, train and the gate in (3).We write delta for the empty process δ as in (1).The associated LTS process terms C, T and, respectively, G execute in parallel: T || G || C. The comm section defines, for instance, communications acknowledging the arrival of the train Ta_out|Ta_in -> Ta, or the opening of the gate Go_in|Go_out -> Go_ack.The actions allowed to be independently executed by T || G || C correspond to the train arriving, train leaving, train entering the crossing, car arriving, car entering the crossing, car leaving, acknowledging the gate closing and acknowledging the gate opening, respectively: { Ta, Tl, Tc, Ca, Cc, Cl, Gc_ack, Go_ack }.
Note that the actual LTS model as in Figure 2 can be derived from the mCRL2 specification in Figure 5, in accordance with the set of semantic rules in (2).This is achieved by applying a series of tools in the mCRL2 toolbox, in a "pipe-and-filter" fashion.The sequence of steps can be summarised as follows: spec.mcrl2 The first step translates the mCRL2 specification to a linear process specification in the .lpsformat.The next step generates an LTS from a linear process.Eventually, the LTS is converted into the .fsmformat which contains transition and state information, in a human readable format.
A modal formula with data like in ( 6) can be defined in an .mcffile.For instance, in the context of the level crossing example in Section 2.3, we can create a file called safety.mcf,and define a safety formula specifying that a train and a car cannot be in the crossing at the same time: Note that the action names Tc and Cc must be defined in the model specification file .mcrl2.Additionally, observe the slightly different notation used for denoting negation and conjunction of formulae: ! and &&, respectively.Model-checking the above formula against the model in Figure 5 The lps2pbes tool generates a parameterised boolean equation system from the linear process specification.The formula saved in the safety.mcffile will be used as a parameter of the lps2pbes tool.The latter can generate a counterexample based on the spec.bpesfile in case the formula is not satisfied by the system model.For a thorough description of the mCRL2 toolset, and the associated user manual, we refer the interested reader to: https://www.mcrl2.org/web/user_manual/index.html.Last, but not least, a .mcrl2file can include variables and equational specifications of functions with parameters of different sorts.For an example, we provide in Figure 6 the specification of a function subword determining whether all the elements of a given list l1 occur in the same order within a list l2.The keywords sort and struct introduce the data type myAct which, intuitively, stands for an alphabet consisting of the constants ma, mb, mc.The keyword var introduces a list of variables of a certain sort.The keyword map introduces the signature of the subword function with two parameters of type list of elements in myAct.Note that List(...) and Bool are predefined in mCRL2.Functions head and tail are predefined as well, and return the head, respectively the list obtained after removing the first element of a list.The empty list is naturally denoted by [].The keyword eqn introduces the definition of subword via three conditional (recursive) equations; the condition is the expression on the left hand side of ->.

CauseJMu: a Java-mCRL2 tool for causality
In this section we introduce CauseJMu, a tool for automatically computing causality as in Section 3.2, with respect to effects in HML.Our tool is available for download at: https://www.sen.uni-konstanz.de/research/research/causejmu.
CauseJMu is a tool based on the interplay between Java and mCRL2.On the one hand, mCRL2 is exploited for formally specifying the LTS under analysis, and a safety property that can be disproved by reaching a hazard/effect in HML.On the other hand, mCRL2 performs the model-checking of both the safety property and the modal formulae with data (11)- (15) encoding the definition of causality in Section 3.2, whenever a counterexample is identified.All computations π built on top of such counterexamples that determine the true result of the model-checking procedure are valid causal explanations.
As already mentioned in Section 3.2, our approach to causality relies on a complete exploration of the LTS model in order to identify all possible counterexamples witnessing hazardous situations.Nevertheless, the model checking problem is solved in mCRL2 through solving a parity game [29,30], where winning strategies of one player are then used to construct a subgraph of the original LTS in which the same strategies can be used to explain the model checking result.In this setting, there is no natural notion of continuing a search after a first counterexample, Therefore, CauseJMu runs a Breadth First Search (BFS) / Depth First Search (DFS) based algorithm [26] implemented in Java in order to identify all counterexamples underlying possible causal traces within the LTS model (generated with mCRL2 as in ( 16)).Additionally, for each counterexample, the Java-implemented algorithm identifies the size-compatible lists of executions, or decorations, that can switch the setting from a hazardous to a non-hazardous one.In other words, the Java component of CauseJMu automatically computes the set of computations of a given LTS.
It is also worth mentioning that CauseJMu is a multi-threaded application.In short, each such thread is in charge of handling a set of computations.For each computation, one thread (a) translates conditions AAC1 -AAC3 in Definition 3.2 into mCRL2 format, based on the corresponding encodings ( 11)-( 15) and (b) invokes the mCRL2 model-checking procedure for each of the encodings.Whenever the formulae ( 11)-( 15) are satisfied, the corresponding computation is stored as a valid cause.
The user is left to specify a valid model within a .mcrl2file, and a hazard encoded as an HML formula.Moreover, the user is required to specify the maximum length of the causal traces to be computed.The length can be a positive integer value, or "any length" whenever * is introduced.Similarly, the user has to specify the maximum length of the decorations causal by their non-occurrence, via a positive integer values or * .The number of threads handling causality checking can also be specified.Naturally, one thread corresponds to a "sequential" run of CauseJMu.The rest is handled by CauseJMu in a fully automated manner, e.g., the interplay between Java and mCRL2, the automated generation of formulae ( 11)-( 15), the model-checking in mCRL2, etc.The set of causal computations as in Definition 3.2 are eventually displayed to the user.The main steps of the causality checking approach are sketched in Algorithm 1.

Algorithm 1: Main steps in CauseJMu
Input: The .mcrl2 model file path, the hazard formula ϕ, the maximum causal trace length, the maximum length of decorations causal by their non-occurrence, the number of threads Output: The set SC of causal computations 1. Run mCRL2 and generate the LTS model by following the steps in (16); 2. Run the Java BFS/DFS-implementation to generate all computations within the LTS; 3. Split the set of computations amongst the Java threads; 4. For each thread: 5.For each computation π, invoke the Java procedure generating the .mcffile encoding (11); 6. Model-check with mCRL2 all the .mcffiles by following the steps in (17); 7. Store all computations π underling counterexamples identified in step 6.; 8.For each computation π stored in step 7.: 9. Invoke the Java procedure generating the .mcffiles encoding ( 12)-( 15 In what follows, we discuss a few implementation details.In step 9., we only generate the .mcffiles encoding ( 12)-( 14).We skip the minimality condition AAC3 encoded by (15).Instead, at the very end of our causality checking algorithm, we select only those computations π that satisfy AAC1 -AAC2.3(i.e., those computations π for which the corresponding .mcfencodings ( 11)-( 14) are satisfied), whose underlying causal traces are not supra-words of other causal traces.All computations π that satisfy AAC1 -AAC2.3 and entail minimal causal traces comply to Definition 3.2 by construction.In step 7., we only choose those computations π whose underlying causal traces are not supra-words of computations π already stored in the set SC of causal computations.This decision is based on the minimality condition in AAC3 .Additionally, after running the BFS/DFS algorithm in step 2., all identified traces are sorted according to their length.This contributes to speeding up the causality checking procedure as the shortest causes are identified first.
Automating the generation of formulae ( 11)- (15) in Java is not only a nice-to-have feature, but a necessity.This is because actions (introduced by the act keyword in the .mcrl2model specification files) cannot be interpreted as data within modal formulae defined in (6).Also, data cannot be encapsulated within the and [] modalities.
For an example, consider a trivial system s 0 a − → s 1 h − → s 2 , and the effect ϕ = h .It is easy to see that the computation (a, [h]) is the only cause with respect to ϕ.The associated .mcrl2file is: act a h; proc P = a.h; init allow( { a, h }, P); Nevertheless, for instance, formula (14) encoding non-occurrence of events cannot be straightforwardly specified into a .mcffile.Instead, the .mcrl2file is enriched with a new sort myAct defining a new constant for each action of the model: As ma•mh true is not a valid modal formula with data in mCRL2, the corresponding correct formula a • h true is encoded via the fixed point mu X(trace : List(myAct) = head(tracesLD)) ... above.For larger systems, manually encoding formulae (11)-(15) into mCRL2 is not feasible.

Experimental evaluation
We ran CauseJMu for the level crossing example in Section 2.3, on a machine operating on Linux 4.19.5,Intel Core i5 7200U, 8 GB RAM, 64-bit architecture.
As in Figure 2, the LTS corresponding to the parallel execution of the car (C), train (T ) and gate (G) processes consists of 20 states and 31.In this case, CauseJMu considered 71 traces as candidates for causality, and invoked mCRL2 for model-checking about 100 formulae.

CauseJMu correctly identified one causal computation, with the underlying causal trace
Ca Go ack T a and the size-compatible lists of executions causal by their non-occurrence, of length 30.In other words, CauseJMu correctly identified Ca Go ack T a as the shortest trace leading to the hazard Cc ∧ T c , and 30 ways of avoiding the hazardous situation despite the execution of the aforementioned causal trace.Intuitively, Ca Go ack T a describes a scenario in which the car approaches the crossing, the gate is open (and hence, the car can enter the crossing) and the train approaches the crossing as well.All this leads to a state in which both the car and the train can be in the crossing at the same time.One way of avoiding the accident (and identified by CauseJMu) is, for instance, given by the following trace: Ca Go ack Cc Cl T a.In other words, car enters and immediately leaves the crossing before train arrives at the crossing.
We ran CauseJMu to determine causalities in the level crossing example, and observed the execution times depending on the number of Java threads: If for one thread running CauseJMu took about one and a half minutes, the execution time decreased to 25 seconds for five and six threads, respectively.On 10 threads, CauseJMu performed the causality checking within 16 seconds, and on 56 threads in 4 seconds.
mCRL2 implements an efficient model-checking by solving a parity game.The complexity of model-checking a modal formula f as in ( 6) is: where |→| stands for the size of the transition relation of the LTS under analysis, | S | is the number of states within the LTS, | f | is the size of the formula f and d is the alternation depth.Recall that explicitly model checking the minimality formula (15) could be avoided: in step 7. of Algorithm 1 we only choose those computations π whose underlying causal traces are not supra-words of computations π already stored in the set SC of causal computations.Moreover, as stated in Remark 5.3, the remaining formulae (11)-( 14) are of alternation depth at most 1.Hence, the resulting model-checking complexity is linear in the size of the transition relation, for each of the considered formulae!On the implementation side, the drawbacks are as follows.On the one hand, CauseJMu requires most of the time in order to compute all the traces and associated decorations based on the LTS model generated with mCRL2.Nevertheless, it suffices to run this preprocessing step only once for each model; the resulted information could be easily stored for later use.On the other hand, considerable amount of time is added due to the hard disk read/writes that enable the communication between Java and mCLR2.We consider overcoming this issue and further increase performance by using memorymapped files, for instance.
A larger example consisting of two cars running in parallel with the train and the gate processes as in (3) entailed a model consisting of 100 states and 235 one-step transitions.In this case, CauseJMu considered about 11000 traces as candidates for causality, and invoked mCRL2 for model-checking around 58000 formulae.With the current implementation, on 56 threads, all causes witnessing the collision between one of the cars and the train, together with all the ways to avoid these collisions, could be computed within 713 seconds.

Conclusions
In this paper, we exploited counterfactual causal reasoning in order to explain counterexamples of model checking.In our setting hazardous situations are expressed in the Hennessy Milner Logic (HML) and the system model is given as a labelled transition system (LTSs).Our notion of causality is an adoption of Halpern's definition [2,3], based on trace models in the style of Leitner-Fischer and Leue [4,5].We also showed that causality is compositional in the context of non-communicating, interleaved LTSs.We demonstrated by means of an example that similar results cannot be derived for communicating systems.We provided an encoding of causality in Definition 3.2, in terms of modal formulae with data.This is in order to prepare the ingredients for a faithful encoding of causality checking in the mCRL2 model-checker.Eventually, we showed how the mCRL2 toolset can be exploited using a Java wrapper, to automatically determine causal computations based on an LTS system model and an HML hazard/effect specified by the user.The integration mCRL2 and the Java wrapper was implemented in the automated tool CauseJMu.Additionally, we provided insight on the execution time of CauseJMu, when reasoning about causality within a railway level crossing.
As future work we consider optimising the implementation of CauseJMu.We would like to evaluate its performance on more (real-world) case studies, and compare the results with similar tools [31] that for example use parity games for model-checking.Additionally, we want to extend our approach to handle causalities with respect to the violation of liveness properties as well, in which case counterexamples are not finite traces, but rather loops of some sort.
We would like to understand what kind of (configurations over) communicating systems, still useful in practice, benefit from compositionality of causality.We would also like to exploit the possibility of capturing true concurrency semantics, e.g., using event structures, within our notion of causality.This will allow for identifying causal traces of shape ab and ba, for instance, whenever they represent mere interleaving of the same concurrent system and hence, is likely to lead to a more efficient computation of causes.

Definition 2 . 1 .
(Labelled Transition Systems (LTSs)) A labelled transition system (LTS) is a triple (S, s 0 , A, →), where S is a finite set of states, s 0 ∈ S is the initial state, A is the action alphabet and →⊆ S × A × S is the transition relation.We write − → → ⊆ S×A * ×S, to denote the reachability relation, i.e., the smallest relation satisfying: Definition 2.2.(Lists) Consider two natural numbers a, b ∈ N such that a ≤ b; a closed interval [a, b] ⊆ N of natural numbers, is defined as {i [D] to denote type List[D].For instance, [ ] and [ ] are size-compatible, [w 0 , w 1 , w 2 ] and [w 0 , w 1 , w 2 ] are size-compatible, [w 0 , w 1 , . ..] and [w 0 , w 1 , . ..] are size-compatible, whereas [ ] and [w] are not size-compatible.Definition 2.3.(Computations) A computation of size n is a sequence D, (l 0 , D 0 ), . . ., (l n , D n ) with n ∈ N, l i ∈ A and D, D i ∈ [A * ], for 0 ≤ i ≤ n.We call D, D 0 , . . ., D n ∈ [A * ] the decorations of the computation.

Figure 1 .
Figure 1.The Car, Train and Gate as LTSs and it corresponds to C || T || G.The remaining states and transitions are subsequently derived according to the semantic rules in (2).

Figure 2 .
Figure 2. The Level Crossing LTS

Figure 3 .
Figure 3.An LTS and Its Causal Projection w.r.t.h
3 w.r.t φ in T and, respectively, ψ in T .In showing this, we exploit the construction of D, D i , D , D j , Definition 3.2 and the hypothesis.

Figure 6 .
Figure 6.Specifying Functions in mCRL2 ); 10.Model-check with mCRL2 all the .mcffiles by following the steps in (17); 11.If all formulae in step 10. are satisfied, store π in the set SC of causal computations.