Variability Management for a Runtime Monitoring Infrastructure

Abstract

Many software systems today are systems of systems (SoS), which are difficult to analyze due to their size, complexity, heterogeneity, and variability. For instance, unexpected behavior of SoS is often caused by the complex interactions between the involved systems and their environment at runtime. Monitoring infrastructures (MIs) provide support for engineers and support staff analyzing the behavior of SoS during development and operation. Variability plays an important role in MIs, however, while some approaches exist, managing variability of MIs remains challenging. In this paper, we describe how we applied a variability management approach to support the reconfiguration of a SoS monitoring infrastructure (MI) at runtime. Our approach provides configuration support for setting up the MI to reflect system variability. It also supports runtime reconfiguration of the MI to reflect the different monitoring tasks of users and to support evolution. We motivate our work using the case of monitoring a realworld SoS from the domain of industrial automation and discuss variability-related challenges in four monitoring scenarios. We evaluate the feasibility of our approach by applying it to these scenarios. We also demonstrate that our approach reduces manual reconfiguration effort and helps to reduce the overhead of the MI.

Evolution in dynamic software product lines

“…Clients are, for instance, tools for checking constraints 47 on the expected behavior based on the monitored events or visualization components explaining constraint violations to facilitate diagnosis. In previous work, we emphasized the need for sophisticated runtime variability management mechanisms 19 and support for automated evolution in REMINDS 21 , since a monitoring infrastructure must co-evolve with the underlying system it monitors. In the context of this paper, however, we focus on the evolution of the components of REMINDS itself: the probes, monitored events and data, and constraints being added, modified, or removed at runtime in the REMINDS monitoring infrastructure.…”

Evolution in dynamic software product lines

“…Constraints are then used to check the behavior of the system at runtime based on these events and data. To support the reconfiguration of our mi at runtime we have developed a variability management approach [16], i.e., we describe the variability of the key components of the mi -probes, events, and constraints -using variability models. The mi is a dspl and allows us to illustrate the co-evolution challenges outlined above.…”

“…The probes provide events that are checked by six constraints (C1-C6) at runtime. We do not present details on all constraints here for the sake of simplicity (see [16] for details). Constraint C4, for instance, checks that after a plant operator changed a steel production plan, these changes are archived in the database.…”

“…At the time of writing, we have implemented a prototype and tested it on evolution scenarios from the mi domain [16]. The Updater component already works and several Javabased Update Rules have been implemented as part of an Eclipse plug-in for the decision-oriented DOPLER tool [8].…”

“…However, these approaches are limited to a given set of changes, e.g., the addition of a variant, as other kinds of changes cannot be automated [9]. Based on our work on runtime reconfiguration of monitoring systems [20,16] and on dynamic architecture evolution in dspl engineering [1], we investigate the issues related to dspl evolution in more detail.…”