A context management system for a cost-efficient smart home platform

This paper presents an overview of state-of-theart architectures for integrating wireless sensor and actuators networks into the Future Internet. Furthermore, we will address advantages and disadvantages of the different architectures. With respect to these criteria, we develop a new architecture overcoming these weaknesses. Our system, called Smart Home Context Management System, will be used for intelligent home utilities, appliances, and electronics and includes physical, logical as well as network context sources within one concept. It considers important aspects and requirements of modern context management systems for smart X applications: plug and play as well as plug and trust capabilities, scalability, extensibility, security, and adaptability. As such, it is able to control roller blinds, heating systems as well as learn, for example, the user’s taste w.r.t. to home entertainment (music, videos, etc.). Moreover, Smart Grid applications and Ambient Assisted Living (AAL) functions are applicable. With respect to AAL, we included an Emergency Handling function. It assures that emergency calls (police, ambulance or fire department) are processed appropriately. Our concept is based on a centralized Context Broker architecture, enhanced by a distributed Context Broker system. The goal of this concept is to develop a simple, low-priced, multi-functional, and save architecture affordable for everybody. Individual components of the architecture are well tested. Implementation and testing of the architecture as a whole is in progress.


Introduction
Today, the importance of context information has increased and a lot of systems are already based on context data.Especially automated system, like Home Automation or Home Assisted Living are based on such data.Therefore it is necessary to develop appropriate context management architectures as well as concepts and mathematical methods to inter-pret the data and adapting the system.In this paper, we introduce a cost efficient Context Management Platform which is based on distributed Context Broker (CxB) architecture for enabling context aware system adaptation.But first it is important to define the notion "Context".According to Dey and Abowd (Dey, 1999), Context is "any information that can be used to characterize the situation of an entity.An entity is a person, place or object that is considered relevant to the interaction between a user and an application, including the user and application themselves." For the so called Smart Home Platform (SHP), context consists of sensor data and data which is gathered from the internet (e.g.weather).Consequently our architecture must be able to handle all these kind of context data.Different kinds of architectures have been studied in the last years.Most of the architectures have been developed with a centralized broker architecture, e.g.CoBrA (Chen, 2003a) (Chen, 2003a) or (Schneider, 2010a).
Easy Meeting (Chen, 2004a,b) and MyCampusEasy (Gandon, 2003) (Gandon, 2004) are typical projects were researchers deal with reasoning.Easy Meeting is based on the Context Broker Architecture (CoBrA) and is a prototype of an intelligent meeting room.The Carnegie Mellon University has developed the MyCampus to provide context aware services for the community in the university.The e-Wallet is the key element, that supports access control and obfuscation rules for user's privacy.
The introduced approaches are based on a centralized Context Broker.A resulting disadvantage of such a system is the limited quantity of administrable clients.However, the basis for our system will be a centralized Broker system (compare CCast project, CCast, 2009).It breaks the system down into three main entities, a Context Provider (CxP), a Context Consumer (CxC) and a Context Broker.The CxB acts a broker for all kind of data and is aware of all CxPs and CxCs. Figure 1 shows the principal structure of the centralized CxB approach.This approach is not entirely new and 2 Schneider: A Cost-Efficient Smart Home Platform CxCs. Figure 1 shows the principal structure of the centralized CxB approach.This approach is not entirely new and has already been studied by several researchers and used in different projects.
In the case of large architectures, more precisely systems with hundreds of clients, an efficient management of the data is needed.A disadvantage of the centralized approach is the decreasing performance if the number of entities increases.Especially in the use case of a Smart Home Platform, sensor data and other context data (e.g from the internet) will be used to trigger events.Additionally, the system intelligence is located into so called Services.Each Service implements a Context Consumer and a Context Provider Interface, furthermore is has an interface to subscribe for context data.This interface is needed to enable value-triggered events.
Hence a centralized architecture will not be able to handle all this amount of data.To overcome this weakness, we developed a distributed architecture which is based on the federation of sub context managements systems.The organization of these systems will be comparable to a Domain Naming 90 Service (DNS) and was introduced in (Schneider, 2010-2).

