Real-time-aware reconfiguration decisions for dynamic software product lines

Dynamic Software Product Lines (DSPL) have recently shown promising potentials as integrated engineering methodology for (self-)adaptive software systems. Based on the software-configuration principles of software product lines, DSPL additionally foster reconfiguration capabilities to continuously adapt software products to ever-changing environmental contexts. However, in most recent works concerned with finding near-optimal reconfiguration decisions, real-time aspects of reconfiguration processes are usually out of scope. In this paper, we present a model-based methodology for specifying and automatically analyzing real-time constraints of reconfiguration decisions in a feature-oriented and compositional way. Those real-time aware DSPL specifications are internally translated into timed automata, a well-founded formalism for real-time behaviors. This representation allows for formally reasoning about consistency and worst-case/best-case execution-time behaviors of sequences of reconfiguration decisions. The technique is implemented in a prototype tool and experimentally evaluated with respect to a set of case studies1.


INTRODUCTION
Background and Motivation. Dynamic software product lines (DSPL) [12] constitute an emerging methodology for developing dynamically (re-)configurable software. To this end, DSPL enhance the well-known principles of software product line engineering (SPLE) [22] by additionally facilitating (1) flexible binding times for configuration options and (2) repeatedly reconfigurable configuration decisions of those options, even at run-time. In this way, DSPL support systematic development of software products which are able to continuously (self-)adapt themselves to ever-changing environmental contexts in a presumably optimal manner [12].
In the recent past, many promising DSPL engineering techniques have been proposed to support users and/or management/planning components in making suitable reconfiguration decisions [17,20,26]. Those approaches are mostly concerned with selecting from a set of possible next configurations those having presumably optimal non-/functional product properties (e.g., by considering available past-and/or predictable future context information). In contrast, the computational overhead and other (non-)functional characteristics potentially caused by selecting-and finally performing-such reconfigurations are usually either abstracted away or entirely of out scope in most recent works. In particular, real-time properties of the resulting reconfiguration processes might become particularly relevant and even safety-or mission-critical, depending on the application domain under consideration. These properties may include concerns like the following.
• What is the minimum/maximum time to switch on/off particular features when performing a reconfiguration? • What is the minimum/maximum time a reconfigurable system is allowed to use a particular set of features? • What is the minimum/maximum time the system is allowed to deactivate a particular set of features?
Such real-time reconfiguration constraints impose entirely novel analysis problems during DSPL engineering, including real-time aware consistency checks and optimization goals for reconfiguration choices (e.g., finding the fastest possible reconfiguration to satisfy newly emerging contextual requirements).
Problem Statement. In order to tackle these issues, an integrated DSPL engineering methodology has to be enhanced, accordingly, in order to properly address the following problem statements.
• How to express real-time constraints for DSPL reconfiguration decisions in a concise and feature-oriented way? • How to automatically analyze such models w.r.t. crucial consistency properties?
Contributions. In this paper, we propose a model-based approach for formally specifying and automatically analyzing real-time constraints of reconfiguration decisions for reconfigurable (self-)adaptive systems developed as DSPL. Our textual specification language is feature-oriented and enables developers to express different kinds of real-time requirements for DSPL reconfiguration processes in an expressive, yet graspable way. The resulting real-time aware DSPL specifications are internally translated into timed automata (TA) [2], a well-founded formalism for modeling and analyzing real-time behaviors. This representation facilitates automated reasoning about consistency properties expressed in a restricted form of TCTL (timed computational tree logics) [1] as well as real-time aware reconfiguration decisions. We implemented our technique in a prototype tool utilizing the Uppaal tool [7] for TA modeling and TCTL analysis and we experimentally evaluated the applicability of our approach with respect to a set of community case studies.
To summarize, this paper makes the following contributions.
• Modeling Language. We combine feature diagrams [15] with a feature-oriented textual language for concisely expressing real-time reconfiguration constraints for DSPL. • Automated Analysis. We devise a compositional transformation schema for translating such DSPL specifications into a semantically equivalent timed automata model. This model enables precise analyzes of those specifications by employing the rich theory and mature tool support of timed automata. • Tool Support. We provide tool support for our technique based on FeatureIDE [28] for feature modeling and the Uppaal tool for timed-automata analyses. • Experimental Evaluation. We present experimental evaluation results gained from applying our tool to a collection of community case studies, manually enriched by real-time reconfiguration constraints.
Verifiability. To make our results reproducible, we provide the tool implementation and all experimental results as well as raw data on a supplementary web page 2 .

