Variability Abstraction and Refinement for Game-based Lifted Model Checking of full CTL (Extended Version)

Variability models allow effective building of many custom model variants for various configurations. Lifted model checking for a variability model is capable of verifying all its variants simultaneously in a single run by exploiting the similarities between the variants. The computational cost of lifted model checking still greatly depends on the number of variants (the size of configuration space), which is often huge. One of the most promising approaches to fighting the configuration space explosion problem in lifted model checking are variability abstractions. In this work, we define a novel game-based approach for variability-specific abstraction and refinement for lifted model checking of the full CTL, interpreted over 3-valued semantics. We propose a direct algorithm for solving a 3-valued (abstract) lifted model checking game. In case the result of model checking an abstract variability model is indefinite, we suggest a new notion of refinement, which eliminates indefinite results. This provides an iterative incremental variability-specific abstraction and refinement framework, where refinement is applied only where indefinite results exist and definite results from previous iterations are reused.


Introduction
Software Product Line (SPL) [6] is an efficient method for systematic development of a family of related models, known as variants (valid products), from a common code base. Each variant is specified in terms of features (static configuration options) selected for that particular variant. SPLs are particulary popular in the embedded and critical system domains (e.g. cars, phones, avionics, healthcare).
Lifted model checking [4,5] is a useful approach for verifying properties of variability models (SPLs). Given a variability model and a specification, the lifted model checking algorithm, unlike the standard non-lifted one, returns precise conclusive results for all individual variants, that is, for each variant it reports whether it satisfies or violates the specification. The main disadvantage of lifted model checking is the configuration space explosion problem, which refers to the high number of variants in the variability model. In fact, exponentially many variants can be derived from only few configuration options (features). One of the most successful approaches to fighting the configuration space explosion are socalled variability abstractions [14,15,16,12]. They hide some of the configuration details, so that many of the concrete configurations become indistinguishable and can be collapsed into a single abstract configuration (variant). This results in smaller abstract variability models with a smaller number of abstract configurations, such that each abstract configuration corresponds to some subset of concrete configurations. In order to be conservative w.r.t. the full CTL temporal logic, abstract variability models have two types of transitions: may-transitions which represent possible transitions in the concrete model, and must-transitions which represent the definite transitions in the concrete model. May and must transitions correspond to over and under approximations, and are needed in order to preserve universal and existential CTL properties, respectively.
Here we consider the 3-valued semantics for interpreting CTL formulae over abstract variability models. This semantics evaluates a formula on an abstract model to either true, false, or indefinite. Abstract variability models are designed to be conservative for both true and false. However, the indefinite answer gives no information on the value of the formula on the concrete model. In this case, a refinement is needed in order to make the abstract models more precise.
The technique proposed here significantly extends the scope of existing automatic variability-specific abstraction refinement procedures [8,17], which currently support the verification of universal LTL properties only. They use conservative variability abstractions to construct over-approximated abstract variability models, which preserve LTL properties. If a spurious counterexample (introduced due to the abstraction) is found in the abstract model, the procedures [8,17] use Craig interpolation to extract relevant information from it in order to define the refinement of abstract models. Variability abstractions that preserve all (universal and existential) CTL properties have been previously introduced [12], but without an automatic mechanism for constructing them and no notion of refinement. The abstractions [12] has to be constructed manually before verification. In order to make the entire verification procedure automatic, we need to develop an abstraction and refinement framework for CTL properties.
In this work, we propose the first variability-specific abstraction refinement procedure for automatically verifying arbitrary formulae of CTL. To achieve this aim, model checking games [25,23,24] represent the most suitable framework for defining the refinement. In this way, we establish a brand new connection between games and family-based (SPL) model checking. The refinement is defined by finding the reason for the indefinite result of an algorithm that solves the corresponding model checking game, which is played by two players: Player ∀ and Player ∃. The goal of Player ∀ is either to refute the formula Φ on an abstract model M or to prevent Player ∃ from verifying it. Similarly, the goal of Player ∃ is either to verify Φ on M or to prevent Player ∀ from refuting it. The game is played on a game board, which consists of configurations of the form (s, Φ ) where s is a state of the abstract model M and Φ is a subformula of Φ, such that the value of Φ in s is relevant for determining the final model checking result. The players make moves between configurations in which they try to verify or refute Φ in s. All possible plays of a game are captured in the game-graph, whose nodes are the elements of the game board and whose edges are the possible moves of the players. The model checking game is solved via a coloring algorithm which colors each node (s, Φ ) in the game-graph by T , F , or ? iff the value of Φ in s is true, false, or indefinite, respectively. Player ∀ has a winning strategy at the node (s, Φ ) iff the node is colored by F iff Φ does not hold in s, and Player ∃ has a winning strategy at (s, Φ ) iff the node is colored by T iff Φ holds in s. In addition, it is also possible that neither of players has a winning strategy, in which case the node is colored by ? and the value of Φ in s is indefinite.
When the game results in a tie with an indefinite answer, we want to refine the abstract model. We can find the reason for the tie by examining the part of the game-graph which has indefinite results. We choose then a refinement criterion, which splits abstract configurations so that the new, refined abstract configurations represent smaller subsets of concrete configurations.

