Live synthesis

Abstract

Synthesis automatically constructs an implementation that satisfies a given logical specification. In this paper, we study the live synthesis problem, where the synthesized implementation replaces an already running system. In addition to satisfying its own specification, the synthesized implementation must guarantee a sound transition from the previous implementation. This version of the synthesis problem is highly relevant in “always-on” applications, where updates happen while the system is running. To specify the correct handover between the old and new implementation, we introduce an extension of linear-time temporal logic (LTL) called LiveLTL. A LiveLTL specification defines separate requirements on the two implementations and ensures that the new implementation satisfies, in addition to its own requirements, any obligations left unfinished by the old implementation. For specifications in LiveLTL, we show that the live synthesis problem can be solved within the same complexity bound as standard reactive synthesis, i.e., in 2EXPTIME. Our experiments show the necessity of live synthesis for LiveLTL specifications created from benchmarks of SYNTCOMP and robot control.

1 Introduction

The past decade has brought remarkable progress in the automatic synthesis of reactive systems from temporal specifications [8, 17, 22]. Traditionally, synthesis is seen as a one-off method: the generated implementation is guaranteed, by construction, to satisfy the specification. If the specification changes, the process is repeated from the start. For systems that are always-on, like banking systems, or controllers in power plants, this may, however, not be an option: when the requirements change, the system must be updated, while it is still running, and the control must transition to the new version without disrupting the safety or functionality of the running system. While such live updates are a well-studied concern in operating systems research (cf. [13]), they are, somewhat surprisingly, still a novelty in formal methods. In this paper, we define a live system as sequence of implementations, each with a corresponding specification. The last element in the sequence is the currently executed system. Performing a live update terminates the currently active system and extends the sequence with a new implementation. The key challenge of live updates is that any obligations imposed by the specification of the terminated system that are not yet satisfied at the time of the update must be taken care of by the newly active system. This transfer of obligations is important to make the update transparent from the user’s perspective. Consider, for example, an arbiter specified as the LTL formula , which requires that every $request$ is eventually followed by a $grant$. If the update occurs after some $request$, but before the corresponding $grant$, then the new implementation must still guarantee the occurrence of the $grant$.

The problem of model checking live updates is to check whether a given new implementation will result in a correct live update; the synthesis problem is to automatically find such an implementation. To specify the correct handover between the old and new implementation, we introduce an extension of linear-time temporal logic (LTL) called LiveLTL. A LiveLTL specification defines requirements on the two implementations and ensures that the new implementation satisfies, in addition to its own requirements, any obligations left unfinished by the old implementation.

We consider two variants of the model checking and synthesis problems. In finite-trace live updates, we only require the update to be correct in a specific situation, i.e., after a specific execution of the previous implementation. In universal updates, we require that the update can occur at any time. We show that model checking live updates is PSPACE-complete in the initial and update specification. Synthesis is 2EXPTIME-complete in the combination of the specifications for both update variants.

We report on experience with a prototype implementation of our approach on a range of benchmarks, including examples taken from the synthesis competition and a robotic case study. In our experiments, live synthesis is used to construct live updates built on reasonable pairs of specifications. The results show the necessity of verifying live updates with the adapted semantics of LiveLTL and that every considered specification states obligations for the update. This paper is the journal version of [9] with extended proofs and case studies as well as an exploration of the class of obligations induced by LiveLTL.

2 Running example – relay station

Consider the following setup: a satellite has been positioned in the orbit of Mars in combination with multiple base stations on the planet. The base stations take samples from the extraterrestrial environment, analyze them and submit their findings to the satellite. After the data has been sent by a station, it waits for instructions from the satellite: whether the sample must be further analyzed, or whether it can be discarded and a new sample must be taken. The satellite, on the other hand, provides the stations with the corresponding instructions and collects the data of all stations for relaying it back to earth. To this end, the satellite takes care that always some data of all base stations has been collected to be present in the report for earth.

We formalize this behavior of the satellite in LTL, the semantics is defined in Sect. 3. On the input side, the satellite receives n measurements $m_{j}$ of every base station, where $0 \le j < n$ ranges over the n deployed base stations on the planet. On the output side, the satellite outputs instructions $i_{j}$ and can create a report r to be sent back to earth. The behavior is formalized using the following guarantees: First of all, every measurement $m_{i}$ must be responded to eventually and instructions are only sent in response to received measurements.

Furthermore, a report is generated as long as every base station submits a measurement regularly, while no report needs to be generated as long as some measurements are still missing.

All guarantees $\varphi _{j}$ must be satisfied at every point in time. We obtain the overall specification . The specification is realizable, as witnessed by the synthesized labeled transition system (LTS) for two base stations in Fig. 1. We follow the transition system for . Starting in the initial state, if $m_0$ and $m_1$ is received, we stay in the same state and as well as is satisfied. The transition system follows the $\lnot m_0$ edge to the state labeled with $i_1$ to satisfy the subformula . Note that would be directly satisfied in the initial state since the Moore semantics evaluates the formula based on the current state and next edge label. The states at the top right and bottom left ensure that $\varphi _2$ is satisfied, i.e., it waits for inputs before the corresponding output is set. Corresponding to $\varphi _4$, the top left and bottom right states control the output r which is only allowed to be true as long as all measurements are received.

Fig. 1

Synthesized LTS for the satellite specification