BACKGROUND
In this section, we introduce an illustrative example used throughout this paper to motivate and describe our concepts.  Illustrative Example: Train Controller. We consider a simplified train controller which operates the traffic of multiple trains on a shared track. A sample scenario is depicted in Figure 1 consisting of two trains on the same track and a central control station (CCS). Different types of communication links can be used to exchange status information between trains and the CCS, for instance: • WAP (Wayside Access Points), a proprietary communication network operated by the railroad company, • LTE (i.e., ordinary cellular network), and • ad-hoc mode for directly relaying messages between trains being located nearby. The selection of-or reconfiguration between-suitable communication links depends on the environmental situation (e.g., LTE is not available inside tunnels) such that the train controller can be seen as a (self-)adapting (software) system. In the following, we use this example to illustrate the basic principles of DSPL engineering.
Feature Models. To model the configuration options of the scenario in Figure 1, we employ feature models (FM), a well-known formalism frequently used in software product line (SPL) engineering [4]. Each feature corresponds to a binary (Boolean) configuration option which is either selected or deselected in a product configuration such that the overall set of features tailors the configuration space of a configurable system. An FM additionally defines constraints among feature thus further refining the configuration space to only contain valid configurations satisfying all given constraints. A common graphical representation of FM is a feature diagram [15] using FODA notation constituting a tree-like structure with nodes referring to features and edges denoting different kinds of configuration constraints. Figure 2 shows the feature diagram for configuring one particular train in our running example. Here, node Train is the mandatory root feature, having four child features. Child features can be only selected in a configuration if the parent feature is also selected. Conversely, the dependency between a parent feature and its child features can be one of the following four possible types, as also illustrated in our example.
• Feature Speed is mandatory (black-filled circle). Hence, selection of Train implies selection of Speed. • Features Link, Inside Tunnel and Train Nearby are optional (white-filled circle). These features can be, but do not have to be, selected in case their parent is selected. • The or-group (black-filled arc) below feature Link denotes that at least one child from that group must be selected if the parent is selected. • The alternative-group (white-filled arc) below feature Speed denotes that exactly one child from that group (i.e., Fast, Slow or Halt) must be selected if the parent is selected.
Further dependencies can be expressed by cross-tree edges such as require-edges (e.g., Ad Hoc only works for Train Nearby) and exclude-edges (i.e., LTE does not work Inside Tunnels).
DSPL. In case of statically configurable software product lines, a configuration (i.e., a feature selection for a desired software product) is chosen by a customer or user once and for all time, usually before going operational for the first time. In contrast, in case of a dynamic SPL such as the train controller, the (software) product must be prepared to be reconfigurable (i.e., to switch between configurations), even at run-time. Such reconfigurations might be caused by contextual changes of the running system (e.g., a train using LTE reaches a Tunnel). In the feature diagram in Fig. 2, we explicitly model contextual situations by means of contextual features being located in the right sub-tree of the feature tree [13]. In this way, we can use cross-tree constraints between those contextual features and proper system features located in the left sub-tree to specify all candidate (re-)configurations potentially satisfying a contextual change (e.g., switching from LTE to Ad Hoc or WAP). By further adding information about (non-)functional properties of the different possible configurations (e.g., latency of communication links), those models can be used for preplanning (presumably optimal) reconfiguration strategies for all kinds of possible contextual switches. To this end, we translate DSPL specifications into timed automata (TA) [2], denoting state-transition graphs enriched by real-time behavior (see Section 4). This enables us to automatically analyze consistency properties for DSPL specifications expressible as TCTL expression [1] using off-the-shelf model checkers for TA such as Uppaal (see Section 4).
Problem Statements. The actual computational effort caused by performing such reconfigurations at run-time (e.g., in terms of permitted CPU time or communication latency) is often out of scope. However, this may cause serious or even fatal problems (e.g., missing a hard communication deadline) in case of critical application domains as considered in our example. This observation leads us to our problem statements, P1-P3, as follows.
• P1: Reconfiguration decisions may require different amounts of setup times, depending on the current configuration and the features involved. • P2: The minimum/maximum time a system is allowed to reside in a configuration and/or to progress to another configuration may be restricted, depending on the current configuration and the features involved.
• P3: Different real-time constraints may influence or even conflict with each other, depending on the current configuration and the features involved.
We now propose an integrated approach tackling these problems.