Background
Variability Models. Let F = {A 1 , . . . , A n } be a finite set of Boolean variables representing the features available in a variability model. A specific subset of features, k ⊆ F, known as configuration, specifies a variant (valid product) of a variability model. We assume that only a subset K ⊆ 2 F of configurations are valid. An alternative representation of configurations is based upon propositional formulae. Each configuration k ∈ K can be represented by a formula: We will use both representations interchangeably.
We use transition systems (TS) to describe behaviors of single-systems.

Definition 1. A transition system (TS) is a tuple T = (S, Act, trans, I, AP, L),
where S is a set of states; Act is a set of actions; trans ⊆ S × Act × S is a transition relation which is total, so that for each state there is an outgoing transition; I ⊆ S is a set of initial states; AP is a set of atomic propositions; and L : S → 2 AP is a labelling function specifying which propositions hold in a state. We write s 1 λ − − →s2 whenever (s 1 , λ, s 2 ) ∈ trans.
An execution (behaviour) of a TS T is an infinite sequence ρ = s 0 λ 1 s 1 λ 2 . . . with Modal transition systems (MTSs) [21] are a generalization of transition systems equipped with two transition relations: must and may. The former (must) is used to specify the required behavior, while the latter (may) to specify the allowed behavior of a system. We will use MTSs for representing abstractions of FTSs. A may-execution in M is an execution (infinite sequence) with all its transitions in trans may ; whereas a must-execution in M is a maximal sequence with all its transitions in trans must , which cannot be extended with any other transition from trans must . Note that since trans must is not necessarily total, must-executions can be finite. We use [[M]] may M T S (resp., [[M]] must M T S ) to denote the set of all mayexecutions (resp., must-executions) in M starting in an initial state. Example 1. Throughout this paper, we will use a beverage vending machine as a running example [4]. Figure 1 shows the FTS of a VendMach family. It has two features, and each of them is assigned an identifying letter and a color. The features are: CancelPurchase (c, in brown), for canceling a purchase after a coin is entered; and FreeDrinks (f , in blue) for offering free drinks. Each transition is labeled by an action followed by a feature expression. For instance, the transition s 0 free/f −−−→ s 2 is included in variants where the feature f is enabled. For clarity, we omit to write the presence condition true in transitions. There is only one atomic proposition served ∈ AP , which is abbreviated as r. Note that r ∈ L(s 2 ), whereas r ∈ L(s 0 ) and r ∈ L(s 1 ).
By combining various features, a number of variants of this VendMach can be obtained. The set of valid configurations is: Figure 2 shows a basic version of VendMach that only serves a drink, described by the configuration: ∅ (or, as formula ¬c ∧¬f ). It takes a coin, serves a drink, opens a compartment so the customer can take the drink. Figure 3 shows an MTS, where must transitions are denoted by solid lines, while may transitions by dashed lines.