Consider a situation, where one of the base stations fails. The satellite controller must be updated, since the satellite would wait indefinitely for the data of the broken base station otherwise. The report generation would also be broken. However, we cannot just eliminate the broken base station from the original specification, synthesize again and restart the satellite with the new result. The reason is that there still may be an outstanding instruction of the satellite for one of the remaining base stations, for which this base station is actively waiting. Therefore, the updated specification still needs to take this obligation of the old implementation into account.

In the remainder of this paper, we consider the necessary changes to the synthesis procedure that are required for a correct update of the specification and synthesized implementation. An adapted verification framework is introduced that enables the validation of live systems. We present a logic that avoids the break of the base stations and satellite due to the disregarded obligations of the old system during update.

3 Preliminaries

Linear temporal logic Linear temporal logic (LTL) [24] is a logic for specifying correctness of linear-time systems. The syntax is a combination of state and path operators over a set of atomic propositions (AP) that define behavior over infinite time. Formulas in LTL are built according to the grammar where $a \in AP$. Temporal operators are next and until , and all other operators are Boolean connectives. We assume every LTL formula to be in release positive normal form (PNF) where negations are only allowed in front of atomic propositions. For readability, implication $\rightarrow$ and equivalence $\leftrightarrow$ as well as the common abbreviations eventually for and globally for are used throughout this paper. Defining the LTL semantics, the operator $\vDash$ evaluates infinite traces $\sigma$ and explicit index i against LTL formulas $\varphi$ where traces are words over letters $\sigma \in (2^{AP})^\omega$. For example, $\sigma$ satisfies if in the next step a holds in $\sigma$ and if a holds until b holds. A trace $\sigma = A_0A_1A_2 \ldots$ with $A_i \in 2^{AP}$ is an infinite sequence of sets of atomic propositions. We use the infix notation $\sigma [n,m]$ to crop the trace to the sub-trace from position n to m, $\sigma [n,m] = A_nA_{n+1}\ldots A_{m-1}$, where $A_i \in 2^{AP}$, and concatenate the finite trace $\sigma _1$ with the possibly infinite trace $\sigma _2$ with $\sigma _1 \cdot \sigma _2$. The semantic operator $\vDash$ builds a language of a specification $\varphi$ with $\text {Words}(\varphi ) = \{\sigma \in (2^{AP})^\omega \big \vert \sigma , 0 \vDash \varphi \}$. A trace $\sigma$ that is terminated at an arbitrary position m, i.e., $\sigma [0,m]$, is a finite trace and denoted by $\eta$. The function $expand: LTL \rightarrow LTL$ uses the standard LTL expansion rules to unroll the given formula, $expand_n$ repeats expand n times. For example, . The function $\textit{after}: LTL \times 2^{AP} \rightarrow LTL$ [5] evaluates the formula on a given atomic proposition assignment and returns the remaining formula, e.g., and . The function is formally defined as

. Transition Systems. The reactive model for LTL are transition systems where state labels correspond to the output of systems and transition labels correspond to the input of the environment. Given a finite set of directions $\Upsilon$ and a finite set of labels $\Sigma$, a $\Sigma$-labeled $\Upsilon$-transition system is a tuple $TS = (T, t_0, \tau , o)$, consisting of a finite set of states T, an initial state $t_0 \in T$, a transition function $\tau : T\times \Upsilon \rightarrow T$, and a labeling function $o: T \rightarrow \Sigma$. Given AP and partition $AP = O \cup I$ for output and input atomic propositions, implementations for LTL specifications are $2^O$-labeled $2^I$-transition systems (TS). The paths of a transition system start in $t_0$ and follow the transition function $\tau$ collecting input and output labels with the output function o. The traces of a transition system $Traces (TS)$ omit the state information of paths. We assume transition systems without terminal states and a deterministic transition function.

Model checking and synthesis Model checking a transition system TS against a specification $\varphi$ checks the relation $Traces (TS) \subseteq Words (\varphi )$. The problem of automatically constructing a transition system that satisfies the model checking property is referred to as synthesis. In the course of this paper, we refer to the algorithms of LTL model checking and synthesis as black box algorithms. Similar to $Traces (TS)$, we denote the set of finite traces of TS by $FinTraces (TS)$.

4 Live updates

Common formalisms for verification agree on the following assumption: different system versions are analyzed in isolation, i.e., everything that happened before the initial state of the new implementation is irrelevant for its correctness. For updates at runtime, this assumption is infeasible. The update system has to satisfy obligations that were stated during the execution of the previous system to be correct. In this section, we set the foundations for a specification language that is able to express the correctness of a live update by defining the structure of two live update problems. We identify the factors that affect the update process and formalize the interplay of the components. The definitions are kept independent of specific temporal logics and can be adapted to various logics and system models.

Proving the correctness of systems either by model checking or synthesis assumes the existence of a starting point that is handled as the initial state. For live updates, the starting point of verification is not the initial state of the update system, but the initial state of the system running beforehand. Running systems create obligations that cannot be discarded when updated live; otherwise, for example, an observer would starve waiting for its response. The recent development of live systems enforces the sensibility of correctness algorithms to validate systems w.r.t. the context they are started in. For linear-time systems given as transition systems, we define the context as the finite execution of the previous system combined with its specification. The finite execution implicitly changes the state of the formula which we refer to as active formula. We capture this change to the formula with a function $\Psi$, which, given a finite trace and a specification, returns a specification that captures the obligations needed for the satisfaction of the update system. With defining $\Psi$, one is able to vary the impact of the initial system to the update system. Verifying an update system with standard LTL, one implicitly defines $\Psi$ to be for every input, enforcing no obligations on the update system.