Decentralized Context Management Architecture
In this section, we introduce our decentralised system approach in detail.But first it es necessary to define some requirements for the system:

95
-Plug and Play: will be fulfilled with respect to (Schneider, 2010-2) and (Schneider, 2009) -Security and Privacy

Interfaces
As basic concept we used the centralized broker architecture 100 from (CCast, 2009).Figure 2 shows all necessary interfaces to deploy the system in a centralized manner.As already explained, for the smart home platform use case a decentralized architecture is necessary.Therefore, tional interfaces and will be described in the following subsections.

Context Broker CxB
The centralized CxP implementation comprises of the following interfaces:  has already been studied by several researchers and used in different projects.
In the case of large architectures, more precisely systems with hundreds of clients, an efficient management of the data is needed.A disadvantage of the centralized approach is the decreasing performance if the number of entities increases.Especially in the use case of a Smart Home Platform, sensor data and other context data (e.g. from the internet) will be used to trigger events.Additionally, the system intelligence is located into so called Services.Each Service implements a Context Consumer and a Context Provider Interface, furthermore is has an interface to subscribe for context data.This interface is needed to enable value-triggered events.
Hence a centralized architecture will not be able to handle all this amount of data.To overcome this weakness, we developed a distributed architecture which is based on the federation of sub context managements systems.The organization of these systems will be comparable to a Domain Naming Service (DNS) and was introduced in (Schneider, 2010b).

Decentralized context management architecture
In this section, we introduce our decentralised system approach in detail.But first it es necessary to define some requirements for the system: -Plug and Play: will be fulfilled with respect to Schneider, 2010b andSchneider, 2009 -Security and Privacy

Interfaces
As basic concept we used the centralized broker architecture from (CCast, 2009).Figure 2 shows all necessary interfaces to deploy the system in a centralized manner.
As already explained, for the smart home platform use case a decentralized architecture is necessary.Therefore, CxCs. Figure 1 shows the principal structure of the centralized CxB approach.This approach is not entirely new and has already been studied by several researchers and used in different projects.
In the case of large architectures, more precisely systems 75 with hundreds of clients, an efficient management of the data is needed.A disadvantage of the centralized approach is the decreasing performance if the number of entities increases.
Especially in the use case of a Smart Home Platform, sensor data and other context data (e.g from the internet) will be 80 used to trigger events.Additionally, the system intelligence is located into so called Services.Each Service implements a Context Consumer and a Context Provider Interface, furthermore is has an interface to subscribe for context data.This interface is needed to enable value-triggered events.

85
Hence a centralized architecture will not be able to handle all this amount of data.To overcome this weakness, we developed a distributed architecture which is based on the federation of sub context managements systems.The organization of these systems will be comparable to a Domain Naming 90 Service (DNS) and was introduced in (Schneider, 2010-2).

Decentralized Context Management Architecture
In this section, we introduce our decentralised system approach in detail.But first it es necessary to define some requirements for the system:

95
-Plug and Play: will be fulfilled with respect to (Schneider, 2010-2) and (Schneider, 2009) -Security and Privacy

Interfaces
As basic concept we used the centralized broker architecture 100 from (CCast, 2009).Figure 2 shows all necessary interfaces to deploy the system in a centralized manner.
As already explained, for the smart home platform use case a decentralized architecture is necessary.Therefore, tional interfaces and will be described in the following subsections.

Context Broker CxB
The centralized CxP implementation comprises of the following interfaces:   some of the available entities need to be enhanced with additional interfaces and will be described in the following subsections.