CTL Properties.
We present Computation Tree Logic (CTL) [1] for specifying system properties. CTL state formulae Φ are given by: where l ∈ Lit = AP ∪ {¬a | a ∈ AP} and φ represent CTL path formulae. Note that the CTL state formulae Φ are given in negation normal form (¬ is applied only to atomic propositions). The path formula Φ can be read as "in the next state Φ", Φ 1 UΦ 2 can be read as "Φ 1 until Φ 2 ", and its dual Φ 1 VΦ 2 can be read as "Φ 2 while not Φ 1 " (where Φ 1 may never hold). We assume the standard CTL semantics over TSs is given [1] (see also Appendix A). We write [T |= Φ] = tt to denote that T satisfies the formula Φ, whereas [T |= Φ] = ff to denote that T does not satisfy Φ.
We say that an FTS F satisfies a CTL formula Φ, Otherwise, we say F does not satisfy Φ, written [F |= Φ] = ff. In this case, we also want to determine a non-empty set of violating variants K ⊆ K, such that We define the 3-valued semantics of CTL over an MTSs M slightly differently from the semantics for TSs. A CTL state formula Φ is satisfied in a state s of an Example 2. Consider the FTS VendMach and MTS α join (VendMach) in Figures 1 and 3. The property Φ 1 = A(¬rUr) states that in the initial state along every execution will eventually reach the state where r holds. Note that [VendMach |= Φ 1 ] = ff. E.g., if the feature c is enabled, a counter-example where the state s 2 that satisfies r is never reached is: (2) there is no must-execution that violates Φ 1 .
Consider the property Φ 2 = E(¬rUr), which describes a situation where in the initial state there exists an execution that will eventually reach s 2 that satisfies r. Note that [VendMach |= Φ 2 ] = tt, since even for variants with the feature c there is a continuation from the state s 1 to s 2 . But, [α join (VendMach) |= Φ 2 ] = ⊥ since (1) there is no a must-execution in α join (VendMach) that reaches s 2 from s 0 , and (2) there is a may-execution that satisfies Φ 2 .

Abstraction of FTSs
We now introduce the variability abstractions [12] which preserve full CTL. We start working with Galois connections 5 between Boolean complete lattices of feature expressions, and then induce a notion of abstraction of FTSs.
The Boolean complete lattice of feature expressions (propositional formulae over F) is: (FeatExp(F) /≡ , |=, ∨, ∧, true, false, ¬). The elements of the domain FeatExp(F) /≡ are equivalence classes of propositional formulae ψ ∈ FeatExp(F) obtained by quotienting by the semantic equivalence ≡. The ordering |= is the standard entailment between propositional logics formulae, whereas the least upper bound and the greatest lower bound are just logical disjunction and conjunction respectively. Finally, the constant false is the least, true is the greatest element, and negation is the complement operator. Over-approximating abstractions. The join abstraction, α join , replaces each feature expression ψ with true if there exists at least one configuration from K that satisfies ψ. The abstract set of features is empty: α join (F) = ∅, and abstract set of configurations is a singleton: α join (K) = {true}. The abstraction and concretization functions between FeatExp(F) and FeatExp(∅) are: which form a Galois connection [15]. In this way, we obtain a single abstract variant that includes all transitions occurring in any variant.
Under-approximating abstractions. The dual join abstraction, α join , replaces each feature expression ψ with true if all configurations from K satisfy ψ.
The abstraction and concretization functions between FeatExp(F) and FeatExp(∅), forming a Galois connection [12], are defined as [9]: α join = ¬ • α join • ¬ and γ join = ¬ • γ join • ¬, that is: In this way, we obtain a single abstract variant that includes only those transitions that occur in all variants.

Abstract MTS and Preservation of CTL.
Given a Galois connection (α join , γ join ) defined on the level of feature expressions, we now define the abstraction of an FTS as an MTS with two transition relations: one (may) preserving universal properties, and the other (must) preserving existential properties. The may transitions describe the behaviour that is possible in some variant of the concrete FTS, but not need be realized in the other variants; whereas the must transitions describe behaviour that has to be present in all variants of the FTS.
Note that the abstract model α join (F) has no variability in it, i.e. it contains only one abstract configuration. We now show that the 3-valued semantics of the MTS α join (F) is designed to be sound in the sense that it preserves both satisfaction (tt) and refutation (ff) of a formula from the abstract model to the concrete one. However, if the truth value of a formula in the abstract model is ⊥, then its value over the concrete model is not known. We prove (see Appendix B):