MODELING REAL-TIME RECONFIGURATION CONSTRAINTS
In this section, we formally introduce our constraint language for expressing real-time requirements for reconfiguration behavior of DSPL as described in the previous section. The proposed language is declarative and feature-oriented, by employing feature constraints in terms of propositional formulae over Boolean features variables to denote sets of configurations affected by constraint in a compact way. As an example, the feature constraint We will omit abstract features (represented by a lighter shade of blue in feature diagrams) in our set-based notation of configurations for convenience and define feature constraints as follows.
Definition 3.1 (Feature Constraint). Let be a set of feature names and ∈ . A feature constraint over is inductively defined as In particular, for every feature model fm over a set of feature names, a semantically equivalent feature constraint fm over a set of Boolean variables can be constructed which exactly denotes the set of valid configurations of fm [5]. Hence, we will omit the graphical representation of a feature model and refer to fm in the following. Moreover, by ⟦ ⟧ ⊆ 2 we denote the set of all valid configurations, containing those subsets ∈ ⟦ ⟧ of features of set satisfying feature constraint . In this regard, ⟦ fm ⟧ denotes the set of all valid configurations w.r.t. a feature model fm.
Next, we use feature constraints to express real-time reconfigurations constraints. To this end, we combine two feature constraints 1 and 2 as [ 1 → 2 ] to denote a reconfiguration constraint which holds for all reconfiguration steps leading from configuration ∈ ⟦ 1 ⟧ to a subsequent configuration ′ ∈ ⟦ 2 ⟧. As an example, [ → ] denotes a reconfiguration constraint (see below) which holds for all reconfiguration steps leading from an active configuration containing feature Fast to a subsequent configuration containing feature Halt. As reconfiguration constraint , we consider four basic types of real-time requirements which are each represented using a predefined keyword in our language.
• Keyword setup expresses that the execution of a reconfiguration step requires a certain amount of time (e.g., the reconfiguration from Fast to Slow takes at least 45 seconds). • Keyword reside expresses the time a configuration is allowed to stay active (e.g., a configuration with Fast is only permitted for 30 minutes). • Keyword progress expresses that a reconfiguration has to be executed within a certain period of time (e.g., if feature Link is not contained in a current configuration, then feature Halt must be activated after at most 30 seconds).
• Boolean literal false can be used to forbid a reconfiguration step (e.g., a reconfiguration leading from Fast directly to Halt is not allowed). We define real-time requirements as follows.
Definition 3.2 (Real-Time Requirement). A real-time requirement is defined by the following grammar: We restrict real-time requirements to contain bounds ∈ N, as real-valued bounds would obstruct fundamental decidability properties of timed automata (see below). By combining feature constraints (e.g., [Fast → Slow]) and real-time requirements (e.g., setup ≥ 45), we are now able to address problem statements P1 and P2 by means of real-time reconfiguration constraints. For instance, a minimum time required for decelerating a train is expressed as: This constraint requires every reconfiguration step from a current configuration ∈ ⟦Fast⟧ to a subsequent configuration ′ ∈ ⟦Slow⟧ to take at least 45 time units (e.g., seconds).
We combine the previously described concepts to define realtime reconfiguration constraints as follows.

Definition 3.3 (Real-Time Reconfiguration Constraint).
Let fm be an FM over feature set . A real-time reconfiguration constraint is defined by the following grammar: where is a real-time requirement and , ′ are feature constraints over such that ⟦ ⟧ ∩ ⟦ ′ ⟧ = ∅ holds.
We think that it is reasonable to require ⟦ ⟧ and ⟦ ′ ⟧ to be disjoint as, otherwise, evaluation semantics of constraints regarding configurations ∈ (⟦ ⟧ ∩ ⟦ ′ ⟧) may be undefined. As an example, consider the constraint Here, a reconfiguration from = {InsideTunnel, WAP, Slow} to ′ = {InsideTunnel, WAP, Fast} would be affected by the constraint as ∈ ⟦InsideTunnel⟧ and ′ ∈ ⟦WAP⟧. This seems counterintuitive as the features InsideTunnel and WAP are actually not reconfigured. Nonetheless, would lead to a different behavior of this reconfiguration. Therefore, we explicitly exclude constraints with overlapping sets of source and target configurations. We call the proposed language real-time reconfiguration constraint language (RRCL) and assume a DSPL specification to consist of a feature model and a set of RRCL constraints in the following. In the next section, we tackle P3 by proposing a technique for automatically analyzing consistency of such a DSPL specification.