Context broker CxB
The centralized CxP implementation comprises of the following interfaces: To use Context Broker in a distributed architecture, additional interfaces are necessary.One interface is needed to enable communication between two CxBs.But before this communication can be established, a CxB detection needs to be performed.Therefore, a Broker detection interface has been included.It is used to detect adjacent CxBs and to request their address to establish a communication.Additionally, each CxB has to provide an Provider Detection interface and a Consumer Detection Interface.

Context provider CxP
A Context Provider delivers various kind of data.It is not restricted to sensor data from physical sensors (such as temperature or light), but also allows to provide pre-processed data, for example system load or available bandwidth.For the centralized system, a CxP is equipped with the Interfaces listed in Table 2.With respect to the plug and play requirement, an additional Broker Detection Interface is necessary.This Interface is the counterpart to the Provider Detection Interface in a CxB.The detailed function of a CxB detection is described in Schneider, 2010a.Additionally each Broker need an interface to communicate with other CxBs.But before a CxB is able to communicate with another CxB, a detection process is to be carried out.Therefore, a CxB sends a broadcast with its own address and waits for response.
Another issue is the implementation of a context subscription interface for enabling services.This interface must be able to allow CxCs to subscribe to context for periodic as well as event-triggered data transfer.

Context consumer CxC
A Context Consumer is an entity which uses context data for its actual purpose.This can be, for example, an actuator for steering a roller blind or the heater.But for developing of our system architecture, we didn't make any restrictions.This offers the possibility to include any kind of services into the platform.For the centralized approach, a CxC is equipped with the Interfaces, listed in Table 3.
This entity also needs an additional Broker detection interface, which is counterpart of the Consumer Detection Interface, located on a CxB.Additionally each Broker need an interface to communicate with other CxBs.But before a CxB is able to communicate with another CxB, a detection process is to be carried out.Therefore, a CxB sends a broadcast with its own address and 135 waits for response.Another issue is the implementation of a context subscription interface for enabling services.This interface must be able to allow CxCs to subscribe to context for periodic as well as event-triggered data transfer.

Context Consumer CxC
A Context Consumer is an entity which uses context data for its actual purpose.This can be, for example, an actuator for steering a roller blind or the heater.But for developing of our system architecture, we didn't make any restrictions.This 145 offers the possibility to include any kind of services into the platform.For the centralized approach, a CxC is equipped with the Interfaces, listed in Table 3.
An important issue is the integration and provision of services.Services are software components to implement any kind of functionality. Figure 3 shows an example the princi-155 pal structure of providing cloud-/web-based services to distributed environment.With this system, a user is able to add or remove functionalities to the system without any additional hardware.Further more functionalities can be moved to the "Cloud", in 160 other words, external servers provide most of the necessary services and the user needs only the basic system.Further functionalities can be bought or rented if required.A user also has the possibility to provide own sensor data or offer own services for public use.With this concept 165 the privacy of a user is ensured and he can decide, which data/information should be private or public.

Services
An important issue is the integration and provision of services.Services are software components to implement any kind of functionality. Figure 3 shows an example the principal structure of providing cloud-/web-based services to distributed environment.
With this system, a user is able to add or remove functionalities to the system without any additional hardware.Further more functionalities can be moved to the "Cloud", in other words, external servers provide most of the necessary services and the user needs only the basic system.Further functionalities can be bought or rented if required.
A user also has the possibility to provide own sensor data or offer own services for public use.With this concept the privacy of a user is ensured and he can decide, which data/information should be private or public.
As already mentioned, the centralized broker architecture is not new and has been studied in several projects.Services offer the possibility to maintain various kinds of tools.A user can subscribe to a service and adjust the service behaviour according to his demand.Therefore the service has to request or subscribe for the necessary context information.With this data, a service is able to trigger an event based on the users adjustments.Each event will request the address of the appropriate CxC and query for the requested data.All kind of data transmission is performed via TCP/IP in a XML coded scheme.
This approach provides the possibility to move software components, especially computationally intensive processes to the "Cloud".For our system, it doesn't matter how the cloud looks like, or is implemented, respectively.We handle it as a black box but in most cases it will be implemented as a software-service on an external server located in the internet i.e. in the "Cloud".