Theorem 1 (Preservation results).
For every Φ ∈ CT L, we have: Divide-and-conquer strategy. The problem of evaluating [F |= Φ] can be reduced to a number of smaller problems by partitioning the configuration space K.
for some 1 ≤ j ≤ n. By using Theorem 1, we obtain the following result.
Example 3. Recall the FTS VendMach of Fig. 1. Figure 3 shows the MTS α join (VendMach), where the allowed (may) part of the behavior includes the transitions that are associated with the optional features c and f in Vend-Mach, and the required (must) part includes transitions with the presence condition true. Consider the properties introduced in Example 2. We have

Game-based Abstract Lifted Model Checking
The 3-valued model checking game [23,24] where AE ranges over both A and E. The expansion exp(Φ) is defined as: The moves (6) − (9) are deterministic, thus any player can make them.
A play is a maximal play iff it is infinite or ends in a terminal configuration. A play is infinite [25] iff there is exactly one subformula of the form AU, AV, EU, or EV that occurs infinitely often in the play. Such a subformula is called a witness. We have the following winning criteria: A strategy is a set of rules for a player, telling the player which move to choose in the current configuration. A winning strategy from (s, Φ) is a set of rules allowing the player to win every play that starts at (s, Φ) if he plays by the rules. It was shown in [23,24] that the model checking problem of evaluating [M, s |= 3 Φ] can be reduced to the problem of finding which player has a winning strategy from (s, Φ) (i.e. to solving the given 3-valued model checking game).
The algorithm proposed in [23,24] for solving the given 3-valued model checking game consists of two parts. First, it constructs a game-graph, then it runs an algorithm for coloring the game-graph. The game-graph is G M×Φ = (N, E) where N ⊆ S × sub(Φ) is the set of nodes and E ⊆ N × N is the set of edges. N contains a node for each configuration that was reached during the construction of the game-graph that starts from initial configurations I ×{Φ} in a BFS manner, and E contains an edge for each possible move that was applied. The nodes of the game-graph can be classified as: terminal nodes, ∧-nodes, ∨-nodes, Anodes, and E -nodes. Similarly, the edges can be classified as: progress edges, which originate in A or E nodes and reflect real transitions of the MTS M, and auxiliary nodes, which are all other edges. We distinguish two types of progress edges, two types of children, and two types of SCCs (Strongly Connected Components). Must-edges (may-edges) are edges based on must-transitions (maytransitions) of MTSs. A node n is a must-child (may-child) of the node n if there exists a must-edge (may-edge) (n, n ). A must-SCC (may-SCC ) is an SCC in which all progress edges are must-edges (may-edges).
The game-graph is partitioned into its may-Maximal SCCs (may-MSCCs), denoted Q i 's. This partition induces a partial order ≤ on the Q i 's, such that edges go out of a set Q i only to itself or to a smaller set Q j . The partial order is extended to a total order ≤ arbitrarily. The coloring algorithm processes the Q i 's according to ≤, bottom-up. Let Q i be the smallest set that is not fully colored. The nodes of Q i are colored in two phases, as follows. Phase 1. Apply these rules to all nodes in Q i until none of them is applicable.
-A terminal node C is colored: by T if Player ∃ wins in it (when C = (s, true) or C = (s, a) with a ∈ L(s) or C = (s, ¬a) with a ∈ L(s)); and by F if Player ∀ wins in it (when C = (s, false) or C = (s, a) with a ∈ L(s) or C = (s, ¬a) with a ∈ L(s)). -An A node is colored: by T if all its may-children are colored by T ; by F if it has a must-child colored by F ; by ? if all its must-children are colored by T or ?, and it has a may-child colored by F or ?. -An E node is colored: by T if it has a must-child colored by T ; by F if all its may-children are colored by F ; by ? if it has a may-child colored by T or ?, and all its must-children are colored by F or ?.