Definition 4.1

(Finite trace live update) Let $TS_I$ be an initial system, $TS_U$ be an update system, $\varphi$ be an initial specification, $\psi$ be an update specification, and $\eta$ be a finite trace of $TS_I$. $TS_U$ is considered correct if it is correct w.r.t. $\psi$ and the result of $\Psi (\eta ,\varphi )$ for the function $\Psi : (2^{AP})^{*} \times LTL \rightarrow LTL$ defining the obligation.

Fig. 2

Finite trace live update (a) and the universal live update (b) with $\varphi$ as the initial specification, $\psi$ as the update specification, and $\Psi$ as the function computing the obligation for $TS_U$

The finite trace live update handles the context of the update as white-box: the finite execution of the previous system is fully known. For this explicit execution, the obligation is computed and, together with the specification of the update system, verified against the update. Figure 2a shows the dependencies built by the finite trace live update where n is the number of discrete time-steps of the finite execution. However, the explicit finite execution of the initial system is not always available. Therefore, Definition 4.2 introduces update correctness for all possible finite paths of the initial system.

Definition 4.2

(Universal live update) Let $TS_I$ be an initial system, $TS_U$ be an update system, $\varphi$ be an initial specification, and $\psi$ be an update specification. $TS_{U}$ is considered correct if it is correct w.r.t. $\psi$ and $\Psi (\eta , \varphi )$ for all possible finite traces $\eta$ of $TS_I$.

The context of the update is handled as black-box in the universal case. The explicit execution and the system’s state of the update is unknown, as shown in Fig. 2b. Nevertheless, if all possible obligations are satisfied by the update system, the update is guaranteed to be correct. Definition 4.2 increases the number of possibilities to be verified, since arguing over an infinite set of finite traces cannot be performed directly. In comparison with the explicit live update, length n is kept arbitrary since every finite trace may enforce its particular obligation.

Since we consider reactive systems, it is natural to aim for an update system that reacts to the update context and contains different initial states for different contexts, i.e., for each result of $\Psi (\eta , \varphi )$ the update system starts differently. Note that this problem is covered by the finite trace live update if the number of different contexts is finite. One can solve the update problem for each context and combine the resulting update systems accordingly. In general, multiple other meaningful models of update correctness can be designed, e.g., an existential version defining the existence of an update point in the initial system’s future. Nevertheless, finite trace and universal live updates suffice for the course of this paper and build a justifiable framework for live updates.

5 A temporal language for live updates

With the two live update problems defined, we introduce LiveLTL to state and verify the correctness of live updates. LiveLTL is an extension to LTL and specifies live update properties that automatically enforce the obligations of the previous execution on the update system. The syntax and semantics of LiveLTL as well as the language equivalence to LTL are shown. Moreover, we identify the class of obligations that can be stated by LiveLTL specifications.

5.1 LiveLTL

LiveLTL is designed according to three aspects: (1) the initial system is not able to enforce new obligations after termination, (2) all obligations stated before termination are satisfied by the update system, and (3) obligations are satisfiable in finite time. This guideline is a trade-off between independence of the previous system and incurring obligations from the initial specification to the update system. The definition of LiveLTL follows the finite trace update structure and builds the language for inputs as a combination of a finite and an infinite trace evaluation. The syntax is taken from LTL, and we assume the set of atomic proposition for the initial system to be a subset of the atomic propositions of the update system. As extension to the semantic operator $\vDash$ of LTL, the operators $\vDash _{|\eta |,\mathcal {I}}$ and $\vDash _{|\eta |,\mathcal {U}}$ form the language for the initial system and the update system, respectively. $\vDash _{|\eta |,\mathcal {U}}$ performs an index shift from time-step 0 to the update position and evaluates the changed formula with the LTL operator and is defined as $\sigma , i \vDash _{|\eta |,\mathcal {U}}\varphi \text { iff }\ \sigma , i+|\eta | \vDash \varphi$. Since the update specification is only relevant for the update system, the shift of size $|\eta |$ enables the correct evaluation of the update system’s part of the trace. $\vDash _{|\eta |,\mathcal {I}}$ inserts $|\eta |$ as upper bound for recurrent formulas, i.e., formulas with the release operator:

Informally, opens the obligation $\varphi _2$ in every execution step which contradicts (1) if evaluated after the update. As standard LTL semantics enables the specification to infinitely open new obligations, $\vDash _{|\eta |,\mathcal {I}}$ is built to limit this behavior to the actual finite execution of the initial system. The definition of $\vDash _{|\eta |,\mathcal {I}}$ mostly follows the definition of $\vDash$, except for the evaluation of release formulas. For all indices greater or equal to the length of the trace, is immediately satisfied, thus imposing the end of newly created obligations from the initial implementation. Therefore, the initial operator permits the transfer of finitely satisfiable obligations to the update system (2), but forbids the impact of the initial system after its termination (1). Note that for LTL formulas in PNF, all operators except release only specify finite behavior and all open obligations are satisfiable in finite time (3). The newly introduced operators are used to define the language of LiveLTL.

Definition 5.1

(Language of LiveLTL) Let $\varphi ,\psi$ be LTL formulas and let $\eta \in (2^{AP})^{*}$. The linear-time property induced by $\varphi , \psi$, and $\eta$ is

