ThinkHome Energy Efficiency in Future Smart Homes

The worldwide energy demand is rising constantly. While many sectors (e.g., transport, production industry) have been trying to reduce their energy consumption for several years, sustainability in the residential domain must still be considered being in its infancy. This stems at least partly from the fact that, although awareness and motivation to save energy are nowadays typically existent among home owners, adequate technological support for the users is greatly lacking. This concerns foremost the unavailability of dedicated, comprehensive systems that support an energy-efficient operation of a home or building. Considering the rapidly increasing energy costs, reduced energy consumption has economic benefits but it also pays on a macroscopic level, where national and international environmental goals and laws have to be fulfilled.

Realizing an energy-efficient building operation is closely tied to the employment of building automation systems (BAS), which are considered as an almost mandatory condition for the sustainable (low-energy, low-emission) home or building [1]. Hence, over the past decade, smart homes have become an emerging issue in academic research as well as in the residential building sector. The tempting vision of smart control over environments motivates home owners to integrate automation technology into their homes with the promising effects of increased comfort, peace of mind, and reduced operational costs. Still, the mere installation of such systems does not automatically constitute a perfect solution. In fact, much of the potential that would be available through BAS in the smart home lies fallow. This is for several reasons. Control strategies that link sensors and actuators are not as powerful and flexible as they should be. Furthermore, tuning the control precisely to the requirements and also preferences of its users is a task reserved to experts with profound system knowledge. Additionally, it requires to take into account the characteristics of building structure, building automation equipment, and other influence factors. Thus, optimizations of (both new and existing) systems are hardly ever realized in full due to the large effort encountered. For the same reason, necessary readjustments to new or changed requirements (e.g., when a room is remodeled from office to bedroom) are foregone almost as a rule once the system has been installed.

Another shortcoming that BAS are facing today is that the promising integration of household appliances (white goods) and consumer electronics (brown goods) is not happening pervasively, if at all. The reason is that the integration of these devices is not trivial at the physical layer (e.g., wired-wireless), nor at the network layer (communication), neither at the application level (data semantics). Additionally, such an extension of the BAS scope obviously increases the overall system complexity. However, for full resource conservation, it is mandatory to include major energy consumers such as household appliances in novel control strategies of the automation system.

Apart from the technical reasons that counteract optimal system performance, also organizational factors are influential. Due to the complexity of the systems and the underlying physical processes that shall be controlled (e.g., thermal comfort control), users are often unable to fully understand their system and to apprehend the high number of influence factors that are connected to it (parameters such as building structure, environmental conditions, system/device capabilities, etc.).

To fully unleash the environmental potential of BAS, a new approach to the problem that eliminates the aforementioned shortcomings is imperatively needed. Hence, a novel system concept is required that transparently integrates all different systems of a (smart) home, makes available all important parameters and information, and enables advanced use cases that cater equally for both, energy efficiency and user comfort. Most important, the system needs to support the inhabitants (e.g., to feel comfortable or to save energy) but it must never patronize them. The system therefore has to be able to perceive its environment and to be aware of the users and their actions, thus being able to learn from and adjust to them.

A novel approach to realize the smart, minimum energy, green building is taken in this work. The proposed home system concept is termed ThinkHome. According to its name, ThinkHome aims at the realization of an intelligent home by introducing semantic context and artificial intelligence (AI) in this future home. The advanced intelligence is realized by means of control strategies that are embedded and cooperate fairly within the highly interoperable ThinkHome system structure that provides transparent access to data, users, building systems, and miscellaneous other services.

In the remainder of the paper, the complete ThinkHome system concept is presented in greater detail. In Section 2, the system architecture is described and system building blocks, related mechanisms, and goals of ThinkHome are introduced. The potential of the system is then illustrated by means of use cases in Section 3. The main system parts, a knowledge base and a multiagent system, are explained in Sections 4 and 5, respectively. In Section 6, an example of an intelligent ThinkHome control strategy is presented, evaluated, and compared with other approaches. In the following section, the ThinkHome approach is set in context to related work. Finally, the work is concluded and an outlook on future challenges is given in Section 8.

The ThinkHome system is designed under two main premises: it shall ensure energy efficiency and comfort optimization. While a focus on energy is easily justified with sustainability and economic considerations, the reason to prominently feature comfort originates from the fact that comfort is a main decision criterion for home owners to employ expensive building automation technology. Thus, ThinkHome aims at providing a comprehensive system and architecture for sustainable next-generation buildings. It can be seen as a digital ecosystem due to its collaborative characteristic, where advanced methods and algorithms are applied in order to optimize control decisions as well as dedicated parts to facilitate information availability and access. The architecture of the system is designed to provide important characteristics such as flexibility, modularity, and compatibility in a native way. The underlying structure allows a quick extension, works on different building control standards, integrates devices from different domains formerly left out of BAS (e.g., household appliances), and can handle equipment from different manufacturers. Beyond these features, ThinkHome supports the optimized application of artificial intelligence methods to the building environment, focusing on relevant features like ubiquity, context awareness, conflict resolution, and self-learning capabilities. In this context, the Artificial Recognition System (ARS) project shall be mentioned, which covers many of these aspects and is a major topic in [2]. The works collected in the book operate on mechanisms originally coming from neuropsychology and psychoanalysis and have the common goal to provide computer systems with consciousness (e.g., for situation modeling)—an approach also tempting when thinking of smart homes.

The ThinkHome system moreover considers the building management from an holistic viewpoint, thus going far beyond optimizing each service or application independently, an integrated view that is also demanded by Borggaard et al. [3]. Sustainable operation in ThinkHome is realized by intelligent control strategies that take into consideration a multitude of parameters ranging from building structure over weather forecast data to personalized user preferences. The comprehensive system acts autonomously and automatically towards the system goals and assists the users to reach their preferred building conditions in the most energy efficient way. Thereby, all energy consumer in the home are targeted, that is, the system is not limited to the traditional BAS domains heating, ventilation and air-conditioning, and lighting/shading, but it also considers consumer electronics and household appliances.

In order to implement the previous characteristics, the ThinkHome architecture features two main parts, a comprehensive knowledge base (KB) and a multiagent system (MAS). As shown in Figure 1, the system is completed by the global goal component that is symbolically located on top of the system as well as a historization (data storage) system in the bottom right corner.