ANALYZING REAL-TIME RECONFIGURATION CONSTRAINTS
Our concept for tackling P3 is based on reconfiguration automata (RA) [23]. The set of states of RA correspond to the set of valid configurations of the DSPL under consideration and the set of edges between states represent permitted reconfiguration steps. In this basic DSPL model, reconfiguration steps require zero time. In order to enrich RA by real-time reconfiguration behaviors, we employ the theory of timed automata (TA) [2].
Basic Notions of TA. Let us again consider our running example. For the sake of readability, we consider as our FM only the alternative-group of feature Speed in Figure 2. Thus, we have comprising three valid configurations. A TA modeling the realtime reconfiguration behavior of this simplified example is depicted in Figure 3, referred to TA in the following. Like in reconfiguration automata, each valid configuration ∈ ⟦ fm ⟧ is, again, represented by a state which is, however, called location in TA. Consequently, we will use the terms configuration and location interchangeably in the context of TA . Furthermore, as initial location, we assume {Fast} (depicted by the arrow below the location). Each possible reconfiguration is represented by a corresponding edge (called switch in TA) being labeled with an action ∈ Σ. Here, we have Σ = {fast, slow, halt}, simply denoting the target location (i.e., target configuration) of the reconfiguration related to the switch. This sample TA actually permits all possible reconfigurations between any pair of valid configurations.
By using TA as reconfiguration model, we can express real-time constraints for single reconfiguration steps as well as entire reconfiguration sequences. To this end, TA models are equipped with a set of clocks , acting as continuously and synchronously increasing, yet independently resettable numerical variables over clock domain T C (e.g., T C = R + ). A clock ∈ can be used to measure the time elapsed since the last reset of that clock. Thereupon, clock constraints restrict time behavior in sequences of action occurrences to denote valid timed runs. For example, consider TA in Figure 4 in which clock is used in two ways.
• The clock reset → 0 performed by the switch from location Fast to AfterReset sets the value of back to 0. • The guard [ > 45] attached to the right switch from location AfterReset to ¬Fast denotes that this switch can only be taken if the value of clock is greater than 45. In addition to switch guards, clock constraints can be also attached to locations to denote invariants which must hold while residing in that location during a timed run. For instance, the invariant < of the upper right location ′ in Figure 7 only allows runs to reside in this location while the value of clock is less than . Further note that TA also contains a special action symbol denoting internal actions (see below), where we write Σ = Σ ∪ { }. To sum up, we formally define a TA according to [2].
Furthermore, we use the notation ℓ , , ℓ ′ to denote that (ℓ, , , , ℓ ′ ) ∈→ holds. Next, we describe a translation of a DSPL specification as introduced in Sect. 3 into an equivalent TA model.
Translating RRCL constraints into TA. Similar to reconfiguration automata, we represent the set of configurations of a DSPL as locations in TA . We refer to the resulting TA as core DSPL reconfiguration model, initially permitting all possible (re-)configurations without any real-time restrictions. Thereupon, we refine the core model to only allow the reconfiguration behavior specified by the set of RRCL constraints. At first sight, a straight-forward solution appears to be to simply enrich the core model by further clock constraints. However, this approach turns out to become overcomplicated and non-compositional in case of multiple, potentially interdependent RRCL constraints. Instead, we construct for each RRCL constraint a separate TA model TA running in parallel to the core model and interacting via synchronization actions in order to restrict the reconfiguration behavior as requested by . To this end, we employ parallel composition [30] of TA models.
Parallel Composition of TA. Under parallel composition, a pair of TA synchronizes their behavior via shared actions. For example, assume TA and TA both reside in their initial location (i.e., {Fast} and Fast). If TA executes the switch labeled with halt, then TA must also fire its switch labeled with the same action such that both TA synchronously enter the target locations, {Halt} and ¬Fast, respectively. In contrast, executions of switches labeled with (e.g., from Fast to AfterReset in TA ) do not require any synchronization thus enabling one TA to proceed to another location independently of the TA running in parallel. Based on the notion of composition, we can model each RRCL constraint in a separate TA synchronizing with the core model TA , which facilitates a compositional construction method. We next describe construction schemas for the different kinds of RRCL constraint in more detail.
Construction Schema for Setup-Constraints. Let us consider the setup-constraint supposed to affect the switch {Fast} slow {Slow} in the core model TA . This reconfiguration step should take at least 45 seconds. To enforce , we construct TA as shown in Figure 4 with location Fast being the initial location. As a consequence, if TA and TA reside in their initial locations, a reconfiguration to {Slow} is not possible. The disabling of the respective switch in TA is achieved by TA not providing action slow in its initial location Fast. In contrast, after executing the -labeled switch to AfterReset, TA is able to permit TA to execute a slow-labeled switch as soon as the guard [ > 45] is satisfied. In this way, TA influences the reconfiguration behavior of TA in a way that satisfies constraint . This construction schema can be generalized to all kinds of setupconstraints of the form: Index is attached to to identify the corresponding RRCL constraint. Based on , we explain how TA is constructed in  ⟦ fm ⟧) is partitioned into three subsets by : The first subset contains configurations that either satisfy , ′ or neither of both (i.e., ∈ ⟦¬ ∧ ¬ ′ ⟧). A dashed rectangle in Figure 5 does not correspond to one single location of TA but rather to a set of locations (i.e., dashed rectangles depict abstract locations). The same applies to arrows: an arrow from ⟦ ⟧ to ⟦ ′ ⟧ denotes that TA contains a switch between all locations of the respective sets: Each switch is annotated with action ( i , ′ i or not i ) for synchronization with TA , see Figure 6. This TA looks similar to that in Figure 4 except for the names of locations and actions which are supposed to reflect the feature constraints and ′ of . For instance, in both TA and TA every switch leading to a location associated with is annotated with action i . The names of locations in TA depict feature constraints corresponding to the current configuration (i.e., location) of TA . For instance, assume TA to reside in location ¬ . Our construction schema ensures that TA is either in ⟦¬ ∧ ¬ ′ ⟧ or ⟦ ′ ⟧ as all these configurations satisfy ¬ . A reconfiguration from one of their locations to ⟦ ⟧ executes action i . Thus, TA executes the switch from ¬ to to synchronize with TA on i thus restricting the behavior of TA . Next, we present our construction schema for reside-constraints. After the corresponding reconfiguration, the DSPL is allowed to reside in configuration Fast only for at most 1800 seconds (e.g., the train can only drive fast for a maximum of 30 minutes to prevent from overheating). We now consider all kinds of reside-constraints of the form: = [ → ′ ] reside < . Those constraints enforce the DSPL to stay in a configuration ′ ∈ ⟦ ′ ⟧ for up to seconds. However, this is only enforced if ′ has been entered via a preceding configuration ∈ ⟦ ⟧.

