## 2 Preliminaries
A literal \(time(t)\) indicates that \(t\) belongs to \(\mathcal{T}\). A literal \(next(t,t^{\prime})\) states that \(t<t^{\prime}\) are immediately consecutive steps from \(\mathcal{T}\), in the sense that there is no other time step \(t^{\prime\prime}\) such that \(t<t^{\prime\prime}<t^{\prime}\). The set of laws (often called _action description_) that affect the evolution of the state of the domain is represented by means of ASP rules. For example, a _dynamic causal law_ stating that pushing a button \(b\) of a given light bulb \(l\) to light up may be captured by a rule:  
\[h(on(l),T^{\prime})\gets next(T,T^{\prime}),o(push(b),T). \tag{2}\]  
A _state constraint_ stating that, when the light bulb is on, it is also hot, may be captured by a rule:  
\[h(hot(l),T)\gets time(T),h(on(l),T). \tag{3}\]  
The description of the behavior of the system (at least in simple cases) is completed by the inertia axioms [16; 17], which intuitively state that _things tend to stay as they are_. They can be compactly represented in ASP with rules such as  
\[ \begin{array}{l}h(F,T^{\prime})\leftarrow next(T,T^{\prime}),h(F,T),\text{ not }\ h(\
eg F,T^{\prime}).\\ h(\
eg F,T^{\prime})\gets next(T,T^{\prime}),h(\
eg F,T),\text{not }\ h(\
eg F,T^{\prime}).\end{array}  \tag{4}\]  
A thorough discussion on dynamic domains and on their representation in ASP is beyond the scope of this paper. We refer the interested reader to [11] for details. Next, we provide a basic introduction on the support for incremental computations in clingo. Due to the complexity of the topic, we limit the scope of the discussion to only what is strictly necessary for the description of our approach, and refer the interested reader to [6; 7] for a thorough discussion. Additionally, we focus our discussion to the incremental computation facilities provided by clingo 5.4.0, the version of the solver available at the time of the development of our approach. _Incremental ASP programs._ For incremental computations, an ASP program is conceptually partitioned into one or more modules. Each module is identified by a directive of the form:  
\[\#program\ id(par_{1},par_{2},\ldots) \tag{5}\]  
where \(id\) is a unique identifier for the module (in practice, clingo allows for repeated \(\#program\) directives, but all rules labeled by such directives are internally combined into the same, unique module) and \(par_{1},par_{2},\ldots\) is a potentially empty list of constant symbols acting as parameters of the module. Such parameters are allowed to occur in the rules of the module in any place that is syntactically valid for a constant symbol. The only module that clingo processes by default is the _base_ module, which takes no parameters. All other modules can be dynamically added to the computation by the programmer. When that happens, the programmer will also specify the values of the module's parameters, if any. Ifthe module has parameters, then what is added to the computation is the instance of the module with regard to the parameter values provided, where instance in this case refers to the set of rules obtained by replacing, in all rules of the module, all parameters' constant symbols by their corresponding values. Clingo allows a programmer to label certain literals as _external_. Such a label indicates to clingo that the truth value of those literals may be determined by rules added to the program at a later time, or even by direct truth assignment by the programmer via the \(assign\_external(l)\) and \(release\_external(l)\) API functions. In terms of internal handling of rules, clingo treats external literals as module inputs, which prevents those literals and the rules that contain them from being simplified away when their truth value is undefined.