Data transmission
An example for data transmission is given in Fig. 4. It shows the automatic detection of a Smart Home Platform (SHP).

Data Transmission
An example for data transmission is given in Figure 4.It shows the automatic detection of a Smart Home Platform (SHP).As already explained, all the communication between the entities will be done by a XML derivate Language called ContextML (CML).In this paper we will not provide details on CML, however, refer interested to (Knappmeyer, 2010).

Context Prediction and Situation Detection
To make a Smart Home Platform as attractive as possible for a consumer, most of the functions should be automatically performed and installation effort should be as low as possible.To deploy such a SHP in a fully automated manner, it is necessary to detect situation or to predict them.Con-200 sequently it is necessary to predict context information and to combine the data for gathering new findings.To achieve this goal, different concepts are available to recognize a situation.But first, we define the term "situation": "A situation -Consideration of approximate inference methods (e.g. Monte Carlo algorithm) 220 Figure 5 shows an example for a Bayesian network and models the light automation.The room is equipped with different kind of sensors (e.g.movement, temperature, ...), consequently the system is able to detect if somebody is in the room.If movement detection is true, the light is switched on.A weakness respectively a problem is the time how long the room is in use.This results in the problem, how long should we turn on the light after a movement?If there is no movement, has the person left the room or is she/he still sitting inside the room?If we describe the system with a 230 fixed on-time, we get the graph in Figure 6.
To get an energy efficient system, the time difference between the time of movement and the light-on time should be minimized.Figure 6 shows that systems with fixed times are not able to provide satisfying results.Furthermore gen-235 eral concepts to provide adaptive system behaviour need to be developed.In case of a smart home platform, most of the system parameters depend on the users behaviour and are function of time.To ensure such a behaviour, we use a Finite State Machine and combine this with a Bayesian Network.

240
The following subsections will describe our model in detail.As already explained, all the communication between the entities will be done by a XML derivate Language called ContextML (CML).In this paper we will not provide details on CML, however, refer interested to (Knappmeyer, 2010).

Context prediction and situation detection
To make a Smart Home Platform as attractive as possible for a consumer, most of the functions should be automatically performed and installation effort should be as low as possible.To deploy such a SHP in a fully automated manner, it is necessary to detect situation or to predict them.Consequently it is necessary to predict context information and to combine the data for gathering new findings.To achieve this goal, different concepts are available to recognize a situation.But first, we define the term "situation": "A situation is an abstraction for a pattern of observations made by a distributed system such as a sensor network" (Cardell, 2010).Therefore different recognition algorithms are available: The goal of such a complex system is the Combined observations of the individual sensor nodes yield spatial-temporal map of the monitored environment.With this data a service is able to adopt the system behaviour to the users preferences.
To detect a dynamic situation, it is essential to select an appropriate modelling method.Two approaches are adequate for this usage: -Construction of appropriate Bayesian networks -Consideration of approximate inference methods (e.g.Monte Carlo algorithm) As already explained, all the communication between the entities will be done by a XML derivate Language called ContextML (CML).In this paper we will not provide details on CML, however, refer interested to (Knappmeyer, 2010).

Context Prediction and Situation Detection 195
To make a Smart Home Platform as attractive as possible for a consumer, most of the functions should be automatically performed and installation effort should be as low as possible.To deploy such a SHP in a fully automated manner, it is necessary to detect situation or to predict them.Con-200 sequently it is necessary to predict context information and to combine the data for gathering new findings.To achieve this goal, different concepts are available to recognize a situation.But first, we define the term "situation": "A situation Figure 5 shows an example for a Bayesian network and models the light automation.The room is equipped with different kind of sensors (e.g.movement, temperature, ...), consequently the system is able to detect if somebody is in the room.If movement detection is true, the light is switched on.To get an energy efficient system, the time difference between the time of movement and the light-on time should be minimized.Figure 6 shows that systems with fixed times are not able to provide satisfying results.Furthermore gen-235 eral concepts to provide adaptive system behaviour need to be developed.In case of a smart home platform, most of the system parameters depend on the users behaviour and are function of time.To ensure such a behaviour, we use a Finite State Machine and combine this with a Bayesian Network.