After Reset
Next, we describe the respective TA construction schema. First, core model TA ( Figure 5) is enriched by shared actions in the same way as already done for setup. In contrast, the structure of TA now slightly differs as depicted in Figure 7. For example, assume TA to be in location ∈ ⟦ ⟧ and TA in location . If a reconfiguration to ′ ∈ ⟦ ′ ⟧ emerges (which is only possible via action ′ i ), then TA executes the corresponding switch to ′ and resets clock . Here, invariant < ensures to leave the location ′ within the specified amount of time. Furthermore, location ′ of TA can only be left via switches annotated with actions i or not i . Hence, invariant < enforces TA to leave ⟦ ′ ⟧ within the specified amount of time.
Next, we present the construction schema for progress-constraints.
Construction Schema for Progress-Constraints. For instance, consider the progress-constraint which is enforced if the current configuration does not contain feature Link. In this case, the DSPL must reconfigure within 30 We now consider all kinds of progress-constraints of the form: In general, a progress-constraint enforces the DSPL to leave configurations from set ⟦ ⟧ to some configuration satisfying ′ within time units. For this, the DSPL is not allowed to leave ⟦ ⟧ by switching to a configuration ∈ ⟦¬ ∧ ¬ ′ ⟧ to prevent the DSPL from circumventing the intended reconfiguration behavior (e.g., an emergency stop could be circumvented by switching Link continuously on and off).
Next, we describe how to enforce those constraints in TA. Core model TA ( Figure 5) is enriched by synchronization actions in the same way as for setup-and reside-constraints. In TA (see Figure 8), every location is related to exactly one abstract location in Figure 5. Thus, every reconfiguration targeting a configuration ∈ ⟦ ⟧ synchronizes with one of the switches annotated with i of TA . Invariant < of location then ensures that this location has to be left with time units. Furthermore, a reconfiguration to ⟦ ′ ⟧ is guaranteed as location has only one outgoing switch. So far, we described construct schemas TA for every type of constraint individually. Concerning the whole set Ψ of RRCL constraints of a DSPL specification, our construction schemas permit a compositional approach such that the construction of each individual TA , for any ∈ Ψ is independent of the other constraints in Ψ. However, this does not hold for the modifications to be done in TA which will be explained in the following.
Handling Sets of RRCL Constraints. In case of multiple constraints potentially affecting overlapping sets of configurations, TA construction may require switches in TA being labeled with multiple synchronization actions. For instance, the two RRCL constraints both introduce different actions at the switch from {Fast} to {Slow} to adapt their location to a reconfiguration from {Fast} to {Slow} (depicted in Figure 9). Unfortunately, TA do only allow one action-label per switch. To solve this issue, we introduce for different actions affecting the same switch in TA , − 1 intermediate locations as depicted in Figure 10 and 2 ) are executed in some order, but with zero delay in between. This schema emulates multiple TA to synchronize on the same reconfiguration in TA . As a result, every TA is able to either permit or prohibit the corresponding reconfiguration independent from all other TA ′ thus potentially leading to complicated interactions between RRCL constraints.
To summarize, we presented in this section a construction schema of a TA model reflecting the real-time reconfiguration semantics of a DSPL specification consisting of a feature model and a set of RRCL constraints Ψ. Next, we outline the potential semantic interplay of constraints which may yield to inconsistencies in the model. For example, consider the three constraints Furthermore, assume the current configuration to be {Link, LTE, Fast}. If LTE becomes unavailable, both LTE and Link are deselected. In this case, 3 requires the system to select Halt within 60 seconds (i.e., to perform an emergency stop if no communication link is available). However, the combination of 1 and 2 makes it impossible to satisfy 3 as both setup times sum up to 75 seconds for a reconfiguration from ⟦Fast⟧ to ⟦Halt⟧. Thus, the interplay between all three constraints results in an inconsistent DSPL specification. To detect inconsistencies, we describe how the TA representation allows us to verify correctness properties of DSPL specifications in an automated way. To this end, we first recapitulate operational semantics of TA based on Timed Labeled Transition Systems (TLTS) [14].
Operational Semantics of TA. For instance, the TLTS corresponding to the TA depicted in Figure 10 is partially shown in Figure 11. A TLTS consists of states being pairs of a TA location and a valuation for all clocks : → T C (where we write = ( ), for convenience, to denote that clock has value ( )). For example, the initial state of the TLTS consists of location {Fast} and clock valuation = 0. Furthermore, a TLTS has two types of transitions: • Delay transitions represent passage of time while staying in a TA location. For instance, a transition from ⟨{Fast}, = 0⟩ to ⟨{Fast}, = 1⟩ corresponds to the passage of one time unit in location {Fast}. • Action transitions represent execution of actions when taking a switch from one location to another location without any time elapsing. For instance, the transition from ⟨{Fast}, = 1⟩ to ⟨ℓ ′ , = 0⟩ corresponds to the execution of the switch to ℓ ′ which resets clock . To sum up, TLTS semantics of a TA is defined as follows [2].  -⟨ℓ, ⟩ ↠ ⟨ℓ, + ⟩ if ∈ (ℓ) and ( + ) ∈ (ℓ) for ∈ T C , A TLTS of a TA is, in general, not finite but allows us to illustrate operational semantics of TA in an intuitive way. TA analysis tools like the model checker Uppaal [7], however, internally utilize a finite symbolic representation of TA semantics. In particular, Uppaal is able to check properties defined by a query language based on Timed Computation Tree Logic (TCTL) [1]. A query in Uppaal is composed of path formulae and state formulae [6]. The latter ones are used to define predicates over the states of a TLTS. Consequently, a state formula is evaluated over a state of the TLTS yielding either true or false. For instance, consider TA depicted in Figure 4. Here, the state formula = TA _ Psi.Fast is only satisfied in states of the TLTS of TA being related to location Fast (e.g., ⟨{Fast}, x=3⟩). Furthermore, state formulae may also contain operators of propositional logic (e.g., and, or, imply, not). Besides state formulae, path formulae are used to define which paths of the TLTS are relevant for the query. Moreover, path formulae are always related to a property (e.g., a state formula).
We next describe crucial semantic properties of DSPL specifications which we are now able to specify and check by applying TCTL formulae to the TLTS of the constructed TA representation.
Deadlock Freedom. After a sequence of reconfiguration steps, it may happen that eventually a configuration is reached which cannot be left any more (e.g., due to contradicting RRCL constraints, no more reconfiguration is possible). Such a deadlock can be detected by Uppaal with a query of the form: Here, the path formula E<> instructs Uppaal to find a state on an arbitrary path in the TLTS satisfying the corresponding state formula (i.e., deadlock and ...). Thus, the query only yields a negative result if it is impossible to satisfy the state formula. Keyword deadlock is a built-in construct of Uppaal syntax for identifying deadlock states. Furthermore, the disjunction instructs Uppaal to only take into account proper locations in TA and to ignore intermediate locations.