The task of the knowledge base is to intelligently maintain all relevant concepts that are considered to be influence factors in a smart home. Thus, it stores details on users like their preferences and profiles, current occupancy and activities (i.e., context), as well as schedules. Likewise, also weather data and building conditions are conceptualized mainly to enable dynamic optimizations. Furthermore, the KB keeps information about the building: it integrates data already collected during the architectural conception and construction process of a building, in particular comprising data on the building structure, building orientation, used materials, and related properties of these items. It also stores information on all resources (e.g., devices) that are available within the smart home, including energy-related aspects. Viewed in a global context, the KB is the foundation for the MAS and basically supports the system to infer the most appropriate building control strategies, that is, those that are most energy efficient and comfort oriented in the current situation. Additionally, the KB functions as an abstraction layer of the underlying BAS. As it is not relevant for control strategies to be aware of the concrete installations in the building, but rather of the services they offer, the KB provides a generic and integrated view of the different devices, networks and related functionalities to the higher system part. Taken together, this part of the system represents the shared vocabulary used by the MAS for execution of advanced control strategies. It is therefore fundamental in grounding ThinkHome.

Located on top of the KB, the intelligence part of the system is implemented as a multiagent system. This approach was chosen for two reasons. First, MAS is a powerful logical methodology that perfectly complements the previously identified necessities and requirements, mainly in terms of distributed intelligence, for providing encapsulation on a functional level and for natively supporting communication among different system parts. Second, the use of the agent paradigm also brings along independent evolution, exchange, and maintenance of the autonomous parts that are implemented as agents. The use of well-defined interfaces helps to retain the required autonomy and even permits a possible local distribution of components.

During operation, the MAS makes use of the data and knowledge about the system that is stored either explicitly or that can be inferred from the ontology model in the KB. This variety of information allows the MAS to execute advanced control algorithms and strategies that are enriched by a multitude of influence parameters and mainly rely on mechanisms from artificial intelligence (AI). These control strategies are embedded in different agents, where each agent pursues its own task and goals but can cooperate with other agents to also solve more complex problems. In order to be aware of the environment, the agents retrieve information from the knowledge base. The KB always keeps a current representation of the system state (i.e., a process image), while historical data are collected in a dedicated back-end data storage system (cf. Figure 1). Other dedicated agents realize further interfaces of the overall system to the users, the BAS, and other miscellaneous services (e.g., remote server synchronization).

ThinkHome's structure, based on a smart and vivid agent information exchange, also facilitates the integration of context awareness methods and self-learning capabilities. Agents initiate actions relying on data from the smart home stored in the knowledge base or the history storage. This data can later also be analyzed to create profiles or benchmarks, compute predictions, refine the agent parameters (believes, goals), select control algorithms, or tune their parameters.

The comprehensive ThinkHome approach also considers two aspects frequently forgotten in other systems: a usable interaction between the system and its users and an unobtrusive yet ubiquitous integration of the smart system in the daily context. Both promise a higher user acceptance and satisfaction with the system, but demand that the system is capable of automatic and mostly autonomous control of the environment. Unobtrusive action of the system is for example enforced with the help of learning and context awareness mechanisms that help the system to transparently act on behalf of its users without demanding any direct interaction of them. One example on how these properties can be implemented within ThinkHome is outlined in Section 6, where the smart home tries to learn from the users by just observing them in order to be able to predict their desires, act ahead autonomously, and finally also assess their level of satisfaction.

ThinkHome also passively contributes to energy efficiency, because users may take part actively in the control process, if they wish to. With the help of the extensive amount of data available in the system, users can be provided with periodical energy consumption reports and hence get feedback on their actions which can increase their energy awareness. One possible and particularly unobtrusive way to deliver this feedback is ambient displays, a technology that visualizes diverse aspects of energy or water consumption with the help of, for example, colors that then function as more abstract consumption indicators [4]. The ThinkHome system can also provide information on how to conserve energy by means of practical savings advices, for example, by recommending to open the shades before turning on artificial lighting. On a larger scale, it is also envisioned that multiple ThinkHome systems (installed in different homes) could be linked and exchange data on new control strategies, compare historic data and trends, or even cooperate to achieve certain goals (e.g., implement novel demand side management concepts) [5]. Finally, the combined ontology-based MAS approach is especially beneficial considering the complexity and heterogeneity of the involved disciplines: home automation, knowledge representation, modeling and processing, AI, machine-learning, and context awareness. Mechanisms from all these domains have to be coupled in an intelligent fashion to implement an advantageous control, a challenge solved by the ThinkHome system architecture. The comprehensive system approach is completed by a seamless integration of the intelligent MAS and the knowledge base pursuing an open and well-defined interface definition already from the start.

It can be seen that the wide variety of parameters harvested by the ThinkHome system can apparently lead to an energy-optimized building control if used in a sensible way. This system concept comprises facts that up to now have rarely been included in any smart home approach, thus further promoting the benefits that smart homes and modern automation systems have to offer nowadays. Due to the diversity of considered information, even alternative control strategies that consume very few or no energy (e.g., opening a window) can be weighted and taken into account to lessen energy expenditure.

To justify a new technology like ThinkHome, it is important to identify useful applications and scenarios for which the system can provide substantial improvements. The following section therefore investigates different use case classes which exhibit a high energy savings potential especially in the residential sector.

In information systems, the division of a domain into relevant concepts and its formal representation is known as ontology [12]. The ThinkHome ontology can be seen as basis for the proposed system. All data has to be stored and provided in an intelligent way, supplying the system with needed knowledge. For the storage of information it was decided to use the Web Ontology Language (OWL), mainly because of its formal definition and reasoning capabilities. Furthermore, OWL is one major technology of the so-called Semantic Web. This additionally supports the openness of the ThinkHome knowledge representation.

As already mentioned, an OWL datastore contains different constructs to create a formal representation of knowledge. The model, which is similar to a database scheme in database design, is constructed by concepts and properties. A concept defines a general idea of a possible item in the defined knowledge base. For the suggested ThinkHome ontology, such concepts are for example WeatherInformation including all data concerning immediate exterior circumstances or HumanActor describing the group of human system users. In most ontologies constructed from scratch, it is desired to organize the identified concepts in a subsumption hierarchy, which means in a superclass/subclass connection. Properties are the relations between these concepts and can be differentiated in two kinds: object properties which establish connections between different concepts and datatype properties which connect concepts with values of a specified datatype. The last basic elements which represent the data are individuals. These are distinct from the conceptual model and act as concrete instantiations. For example, in the field of building information this would be a particular wall separating two defined rooms or a specific window type.

