Elsevier

Computer Networks

Volume 45, Issue 5, 5 August 2004, Pages 625-644
Computer Networks

Feature interactions in embedded control systems

https://doi.org/10.1016/j.comnet.2004.03.002Get rights and content

Abstract

Present-day software systems, like modern telecommunications systems or distributed Internet applications, have reached levels of complexity that can no longer be addressed with ad-hoc techniques. Therefore, systematic approaches for coping with this huge complexity are required. To correctly develop such systems, interactions between the system's features have to be considered, as these might be the origin of incorrect system behavior. In addition to the traditional domains of large systems, increasingly complex systems can be found in the domain of embedded control systems, of which automotive as well as building and home control systems are interesting examples. In particular, the environment, in which an embedded control system operates, plays a crucial role in such a system's behavior, and can thus be the source for additional interrelationships between features. In this article, a systematic approach for the automatic detection of feature interactions in embedded control systems is presented, which allows the identification of interactions within a system as well as the detection of interactions that are caused by the environment.

Introduction

Embedded control systems have already become ubiquitous in today's world, where these systems are used in a multitude of application domains. These domains range from controllers for household appliances (each washer or microwave is equipped with some form of computer control), to automotive control systems (where systems like the anti-lock braking system, ABS, or the electronic stability program, ESP, are standard equipment in each new car), to systems that are employed for controlling large facilities (like office buildings, hotels, and airports). With an ever-increasing demand for new functionality and the number of devices that should be controlled, the complexity of these systems rises. Modern luxury cars, like BMW's 7 series, are equipped with up to 70 controllers and house software of more than 60 MB [1]. State-of-the-art building automation systems take a large number of different physical effects (light, temperature, humidity, etc.) into account to attain optimal performance [2], and like the control system of the Burj Al Arab hotel in Dubai, control up to 26,000 data-points [3].

Because of this complexity, a number of problems arise. One of these problems is the extension of such systems with additional functionality. This is typically required if new user needs should be considered. Besides the desired behavior, this new functionality might introduce undesirable interrelationships with old parts of the system, and thus an unwanted system behavior might be the result. Another problem can be discovered when parts of such complex systems are to be reused, because required interrelations to other parts of the reused system have to be taken into account.

In the telecommunications domain, this feature interaction problem [4] has been recognized for a long time and has received considerable attention from the scientific community as can be seen by events like the “Feature Interaction Workshop”, which has been held for the seventh time in 2003 [5]. However, this feature interaction problem has so far not been specifically approached for embedded control systems––probably because only now has the complexity reached dimensions that requires systematic control and resolution.

As a notable difference with respect to the telecommunications domain, embedded control systems will almost always be embedded in a physical environment, which provides responses to a system's stimuli and which is not part of the actual software system. Because of this special role of the environment, the identification and resolution of interactions that occur within the system is not enough, but also interrelationships that are introduced by interactions with the environment must be considered.

An example for such special interactions can be found when a building automation system for controlling lighting and heating is considered. At first glance, the heating control part can be realized independently of the lighting control part. However, if sunlight is employed for establishing the desired level of illumination, the controlled space might considerably heat up, which will present an interaction with the temperature control part, as it has no means for avoiding this situation and thus might not be able keep the desired temperature. A further example for this important role of the environment comes from the automotive domain. Let us assume that a car is equipped with cruise control and the electronic stability program (ESP) [6]. If cruise control speeds up the car at a high rate on a wet road, the wheels will slip. This is detected by the ESP, which intervenes by braking the slipping wheels, thus avoiding undesirable vehicle dynamics (like skidding). If the cruise control component knew nothing of the ESP feature and the physical reasons for its interventions, it would continue accelerating the car, which inevitably would result in the car leaving the road.

Before being able to treat feature interactions, they must first be detected. In this paper, we suggest detection concepts that work on requirements specification documents, which provide an early detection of interactions and reduce the effort for resolving such interactions in later development phases. Because of the complexity of the systems under consideration, such a detection activity cannot reasonably be performed manually. Therefore, an automation of this activity is required. This article elaborates on concepts and solutions for such automation that have been first presented in [7]. Most notably this includes the extension of the approach from building automation systems to the broader domain of embedded control systems and the refinement of the detection algorithms based on experience with first prototypes of the detection tools.

In the remainder of this article, the product model that classifies the elements of the requirements specification documents is introduced in Section 2. Based on the entities of this product model, our concepts and algorithms for detecting feature interactions in embedded control systems are presented in Section 3, followed by the results of four case studies in Section 4. Finally, the approach is discussed and related to existing work in the feature interaction field (Section 5).

