Variability in Ambient Intelligence A Family of Middleware Solution

Introduction

Ambient Intelligence (AmI) represents a new generation of computing environments equipped with a wide range of small devices and appliances present everywhere, available for everyone and at all times (Weiser, 1991). AmI technologies are mainly based on the combination of concepts from ubiquitous and pervasive computing (Pervasive, 2003) and the production of software embedded in everyday objects and devices. AmI applications have to deal with a wide variety of devices ranging from mobile phones and PDAs with medium capacities to sensors, actuators, consumer electronics and wearable devices (Pervasive, 2003) with critical resource limitations. These devices are networked and operate across highly heterogeneous computing environments in terms of network access types, typically consisting of wireless (e.g. WiMAX, WBRO, etc.), cellular (e.g. UMTS, GSM, GPRS, etc.) and short/medium range (e.g. Bluetooth, Wifi, UMB, etc.) systems. Middleware platforms could play a key role in hiding the complexity and heterogeneity of lightweight devices connected via high-speed networks, by providing specific services (e.g. location, context-awareness, security, etc.) to support and to facilitate AmI applications development.

The large number of heterogeneous devices and the diversity of communication technologies and AmI application requirements make it unfeasible to construct a single middleware platform, using traditional single software engineering techniques, which can be deployed and configured on all kind of devices and providing services that fulfil the requirements of all AmI applications. Instead, the developer of a middleware platform for AmI applications should create families of middleware platforms that can be instantiated and customised according to the different hardware and software constraints imposed by both devices and applications. Thus, the application of a Software Product Line (SPL) approach would be very useful to deal with the different requirements of either devices or applications in terms of commonalities and variabilities defining a family of AmI middleware platforms (Apel & Böhm, 2005). Since device resource constraints (e.g. in memory, processor throughput, etc.) is an important consideration in AmI, only a specific middleware platform configuration that is suitable for the device capacities must be installed. Resource limitation is not the only variable dimension that AmI developers have to deal with however. Other factors can be identified relating to the communication protocols supported, the kind of interfaces or the high diversity of operating systems as well as the different APIs available for each operating system delivered for specific devices. Not all the devices support the same version of a given operating system, and not all the APIs are available for all kinds of devices. Middleware for AmI should benefit from the SPL approach in terms of configurability, reusability and evolution management (White & Schmidt, 2008). AmI applications will benefit from a highly-optimized and custom middleware, which will offer appropriate services consistent with device configuration and resource constraints.

In a family of middleware for AmI, the product-line architecture (PLA) is common for all the product members. The PLA of the middleware is composed of different fine-grained services creating domain (AmI) specific features, either common or variable features. So, a first step towards the definition of a middleware for AmI product line consists of specifying the feature model specific for the AmI domain. Feature modeling analyzes commonality and variability from a domain perspective (Lee, 2002). Then, a feature model allows specifying where the variability is in independently of the core asset, and enables reasoning about all the different possible configurations. A feature model for the AmI domain will help to specify and automatically derive different configurations of middleware tailored according to a high diversity of constraints (e.g. device capacities or application requirements).