In addition to defining simple relations, several logical restrictions can be put on these basic elements as to create more complex dependencies. One example would be an anonymous superclass restriction, which allows membership in a class to be defined through logically combined properties of a set of individuals.

OWL, in the majority of the cases, is restricted to some form of logic such as description logics (DL) in order to make it decidable. This means when DL is enforced, a so-called DL-reasoner (e.g., Pellet [13]) can infer new information from the ontology. As OWL is an open standard, ontology reuse as well as integration into other projects is possible.

The vision of ThinkHome is to create a comprehensive knowledge base which includes all the different concepts needed to realize energy efficient, intelligent control mechanisms. The information base brings together different branches of control information which all can be seen as universe of discourse for the intelligent multiagent system. The multiagent society can subsequently query the facts stored in the ontology, thus enabling intelligent decision making.

Figure 2 shows the main branches of the ontology. This division may not be seen as physical separation of knowledge, but merely as logical segmentation of core concepts. First and foremost the storage of building information is of great importance. As already discussed in Section 3, the storage of building characteristics can support optimized control strategies striving for energy-efficient operation of the smart home. It is not feasible for a user to enter all these values manually due to the huge effort and lack of knowledge. Thus, an automatic approach is favored. Therefore, for the ThinkHome system, the inclusion of data stored in a building information model (BIM) was considered.

A BIM is a data exchange format used by architects, construction engineers, and building physicists among other parties involved in the construction process of a building. Each of these stakeholders adds domain knowledge to a common model which keeps information of the whole building lifecycle (except the operational phase). As a consequence, the model serves as a valuable source of information. There exist several open formats of BIM, where the Industry Foundation Classes (IFC) and the Green Building XML (gbXML) can be seen as the most popular ones today [14]. gbXML was chosen for application in ThinkHome, because the format focuses on the exchange of information for energy simulation and calculation, and therefore stores facts that are helpful for the focal point of the proposed system. Through the information retrieved from the BIM, we obtain enough concepts to model the whole building including wall layers, window sizes and types, door sizes and positions, room area and volume as well as assigned room purpose and orientation of the building. Subsequently, exact calculation of the building behavior with respect to thermal mass and room arrangement becomes possible. This is especially beneficial for an energy-efficient provision of thermal comfort (cf. Section 3).

In the ThinkHome project, a transformation from gbXML to the OWL language format was carried out by Extensible Stylesheet Language Transformation (XSLT) documents. This straightforward approach allows to integrate all data already collected by former engineering parties and store it in an intelligent way as OWL document. The Web Ontology Language allows to classify the concepts retrieved from gbXML and, due to the formal definition of the language, also reasoning on the data becomes possible.

Apart from concepts relating to the building, also actor information about the users of the system has to be considered. Users in this case can be either human users, but also system agents. The reason for this is that the ontology builds the foundation of a multiagent system in which intelligent actors can take autonomous actions on behalf of the users. For humans, the knowledge base must know different characteristics (e.g., age, gender) and also keep a user profile (cf. Sections 5 and 6). In the user profile, the preferences of the users are stored. These profiles are an aggregation of atomic actions residing in the ontology as processes.

A process is a concept containing elementary operations that are used to describe the users' activities. Certainly also basic system processes are kept in this part of the ontology. Very important, with respect to the use cases depicted earlier, is to consider exterior influences. These weather and climate data can be used to infer the proper action and perform tasks most energy efficiently. In addition, this information can be exploited in order to guarantee user comfort, for example, by natural lighting through sunlight (cf. Section 3). Comfort information is a smaller part of the ontology which nevertheless can be seen as core concept: it stores various aggregations of elementary measurement units (e.g., temperature, humidity, luminosity) and therefore provides a notion of comfort to the system. Most of the measures can be retrieved from the building information unit, as the data imported from gbXML includes a vast amount of measurement units of any kind. In the energy information branch reside different available energy providers and their trading conditions. This information is especially valuable when envisioning the integration of the ThinkHome system into a smart grid, as the ontology can provide the momentarily best option for energy consumption or recovery. This part of the ontology also keeps energy schedules for different occupancy states and scenarios (e.g., day, night, weekends, holidays) and this way allows to anticipate consumption peaks. Furthermore, it is important to have an idea of the provided building automation services, as well as equipment available in the smart home. This resource information branch includes white goods, brown goods, and automation networks hosting lighting, shading as well as heating, ventilation, and air conditioning (HVAC) devices. As the automation networks can be of different types, protocols, and manufacturers, it is valuable to represent them as concepts in an ontology. This way, their definition can be generalized, which in turn supports the transparent integration and communication across the different networks. In addition, energy producers like solar collectors or a thermal heat pump are stored in this section. Hence, a complete model of the energy consuming and producing landscape available in the building is depicted in the knowledge base [15].

Especially for the last core section, approaches dealing with dynamic data and historization of information have to be kept in mind. A recording of historic sensor data can be valuable for performing trend analysis or generating updated occupancy profiles as pointed out in Section 6. As the described knowledge base can only provide an instantaneous reflection of the system's state, a proper transition into a historical permanent storage becomes necessary. Obviously, not all of the information needs to be represented as historical data as large amounts of information are known to be highly static (e.g., building information). Therefore, just a subpart of the global knowledge base has to be considered for historization. Possible comprehensive environments for managing large-scale ontologies as RDF triple store are the Virtuoso Universal Server Project [16], as well as the JENA Semantic Web Framework [17].

4.1. Benefits of Using OWL

4.1.1. Query Language

