Static and dynamic property-preserving updates

https://doi.org/10.1016/j.ic.2020.104611Get rights and content

Abstract

Systems need to be updated to last for a long time in a dynamic environment. The update can be performed both statically, by restarting the system, or dynamically. Updates have to preserve the desirable properties of the system, while possibly enforcing new ones.

We consider a simple yet general update mechanism, replacing a component of the system with a new one. We define contexts and components as Constraint Automata interacting via either asynchronous or synchronous communication, and we express properties using Constraint Automata too. Then we build most general updates preserving specific properties, considering both a single property and all the properties satisfied by the original system, in a given context or in all possible contexts. To tackle also dynamic update, we consider the state transfer problem, namely how to find the state in which the new component should be started to ensure a correct overall behaviour.

Introduction

Update is a relevant topic [1], both for automatic updates, as in the context of adaptive systems [2] or autonomic computing [3], and for manual updates. Update may be triggered by different needs, e.g., to fix bugs, to satisfy changing user requirements, or to match changes in the computing environment. Answering these needs is necessary since one wants systems to last for a long time in a changing scenario. However, a main point, namely correctness of the system after update, has received less attention till now, as remarked also in [4]. A real-world example highlighting the importance of this aspect is the following: what was called “one of the biggest computer errors in banking history”, deducting about $15 millions from over 100000 customers' accounts, was due to a software update [5].

In this paper we consider a very simple yet general update mechanism, which replaces a part of the system with a new one. Formally, the system is seen as a context C containing the component1 to be updated A, i.e., the system has the form C[A]. An update replaces component A with a new component B, thus the system upon update has the shape C[B]. The update can be performed either statically, that is C[A] is shut down, and the new system C[B] starts in the initial state, or dynamically, by replacing A with B without restarting C (dynamic updates are also called live updates, or on-the-fly updates). In this second case, when C[B] starts, C is in the same state as when A has been removed.

In the simpler case of static update a basic question is: how to build a most general new component B such that if system C[A] satisfies a given property Φ, then also system C[B] satisfies the same property? This question is answered in Section 3. Note that system C[B] may satisfy further properties that system C[A] does not satisfy. The answer to the question above, which relates components A and B, depends both on the context C and on the property Φ. From this observation two generalisations emerge naturally. On one side, one may ask how to build a most general new component B such that for a given context C, all the properties satisfied by system C[A] are also satisfied by system C[B] (Section 3). We call such an update correct for a given context w.r.t. any property. On the other side, one may ask how to build a most general new component B such that for each context C if system C[A] satisfies property Φ, then system C[B] satisfies the same property (Section 4). We say that such an update is correct (w.r.t. property Φ), hence it can be applied in any context. Finally, one may combine the two generalisations asking how to build a most general new component B to ensure correctness of update in any context and w.r.t. any property (Section 4).

The questions above can be rephrased also for dynamic update, by requiring that the system behaving first as C[A], and then as C[B], satisfies the desired properties. Here there is an additional element coming into play, namely how to select the state in which B starts, depending on the state of A just before the update. This problem is known as the state transfer problem, and has been first studied in [6]. The problem is notoriously hard and is normally dealt with by manual tedious work, as reported, e.g., in [7], [8]. We will compute (Section 5) a partial function that, for each state of A, tells us whether the update can be safely performed or not and, in the first case, which states of B can be selected as starting states.

The questions above are very general, and the detailed answer depends on the choice of the model for components and contexts, of the composition operators, and of the formalism for expressing properties. We consider here components, contexts and properties represented as Constraint Automata [9], [10], which have been used in the literature, e.g., to give a formal semantics to REO connectors [11] and Rebeca actors [12]. We use sets of prefix-closed finite and infinite traces as semantic framework. We concentrate on safety properties, thus prefix-closed sets of traces are enough. We consider both asynchronous and synchronous composition for components and contexts. We leave the systematic exploration of the research space above to future work. We illustrate the main results of our approach by means of a simple running example. All the operations on Constraint Automata were computed using the tool GOAL [13],2 an interactive tool for defining and manipulating automata, which we extended to deal with Constraint Automata.