Reachability. A location being unreachable from the initial location in TA
is another indicator for an undesirable inconsistency in DSPL specifications. To detect those locations, the following query can be used in Uppaal: If the query succeeds, then there exists at least one path (E<>) eventually reaching the given location (e.g., TA _ FM.Halt).
Liveness. Finally, liveness of reconfiguration behavior is another crucial property of DSPL specifications. Unfortunately, Uppaal only supports a limited subset of TCTL forbidding nested path formulae as required for more elaborated liveness properties. Hence, we currently limit our considerations to check whether each pair of locations is mutually reachable from each other.
In the following section, we present experimental results gained from applying our TA construction and verification methodology for DSPL analysis to a collection of subject systems.

TOOL IMPLEMENTATION & EVALUATION
In this section, we present a tool implementation of our approach as well as results of an experimental evaluation obtained from applying our tool to a collection of subject systems. The goal of the experiments is (1) to show applicability of the proposed approach as well as (2) to investigative the computational effort required for the different steps of the methodology.
Tool Support. We implemented the methodology in the tool RRCL-Analyzer. Our tool takes a DSPL specification, consisting of an FM in the file format of FeatureIDE and a set of RRCL constraints in a text-based representation, as inputs (see Section 3). Our tool then constructs a set of TA as described in Sect. 4. The generated output is written into an XML file serving as input for the TA tool Uppaal which is executed with respective analysis queries for consistency checking. The execution times required for the overall procedure can be measured and logged, accordingly, to support experimental evaluation. We provide the tool, case studies and experimental results on a supplementary web page 4 .

Research Questions.
• RQ1. What is the computational effort for generating a TA representation from a DSPL specification as compared to the subsequent consistency checks? • RQ2. How does the computational effort for consistency checks depend on the size of the FM? • RQ3. How does the computational effort for consistency checks depend on the number of RRCL constraints?
Methods and Experimental Design. Due to the novelty of the modeling approach, no DSPL case studies with RRCL constraints exist so far. Hence, we used a collection of existing FM models as well as synthetically generated FM and augmented them with RRCL constraints, synthetically generated by a self-written RRCL generator. This allows us to control the sizes of FM for answering RQ2 as well as the number of RRCL constraints for answering RQ3. For answering RQ1, we measured CPU time required for TA generation from the subject systems considered for RQ3. Our 4 https://doi.org/10.5281/zenodo.4038317 RRCL generator samples feature constraints (i.e., and ′ ), constraint type (e.g., setup) and corresponding time intervals from a uniform distribution. For creating feature constraints, we use a publicly available SAT generator 5 . The resulting DSPL specifications (i.e., FM and RRCL constraints) serve as input for our tool which automatically performs the TA construction and calls Uppaal for consistency checks. To keep the overall experimental setting graspable, we limit our considerations to reachability checks. However, the results for checking deadlock freedom and liveness are available on the a supplementary web page.
Subject Systems. We applied RRCL-Analyzer to our running example as well as two further case studies from literature. The first case study, the database system BerkeleyDB [25], has 256 possible valid configurations, as the FM consists of 8 independent features. The second case study, called Heroku [26], represents a cloud scenario, namely a platform-as-a-service environment with 25 features and 720 possible valid configurations. We further enlarge the set of subject systems by 75 synthetically generated models using BeTTy [24], each having at most 256 valid configurations. BeTTy produced 75 FM with 2 up to 246 valid configurations. We additionally augment each FM with different numbers of RRCL constraints (i.e., |Ψ| ∈ {0, 3, 6, 9}). As a result, we gained 308 subject systems by means of DSPL specifications.
Data Collection. For each subject system, we run our tool to first generate the corresponding TA representation. We then apply the checks presented in Section 4 by calling Uppaal. For both steps, we measure the required CPU times. For the first step, this time includes parsing of the DSPL specification up to the output of the XML file. For the seconds step, we measured the time between the startup and termination of Uppaal. We repeated each experimental run three times and took the average value.
Measurement Setup. We executed all experiments on an Intel Core i7-6700k machine with 4x4GHz, 16GB RAM and Linux Mint 19.2. Our tool is implemented in Java (Azul OpenJDK 1.8.0_202). For the consistency checks, we call Uppaal version 4.1.19.