$$\begin{aligned} \text {Words}(\varphi ,\psi , \eta ) = \{\, \eta \cdot \sigma \in (2^{AP})^{\omega }\, \big \vert \,&\eta \cdot \sigma , 0 \vDash _{|\eta |,\mathcal {I}}\varphi \ \wedge \\&\eta \cdot \sigma , 0 \vDash _{|\eta |,\mathcal {U}}\psi \}. \end{aligned}$$

The language is dependent on the initial specification, the update specification, and the finite trace. Evaluating the inclusion of an infinite trace with the first $|\eta |$ elements being fixed consists of a combination of the operators $\vDash _{|\eta |,\mathcal {I}}$ and $\vDash _{|\eta |,\mathcal {U}}$. The initial LiveLTL operator is defined on the syntactic structure of the initial formula and is insensitive with respect to syntactic tautologies. Providing formulas without syntactic ambiguity that cannot be dissolved in $|\eta |$ time steps is left to the specifier. The following theorem relates LiveLTL and LTL.

Theorem 5.1

LiveLTL and LTL are equally expressive.

Proof

LTL $\subseteq$ LiveLTL: To show that $LTL \subseteq LiveLTL$, let $\varphi \in LTL$ be an arbitrary LTL formula. One can directly obtain $\text {Words}(\varphi )$ with $\text {Words}(\varphi ',\psi ',\eta )$ by instantiating the LiveLTL components with $\varphi ' = \top$, $\psi ' = \varphi$, and $\eta = \epsilon$.

