## 3 Context Acquisition and Analysis Using FamiWare  
Our solution will address the problems raised during the context acquisition, storage, analysis and actuation by applying different mechanisms, which are detailed as follows:  
* **Context acquisition. ** To perform this task, FamiWare has a common structure for the monitoring services. It has already implemented several monitoring services (such as location monitoring in mobile sensors or smartphones). In Section 4, we will describe how to add other new monitoring services to the FamiWare family. * **Context storage. ** FamiWare performs this task by keeping context values to be used later. For example, in the TinyOS version, local context data are stored in the flash memory of the sensor. Figure 2: Overview of our approach. * **Context analysis. ** FamiWare provides a context-awareness service that receives the monitored data to analyze them with the purpose of detecting context changes. For analyzing new context information, which has not been considered in FamiWare previously, we need to add it to the FamiWare family, as we will detail further, in Section 4. * **Context actuation. ** As a context change happens, first the context-awareness service takes the decision of what to perform to adapt the system, and then the FamiWare reconfiguring service is in charge of executing a list of planned actions (e.g., activate a camera or turn off some sensors). Because of the complexity of the reconfiguration process to be performed in distributed systems composed by tiny devices, this task is beyond the scope of this paper. Nevertheless, the interested reader can find further details on how it is addressed by FamiWare in [29]. In order to acquire the context, FamiWare monitoring services have a common structure with the following characteristics: (1) they read data from a sensing unit (e.g., light or temperature) or from other resources to obtain relevant context information (e.g., battery); (2) this reading is done periodically for each specific interval of time or frequency; and (3) the context data is sent to the device in charge of analyzing the context. In a similar way, the context-awareness service implements an interface that allows the definition of data to be under observation as part of the context. For example, a particular instantiation of this service may observe the temperature but not the position. For each context, there is an associated function, which is responsible for detecting context changes that trigger a reconfiguration (e.g., the battery level is under 20%). Once this happens, this service will choose a reconfiguration plan to perform the self-adaptation to adapt the system to the new context situation. Nevertheless, the number of context situations that may provoke a change in a system is difficult to limit. In this work, we define the model-driven process and the service architecture of FamiWare in order to help application developers to define new contexts in an intuitive way. In addition, other advantage of using FamiWare is its base infrastructure to hide heterogeneity problems of the communication of context data through the network. Figure 3 shows the communication between the different kinds of devices (the three devices shown in the system of Figure 1) by means of FamiWare. In the figure, three products of the FamiWare family are represented: the version developed in neSC for devices with TinyOS operative system, the Java version for Sun SPOTs that works with the Virtual Machine Squawk VM and the Java version for Android devices. Specific products of FamiWare are installed in each device of a particular system. FamiWare also provides a _gateway_ to allow the communication between the heterogeneous devices of the system to deliver the context data from one device to the others and work together transparently. Currently, in FamiWare several monitoring services are defined and implemented and it considers diverse contexts, such as being aware of the battery level, the location of a device, the light sensed, _etc_.