Results and Discussion
We now present experimental results grouped by RQ. RQ1. For all subject systems, we obtained values between 866 ms and 1,218 ms on average for TA generation. RQ2. Measurements for RQ2 regarding reachability analysis are shown in Figure 12. Here, the subject systems (i.e., FMs) are sorted according to the number of valid configurations. The y-axis depicts the measured CPU time in seconds and the black circles represent the average value of three measurements. Note that the reachability check yields positive results for every subject system of RQ2 due to the absence of reconfiguration constraints. RQ3. Measurements for RQ3 regarding reachability analysis are shown similar to Figure 12 in Figure 13. Additionally, we distinguish the results for different |Ψ| ∈ {0, 3, 6, 9} by different symbols. Note that, in contrast to RQ2, reachability checks now yield both positive and negative results: 83 out of 308 subject systems were reported inconsistent (i.e., not every valid configuration is reachable due to contradicting RRCL constraints).
Next, we discuss the results w.r.t. to each RQ separately. RQ1. As a first observation, especially in case of larger FMs (in terms of |⟦ fm ⟧|), the effort for TA generation is negligible as compared to the analyses runs of Uppaal (e.g., 1.2 seconds versus 35 seconds for |⟦ fm ⟧| = 246). Thus, applicability of our approach mostly depends on scalability of the checks in Uppaal. RQ2. The measurements for reachability analysis for all subject systems with |Ψ| = 0 are depicted in Figure 12. As a baseline, we also considered DSPL specifications without any RRCL constraints (|Ψ| = 0). Except for one outlier at |Ψ| = 30, the values seem to adhere an exponential curve. This can be explained by the fact that the number of configurations corresponds to the number of TA locations of TA which is (besides the number of clocks) the major factor influencing the complexity of TA model checking (e.g., reachability checking for TA is PSPACE-hard [2]). RQ3. The measurements for RQ3 regarding reachability analysis are shown in Figure 13 with |Ψ| ∈ {0, 3, 6, 9}. We make the following two observations: (1) if |Ψ| increases, the average runtime of the analysis also increases; (2) if |Ψ| increases, the curve becomes less sharp (i.e., the measured values vary a lot more).
An explanation for (1) may be that each additional TA introduces further locations and clocks thus (potentially) enlarging the state space (cf. RQ2). Observation (2) may be explained by interactions of multiple constraints thus making large parts of the state space unreachable. Consequently, adding RRCL constraints to a DSPL specification may decrease the effort for consistency checking. For instance, consider the CPU times required for the subject systems with |⟦ fm ⟧| = 246 in Figure 13. Here, reachability analysis requires less time for |Ψ| = 9 (red plus signs) than for |Ψ| = 6 (blue squares). However, in the majority of cases, composing further TA increases the state space and, hence, the effort for model checking, too. Finally, note that the curves of the measurements for RQ2 and RQ3 w.r.t. deadlock freedom and liveness are shaped very similar to those in Figure 12 and 13. Only the scales of the y-axis significantly differ, where checking deadlock freedom is, on average, twice as fast as reachability. In contrast, liveness checks require a lot more computational effort as it consists of |⟦ fm ⟧| reachability analyses.

Threats to Validity
An internal threat to validity might arise from the selection of subject systems, as most of the models are synthetically generated. Due to the novelty of our approach, real-world case studies do yet not exist. However, a case study as the one presented in Weckesser et al. [29] could be adapted to evaluate our approach in a future work. Nonetheless, we expect similar results for realworld systems of comparable size (i.e., similar numbers of valid configurations) as the computational effort is mainly caused by this number. Additionally, the increasing CPU time for larger FMs (again, w.r.t. the number of valid configurations) may obstruct applicability of the approach to real-world systems. However, this issue is inherent to model checking approaches in general due to the complexity of the underlying theory (e.g., reachability checking for TA is PSPACE-hard [2]). Exploring methods for state-space reduction may be promising in future work to alleviate this issue. Moreover, not only the number, but also the type and distribution of synthetically generated constraints may significantly influence the computational effort of consistency checks. Nonetheless, generating RRCL constraints based on uniform distributions is a reasonable assumption for our assessment of the presented approach. In future work, further empirical investigations of real-world models may yield more realistic probability distributions for RRCL generation.
A threat to external validity may be the lack of comparison to other approaches. However, the reason for this is the small amount of other approaches related to DSPLs with real-time properties.
A further threat to external validity might arise from the limited expressiveness of our constraint language. We focused the design on easy usage, compositional TA construction and tractability of the consistency checks. For instance, RRCL constraints are restricted to single reconfiguration step, whereas constraints on compound reconfiguration processes are not supported. However, our compositional construction method enables us to extend the approach in various ways (up to fully-fledged TCTL formulae) in future work.

