## 2 Overview of our Approach
### Problem Statement: Context and Sensor Heterogeneity  
Context and context-awareness in computing emerged as a part of the ongoing research in ubiquitous or pervasive environments. [PERSON] and [PERSON] [21] provided the following definition for context-awareness: _\"A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user's task\"_. This definition allows developers of context-aware services to define a relevant context for a given scenario, the information which can be used to describe a situation of an entity in an interaction with the system (e.g., user's location to know the temperature of a specific room). Context information is generated by heterogeneous and resource-constrained devices (as sensors). One of the main characteristics of context information is its dynamism, _i.e._, a context may change at runtime and therefore may require an adaptation of the system. This information needs to be described in a structured and extensible model. In addition, to manage the context, the following functions are required in any context-aware system:  
* **Context acquisition. ** This task obtains information from different sources. In this work, we focus on the different sensing units integrated into sensor nodes (e.g., acoustic or light sensing units), and both built-in-sensors (e.g., accelerometer) and embedded components (e.g., GPS receiver) into smartphones or tablets. Context acquisition is far from trivial, since normally the contexts are not composed by a single concept coming from a single user or device; instead they use to be made up of several user characteristics and/or environmental information gathered by several devices. * **Context storage. ** In some situations it may be necessary to store some previous values gathered in context acquisition. A local context can be stored locally within the device that acquired it previously. Complex contexts containing information of several sources belonging to the global system must be stored in a centralized node, such as a sink or a server database. * **Context analysis. ** The values collected in the context acquisition function are continuously analyzed and combined to detect a possible context change. The analysis of the heterogeneous contexts gathered previously is a complex task. For example, a context (e.g., temperature) coming from different sensor devices may be given in distinct units (e.g., Celsius or Fahrenheit). * **Context actuation. ** Once a context change is detected, some actions must be executed to adapt the system to the new context situation. These actions can correspond to dynamically reconfigure both the software and hardware involved in the system. We assume our AmI systems will present an architecture similar to that depicted in Figure 1, where different devices work together to allow the context acquisition and detection of changing situations. Figure 1 shows diverse TinyOS motes and Sun SPOTs with sensing units. Furthermore, smartphones and tablets with Android OS use their components to acquire contexts. These three kinds of devices are communicated via Internet to analyze context data. To manage and exchange contexts efficiently, the four functions described previously can be specified by means of modeling context. Context models define and store context data in a machine readable and processable format. There are several approaches to represent context, as summarized in [22], such as _key-value models_[23], _metamodeling languages_[20, 24], _graphical models_[25], or _ontology-based models_[26]. We use a _metamodeling language_, specifically ContextUML to model our context-aware systems. In addition, as FamiWare is built using SPLs and it also uses Feature Models (FMs) [27] to characterize the inherent variability of the AmI domain, including the variable context information, we propose a mapping between the ContextUML elements and the FamiWare Feature Model.