Additionally to an intelligent storage of building and process information, it is of course important to be able to question the knowledge store for these data. Just like SQL being the query language of relational database systems, SPARQL [18] is the interrogation mechanism of the Resource Description Framework (RDF). Furthermore, as RDF is the foundation of OWL, the SPARQL language can subsequently be used to query the ThinkHome knowledge base. RDF stores data as triples in a labeled-directed graph. As a consequence, SPARQL works on graphs and triples which can be combined using variables. For the ThinkHome system, it becomes possible to retrieve selected information about the building and ongoing processes with the help of this query language. For example, with the information retrieved from gbXML and stored in the ontology, it becomes possible to find out specific information of a room or the whole building. A simple SPARQL query can extract areas and volumes as well as the appropriate measurement units of the different rooms in the building (cf. Listing 1).

Listing 1: SPARQL Query: Room Areas and Volumes.

PREFIX gbOWL:<http://www.auto.tuwien.ac.at/

gbBuilding.owl#>

SELECT ?id ?name ?a ?aunit ?vol ?volunit

WHERE

     { ?gbXML gbOWL:hasAreaUnitValue ?aunit.

   ?gbXML gbOWL:hasVolumeUnitValue ?volunit.

   ?area gbOWL:hasNativeValue ?a.

   ?volume gbOWL:hasNativeValue ?vol.

   ?spc gbOWL:containsArea ?area.

   ?spc gbOWL:containsVolume ?volume.

   ?spc gbOWL:hasIdValue ?id.

   ?spc gbOWL:hasNameValue ?name }

This information alone can already be used to optimize the on/off heating schedule according to the space that has to be heated. Similar queries can be created to determine which rooms are adjacent to each other and to obtain the thickness as well as material of interior and exterior walls. With the data retrieved from the gbXML model, it is also possible to exactly determine the position of windows and doors and therefore take sunlight into account to reach thermal and visual comfort as previously discussed in Section 3.

An update of specific data triples in the ontology can be accomplished by SPARQL/Update queries (SPARUL). With the help of this extension of the SPARQL language, it becomes possible to delete and insert triples in RDF data models. Although this addition is not yet a standard for the World Wide Web Consortium (W3C), it is already supported by major Semantic Web technologies like the JENA Semantic Web Framework and the Virtuoso server.

4.1.2. Inference

One of the main concepts of OWL ontologies is inference. This ability can be used to perform subsumption reasoning as well as inferring new information out of the stored data. An example is considering weather conditions when choosing an appropriate cooling method. Not every cooling technique is to be allowed for all different weather situations, as it is obviously not desired to rely on natural ventilation when a thunderstorm with heavy rain and wind is currently taking place outside. Therefore, possible weather situations are classified and stored in the ThinkHome ontology as can be seen in Figure 3. The concepts shown are general classifications, as the particular weather conditions in OWL are stored as individuals. As already mentioned, it is possible to reason upon the stored data with the help of a reasoner and subsequently infer new information.

For example, if currently a badweather condition is experienced and an agent pursues a cooling task for a specific room, it is beneficial to know which cooling methods are possible with respect to the current WeatherSituation. Some concept in the ontology can model exactly this situation (cf. Figure 4). In this case, a class CoolingBadCold is provided, which members are defined to be in the class which permits a bad and cold WeatherSituation and are not heating processes (as the agent is searching for current possibilities to cool the room). Therefore, all individuals of this anonymous superclass are to be members of the defined class CoolingBadCold. As can be seen in the members section of Figure 4, the reasoning mechanism of the ontology can automatically infer two individuals, which denote processes to be possible in this situation: AirCondition and VentilationExteriorAir. Another cooling process defined in the ontology, namely, OpenWindow, is not inferred to be a member as this action should just be performed in a calm WeatherSituation.

This use case shall underline the manifold possibilities that emerge with the application of an OWL ontology. SPARQL queries, as described before, tend to become inherently easier when ontology reasoning capabilities are used and properly defined concepts are provided. Besides, the described model allows to integrate new weather situations or system processes into the model, which can subsequently be included in the result set according to the logical dependencies between the OWL classes and properties. This makes the ThinkHome system highly flexible, as, for example, different climates and weather conditions can easily be added.

To realize optimized control strategies that allow maximizing energy efficiency and user comfort simultaneously and automatically, methods from AI need to be employed. An excellent means are multiagent systems, that are not only a software engineering paradigm, but a method that inherently supports distributed intelligence, interaction and cooperation to act towards defined goals [19]. Agent-based systems are further characterized by cooperative problem solving in which some or all agents may take part. Moreover, MAS is designed to encapsulate software parts in agents that can be maintained or exchanged independently and easily.

In ThinkHome, the MAS has the main task to realize advanced control strategies. Thus, it bears the artificial intelligence part in it, which decides on the control strategies and their parameters. Furthermore, it integrates auxiliary data sources and implements context inference as well as conflict resolution services. The MAS is inhabited by a number of specialized agents that are responsible of solving different problem aspects. These agents follow the Belief-Desire-Intention (BDI) architecture model [20]. The overall solution is obtained by cooperation among the agents to solve some problem where some or all agents may take part. The set of different agents is called agent society. All agents are interconnected by means of an agent-based framework that hosts the agents and provides services for communication and data exchange among them. A prominent example of such a framework is the Java Agent DEvelopment Framework (JADE) [21].

The sustainable operation of ThinkHome is achieved by the system constantly striving to perform an optimal mapping between the current smart home state, the given user goals (i.e., user comfort), and energy efficiency. To obtain these data, access to the knowledge base is required. Therefore, the agent-based system implements interfaces to the underlying ontology. For interaction with the physical environment, also an interface to the building automation systems of the smart home is designed.