The present paper is an extended and revised version of [14], which concentrated on static update. Here we also consider dynamic update, hence the state transfer problem. We also provide more efficient constructions for update in a given context (both for a single property and for all properties) when the selected context is input-deterministic. The present paper includes full proofs of all the results, which were absent in [14]. Finally, the whole paper has been carefully revised, and extended with additional examples and a more detailed description of related work.

Section snippets

Constraint automata

We model components, contexts and properties as (nondeterministic) Constraint Automata (CAs) [9], defined below. Throughout the paper we assume a finite set Data of data values which can be communicated and a finite set of states for the CAs. As in [9], the finiteness assumption is needed for the effectiveness of our constructions.

Definition 1 Constraint Automata

A Constraint Automaton A is a tuple Q,N,q0, where:

  • 1.

    Q is a finite set of states;

  • 2.

    N is a finite set of nodes representing the interface between the CA and the outside

Updates correct for a given context

We start this section with a formal definition of correct update.

Definition 7 Correct update

Given a system C[A], an update replacing component A with a new component B is correct w.r.t. a property Φ iff whenever C[A]Φ also C[B]Φ.

We assume that components A and B have the same interface, that is, the same set of nodes. This is not restrictive since one can always add nodes that are never used.

This section considers both the cases “all properties, given context” and “given property, given context”. We show that they can

Updates correct for all contexts

In this section we study both the cases “given property, all contexts” and “all properties, all contexts”. Similarly to the previous section, we can assume without loss of generality that components A and B have the same interface U, and that all the contexts we consider have U as internal interface.

Let us start from the case of a given property. The property defines a minimum set of nodes O that the external interface of the context should provide. For some properties, replacing component A

From static to dynamic update

Previous sections concentrate on static update, where the system is shut down before update, and computation restarts from the initial state after update. We consider here dynamic update, where the component A is replaced by B at runtime. In particular, when B starts, the context C is not necessarily in the initial state, but it is in the same state it was in when A was removed. In this setting, starting B in the initial state may be wrong. This raises the issue of defining how state transfer

Related work

While many approaches tackle system update [1], the problem of ensuring correctness of a system upon update has received less attention till now. We discuss below relevant classes of related work.

Refinement. Approaches based on behavioural congruences, such as [24], allow one to prove the correctness of updates when a component is replaced by a syntactically different, but semantically equivalent one. Similarly, approaches based on refinement, such as [25] in the context of Reo, allow one

Conclusion

We studied the problem of finding out whether an update replacing a component A with a component B in a given context C is correct w.r.t. a safety property Φ. We also characterised the updates correct in any context (for a given property), for any property (in a given context), and for any property in any context. In all the cases, we considered both synchronous and asynchronous composition. In order to support dynamic update, we also studied how to map the state of the original component A

Declaration of Competing Interest

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.

References (45)

  • C.M. Hayden et al.

    Specifying and verifying the correctness of dynamic software updates

  • S. Hansell

    Glitch makes teller machines take twice what they give

  • D. Gupta et al.

    A formal framework for on-line software version change

    IEEE Trans. Softw. Eng.

    (1996)
  • A. Baumann et al.

    Providing dynamic update in an operating system

  • H. Chen et al.

    Live updating operating systems using virtualization

  • C. Baier et al.

    Formal verification for components and connectors

  • F. Arbab

    Reo: a channel-based coordination model for component composition

    Math. Struct. Comput. Sci.

    (2004)
  • M. Sirjani et al.

    Compositional semantics of an actor-based language using constraint automata

  • M. Tsai et al.

    GOAL for games, omega-automata, and logics

  • D. Bresolin et al.

    Most general property-preserving updates

  • M. Lange

    Weak automata for the linear time μ-calculus

  • N. Kobayashi et al.

    Complexity of model checking recursion schemes for fragments of the modal mu-calculus

    Log. Methods Comput. Sci.

    (2011)
  • Cited by (2)

    The authors acknowledge the support from the Italian INdAM – GNCS projects 2016 Logic, automata and games for self-adaptive systems and 2017 Logic and automata for interval model-checking. The authors also thank the anonymous reviewers for their useful comments and suggestions.

    View full text