240
The following subsections will describe our model in detail.

Finite State Model
A Finite State Model is a mathematical model that is used to design computer programs and digital logic circuits.As already explained above, the system behaviour is simplified 245 into a finite amount of states.A transition from one state to another can only initiated by a triggering event or a changing condition.As result, we sustain a model, similar to Figure 5.

Bayesian Network
In our case, Bayesian Networks can be seen as an extension 250 of the finite state model.The additional part or the extensions are the conditional probability tables.To make such a system adaptive respectively intelligent, these table are not fixed and must depend on external parameters.In our movement example, time seems to be a very important parameter 255 because most of the human behaviour depends on the daytime.Therefore appropriate model for the users behaviour have to be found.

Conclusions
In this paper we introduced the so called Smart Home Plat- Figure 5 shows an example for a Bayesian network and models the light automation.The room is equipped with different kind of sensors (e.g.movement, temperature, ...), consequently the system is able to detect if somebody is in the room.If movement detection is true, the light is switched on.A weakness respectively a problem is the time how long the room is in use.This results in the problem, how long should we turn on the light after a movement?If there is no movement, has the person left the room or is she/he still sitting inside the room?If we describe the system with a fixed on-time, we get the graph in Fig. 6.
To get an energy efficient system, the time difference between the time of movement and the light-on time should be minimized.Figure 6 shows that systems with fixed times are not able to provide satisfying results.Furthermore general concepts to provide adaptive system behaviour need to be developed.In case of a smart home platform, most of the system parameters depend on the users behaviour and are function of time.To ensure such a behaviour, we use a Finite State Machine and combine this with a Bayesian Network.The following subsections will describe our model in detail.

Finite state model
A Finite State Model is a mathematical model that is used to design computer programs and digital logic circuits.As already explained above, the system behaviour is simplified into a finite amount of states.A transition from one state to another can only initiated by a triggering event or a changing condition.As result, we sustain a model, similar to Fig. 5.

Bayesian network
In our case, Bayesian Networks can be seen as an extension of the finite state model.The additional part or the extensions are the conditional probability tables.To make such a system adaptive respectively intelligent, these table are not fixed and must depend on external parameters.In our movement example, time seems to be a very important parameter because most of the human behaviour depends on the daytime.Therefore appropriate model for the userB4s behaviour have to be found.

Conclusions
In this paper we introduced the so called Smart Home Platform and listed the requirements to the Context Management Platform.Furthermore, we have shown, that it is possible to extend available centralized broker architectures to distributed architectures with adding interfaces to the available components.A benefit of this approach is, that available interfaces can be used without any change.The new introduced interfaces can use the available communication protocol which is based on ContextML.Additionally the architecture has been extended with services that offer the user to add functionalities to the system without any change of the hardware.
Furthermore, we have shown approaches to predict Context and to detect situations.This enables an intelligent behaviour of the Smart Home Platform
the plug and play requirement, an additional Broker Detection Interface is necessary.This Interface is the counterpart to the Provider Detection Interface in a CxB.The detailed function of a CxB detection is described 130 in ??. 140

Table 1 .
Interfaces of Centralized Context Broker

Table 1 .
Interfaces of Centralized Context Broker It is used to detect adjacent CxBs and to request their address to establish a communication.Additionally, each CxB has to provide an Provider Detection interface and a Consumer Detection Interface.

Table 1 .
Interfaces of Centralized Context Broker.

Table 2 .
Interfaces of Centralized Context Provider.

Table 3 .
Interfaces of Centralized Context Consumer.