LiveLTL $\subseteq$ LTL: To show that $LiveLTL \subseteq LTL$, we first shift the update formula to the end of the finite trace $\eta$ with . The evaluation of the formula $\psi$ is thereby delayed to the starting point of the update system. Secondly, we simulate the handover of the initial formula to the update system: We use $expand_{|\eta |}$ to unroll the initial formula $\varphi$ for $|\eta |$ time-steps. The resulting formula is equivalent to $\varphi$ and the operators and only occur inside $|\eta |$ next operators. Following the LiveLTL semantics, we limit the influence of : Let $strip: LTL \rightarrow LTL$ be a function syntactically substituting every by . The formula $strip(\varphi ')$ on the expanded formula simulates the operator $\vDash _{|\eta |,\mathcal {I}}$. To obtain the equivalent LTL formula, we concatenate both formulas with an LTL encoding of the finite trace, denoted by $LTL(\eta )$: , where . $\square$

While being equally expressive, LiveLTL enables the direct evaluation of the newly introduced live update problems on a given context. Correctness for finite trace live updates follows from standard language inclusion.

Definition 5.2

(Finite trace LiveLTL update) Let $TS_U$ be an update system, $\varphi$ be an initial specificaiton, $\psi$ be an update specification, and $\eta$ be a finite trace. $TS_U$ is correct w.r.t. finite trace LiveLTL if $\eta \cdot \text {Traces}(TS_U) \subseteq \text {Words}(\varphi , \psi , \eta ).$

Example 5.1

Interpreting the running example as finite trace LiveLTL update, we can obtain the finite trace $\eta = \{m_1, i_0, i_1, r\}, \{i_1\}, \{m_0, m_1\}$ as execution of the relay station. Evaluating $\eta$ with $\vDash _{|\eta |,\mathcal {I}}$ shows that , , and need to be satisfied by the update system, since both measurements are unanswered, and no report was given after both base stations sent their measurements. Note that changing the last trace element to $\{m_0\}$ eliminates the obligations for the base station $i_1$ and the report r.

The finite trace update directly translates to the definition of LiveLTL, whereas the universal live update adds a level of quantification.

Definition 5.3

(Universal live LTL update) Let $TS_I$ be an initial system, $TS_U$ be an update system, $\varphi$ be an initial specification, and $\psi$ be an update specification. $TS_{U}$ is correct w.r.t. universal LiveLTL if $\forall \eta \in \text {FinTraces}(TS_I): \eta \cdot \text {Traces}(TS_U) \subseteq \text {Words}(\varphi , \psi , \eta ).$

To satisfy the universal update condition, the update system needs to be robust against every possible obligation of the initial system. We explore the model checking and synthesis problems of LiveLTL in Sect. 6.

5.2 Obligations

The impact of the initial system on the update system is declared by the operator $\vDash _{|\eta |,\mathcal {I}}$ and forms a class of temporal properties. We investigate this class and build a monitor that traces the open obligations during the execution of a system. In practice, the explicit update to be performed is unknown during the design of the initial system. Therefore, one approach to face live updates is keeping track of open obligations, while the system is executed. To obtain the expressivity of the obligations possibly enforced by LiveLTL, we introduce the obligation property.

Definition 5.4

(Obligation property) A linear-time property $P_{obl}$ over AP is called an obligation property if for all words $\sigma \in P_{obl}$ there exists a good prefix, i.e., for every $\sigma \in P_{obl}$ there exists a word $\sigma [0, m]$ s.t. $\forall x. x \in (2^{AP})^\omega :\ \sigma [0,m] \cdot x \in P_{obl}$.

Obligation properties coincide with the class of co-safety properties (having the same definition as $P_{obl}$), which is natural outcome of the LiveLTL semantics. To obtain the open obligations with constant cost during runtime, the construction of a monitor tracking the obligations provides a space bounded solution. The monitor is meant to be constructed simultaneously to the initial system. To define the obligation monitor, we consider the formulas $\varphi$, $\psi$ to be in the same proper equivalence class $[\varphi ]_p = [\psi ]_p$ (cf. [5]), if the formulas are equivalent based on propositional logic. The obligation monitor for an arbitrary LTL formula is then defined as follows:

Definition 5.5

(Obligation monitor) Let $strip: LTL \rightarrow LTL$ be a function syntactically substituting every by . A deterministic obligation monitor for an LTL formula $\varphi$ is the tuple $\mathcal {O}\mathcal {M}_\varphi = (T, t_0, \Upsilon , \textit{after}, o)$, where $T = \{ [\varphi ']_p \big \vert \omega \in (2^{AP})^{*}: [\varphi ']_p = \textit{after}(\varphi , \omega )\}$ is the set of states, $t_0 = strip(\varphi )$ is the initial state, $\Upsilon = 2^{AP}$ is the set of directions, $\textit{after}$ is the transition function defined over T and $\Upsilon$, and $o(t) = strip(t)$ is the labeling function.

Since the state space of $\mathcal {O}\mathcal {M}_\varphi$ corresponds to the state exploration of $\varphi$, converting the formulas to obligations is achieved by $strip$ and stored in the labeling function. This can be interpreted as the obligations that have to be satisfied by the update system if an update is initiated in this state. The obligation monitor only tracks states and does not guarantee that every reachable state corresponds to a reachable state of a correct implementation of $\varphi$. We justify this property by assuming $TS_I$ is correct.

Fig. 3

Obligation monitor for $\varphi _1$ with one base station in (a) and the same obligation monitor combined with the two rightmost states of the running example in (b)

Example 5.2

Figure 3a displays the obligation monitor for of our running example with one base station. The monitor starts in an obligation free state corresponding to the state before the system is started and contains one direction for every element of $2^{AP}$. Note that we denote directions symbolically. Whenever $m_1$ is received on an edge, the obligation is raised. From the state, we differentiate between $m_1$ and $\lnot m_1$ leading to another raise of the obligation together with or only , respectively. Returning to the obligation is only possible if $i_1$ is set to and $m_1$ is in the same step.

We explore the following properties of an obligation monitor $\mathcal {O}\mathcal {M}_\varphi$ for an LTL formula $\varphi$:

Theorem 5.2

(Size of $\mathcal {O}\mathcal {M}_\varphi$) The number of states of $\mathcal {O}\mathcal {M}_\varphi$ is bounded by $2^{2^{|\varphi |}}$ and the number of obligations for $\varphi$ is bounded by $2^{2^{|\varphi |}}$. The maximal size of an obligation formula of $\varphi$ is $2^{|\varphi |}$.

Proof

The authors of [5] proved that if $\varphi$ has n proper subformulas, then the number of reachable $\varphi '$ from $\varphi$ is at most $2^{2^{n}}$. Therefore, the proper equivalence avoids an unnecessary blow-up by propositionally equivalent formulas. Function T is exactly the reachable states under the proper equivalence class, s.t. the number of states in $\mathcal {O}\mathcal {M}_\varphi$ is bounded by $2^{2^{|\varphi |}}$. The bound for obligation formulas follows directly from the state space of $\mathcal {O}\mathcal {M}_\varphi$ combined with $dom(strip) \ge img(strip)$: We obtain at most $2^{2^{|\varphi |}}$ different obligations and performing the function $strip$ can only decrease the size. The third part of the theorem is known by combinatorial logic. $\square$

Note that an offset between initial system and obligation monitor is created. While transitions of the initial system consider environment inputs and states correspond to system outputs, elements of the state space of the obligation monitor are formulas and the transitions are defined by inputs and outputs combined. Residing in a state in the obligation monitor can be interpreted as taking a transition in the system and not yet reaching the next state. Figure 3a shows a monitor for a specification, where the implementation is unknown during construction and the obligation monitor needs to over-approximate the reachable states of the implementation. If known, one can limit the reachable states of the monitor to the paths in the transition system. Indeed, in regard to completeness, unreachable obligations need to be eliminated from the obligation monitor during verification.

Example 5.3

The obligation monitor for the relay station cropped to the two rightmost states is shown in Fig. 3b. We combine the two states with the obligation monitor for the formula $\varphi _1$ (cf. Fig. 3a) to compute the exact reachable obligation states. For readability, we discard all transitions leading out of that cycle. Assuming that we start with $\top$ as initial obligation represented by the initial state, we follow the transition $\lnot m_0 \wedge m_1$ to the obligation monitor state , the top left state in the implementation. To give an example for the offset of the monitor and the transition system, if we take the loop $\lnot m_0 \wedge m_1$, we stay in the same state but change the obligation: The future system has to satisfy . The obligation monitor consists of five different states with four different obligation properties, whereas the implementation only has two states. The monitor is deterministic and cut to the reachable states and transitions of the implementation.

The construction of obligation monitors is useful in multiple scenarios. For the practical use of verified finite trace updates, the obligation monitor gives a bound for the additionally consumed space needed to verify live updates, whereas storing a finite trace can increase arbitrarily. Moreover, obligation monitors can be adapted to any live update semantics and implicitly build the state space of possible obligations. We delineate two possibilities to obtain the obligations a live update needs to be verified against: Tracking the obligations during execution of the system with $\textit{after}$ and $strip$ and building the obligation monitor before starting the system and running it in parallel. The tradeoff between a huge monitor and an unbounded computation of $\textit{after}$ and $strip$ while running the system is left open to the user. In the following, we solve the live update model checking and live update synthesis problems for LiveLTL.

6 Model checking and synthesis

In this section, we solve the problems of model checking live updates and synthesis of live updates, i.e., live synthesis. We explore finite trace and universal updates for the problems and show the complexity of each result and multiple parameters.

6.1 Model checking live updates

Model checking a transition system TS against an LTL formula $\varphi$ corresponds to answering the question if TS satisfies $\varphi$, i.e., $TS \vDash \varphi$. For live systems, the evaluation of the update transition system starts with the initial finite execution and switches to the update system afterward. Model checking the update system is therefore a language inclusion check of the traces of the transition system combined with $\eta$ against the LiveLTL semantics.

Definition 6.1

(Model checking finite trace live updates) Let $TS_U$ be an update system, $\varphi$ be an initial specification, $\psi$ be an update specification, and $\eta$ be a finite trace. The problem of model checking finite trace live updates is defined as $\eta \cdot Traces(TS_U) \subseteq \text {Words}(\varphi ,\psi , \eta ).$

The model checking problem can be split into two separate parts, directly identifying the newly introduced conditions for live systems with the operators $\vDash _{|\eta |,\mathcal {I}}$ and $\vDash _{|\eta |,\mathcal {U}}$. In addition to that $TS_U$ combined with $\eta$ needs to satisfy the update semantics of LiveLTL. Since both tasks can possibly be performed in isolation of each other, the overhead given by the live update semantics under the assumption of an update system already verified with LTL is an interesting topic but left open for future work. The complexity of the problem is stated w.r.t. the length of the trace and the combination of initial and update formula:

Theorem 6.1

(Complexity in $\varphi$ + $\psi$, and $\eta$) The model checking problem for finite trace live updates is PSPACE-complete in $|\varphi | + |\psi |$ and in NL in $\eta \cdot TS_U$.

The proof is subsumed by the proof of Theorem 6.2. The universal live update is verified independently of specific initial traces. The condition is stronger than for finite trace updates, and the number of compatible initial and update systems is smaller. Given that the context is unknown, the executions starting in the initial state of $TS_U$ need to satisfy every possible open obligation. Universal updates are relevant if neither the trace nor the obligation monitor are stored and computed, respectively. Given the initial system, model checking universal update compatibility obtains the same complexity as finite trace updates.

Definition 6.2

(Model checking universal live updates) Let $TS_I$ be an initial system, $TS_U$ be an update system, $\varphi$ be an initial specification, and $\psi$ be an update specification. The problem of model checking universal live updates is defined as $\forall \eta \in \text {FinTraces}(TS_I): \eta \cdot Traces(TS) \subseteq \text {Words}(\varphi ,\psi , \eta ).$

The implicit update points in $TS_I$ allow for the connection of both transition systems and model checking with a linearly increased formula.

Theorem 6.2

(Complexity in $\varphi + \psi$, and $TS_I \cdot TS_U$) The model checking problem for universal live updates is PSPACE-complete in $|\varphi |+|\psi |$ and NL in $TS_I \cdot TS_U$.

Proof

We obtain the lower bound by initializing $\varphi$ with $\top$ and $TS_I$ with an empty system. Model checking with LiveLTL semantics is then verifying the update system against the update formula. For the upper bound, we concatenate both, the specifications and the transition systems. $TS_I$ and $TS_U$ are connected by a duplicate of every edge in $TS_I$ annotated with a newly introduced atomic proposition update. update is controlled by the environment and switching the systems also obtains the inputs from the environment in this step. The new atomic proposition also encodes the end of the initial system in the formula: Every occurrence of release receives the limitation to update. The construction follows the equi-satisfiability proof of [18] for LTL on finite traces ($LTL_f$ [12]). We therefore obtain a formula that is co-safe if the environment assumption holds. To initialize the formula of the update system, update also spawns $\psi$ which has to hold after starting the update system. We combine all formulas and obtain one LTL formula and one system that are both linear in the size of the source formulas and transition systems. Since we base the reduction on known $LTL_f$ results and simple concatenation of transition systems, we can use LTL model checking for LiveLTL model checking. Therefore, we obtain the complexity results from LTL [25] for $\varphi + \psi$ and $TS_I \cdot TS_U$. $\square$

6.2 Live synthesis

In this section, we introduce the problem of live synthesis and show the complexity of synthesizing live systems. Synthesis of live updates during the runtime of the initial system promises correct-by-definition updates that can substitute the executed system instantaneously. In contrast to model checking, the synthesis procedure returns an implementation or unrealizable, proving that the finite trace or initial system and initial specification are incompatible with the update specification. We begin with live updates for an explicit finite trace of the initial system – the update system needs to react to the explicit context and open obligation. The definition follows the model checking problem, but searches for a transition system satisfying the live update.

Definition 6.3

(Finite trace live synthesis) Let $\varphi$ be an initial specification, $\psi$ be an update specification, and $\eta$ be a finite trace. The finite trace live synthesis problem is the computation of a transition system TS s.t. $\eta \cdot \text {Traces}(TS) \subseteq \text {Words}(\varphi ,\psi , \eta ).$

We additionally call a live update realizable if there exists a transition system that satisfies the finite trace live update. The complexity of the update synthesis is expressed w.r.t. $\varphi$ and $\psi$ and aligns to existing LTL synthesis bounds.

Theorem 6.3

(Complexity in $\varphi$ and $\psi$) The finite trace update synthesis problem is 2EXPTIME-complete in $|\varphi |$ and $|\psi |$.

Proof

The hardness proof follows the Proof of Theorem 5.1 from LTL to LiveLTL. We reduce LiveLTL to LTL to show completeness: The finite trace update is synthesized for $\varphi$, $\psi$, and $\eta$. The formula $\varphi '$ that we synthesize the update for is an LTL formula and similar to the proof of Theorem 5.1. This formula contains the encoded trace $\eta$, $\varphi$ restricted to the semantics of LiveLTL, i.e., every release formula can be released by the system AP update, and the shifted version of $\psi$ to position $|\eta |$. Furthermore, we add the AP update to the last position of the trace encoding of $\eta$. The synthesized strategy follows the trace $\eta$ until update, and then satisfies the obligation of $\varphi$ and $\psi$. The formula $\varphi '$ is constant in $\psi$ and linear in $\varphi$, and we therefore obtain the same complexity in $\varphi$ and $\psi$ as for LTL [25]. $\square$

The universal update is again of interest if the context of the live update is unknown. Synthesizing a transition system that satisfies the universal live update enables the user to plug-in the new system at any time-step without further analysis.

Definition 6.4

(Universal live synthesis) Let $\varphi$ be an initial specification, $TS_I$ be an initial system, and $\psi$ be an update specification. The universal live synthesis problem is the computation of a transition system TS s.t. $\forall \eta \in \text {FinTraces}(TS_I): \eta \cdot \text {Traces}(TS) \subseteq \text {Words}(\varphi ,\psi , \eta ).$

Again, we call the problem of the existence of a solution realizability. In general, the universal update obtains a conjunction of double exponentially many conjuncted obligations. To avoid the expansion of the update system, we combine the parity games of the initial and update system. Again, the initial formula conducts the impact on the update system and provides the complexity results.

Theorem 6.4

(Complexity in $\varphi$ and $\psi$) The universal update synthesis problem is 2EXPTIME-complete in $|\varphi |$ and $|\psi |$.

Proof

The hardness proof follows the proof of Theorem 5.1 from LTL to LiveLTL. To show the completeness, we reduce LiveLTL to LTL. Assume the universal update from $\varphi$ to $\psi$ with initial system $TS_I$. Let $\varphi '$ be obtained by limiting all release formulas in the formula $\varphi$ to the environment AP update, i.e., all occurrences of are replaced by . We build the parity game of (cf. [6]), where update is enforced to only occur once but will eventually hold. We introduce the following changes to the game: The first part of the game ($\varphi '$) is restricted to the edges that can be taken in $TS_I$ and all edges are controlled by the environment. This is a simple unrolling of the edges in $TS_I$. Therefore, the environment can move arbitrarily in the first game and build any obligation possible, as in the obligation monitor. Solving the game synthesizes a universal update for the triple $TS_I,\varphi , \psi$ regarding the LiveLTL semantics. Since the reduction is linear in $|\varphi |$ and $|\psi |$, we obtain the complexity results from LTL [25] for $\varphi$ and $\psi$. $\square$