RELATED WORK
We next discuss related work regarding DSPL engineering and modeling of configurable real-time systems.
Lochau et al. [17] propose complex binding-time constraints for DSPL reconfiguration processes [10]. As a result, product (re-)configuration (including Boolean and Non-Boolean features) is modeled as an incremental (staged) process leading to complex interdependencies between features and binding times. For checking temporal consistency properties (e.g., liveness), the DSPL specification is transformed into a state-machine model which is analyzed by utilizing the model checker SPIN. To demonstrate applicability of the approach, the authors present a real-world industrial case study from the automation engineering domain (i.e., a medical device). In contrast to our approach presented in this paper, complex binding-time constraints are concerned with causal dependencies between (re-)configuration steps instead of real-time behavior. Pfannemüller et al. [19,20] present an adaptation logic for planning and executing reconfigurations in self-adaptive systems according to the MAPE-K loop. The knowledge component of the MAPE-K cycle is based on a context feature model. Context information is obtained by a monitoring component (e.g., by collecting sensor values) and encoded into SAT formulae. In case of multiple possible reconfigurations, the planning component estimates the costs (e.g., computational effort) for each reconfiguration and then prioritizes the presumably most efficient one. In contrast to our approach, Pfannemüller et al. neither consider real-time requirements nor use a transition system for reconfiguration processes.
Sousa et al. [26] model DSPL reconfiguration processes with labeled transition systems similar to our approach. The reconfiguration behavior is then further restricted by LTL formulae [21] thus including safety/liveness as well as constraints over arbitrary reconfiguration sequences. In addition, the approach also includes a cost function to prioritize reconfiguration decisions. Moreover, to tackle state-space explosion, the approach avoids explicit construction of the transition system, but rather operates on a symbolic representation in combination with a SAT-solver. In contrast to our model, real-time behavior is not taken into account. However, extending RRCL to (T)CTL and using a symbolic representation of the configuration space is a promising direction for future work.
Luthmann et al. [18] introduce configurable parametric timed automata (CoPTA), a model for configurable real-time behavior of families of product variants super-imposed in a single model. CoPTA models are a combination of featured timed automata (FTA) [9] and parametric timed automata (PTA) [3] and are therefore able to capture infinite configuration spaces. Based on CoPTA models, a family-based as well as a sample-based testing theory for realtime critical configurable software is developed. In contrast to the approach presented in this paper, CoPTA models do neither specify reconfiguration behaviors of DSPL, nor support verification of consistency properties as proposed for RRCL constraints.
Liva et al. [16] propose a method to automatically extract TA from Java methods by identifying time-related method calls (e.g., System.currentTimeMillis()) to define timed semantics for Java statements. Thereupon, Liva et al. utilize Uppaal to perform timedrelated validity checks on the TA model (e.g., safe termination of methods). In contrast to our approach, Liva et al. do neither consider variability, nor reconfiguration behavior.
Ter Beek et al. [27] present the Eclipse-based framework QFLan to model and verify DSPL. The approach includes a DSL for modeling attributed feature models with a process specification (e.g., a state-machine). Furthermore, quantitative constraints (i.e., arithmetic relations on attributes) can be expressed to restrict reconfigurations. The statistical model checker MultiVeStA is employed to analyze quantified properties such as average values of feature attributes. However, Ter Beek et al. do not take real-time properties into account. Nonetheless, using statistical model checking techniques may also speed up our approach (e.g., Uppaal SMC [11]).

CONCLUSION
We presented a novel approach to specify real-time requirements for reconfiguration steps of a DSPL. We translate those featureoriented real-time constraints into TA models in a compositional way, in order to facilitate automated consistency checks (namely deadlock freedom, reachability and liveness) for real-time critical DSPL specifications using Uppaal. The goal of the design of the language was to achieve a suitable trade-off between ease of usage and tractability of analyses on the one hand, and a sufficient level of expressiveness on the other hand. However, due to its compositional nature, extensions to the modeling approach can be easily conducted in future work. As further future work, we plan to speed-up verification using state-space reduction and statistical model checking Uppaal SMC. Additionally, we plan to consider further non-functional properties denoted as costs and probability information for reconfiguration steps to facilitate near-optimal reconfiguration decisions. Moreover, we plan to conduct real-world case studies such as in Weckesser et al. [29] to further evaluate applicability and usability of our approach.

ACKNOWLEDGMENTS
This work has been funded by the German Research Foundation (DFG) as part of project A4 within the Collaborative Research Center (CRC) 1053 MAKI. This work was funded by the Hessian LOEWE initiative within the Software-Factory 4.0 project.