-An ∧-node (∨-node) is colored: by T (F ) if both its children are colored by T (F ); by F (T ) if it has a child that is colored by F (T ); by ? if it has a child colored by ? and the other child is colored by ? or T (F ).
Phase 2. If after propagation of the rules of Phase 1, there are still nodes in Q i that remain uncolored, then Q i must be a non-trivial may-MSCC that has exactly one witness. We consider two cases.
Case U. The witness is of the form A(Φ 1 UΦ 2 ) or E(Φ 1 UΦ 2 ). Phase 2a. Repeatedly color by ? each node in Q i that satisfies one of the following conditions, until there is no change: (1) An A node that all its must-children are colored by T or ?; (2) An E node that has a may-child colored by T or ?; (3) An ∧ node that both its children are colored T or ?; (4) An ∨ node that has a child colored by T or ?. In fact, each node for which the F option is no longer possible according to the rules of Phase 1 is colored by ?. Phase 2b. Color the remaining nodes in Q i by F . Case V. The witness is of the form A(Φ 1 VΦ 2 ) or E(Φ 1 VΦ 2 ).
Phase 2a. Repeatedly color by ? each node in Q i that satisfies one of the following conditions, until there is no change.
(1) An A node that has a may-child colored by F or ?; (2) An E node that all its must-children are colored by F or ?; (3) An ∧ node that has a child colored F or ?; (4) An ∨ node that both its children are colored F or ?. In fact, each node for which the T option is no longer possible according to the rules of Phase 1 is colored by ?.  Example 4. The colored game-graph for the MTS α join (VendMach) and Φ 1 = A(¬rUr) is shown in Fig. 4. Green, red (with dashed borders), and white nodes denote nodes colored by T , F , and ?, respectively. The partitions from Q 1 to Q 6 consist of a single node shown in Fig. 4, while Q 7 contains all the other nodes. The initial node (s 0 , Φ 1 ) is colored by ?, so we obtain an indefinite answer.

Incremental Refinement Framework
Given an FTS π K (F) with a configuration set K ⊆ K, we show how to exploit the game-graph of the abstract MTS M = α join (π K (F)) in order to do refinement in case that the model checking resulted in an indefinite answer. The refinement consists of two parts. First, we use the information gained by the coloring algorithm of G M×Φ in order to split the single abstract configuration true ∈ Algorithm. Verify(F, K, Φ)  α join (K ) that represents the whole concrete configuration set K . We then construct the refined abstract models, using the refined abstract configurations.
There are a failure node and a failure reason associated with an indefinite answer. The goal in the refinement is to find and eliminate at least one of the failure reasons.

Definition 5.
A node n is a failure node if it is colored by ?, whereas none of its children was colored by ? at the time n got colored by the coloring algorithm.
Such failure node can be seen as the point where the loss of information occurred, so we can use it in the refinement step to change the final model checking result.

Lemma 1 ([23]).
A failure node is one of the following.

-An A -node (E -node) that has a may-child colored by F (T ). -An A -node (E -node) that was colored during Phase 2a based on an AU
(AV) witness, and has a may-child colored by ?.
Given a failure node n = (s, Φ), suppose that its may-child is n = (s , Φ 1 ) as identified in Lemma 1. Then the may-edge from n to n is considered as the failure reason. Since the failure reason is a may-transition in the abstract MTS α join (π K (F)), it needs to be refined in order to result either in a must transition or no transition at all. Let s α/ψ − − →s be the transition in the concrete model π K (F) corresponding to the above (failure) may-transition. We split the configuration space K into [[ψ]] and [[¬ψ]] subsets, and we partition π K (F) in π [[ψ]]∩K (F) and π [[¬ψ]]∩K (F). Then, we repeat the verification process based on abstract models α join (π [[ψ]]∩K (F)) and α join (π [[¬ψ]]∩K (F)). Note that, in the former, α join (π [[ψ]]∩K (F)), s α − →s becomes a must-transition, while in the latter, α join (π [[¬ψ]]∩K (F)), s α − →s is removed. The complete refinement procedure is shown in Fig. 5. We prove that (see Appendix B): The game-based model checking algorithm provides us with a convenient framework to use results from previous iterations and avoid unnecessary calculations. At the end of the i-th iteration of abstraction-refinement, we remember those nodes that were colored by definite colors. Let D denote the set of such nodes. Let χ D : D → {T, F } be the coloring function that maps each node in D to its definite color. The incremental approach uses this information both in the construction of the game-graph and its coloring. During the construction of a new refined game-graph performed in a BFS manner in the next i + 1-th iteration, we prune the game-graph in nodes that are from D. When a node n ∈ D is encountered, we add n to the game-graph and do not continue to construct the game-graph from n onwards. That is, n ∈ D is considered as terminal node and colored by its previous color. As a result of this pruning, only the reachable sub-graph that was previously colored by ? is refined. Example 6. The property Φ 1 holds for π [[¬c]] (VendMach). We show the model α join (π [[¬c]] (VendMach)) and the game-graph G α join (π [[¬c]] (VendMach))×Φ1 in Fig. 11 and Fig. 13 (see Appendix C), where the initial node is colored by T . On the other hand, we obtain an indefinite answer for π [[c]] (VendMach). The model α join (π [[c]] (VendMach)) is shown in Fig. 7, whereas the final colored game-graph G α join (π [[c]] (VendMach))×Φ1 is given in Fig. 6. The failure node is (s 0 , A A(¬rUr)), and the reason is the may-edge (s 0 , A A(¬rUr)) → (s 1 , A(¬rUr)).   Fig. 8  The graph G α join (π [[c∧¬f ]] (VendMach))×Φ1 is shown in Fig. 16 (see Appendix C), where the initial node is colored by F in Phase 2b. G α join (π [[c∧f ]] (VendMach))×Φ1 is shown in Fig. 17 (see Appendix C), where the initial node is colored by T .
In the end, we conclude that Φ 1 is satisfied by the variants {¬c ∧ ¬f , ¬c ∧ f , c ∧ f }, and Φ is violated by the variant {c ∧ ¬f }.
On the other hand, we need two iterations to conclude that Φ 2 = E(¬rUr) is satisfied by all variants in K VM (see Appendix D for details).

