Home

pchzhang wuxiaobin4000

CASSANDRAOSGI: a Failure Prediction Framework for Dynamically Evolving OSGi Systems

CASSANDRA is a novel proactive monitoring and verification technique aimed at predicting near future failures in dynamically evolving systems. CASSANDRA, by combining design-time and run-time information,looks k steps ahead of the current execution state, in order to predict future failures.

Introduction

For current software systems that can dynamically change during run-time, such as service-based and component-based, existing verification techniques are inadequate to prevent failures to happen. Traditional design-time verification techniques (like model checking) have been revised in order to cope with evolution but they alone cannot fully support the analysis of run-time evolving systems. Run-time verification techniques, based on system monitoring approaches, have become fundamental to ensure the correctness of run-time evolving systems. However, they have the ability to detect errors only too late, that is, when a failure happens. What is desirable is instead a technique that, while applied to run-time evolving systems, can predict potential errors that may happen in the near future.

Towards this research goal, this paper proposes CASSANDRA, a novel proactive monitoring approach to predict potential failures by looking ahead the current execution state. To this end, CASSANDRA combines design-time and run-time information for proactive run-time verification of dynamic component-based systems. The proposed proactive monitoring and verification technique uses run-time information to identify the current execution state, and checks whether the projection of a design-time model k steps ahead of the current state satisfies a set of wanted/unwanted properties. The execution state is captured by run-time traces obtained by monitoring the component-base system execution. Each component equips with a design-time model in the form of interface automata. The properties we considered are interaction temporal properties among different components.

The CASSANDRA approach stands on the following assumptions:

  • Each component to be integrated is augmented with a model of the interface suitable to
    be used for run-time checking;
  • It is possible to map observed run-time events with the ones included in the formal model
    used for the run-time checking;
  • The execution of one exploration step by the run-time checking algorithm is faster than the
    execution of the corresponding step by the real system. This assumption is necessary to
    keep the exploration synchronized with the real execution.

CASSANDRA is then based on a run-time checking algorithm that takes in input the interface automata for the various components, the look-ahead value 𝑘, the temporal property that should not be violated by the system:

  • The interface automata of the various components are composed on the fly to construct the
    tree of possible paths of length smaller than k,

  • When a system interaction event is detected the exploration is moved ahead of one step. In
    particular:

    • All the subtrees rooted in a next state linked by an event different from the one
      detected are discarded;
    • For each leaf in the subtree rooted in the next state linked by the detected event, the
      exploration is pushed ahead of one step;

  • In case a property is violated an alert event is generated specifying the trace leading to
    the property violation

Implementation

We customize CASSANDRA into the OSGi component model and framework. In OSGi, components (coming in the form of bundles for deployment) can be remotely installed, started, stopped, updated and uninstalled without requiring a reboot. The “Hot-Deployment feature” enables to add new bundles to the platform without affecting the running services:

  • The OSGi bundle developers provide the architecture with a set of wrappers of bundles
    (each wrapper is equipped with source code, the corresponding interface automata model and
    the Aspect codes).
  • The developers also provide a set of wanted/unwanted properties represented through the
    Property Sequence Chart (PSC) formalism.
  • During runtime we take k steps looking ahead at the interface automata models to construct
    the temporary Global State Machine (GSM) according to the current run-time information. We
    on-the-fly construct the GSM with k steps looking ahead.
  • The approach can proactively check at step k whether possible failures could happen in the
    future k+x steps. Consequently, the application users can take measures to avoid these
    failures.

Contributors

Past Contributors

MongoDB Logo MongoDB