The ThinkHome MAS is specified following the Prometheus methodology [22]. Prometheus provides formal guidelines and a formal notation for a detailed agent and system architecture specification. It proposes an iterative process, during which several design artifacts are created. Prometheus accompanies the specification process from the begin of the design until the implementation. Throughout the specification process, support by a specific design tool named Prometheus Design Tool (PDT (Available at: http://www.cs.rmit.edu.au/agents/pdt/)) is available. At the end, a formal specification of the multiagent system is obtained, that can now be transformed into programming concepts of different agent-oriented programming languages.

The procedure of the Prometheus methodology is well summarized by Gascuena and Fernandez-Caballero in [23]. Following the methodology, the first step is a (informal) description of the system purpose and functionality called "system specification phase." The main goal is to first sketch the system functionality and purpose, and afterwards to refine it with the help of use case scenarios. In this work, the system description can be found in Section 2 and a selection of use case scenarios is presented in Section 3. Based on the system overview, the major system goals are derived and hierarchically grouped in the next step. This leads to the goal overview diagram shown in Figure 5, which presents a hierarchical goal decomposition of the system. Goals are represented as ovals, and arrows emerging from one goal indicate further subgoals. Below a goal, the key words AND or OR are shown that indicate whether all subgoals must be fulfilled to achieve the root goal (AND) or if it is sufficient that one (or more) subgoals are achieved (OR). During this design stage, Prometheus puts the focus more on completeness (i.e., to cover all system goals) than on full correctness of the hierarchy or the decomposition, respectively.

Once the system specification exists, the next step of the methodology, the "architectural design phase," starts. Now it is important to derive the agents out of the previous artifacts, and to model their interaction. An important outcome of this phase is the data coupling diagram which prepares the aggregation of system functions into different agents. The intention is to identify functionalities that logically belong together (i.e., that use the same data and are coupled) and that thus can be modeled and implemented as one agent type. The outcome is a set of agent roles of the system. Among the agent society, a very loose coupling is targeted (e.g., to allow their distribution to different devices), while within a single agent a high cohesion is sought which indicates that the related functionalities have been grouped (e.g., beneficial for the data flow in the system). In ThinkHome, several different agent roles can be differentiated. The following list gives an overview of the main roles (Note, that a single agent type may represent a set of agents that together solve the problem indicated by the name.) that are mandatory for a successful operation of our system. The different agent tasks are described in natural language.

(i)Control Agent. The Control Agent is the core point for the sustainable, energy-efficient operation of the smart home. It is responsible for execution of the intelligent control strategies that control the building state. For this purpose, the agent takes into consideration the global goals, user preferences, the current system state, and auxiliary data (e.g., current solar radiation) to compute appropriate actions for the underlying building automation system. The control decisions will be made upon both simple control algorithms as well as using artificially intelligent ones, for example, artificial neural networks or fuzzy logic [24]. To master this crucial task, the Control Agent acquires information from several other agents in the system, striving to get a global view of the whole system state.

For example, the agent could be informed that a user will come home in one hour (cf. Section 6, where one possibility to generate this information, namely, profile generation, is presented). The control agent then obtains user comfort values, current sensor values from the building automation system, and additional semantic information that is contained in the KB. The latter is used to enrich the available data and hence get a more complete model of the system state (e.g., request a list of current cooling possibilities for the living room). After computation of an appropriate control strategy, it can be executed by the automation system.

(ii)User Agent. The User Agent acts on behalf of users and has the goal to enforce comfortable environmental conditions for its owner. Hence, each system user has its own user agent which advocates the preferences of its user within the system. The design of the user agent follows the notion that to control the indoor conditions of a building in an energy-efficient way, it is most important to reduce the control efforts to the lowest amount possible so that the users still feel comfortable. Therefore, it is mandatory to be aware of the presence, preferences, and habits of all residents, and also to predict future user actions (e.g., computing an occupancy profile for a user). In ThinkHome, this information is kept in the User Agent. This agent further embeds a learning component that is responsible for learning the preferred environmental conditions, habits as well as typical situations and scenarios of its owner during operation. In this task, it is supported by the Context Inference Agent. Additionally, the agent manages a user profile which mainly covers comfort and other preferences, schedules as well as global parameters (e.g., the importance of comfort versus energy efficiency to this user). It also accepts user feedback and provides this feedback to the control agent which can incorporate it in its control strategy.

Since not all possible users are known to the system a priori, persons that are not registered in ThinkHome (e.g., guests) are assigned an anonymous, temporary User Agent that assumes default values and is dispatched to cater for his/her needs during the visit.

(iii)Global Goals Agent. Similar to the User Agent, this agent advocates the global goals when control decisions shall be made in the MAS. It is a key component for the realization of energy-efficient building operation. While the whole MAS is designed to work collectively towards the global goals, this agent strives to enforce certain global goals policies. For example, if energy efficiency is given a very high priority by the user, the agent could insist to give the comfort parameters less importance (or inform the user if the deviation of both goals exceeds a threshold). It is therefore also concerned with, for example, the calculation of the energy impact of certain measures, so that it can recommend or promote certain actions to the control agent.

(iv)Context Inference Agent. The agent can set actions in context with users, location, and time, that is, it can identify activities and build a model of the current situation. This context inference is required for an adaptive, intelligent building control. For example, persons can be identified when entering the building, tracked within the building, and their location is continuously reported to other agents. These can then act upon this information, for example, turn off the lights when all persons left a room. Furthermore, it is important to put user actions in context with the current building state in order to build a better user profile. For example, someone may not like to have the window tilted during nighttime and therefore close it manually. The system can recognize this action and relate it to a control decision that was executed automatically just before and can thus adapt the control strategy to comply to this user's preference.

(v)Auxiliary Data Agent. This agent provides an interface to integrate additional data from miscellaneous sources, for example, from Internet-based web services. A typical example is the retrieval of weather forecasts and also severe weather warnings which can be obtained from a local weather station or over the Internet. Another possibility is the access of current energy prices, the announcement of current excess energy to other ThinkHome houses, or the implementation of demand response mechanisms [25].

(vi)KB Interface Agent. The agent interfaces to the knowledge base and handles all data exchange across the system parts. If initiated by other agents, it uses SPARQL queries to extract information from the knowledge base. The obtained information is parsed, optimized for the use by the other agents, and communicated back to them. In the other direction, information may also flow from the MAS into the knowledge base. In this case, the process is simply reversed, that is, the information is received from other agents and transformed to comply with the knowledge base. For updating the ontology, SPARUL (SPARQL/Update) queries are used.

(vii)BAS Interface Agent. The BAS Interface Agent acts as interface between the agent society and the underlying automation system of the smart home. On one hand, this concerns the execution of the control strategies computed by the Control Agent. It therefore sends data to the BAS controllers to achieve or keep the desired environmental conditions in the building. On the other hand, it functions as a feedback interface from the building back to the ThinkHome system. This includes the sensing of process values (e.g., change of room temperature), initiating updates in the knowledge base, and generally collecting all information that is requested by the MAS from the automation devices.

The system specification phase ends with a detailed description of the agents, which also marks the end of the agent design. In the following "detailed design phase," Prometheus provides an approach on how to transform the design artifacts into concepts of the JACK agent programming language [26]. This step is obviously very implementation related and furthermore JACK technology specific. However, for the ThinkHome system, JACK does not constitute the first choice for programming the agents. This is mainly due to the fact that JACK is a commercial product, for which considerable license fees apply and the implementation of the framework is not openly available. Fortunately, the implementation of Prometheus agents is also possible in other agent frameworks, in fact the specification obtained from following the Prometheus methodology is generic enough to be implemented in most common agent frameworks. Therefore, the ThinkHome MAS will rely on other established technologies such as JADE or an improved version of JADE called AMES, that specifically targets automation systems [27].

The control strategies are the core part of the intelligent operation of a ThinkHome building. They are responsible for the calculation of all actions (switching commands, start/stop times and many other parameters) that are executed by the underlying building automation systems. The control strategies are implemented in a dedicated agent (cf. Section 5). Hence, they are embedded in the agent framework and can access all information that is available in the system, either directly, by communication, or even by cooperation with other agents. In this section, an example of a control strategy that provides increased comfort and simultaneously reduce the energy consumption is presented. For this purpose, an important aspect of the thermal comfort use case is taken up again, namely, the calculation of the setpoint temperature. The setpoint temperature defines the ideal temperature of some space, when heating or cooling is required. Normally, the setpoint temperature is a parameter defined by manual control. However, some buildings require a low level of heating during unoccupied periods to avoid condensation/frost damage or to prevent the building from becoming too cold while for others it may be more important to reduce peak heating requirements at startup. This lower temperature is referred to as set-back temperature. Setpoint temperature schedules then operate the heating equipment according to a (user) defined schedule at night-time, weekends, or holidays during the heating season. This self-regulation of heating and cooling systems is an interesting possibility that can be exploited to improve the energy performance. However, in a smart home system such as ThinkHome, a realization can be even more ambitious.

The proposed setpoint temperature strategy is based on the concept of profiles. The control strategy is implemented and tested within the ThinkHome framework. For evaluation purposes, a comparison by simulation of the following very common strategies is performed: activation of the heating system depending on simple occupancy data (On/off Strategy), controlling the heating system based on a schedule (Scheduled Strategy), and a combination of both of them (Combined Strategy). To obtain a quantitative assessment, also several energy and comfort performance indices are defined.

6.1. Profiles and Profile Generation

A profile is a set of characteristics or qualities that identify a type of behavior, thing, or person. As far as control theory is concerned, profiles help the control system to be aware of changes in a particular scenario in which it has to take decisions. Thus, profiles offer the control system abilities for better prediction and more context awareness. The use of profiles is based on the fact that inhabitants keep certain habits and trends. Once a control system is aware of users' habits at home, optimized strategies for reaching a good balance between comfort, and energy savings can be designed and implemented. The process of getting significant profiles is best supported by ubiquitous environments. A user's desire must be well understood and resulting patterns of specific behaviors must be thoroughly analyzed [28]. It is important to be aware that control algorithms that rely too much on learning from a user's behavior may run the risk of learning bad control strategies [29]. It is, however, also known, that most users behave in a conscious and consistent way [30].

In this approach, two kind of profiles are used: comfort temperature profiles and occupancy profiles. While the first class aims at representing the normal desired setpoint temperatures of the inhabitants, the second class pursues comfort as well as energy saving goals at the same time. Using occupancy profiles, the control strategy allows the smart system to predict occupancy and hence better adjust the heating or cooling status with respect to this additional data.

Within the MAS structure, the control agent who establishes the setpoint temperature embeds also the profile management (while the flexibility of the structure would allow a separation in a dedicated control agent and independent agents for each type of profile as well). As far as profiling is concerned, two distinct parts can be differentiated: the profile generator and a profile optimizer. Figure 6 depicts the different actors that take part in the whole process. It can be summarized as follows. Profiles or patterns are obtained from real data monitored for long time spans. The ThinkHome system may observe the energy usage by smart metering and user behavior by means of the information collected from sensors and with the help of context inference mechanisms. This information is stored in the history storage system (sensor database). At the end of each day, the profile generator takes the data of the whole day and generates a daily profile (corresponding to the passed day) which is also kept within the history storage system (profile database). As time passes, the daily profile count stored in the databases rises. Therefore, in a second step, the profile optimizer retrieves the profiles accumulated in the respective database and processes them as inputs of the clustering tool. As output, the clustering tool creates a representative profile or pattern (in general an improved pattern), which is subsequently transferred to the ThinkHome ontology. This representative profile now defines the control strategy of the next day, meaning that the control agent will use it to compute its decisions. Apart from setpoint temperature control, this process is also applicable for all other kinds of profile-based control (e.g., occupancy, comfort, etc.) with minimum and nonessential variations.

The clustering tool works on self-organizing maps (SOMs)—also known as Kohonen networks—that are commonly applied to obtain a pattern on input databases. SOMs have the capability to classify input samples in groups, as well as to generate a representative sample or model of each classification group. Provided that users keep certain habits, the clustering algorithm will calculate an output element or profile which represents most of the input samples (daily profiles). Thus, the tool is able to assess if the output profile is sufficiently representative in a quantitative way. It is useful for the control system to know the level of reliability of the profile as it will take strategic decisions depending on this assessment. Since tools based on SOMs have shown problems with outliers [29], enhanced SOMs have been introduced [31].

6.2. Strategies

Based on the comfort temperature profile and the occupancy profile, the strategies the controller executes are summarized in Table 1. Occ refers to instantaneous occupancy detected by sensors whereas Occ _P is related to the current occupancy profile prediction. is the waiting period and defines the time when set-back temperature has to be applied. is the preparation time and defines how long it takes a specific room or space to be in fine climatic conditions. It mainly depends on the layout and structure of the building, the heating system, weather conditions, the resulting inertia of the heating system, and other parameters. stands for the time passed since the last occupancy change took place, while refers to the amount of time that will still pass until the next change in the corresponding occupancy profile is expected. The notation marks a falling edge. The controller not only generates output for the underlying HVAC system (comfort mode, economy mode, on/off) but also for the profile generator (Comfort _P ).

Case					setpoint temperature (output)
I	1	1	—	—	Comfort P
II	0	1	<	—	set-back temperature
III	0	1	≥	—	off
IV	0	0	—	<	Comfort P
V	0	0	—	≥	off
VI	0	0	—	<	set-back temperature
VII	1	0	—	—	Comfort P

Basically, the smart system applies the temperature indicated by the comfort temperature profile as long as the system detects presence in the room/house (Cases and ). The rest of the cases follow the typical recommendations of heating/cooling experts for comfort and energy savings, trying to take advantage of the information offered by the occupancy profile.

6.3. Simulation Environment and Results

The simulation environment is based on MATLAB/Simulink and the HAMLab tools (HAMBase). HAMBase is a simulation model for the heat and vapor flows in a building. With the model, the indoor temperature, indoor air humidity and energy use for heating and cooling of a multizone building can be simulated. The physics of the HAMBase model is based on ELAN, a computer model for building energy design [30]. More recently, the ELAN model together with an analog hygric model, has been implemented in MATLAB, resulting in the current HAMBase model. HAMBase is part of the HAMLab tools [32], a complete set of MATLAB files for the implementation of a Heat, Air and Moisture Laboratory. Figure 7 gives an overview of the used simulation environment. Area 1 marks the building model. Area 2 determines the time step, selects the strategy, and fixes the heating setback temperature. Area 3 is the core of the simulation and represents the setpoint temperature control agent of the smart system. It decides the next setpoint temperature based on the time, selected strategy, occupancy data, and the current occupancy profile (if the strategy based on profiles is selected). Area 4 shows the heating controller, a PID controller that takes the indoor and the setpoint temperature as inputs and outputs of the heating power for the building model's heating system. The components not circled are used for visualization, data management, and storage.

Weather data for the simulation is obtained from real weather databases (that are already supplied by HAMLab). Data reflecting the occupancy are taken from Leako System Database. This database actually stores data on the water usage from more than 700 dwellings over the past 5 years, but can also be exploited to provide occupancy data. Out of the huge data amounts, five dwellings and 16 days are selected and taken into account. For the simulation, the setback temperature has been fixed to 18 ^∘ C and the comfort temperature is set to 23 ^∘ C. The preparation time ( ) is fixed to 1 hour, while for the waiting time ( ) 4 hours have been assumed. As already mentioned, the heating controller is designed as PID controller with the parameters , , and .

The different strategies are compared by means of four performance indices: total consumption of heating energy over time Q, average difference between real temperature and desired temperature when people are present dT, the total time the system matches the comfort temperature TiC _i , and the necessary time to reach comfort temperatures TtC _i .

Exemplary taken out of several test runs executed for the five dwellings, Table 2 presents two of the simulation results. It shows, that as long as only the energy savings are valued, the On/off strategy performs best, with the profile-based strategy still being within reach. The explanation for the extreme energy savings is the fact that heating is only turned on if a presence is detected. Nevertheless, it can also be observed that the comfort-related indices (dT, TiC _i , and TtC _i ) of the On/off strategy for the given test cases are quite bad and, thus, it must be concluded that users do not feel fully comfortable in these situations. In contrast to that, the strategy based on profiles exhibits the best performance when focusing on the comfort indexes, thus confirming the usefulness of our approach.

	Profiles	On/off	Schedule	Combined	Best value
Q (Kwh)	1.30	1.13	1.47	1.25	lowest
dT ( ∘ C)	0.10	0.25	0.32	0.17	lowest
TiC (hours)	127.8	111.0	126.8	117.8	highest
TtC (hours)	11.3	28.0	12.2	21.3	lowest
Q (Kwh)	1.22	1.03	1.46	1.21	lowest
dT ( ∘ C)	0.13	0.31	0.82	0.17	lowest
TiC (hours)	94.9	76.9	88.3	88.8	highest
TtC (hours)	16.1	34.1	22.8	22.2	lowest

Q: consumption

dT: difference between real and desired temperature

TiC: time while the system keeps comfort conditions

TtC: time needed to reach comfort conditions.

Figure 8 shows some characteristics of the strategy based on profiles. Detail 1 shows a nondesirable (yet possible) situation, in which the smart system does not expect people coming home in a long time and decides to switch off the heating. However, there is unexpected occupancy and the system has to switch on again to reach comfort temperature as soon as possible. In this case, the strategy shows the same behavior as the On/off Strategy. Details 2 and 3 mark the main advantage of the profile-based strategy: the profile is a powerful tool to (correctly) predict the next occupancy and thus the system adjusts the temperature before somebody arrives. Detail 3 shows this fact and also how the comfort temperature drops due to the profile (or a manual change in the setpoint temperature). In addition, it changes to setback when the dwelling becomes unoccupied but recovers comfort values as soon as people return.

There already exist some preliminary works which attempt to integrate some aspects of a smart home with the help of ontologies. Retkowitz and Pienkos [33] describe a possibility to integrate heterogeneous services in smart homes. It is based on an ontology mapping for semantically equivalent service interfaces. In [34] the respective system architecture is specified in more detail. Different service layers are exemplified with the help of use cases. Main achievements are the unified service interfaces that enable a continuous specification, configuration and deployment process.

In [35] Chen et al. propose an ontology-based system for a smart meeting room. They introduce several use cases for a meeting room and employ context reasoning. Another approach for ontology-grounded context reasoning is taken in [36], where the suggested system uses OWL for context modeling. Benta et al. [37] describe a multiagent system working with an ontology mapping of the environment. The work also focuses on context awareness as well as user tracking and especially user behavior. Although these articles show some promising approaches in the field of context modeling and context awareness, architectural or energy deliberations is not sufficiently considered. The authors of [38] propose a system which is based on J2EE and also uses multiple agents in combination with an ontology. The focus of their system is put on the industrial sector, in particular targeting logistics and scheduling applications. Nevertheless, their study is a rare example of the practical application of an ontology-based multiagent approach in a large real-world system.

The article [39] proposes an ontology that allows a vendor-independent representation of a domotic system (DogOnt). In addition, the authors propose a reasoning mechanism that supports the integration of new domotic components into existing systems. However, the integration in a multiagent system as well as energy efficiency considerations is not in explicit focus. The authors of [40] further describe the design of a requirement ontology in order to support an automatic design process of building automation systems.

Also some works that at least touch the architectural constraints for ontology-based smart home control can be found. The DogOnt project mentions an extension to the architectural domain for the proposed system but does not implement it. The DomoML project [15] proposes a taxonomy which emphasizes household appliances and takes into account their location, but does not deal with the building structure explicitly. The authors of [41] present their ideas on how to map data represented in Industry Foundation Classes to OWL. The proposed method is exemplified on the Sydney Opera House [42]. The ontology representation however mainly puts emphasis on the field of facility management.

While not focusing on ontologies, an integrated approach can also be observed in the inHaus project in Duisburg, Germany [43]. The IT infrastructure combines different technologies (ZigBee, WLAN network, RSSI-based people tracking system, UHF RFID gate, mobile LF- and UHF-Reader units, etc.) with the help of a middleware layer. In the context of inHaus, the authors of [44] also propose a generic probabilistic reasoning framework for networked homes based on ontologies, however, more than the specific application in a smart home, a generic framework approach is followed.

Some interesting works are also found in the field of agent technologies applied to control a smart home. For example, the University of Essex developed iDorm [45], an intelligent dormitory that operates with multiple systems and networks. It consists of an adaptive agent that uses fuzzy algorithms to work in a lifelong learning mode, assimilating the users' needs and preferences. On the other hand, works like HomePort [46] simply propose a way to connect different home control systems through an intelligent gateway, exclusively attending the broad variety of existing technological solutions in the residential sector.

Putting focus on multiagent concepts, the OSGi (formerly Open Services Gateway initiative) platform has proposed to implement an agent-based framework [47]. This project pursues the integration of different domotic devices allowing remote control and fault diagnosis. UPnP (Universal Plug and Play) in combination with an agent framework is used for device discovery, registry, and management.

Multiagent architectures have also been proposed specifically for wireless sensor networks [48]. Here, the effort focuses on developing a cooperative and distributed control system with conflict resolution and users' behavior identification capabilities under a wireless infrastructure (ZigBee). Moreover, the multiagent concept can be understood in a different way. Chen and Tseng [49] define space agents, which are distinguished by house zoning and commanded by a governor agent. UPnP and Microsoft's SCP (Simple Control Protocol) are used to communicate and manage the whole system. In the MavHome project, Cook et al. [50] propose the use of an MAS in the home that is capable of learning inhabitant behavior. Data is gathered using agents that communicate with the help of the Common Object Request Broker Architecture (CORBA). The relationship and communication within an agent network is discussed in the MASBO project (Multiagent System for Building Control) [51]. It concentrates on the study of agents' negotiation as a technique to reach effective consensus of agents. With respect to control strategies, Mozer's Adaptive House in Colorado [52] can be mentioned. Neural networks have been used for control intelligence, targeting a home that programs itself. The effort is mainly put on inferring patterns from the inhabitants' lifestyle and performing actions under prediction assessments. Exploitation of energy savings potential is however treated only as a subgoal.

Although all articles specialize on one topic or another that is also relevant for ThinkHome, none of them touches all important aspects of intelligent smart homes in a comprehensive way. Different MAS are specified, but mostly fail to ground agents in a knowledge base. Also most agent systems propose some context awareness approach, but few exploit the MAS to increase energy efficiency. Ontology-based approaches mainly support context awareness and integration of heterogeneous sensor networks. Even if extended with agent systems, important considerations on building structure, user behavior, or energy-related topics are still not modeled in a knowledge base.

Main advantage and distinguishing characteristic of the ThinkHome system is therefore the comprehensive approach that takes into account all important aspects collectively: a knowledge representation modeling energy, user, context, building, comfort and automation system aspects complemented by an intelligent MAS that autonomously makes use of these data to control the smart home in an energy-efficient and comfort-oriented way. Nevertheless, selected project parts were considered as a starting point for the specification of the respective concepts in ThinkHome. This concerns especially context awareness and artificial intelligence mechanisms.

This paper presented a comprehensive approach to fully unleash the energy savings potential of smart homes. Novel use cases that would technically already be feasible are not executed due to a lack of information in the system, and therefore act as a starting point for the system design. The proposed system architecture builds on a knowledge base that achieves the integration of previously unconsidered information. Starting from a multitude of new parameters coming from the architecture, engineering and construction domain like materials, thermal properties, building layout and orientation, as well as miscellaneous external data, it also integrates conventional data in a unified way. As we have shown, by choosing an ontology to implement the knowledge base, we introduced a first part of the system intelligence, namely, knowledge inference and reasoning, at a very early design stage. It allowed us to make some decisions already on the data level, thus facilitating the higher control tasks.

The comprehensive knowledge storage was complemented by a multiagent system, that finally uses all the stored knowledge to realize a more energy efficient building operation. As an example we showed how optimized profiling schemes are embedded in the agent system and evaluated the energy savings and comfort gains of this control strategy, which showed very promising results. The design of our multiagent system was also geared to build a modular architecture that allows an easy integration of intelligent control strategies, interfacing with additional (external) services (e.g., a context inference service), as well as the flexible extension and exchange of existing or new components.

Additionally, we showed that the ThinkHome approach considers different aspects that too often have been neglected in previous approaches.

(i)designing an open system, that (inter)operates on open standards and open software and provides open interfaces to other systems and domains,

(ii)centering the system on the user to increase user acceptance, yet building an autonomous, not patronizing and unobtrusive system,

(iii)realizing an intelligent system that transparently integrates different parts (devices, protocols, parameters, data) to achieve higher energy efficiency and comfort.

Still the work on such a comprehensive system will not be finished soon. Future work will deal with fathoming the possibilities how ThinkHome could most reasonably be coupled with other systems, for example, smart grids or demand side management applications. We will also have a closer look on how multiple ThinkHome equipped homes could be connected to be able to for example, exchange learnt knowledge as well as to cooperate on energy production/usage on a neighborhood or even district level. Furthermore, a focus will be put on the evaluation and integration of conflict resolution mechanisms (e.g., weighting schemes, Markov diagrams, neuro-fuzzy approaches) to resolve potential conflicts of different user goals as well as of energy-efficient versus comfort-oriented building operation. Finally, the system implementation will be accompanied by a refinement and extension of the presented simulation framework. The simulation will be used to test and evaluate the ThinkHome approach on the long term and also to select and improve further intelligent control strategies.