7 Case study

Table 1 Results of live updates for robot and SYNTCOMP specifications

We explore the live update problems on benchmarks from the reactive synthesis competition [17] and robot control communities [21]. Our goal is a qualitative analysis of pairs of specifications that can be updated live according to the finite trace live update and the universal live update. In more detail, we aim to answer the following questions: For specifications that can potentially be updated to each other, does the LiveLTL semantics state universally updatable obligations? And if not, in how many obligation states is a finite trace update possible?

A prototype for the live synthesis procedure is implemented on top of BoSy [8], a tool that synthesizes implementations for LTL formulas.¹ We use Spot [4] for LTL formula manipulation and implemented the obligation monitor construction for arbitrary LTL formulas. For our experiments, the following structure is used: BoSy synthesizes a system for the initial specification which is used to build the obligation monitor. Therefore, the result of the synthesis query, i.e., a transition system satisfying the formula, is parsed and cut with the obligation monitor to eliminate unreachable states. Since the result of BoSy may differ per execution, we may obtain different sizes of the obligation monitor for different benchmark runs. Based on the obligation monitor, we perform explicit trace live synthesis for every monitor state label and universal live synthesis for all monitor states combined. Therefore, we build the conjunction of obligation monitor state labels and update formula and execute BoSy to check realizability. Note that this algorithm does not satisfy the upper bound of Theorem 6.4, as each obligation has up to exponential size in the initial formula (cf. Theorem 5.2), which is the input of the synthesis algorithm. To compare the performance of LiveLTL synthesis to general LTL synthesis, obtaining the obligations has to be included in the synthesis tool. Nevertheless, the current prototype has the benefit of explicitly stating the obligations and is compatible with arbitrary synthesis tools.