Evaluation
To evaluate our approach, we use a synthetic example to demonstrate specific characteristics of our approach, and the Elevator model which is often used as benchmark in SPL community [22,4,15,12,19]. We compare (1) our abstractionrefinement procedure Verify with the game-based model checking algorithm implemented in Java from scratch vs. (2) family-based version of the NuSMVmodel checker, denoted fNuSMV, which implements the standard lifted model checking algorithm [5]. For each experiment, we measure T(ime) to perform an analysis task, and Call which is the number of times an approach calls the model checking engine. All experiments were executed on a 64-bit Intel Core T M i5-3337U CPU running at 1.80 GHz with 8 GB memory. All experimental data is available from: https://aleksdimovski.github.io/automatic-ctl.html.
Synthetic example. The FTS M n (where n > 0) consists of n features A 1 , . . . , A n and an integer data variable x, such that the set AP consists of all evaluations of x which assign nonnegative integer values to x. The set of valid configurations is K n = 2 {A1,...,An} . M n has a tree-like structure, where in the root is the initial state with x = 0. In each level k (k ≥ 1), there are two states that can be reached with two transitions leading from a state from a previous level. One transition is allowable for variants with the feature A k enabled, so that in the target state the variable's value is x + 2 k−1 where x is its value in the source state, whereas the other transition is allowable for variants with A k disabled, so that the value of x does not change. For example, M 2 is shown in Fig. 8  We consider two properties: Φ = A(true U(x ≥ 0)) and Φ = A(true U(x ≥ 1)). The property Φ is satisfied by all variants in K, whereas Φ is violated only by one configuration ¬A 1 ∧ . . . ∧ ¬A n (where all features are disabled). We have verified M n against Φ and Φ using fNuSMV(e.g. see fNuSMVmodels for M 1 and M 2 in Fig. 23, Appendix E). We have also checked M n using our Verify procedure. For Φ, Verify terminates in one iteration since α join (M n ) satisfies Φ (see G α join (M1)×Φ in Fig. 24, Appendix E). For Φ , Verify needs n + 1 iterations. First, an indefinite result is reported for α join (M n ) (e.g. see G α join (M1)×Φ in Fig. 27, Appendix E), and the configuration space is split into [[¬A 1 ]] and [[A 1 ]] subsets. The refinement procedure proceeds in this way until we obtain definite results for all variants. The performance results are shown in Fig. 9. Notice that, fNuSMV reports all results in only one iteration. As n grows, Verify becomes faster than fNuSMV. For n = 11 (for which |K| = 2 11 ), fNuSMV timeouts after 2 hours. On the other hand, Verify is feasible even for large values of n.
Elevator. We have experimented with the Elevator model with four floors, designed by Plath and Ryan [22]. It contains about 300 LOC of fNuSMV code and 9 independent optional features that modify the basic behaviour of the elevator, thus yielding 2 9 = 512 variants. To use our Verify procedure, we have manually translated the fNuSMV model into an FTS and then we have called Verify on it. The basic Elevator system consists of a single lift that travels between four floors. There are four platform buttons and a single lift, which declares variables f loor, door, direction, and a further four cabin buttons. The lift will always serve all requests in its current direction before it stops and changes direction. When serving a floor, the lift door opens and closes again. We consider three properties "Φ 1 = E(tt U(f loor = 1 ∧ idle ∧ door = closed))", The performance results are shown in Fig. 10. The properties Φ 1 and Φ 2 are satisfied by all variants, but Verify achieves speed-ups of 28 times for Φ 1 and 2.7 times for Φ 2 compared to the fNuSMV approach. fNuSMV takes 1.76 sec to check Φ 3 , whereas Verify ends in 0.67 sec thus giving 2.6 times performance speed-up.