Section snippets

The product model

For automating any development activity, explicit knowledge of the development process (in the form of explicit models) must be available. A product model is one such type of model that explicitly describes the development artifacts (or products) and the relations between them for a given development method (see [8]). We will therefore employ such a product model for the feature interaction detection concepts that are presented in this article.

To provide a better understanding of the entities

Feature interaction detection

In Section 2.3 we have already identified functional needs with features. Thereupon, the goal of detecting feature interactions in embedded control systems can be reached by identifying dependencies between functional needs. These dependencies can be extracted by following the relations between atomic artifacts in an instantiation of the product model. Depending on the available information, results with different precision can be attained. In the following subsections, we will present how four

Case studies

To evaluate the above concepts and to examine their feasibility in a real development context, tool prototypes have been implemented and applied in several case studies that are introduced in the following subsections. In these case studies, systems for different embedded control domains have been evaluated for their feature interactions and the numbers of the detected interactions are given below. These systems include two building, one automotive, and one railway crossing control system.

As

Discussion and related work

Some of the interactions that have been identified above do not seem to be critical (for example {U2,FM1,FM6} in Floor32, Section 4.1) and therefore should probably not be considered in the detection process, thus refining the set of interactions. Such an elimination of interactions might be suitable if an existing system is extended, and therefore only the introduction of undesirable (and thus critical) interactions with old parts of the system has to be determined (for example {U2,UA10} in

Conclusion and perspectives

Important activities in software development are the extension and reuse of existing systems. To correctly carry out these activities, the developers need to be aware of the interactions that exist between features. This article has shown an approach for the detection of feature interactions that is based on a metamodel of the development products. By specifying the detection concepts at the model level (such as evaluating requirements graphs), detailed information about feature interactions

Acknowledgments

I am very grateful to Christian Webel, who has contributed considerably to the implementation of the interaction detection tool and has participated in writing the initial paper [7].

I further wish to thank the anonymous referees and also the participants and reviewers of the 7th “Feature Interaction Workshop”, who have contributed to the improvement of this work by providing detailed and constructive comments.

Parts of this work have been funded by the Deutsche Forschungsgemeinschaft DFG under

Andreas Metzger studied Computer Science at the University of Kaiserslautern in Germany, where in 1998 he received his diploma degree. Since then he has been working as a research and teaching assistant at the Department of Computer Science of the University of Kaiserslautern, where most of his research has been conducted in the context of the special collaborative research center SFB 501 “development of large systems with generic methods” of the German science foundation DFG. In 1999 he has

References (41)

  • A Metzger et al.

    Specifying building automation systems with PROBAnD, a method based on prototyping, reuse, and object-orientation

  • S. Queins, PROBAnD––Eine Requirements-Engineering-Methode zur systematischen, domänenspezifischen Entwicklung reaktiver...
  • A Metzger et al.

    Model-based generation of SDL specifications for the early prototyping of reactive systems

  • A Olsen et al.

    System Engineering Using SDL-92

    (1997)
  • R Budde et al.

    Prototyping: An Approach to Evolutionary System Development

    (1992)
  • C Atkinson

    Meta-modeling for distributed object environments

  • T Clark et al.

    Foundations of the unified modeling language

  • D. Harel, B. Rumpe, Modeling languages: syntax, semantics and all that stuff––Part I: The basic stuff, Report MCSOO-16,...
  • A. Metzger, Requirements engineering by generator-based prototyping, in: H. Alt, M. Becker (Eds.), Proceedings of the...
  • G. Calderón Meza, Modeling friction in a ground vehicle––brake discs & tire/road friction models, in: A. Metzger, G....
  • Cited by (0)

    Andreas Metzger studied Computer Science at the University of Kaiserslautern in Germany, where in 1998 he received his diploma degree. Since then he has been working as a research and teaching assistant at the Department of Computer Science of the University of Kaiserslautern, where most of his research has been conducted in the context of the special collaborative research center SFB 501 “development of large systems with generic methods” of the German science foundation DFG. In 1999 he has been a visiting scientist at the Department of Architecture at Carnegie Mellon for two months. His research interests include metamodeling and automated software engineering and he is interested in persuing a career in academia. Andreas is currently finalising his Ph.D., in which he is investigating in how far quality improvements in software development can be achieved by automating activities of the early development phases (requirements engineering).

    View full text