Autonomic Computing through the Reuse of Variability Models at Run-Time. With more and more devices being added to our surroundings, simplicity becomes
highly appreciated by users. Autonomic Computing plays a key role in simplifying
the use of systems by reducing the need for maintenance. A system with autonomic
capabilities is in charge of installing, configuring, tuning, and maintaining
itself.
Our research shows that Smart Homes can also achieve Autonomic Capabilities. Our research also demonstrates that this Autonomic Behaviour can be achieved through the Reuse of
Variability Models at Run-Time. Applying our approach, we have achieved the following autonomic capabilities in Smart Homes:
Self-configuring: New kinds of devices can be incorporated to the system. For example, when
a new presence sensor is added to a home location, the different smart home services such
as security or lighting control should automatically make use of it without
requiring configuration actions from the user.
Self-healing: When a device is removed or fails, the system should adapt itself in
order to offer its services in an alternative way to reduce the impact of the
device loss. For example, if an alarm fails, the Smart Home can make the lights
blink as a replacement for the failed alarm.
Self-adapting: User needs are different for each user at any given moment. The
system should adjust its services in order to fulfill user preferences. For
example, when a user leaves home, services in the home should be reorganized to give priority to security.
To meet the challenge of Autonomic Homes our approach is based on Variability Modelling and Dynamic Product Line Architectures. Our work is strongly influence by the ideas of Model Driven Engineering and Software Product Lines. The above figure depicts the main building blocks of our approach.
| |
 |
|
To enable Autonomic Capabilities, the system must evolve from one configuration to another.
Since the reconfiguration in our approach is performed in terms of features, a
Model-based Reconfiguration Engine (MoRE) is provided to translate
context changes into changes in the activation/deactivation of features. Then,
these changes are translated into the reconfiguration actions that modify the
system components accordingly.
The overall reconfiguration steps are outlined in the left Figure. The
Context Monitor uses the run-time state as input to check context conditions
(step 1). If any of these conditions are fulfilled (e.g., home becomes empty),
then MoRE uses model
operations to query the run-time models about the necessary modifications to the
architecture (step 2). The response of the models is used by the engine to
elaborate a Reconfiguration Plan (step 3). This plan contains a set of
Reconfiguration Actions, which modify the system architecture and
maintain the consistency between the models and the architecture (step 4). The
execution of this plan modifies the architecture in order to activate/deactivate
the features specified in the resolution (step 5).
The reconfiguration of the system is performed by executing reconfiguration
actions that deal with the activation/deactivation of components, the creation and
destruction of channels among components and the update of models accordingly to
keep them in sync with the system state. MoRE makes use of the OSGi
framework for implementing the reconfiguration actions. This
Framework implements a complete components model that extends the dynamic
capabilities of Java.
|
|