Related Work and Conclusion
There are different formalisms for representing variability models [20,2]. Classen et al. [4] present Featured Transition Systems (FTSs), which are today widely accepted as the model essentially sufficient for most purposes of lifted model checking. They show how specifically designed lifted model checking algorithms [7,5] can be used for verifying FTSs against LTL and CTL properties. The variability abstractions that preserve LTL are introduced in [14,15,16], and subsequently automatic abstraction refinement procedures [8,17] for lifted model checking of LTL are proposed, by using Craig interpolation to define the refinement. The variability abstractions that preserve the full CTL are introduced in [12], but they are constructed manually and no notion of refinement is defined there. In this paper, we define an automatic abstraction refinement procedure for lifted model checking of full CTL by using games to define the refinement. To the best of our knowledge, this is the first such procedure in lifted model checking.
One of the earliest attempts for using games for CTL model checking has been proposed by Stirling [25]. Shoham and Grumberg [23,24,18,3] have extended this game-based approach for CTL over 3-valued semantics. In this work, we exploit and apply the game-based approach in a completely new direction, for automatic CTL verification of variability models. Thus, we view our work as establishing a brand new connection between games and SPL communities. We hope that further interesting interplay will be possible.
The works [11,13] present an approach for software lifted model checking of #ifdef-based program families using symbolic game semantics models [10].

Conclusion
To conclude, in this work we present a game-based lifted model checking for abstract variability models with respect to the full CTL. We also suggest an automatic refinement procedure, in case the model checking result is indefinite.

A Standard CTL Semantics
We formalize the standard CTL semantics over a TS T . We write [[T ]] s T S for the set of executions that start in the state s; and ρ i = s i to denote the i-th state of the execution ρ = s 0 λ 1 s 1 . . ..
Satisfaction of a state formula Φ in a state s of a TS T , denoted [T , s |= Φ], is defined as: Satisfaction of a path formula φ for an (infinite) execution ρ = s 0 λ 1 s 1 . . . of a TS T , denoted [T , ρ |= φ], is defined as: Satisfaction of a path formula φ for a may-or must-execution ρ = s 0 λ 1 s 1 λ 2 . . . of an MTS M, denoted [M, ρ |= 3 φ], is defined as: Theorem 3. The procedure Verify(F, K, Φ) terminates and is correct.

Proof (Theorem 3).
At the end of an iteration, the procedure Verify(F, K, Φ) either terminates with answers 'tt' or 'ff ', or an indefinite result is returned. In the latter case, let ψ be the feature expression guarding the transition in F that is found as the reason for failure. This (failure) transition occurs as a may-transition in α join (F). We generate F 1 = π [[ψ]] (F) and K 1 = K ∩ [[ψ]], as well as F 2 = π [[¬ψ]] (F) and K 2 = K ∩ [[¬ψ]]. In the next iteration, we call Verify(F 1 , K 1 , Φ) and Verify(F 2 , K 2 , Φ). We have that K 1 ⊆ K, K 2 ⊆ K, and α join (F 1 ) contains the (failure) may-transition as a must-transition, while α join (F 2 ) does not contain the (failure) may-transition at all. In this way, we have eliminated the reason for failure in the previous iteration, since only maytransitions can be failure reasons according to Lemma 1. Given that the number of possible updates of the configuration space and the number of may-transitions in abstract models are finite, the number of iterations is also finite.
If the procedure Verify(π K (F), K , Φ) terminates with answer 'tt' that a property is satisfied (resp., 'ff ' that a property is violated) for the variants k ∈ K , then the answer is correct by Theorem 1, case (1) (resp., case (2)).