For the benchmarks in Sect. 7.1, Table 1 shows multiple results: The number of obligation monitor states built by the initial system and specification, the number of finite trace updates that are realizable, and the result of the universal update. Despite the finite trace live update stating updates from every possible finite execution of the initial system, we use the state representation of the obligation monitor to symbolically represent every execution. Table 2 compares the sizes of the update systems synthesized with and without LiveLTL semantics. The systems are represented in the Aiger [2] format, the columns #lat. and #gat. shows the number of latches and gates, respectively. The runtime in seconds for the update specification without update constraints and the universal update conclude the table. All experiments were executed on an Intel i7 processor with 2,8 GHz and 16 GB RAM.

7.1 Benchmark families

The upper part of Table 1 shows the results for live updates from specification patterns introduced by Menghi et. al. [21], where Reactivity implements additional interaction with the environment. The specifications define the behavior of a robot that is able to travel between n different locations and needs to satisfy different specifications on the way. Our second set of benchmarks is taken from the annual synthesis competition SYNTCOMP [17]. The results for live updates in the reactive synthesis setting are shown in the lower part of Table 1.

• Visit, Seq. Visit, and Patrolling enforce the robot to visit every location once, in a sequence, and infinitely often, respectively.

• Reactivity The reactivity specification forces the robot to react to an event after two steps at latest by driving to a delineated location, e.g., for refueling. The reactivity specification can be added to arbitrary specifications.

• Relay station The running example of this paper. The relay station communicates with n satellites and forwards the message if clients acknowledged.

• Arbiter An arbiter controls the access of multiple clients to a shared resource. It ensures that every request to the resource is eventually granted. We consider three variants of arbiter, a simple arbiter (s) only iterating over grants, a full arbiter (f) only granting access if requested beforehand, and a prioritized arbiter (p) that prioritizes the requests of client 0.

• ABP. The alternating bit protocol consists of a receiver ABPReceiver and a transmitter ABPTransmitter specifying the data link layer in the OSI communication network.

• Load balancer The load balancer distributes workload over n worker.

In addition to the specifications, we denote updates with an increased parameter with $n \rightarrow n+1$. This property is of interest if the parameter may change during the execution, e.g., increasing the number of clients of an arbiter.

7.2 Observations

Throughout all experiments, the minor runtime overhead of the universal update synthesis shows that the additional cost for live update correctness is feasible. The robot specifications provide insight of obligations raised during execution. Since most of the benchmarks obtain the same structural behavior, i.e., the robot visits the locations under some restrictions, the universal live updates are realizable. Even when adding requests, e.g., the robot has to refuel in two steps after requested, the live update is realizable by satisfying the open obligations after the update. Changes to the visiting sequence or infinitely often reaching a location with patrolling increases the size of the obligation monitor (#OM-States) but does not lead to unrealizability. Nevertheless, the sizes of the obligation monitors indicate that tracking the behavior of the system is necessary to obtain the correct obligation. Altogether, our results show that although robot specifications raise obligations, synthesizing correct live updates is often feasible due to the absence of conflicts between the specifications. Most interestingly for the reactive systems benchmarks are arbiter live updates. Changing a specification to a simple arbiter is realizable since the arbiter does not additionally restrict the behavior. However, live updates to full arbiter are only possible from some obligation monitor states, shown by the difference of #OM-States and #finite trace updates. Unrealizability follows from obligation states forcing a grant - an unrequested grant of the update system would be spurious. Since the prioritized arbiter does not include non-spuriousness, a live update from and to this arbiter is realizable. The relay station can be universally updated to the one more and one less base stations. Once computed, the obligations can be satisfied in finite time-steps and synthesizing a solution that reacts to all obligations is possible. The sizes of the solutions vary in the number of latches and gates needed to realize the specifications. Table 2 shows that we only observe a minor increase in complexity in the synthesized circuit, for some examples even no increase at all. This changes depending on the complexity of the obligations stated from the initial system. The experiments answer the questions stated at the beginning of this section: Specifications that are meaningful live updates state obligations for the update system, shown by the large number of states of the obligation monitors. Realizability of the update system depends on the restrictiveness of the specification, even if the universal update is unrealizable, our results show that in all benchmarks, some finite trace live updates are realizable.

Table 2 Sizes of the synthesized systems for LTL and the universal live update

8 Related work

The necessity of live updates in always-on systems is long known and was introduced as [7, 10]. Dynamic updates for programming languages, e.g., in C++ [16] and Java [14], enable developers to update dynamic classes during runtime and are called dynamic software updates (DSU). The proposed frameworks implement functionality and are unable to ensure temporal correctness of the updates. Live kernel patches received huge attention in the operating system community [1, 13], where bug-fixes and features of the kernel can be deployed without reboot. Recent work in live updates for operating systems achieved real-life implementations, e.g., for Linux [19] and Android [3] kernels. Implementations of dynamic updates raised the need for verification: Following the idea of observability by the user, Hayden et. al. [15] introduce client-oriented specifications (CO-specs) to define and verify against client-visible behavior. Closest to our work are dynamic updates in controller verification and synthesis. Ghezzi et.al. [11] introduce a controller synthesis approach based on modal sequence diagrams (MSD). The update is a synthesized MSD that takes over the execution when a safe state is reached. While reaching a safe state is also necessary in [20], the authors omit the obligations of the previous system. Where [11] also relies on the existence of a safe state for the live update, [23] also proves the reachability of the update state. Therefore, the condition of the handover between the systems is defined as LTL specification. The main difference is stating the correctness as LTL formula and not observing the update condition semantically from the initial formula.

9 Conclusion

We introduced live synthesis, a synthesis framework for dynamic updates in reactive systems. We identified obligations of a running system as the currently open co-safety formulas and defined LiveLTL to specify the correct handover between two systems. The presented obligation monitor enables tracking of obligations during system execution and continuously shows the open obligations. We explored synthesis and model-checking for two update problems, finite trace live updates and universal update, which consider full information and zero information of the currently open obligations, respectively. Our case study on robot specifications and reactive synthesis benchmarks show that it is necessary to verify live updates in always-on systems and live synthesis is able to automatically generate correct update systems if realizable. We believe that live updates play a crucial role in high-availability system verification and can benefit from existing techniques for reactive systems.