Intelligent Actuation in Home and Building AutomationSystems

Rui José Lobato Camacho

Thesis to obtain the Master of Science Degree in

Telecomunications and Informatics Engineering

Supervisor: Prof. Paulo Jorge Fernandes Carreira

Examination Committee

Chairperson: Prof. Paulo Jorge Pires FerreiraSupervisor: Prof. Paulo Jorge Fernandes Carreira

Member of the Committee: Prof. Maria Inês Camarate de Campos Lynce de Faria

November 2014

ii

Knowledge is power. Information is liberating. Education is the premise of progress,

in every society, in every family.

-Kofi Annan

iii

iv

Acknowledgments

I would never have been able to finish my dissertation without the guidance of my advisor, help from my

friends and support from my family and girlfriend.

I would like to express my deepest gratitude to my advisor, Dr. Paulo Carreira, for his excellent

guidance, caring, patience, exigency, for reviewing my project proposal, both articles and dissertation

numerous times, for providing me with an excellent atmoshpere for doing research and for helping me

in one of the most difficult times of life. I would like to thank Dr. Ines Lynce for helping me understand

constraint solving problem concepts and for patiently reviewing my journal article and providing valuable

tips and hints regarding technical writting.

I would like to thank Akash Manilal, Diogo Anjos, Hugo Sequeira, Joao Santos, Jorge Reto, Paulo

Borges, Pedro Torres, Renato Vieira and Rodolfo Santos for the support and continuous reviews during

the development and writting of this dissertation and for providing a friendly and focused environmnent

that contributed a lot to the progress of my work. I would also like to thank Catarina Moura, Eduardo

Passos, Goncalo Grazina, Ines Castelo, Ines Fernandes, Joao Agostinho, Joao Pedro Santos, Nuno

Alvarez, Pedro Barroso among others, for being there for me during the entire course, helping me

through long projects and works and for being the closest I had from a family when my real family was

far away. I would like to make a special mention to Antonio Fonseca from whom I learded so much about

the academic life.

I would like to thank my family, without which I would never be able to get where I am or be what

I’ve become. To my parents, Rui and Fatima Camacho, for trying their best to teach me about life, for

supporting me all the way through my education and for aspiring great things for me. To my sister, Ana

Camacho, whose faith in my capabilities was ever strong, and to the rest of my family that supported me

through the most various means.

Finally, I would like to thank my girlfriend, Sılvia Diogo, who taught me everything else about myself,

for being by my side in both best and worst moments, and for believing in me.

Many thanks to all, Rui Camacho.

v

vi

Resumo

Os Sistemas de Ambientes Inteligentes tais como Sistemas de Automacao para Casas e Edifıcios

(SACE) estao a tornar-se progressivamente aceites e capazes de atuar automaticamente em prol de

utilizadores de modo a cumprir os seus pedidos ou permitir efetuar actividades. Contudo, quando varios

utilizadores interagem com tais sistemas, os requisitos das actividades muitas vezes interferem, resul-

tando em atuacoes conflituosas que os HBAS deveriam detectar e resolver automaticamente. Apesar

dos avancos recentes em HBAS, ate agora nao foi encontrada nenhuma solucao que recorra a uma

analise de conhecimento adequada para detectar e resolver conflitos.

Este trabalho apresenta uma abordagem pratica a deteccao e resolucao de conflitos agilizada por

analise baseada no conhecimento e apresenta a respectiva validacao. Para alem de uma revisao ex-

tensa da literatura relevante sobre resolucao de conflitos e representacao de conhecimento em Sis-

temas de Automacao de Edifıcios, a principal contribuicao e uma solucao que realiza atuacoes de

forma automatica sobre o ambiente de modo a maximizar o conforto dos utilizadores e optimizar do

consumo energetico.

Palavras-chave: Sistemas de Automacao para Casas e Edifıcios, Ambiente Inteligente,

Deteccao de Conflito, Resolucao de Conflito

vii

viii

Abstract

Ambient intelligent systems such as Home and Building Automation Systems (HBAS) are becoming

evermore accepted and capable of actuating automatically on behalf of users to fulfil their requests or

enable activities. However, when multiple users interact with such systems, the requirements of activities

often interfere, thus resulting in conflicting actuations, which HBAS ought to automatically detect and

resolve. Yet, despite recent advances in HBAS, no ambient intelligent solution has been reported to

perform this kind of autonomous actuation, that is adequately grounded on knowledge analysis.

This thesis presents a literature review on ambient intelligence, conflict detection and resolution,

knowledge-representation and ontology-based HBAS. It also proposes a practical knowledge-based

approach to conflict detection and resolution in HBAS that uses reasoning and constraint-solving algo-

rithms to derive automatic actuations that minimize conflict, maximize user comfort and energy efficiency.

The proposed solution is then validated by means of ontology evaluators, consistency checks and well

defined conflict scenarios.

Keywords: Home and Building Automation Systems, Ambient Intelligence, Conflict Detection,

Conflict Resolution

ix

x

Acronyms

HBAS Home and Building Automation Systems

HAS Home Automation Systems

BAS Building Automation Systems

AmI Ambient Intelligence

UbiComp Ubiquitous Computing

OWL Ontology Web Language

OWL-DL OWL-Description Logic

RDF Resource Description Framework

SPARQL SPARQL Protocol and RDF Query Language

CSP Constraint Satisfaction Problem

SAT Satisfiability Problem

xi

Contents

Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Problem definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Document organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Concepts 7

2.1 Semantic Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Ontologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2 Syntax and semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.3 Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Ambient Intelligence (AmI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Context-awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 Conflict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.1 Sources of conflict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.2 Conflict detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.3 Conflict avoidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.4 Conflict resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Related Work 17

3.1 Conflict resolution in Home and Building Automation Systems (HBAS) . . . . . . . . . . . 17

3.1.1 Multi-Agent Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.2 Policy-based Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.3 Interest-based Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.4 Resource-based Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

xii

3.1.5 Authorization-based Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Conflict resolution in ontology-based systems . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Ontology-based HBAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Solution 27

4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1.1 An ontology for HBAS environment modelling . . . . . . . . . . . . . . . . . . . . . 28

4.1.2 Ontological representation of conflict . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.3 Querying for conflict detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.4 Model analysis using SPARQL Protocol and RDF Query Language (SPARQL) . . 30

4.2 Constraint solving for conflict resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2.1 Syntactic representation of the environment . . . . . . . . . . . . . . . . . . . . . . 33

4.3 Conceptual Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.1 Resolution methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.2 Advising methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3.3 A solution to the conceptual problems . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.3.4 Execution flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4 Technical framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5 Validation 41

5.1 Ontology validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2 Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2.1 Motivation test case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.2.2 Services Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.2.3 Advisor functionality testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2.4 Default vs custom activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.3 Energy efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Conclusions 50

Bibliography 57

xiii

xiv

List of Tables

2.1 OWL-Description Logic (OWL-DL) semantic syntax . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Wang’s representation of Ontology Web Language (OWL)-Lite entailed semantics . . . . 10

3.1 HBAS solutions comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1 Semantic model class listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Query results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Conflict resolution methodology and orientation policies . . . . . . . . . . . . . . . . . . . 36

5.1 System’s produced results to services test scenario . . . . . . . . . . . . . . . . . . . . . 43

5.2 System’s produced results to the ontology reflecting the test scenario where an automated

space tries to host three default activities at the same time, but does not offer all the

necessary services to accommodate all of them. . . . . . . . . . . . . . . . . . . . . . . . 45

5.3 System’s produced results to default vs custom activities test scenario . . . . . . . . . . . 46

xv

xvi

List of Figures

1.1 Motivation example scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Thomas and Khilman two-dimensional conflict taxonomy . . . . . . . . . . . . . . . . . . . 14

4.1 Prototype framework architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.2 Graph representation of the environment state . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3 Example SPARQL queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4 Constraint Satisfaction Problem (CSP) finite domain variables . . . . . . . . . . . . . . . . 34

4.5 CSP Finite domain variables and cost function . . . . . . . . . . . . . . . . . . . . . . . . 34

4.6 Deadlock and starvation example diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.7 Activity vs user-activity class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.8 System execution flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.1 Protege output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2 System output to motivation test scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.3 Services testing diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.4 Advisor functionality test diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.5 Default vs custom activities test diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

xvii

xviii

Chapter 1

Introduction

Home and Building Automation Systems (HBAS) are systems that control electronic devices and equip-

ment inside home and buildings. Home Automation Systems (HAS) differ from Building Automation

Systems (BAS) in the precincts that HAS focus on providing omnipresent and inobtrusive comfort to

users. BAS, in contrast, aim at maximizing energetic efficiency towards economic benefits in large

buildings, while ensuring an adequate level of service (Echelon, 2003; Siemens, 2012). A growing

number of devices in our homes, from lamps (LIFX, 2012; Hue, 2013) to air conditioning units (Nest,

2012; Smart-Zone, 2012; Aros, 2014), although having a physical interface with buttons, are becom-

ing increasingly autonomous and Internet-enabled (WeMo, 2013; Smartthings, 2012; Staples-Connect,

2013), thus forming a networked intelligent control system. Indeed, in the near future, HBAS will feature

so many equipment and devices that it will be virtually impossible to use distinct buttons to handle every

single function in each one of them. Therefore, Ambient Intelligence (AmI) systems will surface to play

an important role in users everyday-life realizing Weiser’s landmark vision (Weiser, 1991), developing

an increasing reliability (Weiser, 1993; Bohn et al., 2005).

Given the ever growing development of intelligent consumer electronics equipment and their capa-

bilities, Home and Building Automation Systems have received increasing attention from the Computer

Science community (Merz et al., 2009). Due to the high variability of user activities and building in-

frastructures, the implementation of Home and Building Automation Systems (HBAS) is largely ad-hoc.

Implementation differ considerably depending on whether it is a small home, a large building, or com-

mercial facility. Implementation might also change among equivalent building structures due to the

constantly changing needs of the end-user or the architectural purpose of the building. As an example

we can consider a residential perimeter where all houses follow the same architecture. One user builds

an office out of a particular space inside his house while another user wants a cinema on the equivalent

room of his house. Daylight sensing and control is not justified by the purpose of a cinema space but

it is quite useful in a study room. This shows us that implementing the exactly same system to similar

houses is not feasible due to heterogeneity of user’s activities and their intrinsic needs. A possible solu-

tion would be leaving in-home device distribution to user’s criteria, like every house owner is responsible

for its decoration, however it is difficult to say if it is possible to guarantee, depending on the system, a

1

proper functioning when users get to choose were each device goes and are not aware of the systems

capabilities and limitations. Overall, infrastructure heterogeneity and the lack of established standards

hamper HBAS take off.

An interesting point is that a system has to meet certain expectations in order to be adopted by

users. When it comes to user-centred systems whose main goals are serving users by controlling their

electronic devices, users expect these systems to keep dynamically adapting and evolving in order to

guarantee continuous usability and ultimately keep on satisfying user’s needs. When a system ceases to

meet its users needs, the system will be dismissed and the user migrates to a more flexible, adaptable

and efficient solution. However, it is very difficult in practice to dismiss a whole HAS or BAS. it is

important that a HBAS built with flexibility and capabilities to continuously adapt.

The crucial aspect of Ambient Intelligence is the capability to react (or even anticipate) users needs

and actuate in a way that is consistent with the users expectations. For this vision to become possible

a large number of devices must coordinate themselves and adjust taking into account a large number

of variables ranging from environment conditions, to space characteristics or even user’s emotional

state. Creating these systems poses a number of challenges to computer science. Imagine a system

that will adjust the light ambience of a room to match the type of movie being played on the TV that

also takes into account the amount of natural light entering the room, thus closing the window blind if

required. However, multiple contexts may coexist inside an automated environment triggering distinct

actuations that may conflict with each other. Existing literature address conflict resolution in HBAS

through simple resource management or priority rule mechanisms (Armac et al., 2006; Retkowitz and

Kulle, 2009; Huerta-Canepa and Lee, 2008). Moreover, ontology-based approaches do not encompass

query knowledge analysis for energy efficiency (Corno and Razzak, 2012; Wicaksono et al., 2010).

Consequently, it is still necessary to develop automation systems able to intelligently reason about

relevant environment conditions extracted from models that represent buildings in terms of automated

spaces and the services that they offer. This thesis presents an ontology-based solution that performs

knowledge analysis by means of queries to infer context. The system models conflict and energy effi-

ciency optimization as instances of CSP in order to perform environment actuations from the attained

solutions.

1.1 Motivation

Consider a living room equipped with an automation system prepared to accommodate different activ-

ities. Suppose that Alice is reading inside the room with the ceiling lamp set to 500 lumen/m2 (lux).

Suppose moreover that Alice’s user profile dictates that, for reading activities, her lighting preference

ranges from 450 to 550 lux. Now, when another person enters the living room it may have different

preferences regarding lighting levels. Distinct preference intervals trigger different responses from the

system upon the entrance of a second person in the room. In particular:

Preference Constraint: An occupant enters with luminance preference of 490-590 lux. There is no

conflict and the current lighting state meets the preference interval of both users.

2

Figure 1.1: Example scenarios, describing the room lighting environment variable setting and possiblesystem responses to the entrance of another occupant with different lighting range preference. Thegreyed bars represent user’s preference intervals. (A) initial scenario where an occupant is alone withroom’s luminance set to 500 lux. (B) A second occupant enters the room with a slight different preferenceinterval, resulting in no system state change. (C) A second occupant enters the room with a differentpreference interval, resulting in a system state change. (D) A second occupant enters the room with adifferent preference interval, resulting in a state where no solution can be found.

Preference Overlap: An occupant enters the room with lighting preference interval of 505-550 lux.

This situation represents a conflict since the lighting in the room is set for 500 so the second user’s

preference is not met. It is possible for the system to adjust itself to satisfy both persons. In this

case adjusting lux levels to 510 would resolve the conflict.

Preference Disjointness: When an occupant with a preference interval of 560-600 lux enters the room,

there is no possible system action to accommodate the lighting preferences of both users. The

preference intervals never intersect. In this case the system could either maintain its state or

inform the users of its inability to resolve the conflict.

Another example of this sort of situation would be user A wanting to do a home cinema session

while user B tries to read in the same room. In this case, user A’s activity is disturbing user B’s activity,

because it is not possible to read in the dark while, at the same time, the volume of the video is relatively

high in order to set a proper cinema home theatre. The same way it is flat to watch a film when the

sound volume is extremely low. There are cases where is not possible to meet all user’s needs, so the

goal would be for the system to dynamically adapt itself to satisfy the most of them. Figure 1.1 illustrates

four distinct scenarios where preference constraint, disjointness and overlap occur due to the presence

and entrance of users inside an automated space.

Clearly, in everyday life, people often perform distinct simultaneous activities inside shared spaces.

Activities compete for the same resources causing side-effects that leads to interference. The occupants

of a shared space require certain environment parameters in order to effectively perform those activities.

The requirements of each user result in different system setups to accommodate each user’s intended

3

scenario. Naturally, some scenarios may coexist in a same space but in many cases the produced

environmnet setups can not co-exist, leading to a conflict situation where one activity is hampered by

the scenario of another.

1.2 Problem definition

Nowadays, matters of automatic conflict detection and resolution in Ambient Intelligence (AmI) systems,

are a problem that computer science has just now started to approach.

Most of the systems hardly go beyond scheduled sequences of policies or actions and simple sensor-

actuator rules, and don’t carry enough flexibility nor intelligence to dynamically adapt to complex con-

flict situations or handle highly subjective circumstances involving user’s interests which are constantly

changing. The amount of work that directly approaches and studies automatic conflict detection and

resolution for AmI systems is scarce. Existing systems are few and present a considerable level of im-

maturity. Once this paradigm is properly approached, it is safe to expect that these systems become

evermore relevant and pave way to a larger number of functionalities, some even not yet envisaged.

The purpose of this work is to determine whether or not it is possible to develop an HBAS that

enables simple and automatic conflict detection and resolution actions and take adequate measures

towards accommodating the requirements of all occupants.

1.3 Contributions1

Conflict detection and resolution in Ambient Intelligence is still a relatively new issue with few mentions

on intelligent environment systems addressing this topic (Resendes et al., 2013). In order to validate the

proposed hypothesis, this research work surveys relevant works within the scope of ambient intelligence,

ontological reasoning and conflict detection.

Our proposed solution is backed by an automated reasoner that explores a knowledge-based rep-

resentation of the environment. The representation is encoded by an ontology model that provides

semantic information over the environment domain. This will result in an accurate and semantically

rich representation of environments and entities, respectively. Concepts such as activities, spaces, ser-

vices, users and environment variables are associated among each other through meaningful relations.

Conflict detection will be achieved by means of SPARQL Protocol and RDF Query Language (SPARQL)

queries to this model, and subsequently, conflict resolution will be attained by finding the most favourable

combination of services by performing constraint solving.

Another distinguishing aspect of the solution detailed herein is that the conflict resolution approach

can also be used to manage and maximize energy efficiency in the environment. This is achieved by

checking for conflicts, not only among activities or user intentions, but also among system actuations

that may impact energy consumptions.

1Part of the contributions of this thesis have been published (Camacho et al., 2014)

4

We should note that existing universal reasoners allow detecting problems and inconsistencies in

the requirements defined using an ontology language. However, the proposed solution does not use

the reasoner inconsistency notifications to detect conflict. Instead, the system detects conflict through

ontology queries building Java objects that represent conflict occurrences. This approach enables the

use of additional conflict information, and later on, more control over the environment analysis.

1.4 Document organization

This document is structured as follows. Chapter 2 presents an overview on relevant concepts regarding

the topic in question, namely ambient intelligence, context awareness and HBAS. This chapter presents

important concepts regarding the semantic web, an overview on constraint satisfaction problem con-

cepts, and finally discusses concepts related to conflict detection and resolution. Chapter 3 presents a

literature review on ambient intelligence, knowledge-representation and ontology-based HBAS, as well

as a survey on existing conflict resolution automation systems in terms of approaches taken. Chapter

4 describes the solution proposal that consists of a modular automatic conflict detection and resolution

system based on knowledge analysis and constraint satisfaction mechanisms. Chapter 5 approaches

the validation methodology, experiments and results that attest the solution practical applicability. Finally,

the conclusions are presented in Chapter 6.

5

6

Chapter 2

Concepts

The problem approached by this work considers a set of concepts and areas of computer science that

play a crucial role to the theoretical idealization and practical development of the proposed solution. As

such, it is necessary to introduce each of these concepts in order to assure the context and consistency

of the problems yet to be described in the following chapters as well as to better understand important

business decisions taken throughout the development process.

2.1 Semantic Web

The Semantic Web is not a separate Web but an extension of the current one (Berners-Lee et al., 2001).

Information is given explicit meaning making it easier for machines to automatically process and inte-

grate information available on the Web (McGuinness and Harmelen, 2004). The state of the art is to

straightforwardly devise Resource Description Framework (RDF) and Ontology Web Language (OWL)

models in order to represent knowledge associated to the automated environment to be managed, which

are closer to industry standards than other commonly used data models. RDF is a data model that rep-

resents information about World Wide Web resources (Perez et al., 2006). Ontology Web Language

is a W3C Recommendation since February, 2004. When compared to RDF models, OWL adds more

vocabulary for describing properties and classes: among others, relations between classes (e.g. disjoint-

ness), cardinality (e.g. ”exactly one”), equality, richer typing of properties, characteristics of properties

(e.g. symmetry), and enumerated classes (McGuinness and Harmelen, 2004).

2.1.1 Ontologies

The term “ontology” is used in different senses among different communities. In the computational

sense, which has recently emerged, we see ontologies as means to represent knowledge by using well

defined semantic and syntactic rules. It allows us to formally model a system’s structure. In other words,

to model the relevant observed entities and relations that are usable according to our purposes (Guarino

et al., 2009).

7

The engineering community had an early informal definition created by Gruber in 1993 that described

the notion of an ontology as “ an explicit specification of a conceptualization” (Gruber, 1993). Years later,

Borst stated in 1997 that an ontology was a “formal specification of a shared conceptualization” (Borst,

1997) and, in 1998, Studer et al. combined these two definitions and described an ontology as “a formal,

explicit specification of a shared conceptualization” (Studer et al., 1998). In order to better understand

the definitions at hand, further insight is required on formal notions of terms like “conceptualization” and

“formal, explicit specification”.

There are several notions for “conceptualization”, but the ontology definitions at hand refer to the

notion created by Genesereth and Nilsson that claim that “a conceptualization is an abstract, simplified

view of the world that we wish to represent for some purpose”. Furthermore, they explain their view on

“conceptualization” by using definitions and examples based on simple mathematical representations

that can be found in (Genesereth and Nilsson, 1987).

A formal explicit specification refers to a language used to associate elements of conceptualization

among each other. For instance, to find a way to express that element A reports to B, it is necessary

to introduce a predicate symbol, say “reports-to”, in order to represent that conceptual relation. In that

case, we say that the language L commits to that conceptualization. An extended explanation about the

notion of formal, explicit specification can be found in (Guarino et al., 2009).

Fensel et al. (Fensel, 2001) states that ontologies provide explicit conceptualization (i.e. meta-

information) that describes the semantics of the data. He compares them with common database

schemas stating that:

1. The language used for defining ontologies is far more semantically and syntactically richer than

other approaches for databases.

2. The data and information described by an ontology models is composed by semi-structured lan-

guage texts instead of tabular information.

3. Ontologies must have a consensual terminology because it is used for sharing and exchanging

information.

4. Ontologies render a domain theory instead of a structure for data containers.

2.1.2 Syntax and semantics

W3C states that the formal support provided description logics are a foundation for Semantic Web tech-

nology (Bechhofer et al., 2004). Informally, description logics describe knowledge in terms of concepts

and role restrictions, which are then used to automatically derive classification taxonomies. A distinctive

feature of description logics is that classes can be defined intentionally in terms of descriptions repre-

senting the properties that objects must satisfy in order to belong to a concept, i.e. to be members of a

certain class (Fensel, 2001). Description logic concepts are referred as classes and roles as properties

in OWL. OWL-DL is a syntactic variant of the SHOIN(D) description logic (Haase and Stojanovic, 2005).

8

Descriptions(C)Abstract Syntax DL SyntaxintersectionOf(C1, C2, ..., Cn) C1 u C2 u ...Cn

unionOf(C1, C2, ..., Cn) C1 t C2 t ...Cn

restriction(R someV aluesFrom(C)) ∃R.Crestriction(R allV aluesFrom(C)) ∀R.C

Class Axioms(C)Abstract Syntax DL SyntaxClass(A partial C1...Cn) A v C1 u ... u Cn

Class(A complete C1...Cn) A ≡ C1 u ... u Cn

Table 2.1: Description of OWL-DL semantic syntax where the left column represents an informal logicsyntax while the right column presents the respective OWL-DL equivalent.

Its terminology is slightly different since OWL is based on RDF(S), hence the support for data values,

data types and data type properties.

According to Horrocks (2003), OWL-DL restricts OWL into two distinct ways (Horrocks and Patel-

Schneider, 2003). For once, some syntactic constructs like recursive descriptions in them are not per-

mitted. Finally, classes, individuals and properties (respectively concepts, individuals and roles in de-

scription logics) must all be disjoint. Table 2.1 summarizes some of the most basic OWL-DL semantics,

that will be used to formalize the ontology that will be presented later in Chapter 4.

2.1.3 Reasoning

Since ontologies can be used to model environment conditions, context information can be processed

through logical reasoning mechanisms. According to Wang (2004), context reasoning allows consis-

tency check upon information provided by the ontology and deduce high-level, implicit information about

the model (Wang et al., 2004).

In order to explain the use of context reasoning for an automation system, consider a context-aware

HBAS example that has the ability to adapt according to the users current activities. Suppose that a user

is reading. The system adjusts the respective room’s lighting to the proper levels and lowers the audio

of any nearby media device. If the user is taking a shower, the system’s domestic phone automatically

forwards any incoming calls to voice mail.

When it comes to ontologies, reasoning can check the model’s consistency and is also able to infer

implicit information that was not expressed initially i.e., information that the ontology model does not

present explicitly can be deduced by means of reasoning rules. Table 2.2 represents, according to

Wang, a sub-set of reasoning rules that support OWL-Lite implied semantics.

Some properties relating objects are also inferred by the reasoner since it only makes sense that, in

certain situations, the relation between instances might imply other relations between the same or other

objects. A simple example would be an instance of ”Occupant” being related to an ”Activity” via the

property ”hasPreference”, in this case we might also say that the instance that is member of the class

”Activity” relates to the first object via the inverse of the ”hasPreference” property named ”isPreferredBy”.

In a more natural language, if this occupant prefers this activity, then this activity is preferred by that

occupant.

9

Rules Logic

Transitive Property (?P rdf:type owl:TransitiveProperty) ∧ (?A ?P ?B)∧ (?B ?P ?C)⇒ (?A ?P ?C)

subClassOf (?A rdfs:subClassOf ?B) ∧ (?B rdfs:subClassOf ?C)⇒ (?A rdfs:subClassOf ?C)

subPropertyOf (?A rdfs:subPropertyOf ?B) ∧ (?B rdfs:subPropertyOf ?C)⇒ (?A rdfs:subPropertyOf ?C)

disjointWith (?A owl:disjointWith ?B) ∧ (?X rdf:type ?A)∧ (?Y rdf:type ?B)⇒ (?X owl:differentFrom ?Y)

inverseOf (?P owl:inverseOf ?Q) ∧ (?A ?P ?B)⇒ (?B ?Q ?A)

Table 2.2: Wang’s representation of a sub-set of reasoning rules that support OWL-Lite entailed seman-tics (Wang et al., 2004). For each rule, a logical representation using variables is shown to demonstratethe concept of the rule at hand.

The domain model containing all the explicit information provided by the user is known as the as-

serted model. Only after running a reasoner, the system is able to generate an inferred model, which

is an extension of the asserted model. The inferred model, not only contains the explicit information de-

fined by the user but also provides implicit information deduced by the reasoner. Inferred models extend

the meaning through implicit properties and assumptions over the user’s asserted model. The inferred

model can be seen as an extension of coherence with deduced relations between entities.

2.2 Ambient Intelligence (AmI)

In a nutshell, AmI aims at performing environment actuations, as implicitly as possible, on behalf of

users. AmI is a discipline that combines distinct computing areas. The first one is Pervasive Computing

(PComp), which is considered to be a form of Ubiquitous Computing (UbiComp). It is a concept where

computing interactions can occur anywhere using any device. It consists on the development of various

ad-hoc networking capabilities formed by numerous and/or highly portable computing devices. Intelli-

gent systems research is another core area that provides situation assessment, gesture and speech

recognition, learning algorithms and so on. Finally, the third area is context awareness, which tracks

and tries to predict object’s and user’s movements, or intentions towards the environment (Aarts and

Wichert, 2009).

AmI can be seen as an umbrella that encompasses several concepts such as device networks em-

bedded in the environment in the sense that technology is ubiquitous. Our solution directly approaches

conflict detection and resolution integrating an intelligence layer located in the upper tier of an Automa-

tion System’s architecture.

AmI is continuously evolving as new ideas and theories start to come up resulting in more aware and

user centred systems. However, the technological infrastructure and power to support UbiComp is still at

early stages and has only now started to emerge. It is expected that, in the near future, advancements

are made on the topic of AmI.

As stated before, it is likely that in the future people tend to rely evermore on automation systems

10

due to the aggressive growth of the number of electronic devices users have in their homes and offices,

consequently emerging the need for normalization and device abstraction. Technological evolution now

allows computer science to dig deeper into AmI and UbiComp, making it is almost certain that, in the

neat future, these concepts will have a stronger presence in our everyday life.

Automation systems are just a small portion of the Ami concept and consist of systems designed to

manage entire homes, offices and buildings. In the near future, HBAS are expected to rely on context-

aware capabilities in order to infer information about the environment that can be used to optimize

proactive actuations on behalf of users.

2.3 Context-awareness

Pascoe (1998) defines context as a sub-set of physical and conceptual information states for a particular

entity (Pascoe, 1998), with entity referring to a certain location, object or user. According to Dey (1998)

that context is user’s physical, emotional and social state (Dey et al., 1998). Abowd (1999) consolidates

these definitions and states that ”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 to be relevant to the interaction

between a user and an application, including the user and applications themselves” (Abowd et al.,

1999). There are other definitions for the term that slightly vary from the latter, but in the scope of

automation systems we shall consider Abowd’s definition.

In a common HBAS, users interact with the system by means of explicit commands to achieve simple

goals like turning some device on or off. On the other hand, the idea of an evermore intelligent system

slowly converging towards the pervasive computing concept, implies that users can also interact with it

through implicit commands that are automatically inferred by the system. This kind of information, such

as user intentions or environment state, is called ”context-information”, which is defined by Dey in 2001

as any information that can be used to characterize the situation of an entity (Dey, 2001). When the term

”context” was first introduced as a computer science term, it related context as locations, surrounding

objects and people’s identities and respective state changes (Schilit and Theimer, 1994). Such informa-

tion is mostly subjective and inconstant, thus unattainable by the common and non-intrusive sensors.

This poses several challenges when it comes to inferring context, e.g., problems regarding context va-

lidity (Zimmer, 2004) or quality-of-context (QoC) (Neisse et al., 2008), and hence to determining the

appropriate action.

User preferences change over time or based on situation (Hasan et al., 2006). On any given moment,

these preferences are influenced by aspects such as mood, motivations, goals and needs. Therefore,

there are two possible reasons for inappropriate context based system behaviour: (i) the system infers

and acts upon a wrongly assumed context; (ii) the system does not detect a context and thus does not

act at all. For both cases, even considering the fact that these systems are intended to automatically infer

context and respond to implicit rather than explicit commands, it is essential that any system behaviour

be overridable. This is especially true on a home control system.

Context-awareness also encompasses user action anticipation. Boton-Fernandez and Lozano-Tello

11

(2011) and Youngblood et al. (2005) present valuable contributions based on data-mining algorithms to

capture user intentions. For the purposes of our work, we assume that such mechanism is in place. Our

work aims at performing a knowledge based analysis upon the environment in order to infer information

about activities and their effects on other users and in the environment.

2.4 Conflict

Researchers have argued that conflict is an inevitable and pervasive aspect of organizational life (Ama-

son, 1996; Galinsky, 2002; Jehn, 1995). Fisher defines conflicts as an incompatibility of goals or values

between two or more parties in a relationship (Fisher, 1997). People generally say that to be in a conflict

is to be in a situation where actions of one entity or person are interfering, obstructing, or in some way,

making another’s behavior less effective (Tjosvold, 1997). Wang and Ting extend this definition, and

state that conflict is a natural disagreement between different attitudes, beliefs, values or needs (Wang

and Ting, 2011).

Smart environments like HBAS that host electronic equipment and other computational resources,

are subject to mutual-exclusive user activities, induced by space sharing between people. This is likely

to result in interpersonal conflict. Furthermore, if the system itself has its own purpose such as saving

energy, further conflict is expected. In terms of AmI systems, conflict can be described as a discrepancy

between goals and intentions towards the environment both between applications and human agents.

2.4.1 Sources of conflict

Daniel Katz, created a typology that distinguishes three main sources of conflict: economic, value,

and power (Katz, 1965). Basically, economic conflict situations involve competing for motives to attain

resources, where parties want to get the most of it that they can. Value conflict is about preferences

interests or practices incompatibilities. Power conflicts happen when each party aim at maximizing or

attain their influence over some relationship and/or social setting.

Katz also states that most conflicts may not have a pure type, they also might involve multiple sources

simultaneously. The more sources are involved, the more intense the conflict is considered to be. Moore

also developed an origins based circle of conflict model that was later adapted by Furlong (Moore, 2003;

Furlong, 2005). The model sees each conflict based on their origins. It states five main underlying

causes: values: that refers to all values, ethics, morals or beliefs; relationships: negative past experi-

ences or history; external : other external factors that may not be directly related to the situation itself,

but still influences or contributes to conflict; data: when the parties have divergent, incorrect or incom-

plete data or information; structure: system architecture or structure problems like limited amount of

resources, authorization problems and organizational structure (Furlong, 2005).

12

2.4.2 Conflict detection

There are a few approaches in Computer Science to address conflict detection. Koegel states that

conflict detection methods and techniques can be categorized into the following approaches (Koegel

et al., 2010): State-based approaches that stores a model’s state, and derives differences by comparing

two states (Conradi and Westfechtel, 1998). Change-based approaches record the system’s changes

while they occur and store them, discarding the need for differencing.

Conflict detection, with respect to a software environment, refers to a system’s ability to recognize an

ongoing or potential inconsistent system state and acknowledge it respectively through software logic

or system notifications. When dealing with conflict detection in HBAS, there are a number of distinct

methodologies and techniques to approach the topic that usually vary with each system paradigm. For

instance, when it comes to policy based systems, policy overlap is a commonly used detection mech-

anism that checks whether a new policy overlaps with some previous rule. Rule based detection is

also used in this sort of systems. Intention difference is another mechanism used mainly in interest-

based systems that seek for situations where users intentions are divergent. Conflict situations can also

be found through model querying, in other words, querying a data model or ontology for inconsistent

system state.

2.4.3 Conflict avoidance

Conflict avoidance is a method for dealing with conflict that tries to directly avoid confronting the situation

or issue at hand. Avoidance scenarios can be either lose-lose for both parties, win-lose or even win-win

in cases where termination of the interaction is actually the best method for solving the problem.

According to Thomas, conflict avoidance is unassertive and uncooperative (Thomas, 1992b), that is,

no regard for one’s concerns and the concerns of others, which are two dimensions used in a taxonomy

created by Thomas and Kilmann to classify interpersonal conflicts (Thomas, 1974), hence represent

a lose-lose scenario since neither party pursues their own concerns nor those of the other individual.

Furthermore, avoidance might take the form of diplomatically sidestepping an issue, in other words,

delaying an issue until a more proper time, or merely withdrawing from the situation at hand.

COMITY is an example of an application framework that focuses on conflict detection and resolution

through avoidance, so as to ensure a conflict-free execution of multiple applications (Resendes et al.,

2013; Tuttlies et al., 2007). The approach is based on PCOM (a Component System for Pervasive

Computing) (Becker et al., 2004). Avoidance in PCOM is achieved by a Conflict Manager component,

which is responsible for managing conflicts for a given domain (Tuttlies et al., 2007).

2.4.4 Conflict resolution

Conflict resolution is defined as the methods, processes or actions involved in facilitating the peaceful

ending of a conflict. Sandole et al. stated that humans tend to cope, more or less effectively, with

interpersonal conflict, and that the way conflict is handled ultimately determines whether the conflict is

constructive or destructive (Sandole et al., 2008).

13

Figure 2.1: Two-dimensional taxonomy, displaying the five types of interpersonal conflict handling modesin terms of assertiveness and cooperativeness levels. The diagonal represents the threshold betweennon-constructive or destructive (left) and constructive (right) interpersonal conflict resolution. Adaptedfrom Thomas (Thomas, 1992a).

Thomas presents a broadly accepted and studied dual concern model for conflict resolution in 1992,

expressing five conflict handling modes (Thomas, 1992b) as shown in Figure 2.1. The model assumes

that an individual’s methods for handling conflict is based on two dimensions or themes where As-

sertiveness refers to the extent to which an intervenor is willing to fulfil his own concerns and Cooper-

ativeness refers to the extent to which an intervenor is willing to fulfil the concerns of others.

Distinct conflict-handling strategies are to be used depending on each party’s disposition of satisfac-

tion towards themselves and others. The five conflict-handling strategies are:

Avoidance Used when both parties express reduced concern for their own results as well as results

of others. Commonly, intervenors adopt a “wait and see” attitude, allowing conflict to fade away

without any personal involvement (Bayazit and Mannix, 2003).

Accommodation Is characterized by high concern for others while, at the same time, expressing few

concern for one’s self. Is considered a pro-social approach because one intervenor drives satis-

faction by meeting the needs of others.

Competition Is a conflict handling style where an individual’s assertiveness is maximized while em-

pathy for others is minimized. Intervenors often tend to force others to accept their demands by

applying competitive or power tactics (Morrill, 1995).

Cooperation Refers to an active concern for both one’s own self and others interests. This conflict

handling mode expresses high interests in a party’s own outcome as well as in others results.

Intervenors tend to cooperate in an effort to find a favourable solution that satisfies all parties

involved.

Compromise Is typical of intervenors that express an intermediate level of concern for both personal

interests and interests of others. This resolution mode encourages parties to accept some de-

14

mands put forth by others, supports fairness, mutual acceptance and influences intervenors to

meet half-way, promoting conflict resolution.

15

16

Chapter 3

Related Work

There is a great deal of work and literature concerning general conflict detection and resolution systems

and HBAS separately. Automatic conflict resolution in HBAS is a relatively new topic in computer science

and there are few solutions that address this issue directly. There are few ontology-based solutions

documented in literature and even fewer are able to perform automatic conflict resolution. On the other

hand, there are systems that take a number of different approaches to automatic conflict resolution that

are not backed by any sort of ontological nor knowledge-based representation techniques. This chapter

presents a literature review on conflict resolution in HBAS, ontology-based systems and finally a detailed

comparative view on the reviewed solutions in terms of functionalities and capabilities.

3.1 Conflict resolution in Home and Building Automation Systems

(HBAS)

Resendes et al. (2013) proposes a solution that is by far the most similar to our work. It is developed

around the idea that shared automation spaces result in interfering user activities and different contexts

require corresponding scenarios that cannot be activated at the same time. Their proposal address

automatic detection and resolution of inter-personal conflict by differencing users preferences, while our

proposal addresses the same plus user virtual assistance and energy efficient features. Their solution

is explained around three complementary questions that depict conflict situations that are likely to arise,

which should be addressed by the system:

Question 1 If an occupant wants to perform some activity, will there be a conflict under the area’s

current environment conditions and occupant preferences?

Question 2 What actuations could the system make in order to harmonize occupant’s preferences and

the place’s conditions?

Question 3 What does the occupant have to do (in terms of preference) in order to fit in a certain place.

17

Their proposed solution uses an Entity-Relationship (ER) model in order to enable further modeling

and understanding of the problem by establishing a representation of services, activities, occupants,

zones and their corresponding relationships. A CSP solver is integrated in the framework so as to

determine if there is any value assignment to some or all variables, so that every constraints hold,

resulting in a consistent solution. MiniZinc1 is a simple but expressive CP language which is suitable for

modelling problems for a range of solvers and provides a reasonable compromise between many design

possibilities Wallace (2004). Generally, a CSP problem is translated into a Minizinc model consisting of

variable declarations, constraints, a goal and an output specification (Resendes et al., 2013).

The obtained results demonstrate the simplicity and viability of their approach. All the performed

experiences had runtime of less than 100ms on a desktop pc, which is a great result and particularly

important, since the fastest the system generates a solution, more time can be spent on determining

and taking the appropriate action.

3.1.1 Multi-Agent Systems

Alshabi (2007) (Alshabi et al., 2007) presented a condensed survey of multi-agent systems, with spe-

cial emphasis on cooperation coordination, conflict resolution and closely related issues that are very

important for large-scale development of distributed complex software systems.

HOPES (Bell and Grimson, 1992), HECODES (Bell and Grimson, 1992) and MAGIC (Bensaid et al.,

1997) are computerized systems constituted by multiple interacting intelligent agents within an environ-

ment. Benefits and shortcomings of these frameworks are presented in the mentioned survey as follows:

HOPES and HECODES are based on a blackboarding technique which consists of a shared knowledge

base, the ”blackboard”, which is updated by specialist knowledge sources with problem definitions and

partial solutions. This way, specialists work together to solve the problem. Blackboarding allows central-

ized control which can improve the overall system’s efficiency. However it represents a bottleneck and

the sources of knowledge are not locally available. MAGIC is more appropriate for better resolution of

distributed problems with autonomous agents. On the other hand, MAGIC lacks when dealing with real

world applications.

Alshabi proposes a service driven framework for the development of cooperative multi agent systems

that introduces the concept of coordinator agent (CA) into the model to guarantee co-operation between

agents and generate total coherent behaviour of the multi-agent system in order to avoid potential con-

flicts. This model considerably differs from HOPES and HECODES in that all communication between

agents are managed by the dynamic coordinator agent instead the static blackboard. In case of conflict,

the agent enters into a negotiation with the conflict group. Three different techniques for complex negoti-

ations are presented: i) negotiation through an arbitrary leader election, ii) negotiation through chaining

ordered agents, and iii) negotiation through cloning (Alshabi et al., 2007).

Kung and Lin (2006) (Kung and Lin, 2006) propose and design the context-aware embedded mul-

timedia presentation system (CEMP), that is based on context vocabulary ontology to provide explicit

description about multimedia information domain and formal context process model. In addition, CEMP1http://www.minizinc.org/

18

system provides an adaptation reasoning mechanism to infer the best adaptation control when the cur-

rent context changes. On the other hand, the context modification may cause conflicts among multiple

adaptation requirements and resource limitations. CEMP also provides a conflict resolution mechanism

by calculating context’s priority and the context weight in order to come up with the best conflict resolution

results.

3.1.2 Policy-based Systems

The HOMER framework developed by C. Maternaghan (2013) (Maternaghan and Turner, 2013) is de-

scribed as a technique for offline conflict analysis among policies and aims to monitor, control and

customize a HAS. HOMER allows policies to be defined in multiple ways: how device signals should

be handled, what shall happen in a certain location at a given time of the day and even how the sys-

tem should react to an individual’s presence. This allows users to freely express their policies and this

flexibility is confirmed to be acclaimed by users.

HOMER runs on top of the Homer Policy System which is composed by an Overlap Detector and

Conflict Detector, among others. The Overlap Detector checks newly added or edited policies against

others that are already stored. Apart from examining the validity of a policy it will also check if a policy

might be simultaneously enabled along with a subsisting one. If so, they are considered to overlap

and verifies if any of the overlapping policies result in actions that conflict with each other. The conflict

detection component makes use of user provided information about ’environment’ effects of certain

actions.

Conflict situations are modelled as CSP. HOMER uses the Java Constraint Programming JaCoP2 as

CSP solver because it can easily be integrated within the framework that is also written in Java. JaCoP

is a basis used for policy overlap detection. Each term in an activity clause is translated to its JaCoP

equivalent. JaCoP has knowledge of a ’store’ that holds the constraints to be satisfied. These constraints

come from event clauses and are enforced in the store, then JaCoP is requested to look for solutions to

those constraints.

CARISMA (Capra et al., 2003) is a middleware model that exploits reflection to enable context-aware

interactions. It provides developers with an abstraction of the middleware as a custom service provider.

The behaviour of the middleware with respect to a specific application is defined as a set of associations

between services, policies can be applied to deliver services and context configurations that must hold

so that a policy can be applied. With this model a conflict occurs when different policies are used in the

same context to provide a service, and the middleware does not know which one to apply.

Based on the fact that CARISMA is able to assign profiles to applications, which describes an ap-

plication’s current configuration, it is possible to qualify and handle two generic types of conflicts: i)

Intra-profile conflicts where a conflict exists inside the profile of an application that is running in a certain

device. ii) Inter-profile conflicts where a conflict exists between profiles or different application configu-

rations running in distinct devices.

2http://jacop.osolpro.com/

19

The conflict resolution mechanism to dynamically resolve conflict is based on microeconomic tech-

niques (Binmore, 1992). The idea is that a mobile distributed system can be seen as an economy,

where a number of consumers make a collective choice over given alternate goods that represent sev-

eral policies that can be used to deliver a service.

3.1.3 Interest-based Systems

Interest based automation systems usually describes conflict as intention divergence between two ac-

tivities or services.

COMITY is an application framework that extends the component/service-based Pervasive Comput-

ing infrastructures that requires applications to specify their influence on the physical environment and

allows them to define context situations they consider to be conflicts (Tuttlies et al., 2007). The approach

is based on PCOM (Becker et al., 2004). PCOM is a component system designed for Pervasive Com-

puting systems with resource restricted devices. It allows to semantically specify enriched contracts

between components. The conflict avoidance is performed by the Conflict Manager component which is

responsible for managing conflicts for a given domain that is automatically discovered by the Resource

Manager using the PCOM discovery service. Applications in COMITY are a coordination of components

that can be changed at runtime, to deliver the functionality required by applications under potentially new

context constraints.

Armac (2006) proposed solution defines components as services, where each service is a set of ac-

tions that denote state transitions on resources (Armac et al., 2006). A conflict situation is detected when

a service attempts to transition a resource from a state previously set by another service. Depending on

the moment when conflicts are identified, two different techniques can be used: static and/or a dynamic

technique. The static detection is done mostly in the design and specification stage and analyses the el-

ements of a system and their interactions based on a formal description of their behaviour. The dynamic

technique is a process running in parallel to the system and continuously extracting information from the

system’s environment, working on an up-to-date image of the system. The admissible state transitions

are captured by an ω-automaton associated with each resource. It also uses a simple but reasonable

conflict resolution strategy based on rule mechanisms and with priority management.

Park (2005) proposes a dynamic conflict resolution system that relates users intentions and their

preferences respectively. Users intentions are modelled as a value associated to a context by actions

required by applications on user’s behalf (Park et al., 2005). User preferences are expressed as cost

functions to reflect the level of user’s reluctance to the differences between their intentions and resolu-

tions choices. Based on cost functions, a resolution is determined to minimize the reluctance of all users

involved in conflicts. The conflicting applications then adapt themselves to the resolution result.

Silva (2010) defines collective conflict as an inconsistent system state that may take place when

collective applications processes several users context information, that ultimately represent divergent

interests. They propose a conflict detection and resolution system that is based upon a client-server

architecture so as to select, configure and apply the current most appropriated conflict resolution algo-

20

rithm available. This sort of decisions are performed based on an application’s demand for quality of

service (QoS) and resource consumption. The QoS criteria considered is the collective users satisfac-

tion as to the results generated by the resolution algorithm (Silva et al., 2010). This solution is further

explained in detail here (Silva et al., 2011), where the developers perform a case study about a tourist

guide application that substantiate the developed solution’s effectiveness.

3.1.4 Resource-based Systems

Retkowitz (2009) proposes a framework based on the perspective that, in the near future, the possibility

of having detached services from hardware devices will lead to conflict situations due to resource con-

currency. To prevent this sort of conflict situations, it is used a dependency-management and resource

allocation mechanism that finds a feasible balance between exclusive access control to devices and

sharing them with other services (Retkowitz and Kulle, 2009). In other words, this mechanism considers

dependencies between services, which are called as bindings, and tries to infer the service composition

that simultaneously matches users requirements, device environment, all service dependencies without

disrespecting previously defined bindings, policies and constraints.

Huerta-Canepa and Lee (2008) take into account interactions and inter-personal conflict between

users and propose a multi-user ad-hoc resource manager for smart-spaces, which allows us to control

devices available in the room, ultimately avoiding conflict (Huerta-Canepa and Lee, 2008). Conflict

avoidance is performed through area device control, and conflict resolution is carried out at the resource

level, based on the utility and cost of executing a given job instead of the current one, and on user

priorities (Resendes et al., 2013).

3.1.5 Authorization-based Systems

Masoumzadeh et al. (2007) refer to authorization conflicts, which can be seen as a particular case of

policy conflicts, as an occurrence of two distinct policies that both allow and deny an access (i.e. pol-

icy allows media device to play music and another imposes silence). The proposed solution performs

conflict detection operations statically and conflict resolution is carried out in run-time. They consider

precedence establishment among conflicting policies to be a practical solution. To that aim, they formal-

ize the use of context constraints in a rule-based context-aware multi-authority policy, i.e. a model that

allows the establishment of precedence principles for policies (Resendes et al., 2013). Then, a graph-

based approach based on that model is used to resolve conflicts. A potential conflict graph is statically

constructed during the detection phase, that can provide the resolution in case an actual conflict is

detected. Moreover, timing strategies and resolution algorithms are also analysed.

3.2 Conflict resolution in ontology-based systems

Conflict arising in semantic interoperability between several heterogeneous data sources is a serious

issue in the database community. S. Ram et al. propose a formal structure of a common ontology

21

known as Semantic Conflict Resolution Ontology (SCROL) that addresses inherent difficulties of cur-

rent semantic interoperability of heterogeneous database approaches (Ram and Park, 2004). SCROL

presents an automatic semantic conflict detection and resolution method for heterogeneous databases.

S. Ram et al argue that “SCROL is developed to encode extensive knowledge on commonly found

semantic conflict that have been identified in their classification framework”. SCROL automatically com-

pares and manipulates contextual information from each source that is used for semantic transformation

across heterogeneous databases. The authors also show that SCROL captures contextual knowledge

by means of illustrative examples as well as evaluation results that show that SCROL is able to success-

fully detect and resolve conflict.

Security services for communications networks require deployment of policies across multiple net-

work devices. S. Davy et al. present an analysis process targeting identification of possible policy

conflicts associated to network devices and security services deployed on them (Davy et al., 2008). It is

based on pre-deployment detection of potential conflicts between a new or modified policy and already

existent policies. It uses a selection algorithm that resorts to an ontology to identify the most relevant

policies to be compared with the ”candidate policy”, and a detection algorithm that compares policies

using a conflict signature pattern encoded in an information model. Moreover, the ontology and informa-

tion model can also be used to build relationship models among deployed policy sets so as to be used

by the selection algorithm, reducing the number of policy comparisons.

KAoS is a multicomponent policy and domain management services compatible with most agent

frameworks (Uszok et al., 2003). Services were initially oriented to the dynamic and complex require-

ments of software agent applications, but were also adapted to the general-purpose grid computing and

web-service environments. KAoS policy services allow the definition, management, conflict resolution

and enforcement of policies within domain services (Tonti et al., 2003). Policies are expressed in a

DAML3 description-logic based ontology. In KAoS, any change of policy or in the status of an actor

triggers logical inference to determine which policies are in conflict and how to resolve them (Lupu and

Sloman, 1999). Policy conflict detection is done through a general-purpose algorithm and harmoniza-

tion algorithms developed within KAoS to allow conflict resolution even when actions, actors or targets

of policies are located at different levels of abstraction.

3.3 Ontology-based HBAS

F. Corno proposes a solution to energy conservation while respecting user preferences regarding the

state of the environment, based on explicit high level modelling (Corno and Razzak, 2012). Their pro-

posal provides AmI designers with an abstraction layer that enables defining generic goals inside the

environment, in a declarative way, towards developing intelligent applications. For environment and de-

vice modelling, a device ontology was adopted and deployed in an automation gateway (Bonino et al.,

2008). Information about power consumption of devices is encoded in another ontology, derived from

Energy Profile ontology (Bonino et al., 2011). User intentions are modelled using the ”Domotic Effects”

3 http://www.daml.org/

22

framework, where conflict resolution is carried out using boolean Satisfiability Problem (SAT) solvers.

H. Wicaksono et al. describes a research approach for an intelligent system that aims at improving

energy efficiency in buildings (Wicaksono et al., 2010). Technical building infrastructures heterogeneity,

ongoing activities inside those buildings, important environment states and factors are taken into account

through the use of ontologies that provide explicit data and context-information. They propose an energy

management BAS framework. To that end, a knowledge based approach applied to extract information

from the ontology by analysing the relations among devices energy consumption as well as events

and activities that take place in parts of the building, surrounding factors and offer related information,

like temperature and weather conditions. The proposed system also allows users to have holistic and

integrated view of the energy consumption in their apartment, office, as well as the entire building.

H. Chen proposed COBRA-ONT, an ontology providing support for pervasive context-aware sys-

tems. This solution is comprised of a collection of ontologies specifying agents, places, events and

associated properties in the context of an intelligent meeting room. This solution supports is based on a

broker-centric agent architecture, namely the Context Broker Architecture (CoBrA) allowing knowledge

sharing, context reasoning and privacy protection support for pervasive context-aware systems. Co-

BrA ontologies are suitable for building pragmatic context-aware systems and help the broker to share

knowledge with other agents enabling it to reason about context. Knowledge reasoning is performed by

F-OWL, a proposed inference engine implemented in Flora-24, which is an object-oriented knowledge

base language and application development framework.

Another attempt to create an appropriate to support context-aware systems, enables a context model

based on ontologies so as to allow context-aware systems to reason about various contexts (Gu et al.,

2004). The model proposed by T. Gu et al. supports semantic context representation by defining the

common upper ontology for context information in general and providing a set of low-level ontologies,

which apply to different sub-domains. It captures various contexts, relationships and quality of context,

while at the same time, providing support for different context reasoning engines. The main advan-

tage is sharing common understanding of the structure of context information among user,s devices

and services to enable semantic interoperability and, most importantly, it enables formal analysis of do-

main knowledge. To that end, the authors also present a Service-Oriented Context-Aware Middleware

(SOCAM) architecture for context-aware services illustrated over a context aware home scenario.

G. Loseto proposes a flexible multi-agent solution leveraging semantic-based resource discovery and

orchestration in HBAS. It is backward compatible with EIX/KNX5 standards to allow semantic specifica-

tion of user profiles and device functionalities (Loseto et al., 2012). Annotations are specified through

ontological formalisms derived from Description Logics (DL’s), namely Dig6, which is a compact equiva-

lent of OWL-DL. The presented framework enables user-transparent interaction. Requests from users

and devices are collected by a home mediator, which acts as a broker among users and home appli-

ances. The multi-agent system allows the addition and removal of any agent at any time and is also

comprised of energy-providing systems, such as photo-voltaic collectors. The authors present a power

4http://flora.sourceforge.net/5http://www.knx.org/knx-en/index.php6http://dl.kr.org/dig/

23

Approach Systems Formal Model(Ontology) Conflict Detection Conflict Resolution Energy Efficient

Multi-AgentSystems

HOPES &HECODES (Bell and Grimson, 1992) NO Avoidance - NO

Policy BasedSystems

HOMER(Maternaghan and Turner, 2013) NO Policy Overlap CSP - JaCoP NO

CARISMA(Capra et al., 2003) NO Policy Based Micro Economic

Mechanism NO

InterestBased Systems

COMITY(Tuttlies et al., 2007) NO Avoidance - NO

(Armac et al., 2006) NO Rule-BasedDetection

Rule Mechanism& Priority

ManagementNO

(Park et al., 2005) NO Intention Difference Cost-Function NO(Silva et al., 2011) NO Intention Divergence Algorithm Selection NO

AuthorizationBased Systems (Masoumzadeh et al., 2007) NO Potential Conflict

Graph Precedence Based NO

ResourceBased Systems

(Retkowitz and Kulle, 2009) NO Avoidance/Prevention ResourceManagement NO

(Huerta-Canepa and Lee, 2008) NO Avoidance(Device Control)

ResourceManagement NO

Table 3.1: Overview and comparison of presented HBAS solutions in terms of approach, modelling,conflict detection/resolution functionalities and energy efficiency support.

management problem in HBAS as a case study to explain and assess their proposal’s effectiveness.

3.4 Discussion

The sections above provided an overview on existent solutions regarding conflict resolution on HBAS

and ontology based systems. However, not all of them provide all necessary features or address cer-

tain issues the way we consider adequate to the purposes of conflict resolution in HBAS. Table 3.1

expresses an overview on the presented solutions for HBAS in terms of approaches and the features

surveyed. According to Table 3.1, many proposed systems rely on avoidance and resource manage-

ment techniques for dealing with conflict. Others use policy-based analysis for detection and constraint

satisfaction or complex algorithms as resolution methodology. The surveyed solutions are capable of

solving most of the problems we considered to be major issues in AmI. However, this survey shows

an heterogeneous tendency in conflict approaches. Furthermore, most of the presented solutions don’t

feature energy efficiency capabilities or apply any sort of knowledge-based analysis. In other words, the

surveyed solutions do not present adequate approaches to conflict detection and resolution in HBAS.

H. Wicaksono perform knowledge based analysis using SPARQL to acquire environment informa-

tion. Indeed the expressive power and flexibility of ontologies is a major surplus regarding information

extraction for conflict detection, making ontologies ideal to approach part of the automatic conflict res-

olution problem in HBAS. Information can be extracted and manipulated from the ontology model in

order to keep track of system states that may lead to conflict. This is better than other options such as

avoidance approaches in the sense that they can only be used as temporary measure or, as mentioned

in Section 2.4.3, as a permanent means of disposing of a matter. Moreover, the Thomas and Kilmann

grid considers avoidance strategies as a lose-lose proposition since it does not address the issue at

hand. Other conflict detection approaches such as policy overlap or rule based detection might suffice

to some frameworks but lacks the expressive semantic power and compatibility offered by ontologies.

Moreover, it seems that the proper way to perform conflict resolution operations in automated envi-

24

ronments is one adequately modelled by ontologies, in which environment states are represented by a

set of variables that must dynamically adapt in order to comply with user’s preferences and energy effi-

cient constraints. The most advantageous combination of variables should then be detected by applying

constraint programming techniques. Yet, according to our survey, only F. Corno and HOMER solutions

use CSP solvers to resolve conflict. Energy saving is an issue that can also be modelled as an instance

of CSP, so that system actuations that aim at satisfying the majority of occupants can simultaneously

increase energy efficiency. As it will be clear later, the solution proposed by this thesis, like F. Corno’s,

models the problem in a way that the resolution module not only searches for solutions to resolve inter-

personal conflict but also aims at finding the most energy efficient set-up within that solutions space.

25

26

Chapter 4

Solution

As stated in previous chapters, shared automated spaces often host different user activities that trigger

conflicting environment states.It is necessary to define a detection methodology able to tell conflicting

actuations from others. As such, part of the solution entails an environment analysis enabled by ontol-

ogy querying. However, it is possible that particular environment states are able to accommodate the

majority, if not all activities inside a shared space. Finding these environment states is a mathemati-

cal challenge that can be tackled with constraint solving techniques. This chapter presents a practical

solution capable of reasoning about conflict detection and resolution in automated spaces.

4.1 Overview

Our proposed framework consists of three main modules responsible for: i) aggregating context informa-

tion, ii) detecting and resolving conflicts iii) and decide what action to take based on the current state of

the environment. The system uses an ontology as knowledge base as input, and outputs commands to

the actuators and notifications to users. The analyser module uses context information provided by the

ontology making use of pre-defined SPARQL queries to extract information from the ontology about po-

tential conflict situations. Finally, the information is translated into valid input data to feed the processor

module responsible for performing mathematical operations to generate solutions. Both the resolver and

advisor apply constraint programming techniques over the elements returned by the analyser, modelling

them as constraints. These constraints denote a set of solutions of which, the most context-adequate to

the problem is to be chosen. The decider receives the solutions and data generated by the resolver and

advisor and reads actuators data in order to verify whether device actuations are needed to make the

environment adapt to the current situation. Figure 4.1 represents the prototype framework architecture

in terms of its constituent modules and data flow.

In order to develop a system capable of reasoning about conflict detection and resolution in auto-

mated environments, it is necessary to establish a formal model modelling knowledge representation

of the domain. The model will enable capturing relevant entities and relations (Guarino et al., 2009).

However, ontology models can grow in complexity and size. A family of logic based knowledge repre-

27

Resolver

DeciderOntology

Actuation

NotificationAdvisor

Analyser

SPARQLQueries

Figure 4.1: Prototype framework of the conflict detection and resolution system, in terms of its con-stituent modules: (i) analyser module, (ii) processor module composed by the resolver and advisor, and(iii) decider module. The system takes the ontology model and SPARQL queries as input and actuatesupon the environment or returns information to occupants.

Class Description Logic

Occupant Individuals that represent the system’s users. ≡ ∀hasPreference.(Activity uu EnvironmentV ariable)

Activity Individuals that represent activities that may beperformed inside each zone.

≡ ∀hasCondition..EnvironmentV ariable

Environment Variable

Individuals that represent the system’s variablesaffecting the environment state(e.g. Temperature, Sound, Luminanceand Air Flow).

≡ ∀isConditionOf.Activity

ServiceIndividuals that represent actuations upon theenvironment variables in orderto change the environment state.

≡ ∀actsOn.EnvironmentV ariable u∀isOffered.Zone

Zone Individuals that represent a single room managedby the automation system.

≡ ∀offers.EnvironmentV ariable t∀hosts.Occupant

Table 4.1: Description of each class used in our proposed ontology and formal representation inOWL-DL, in terms of logic formulas that specifies the properties objects must satisfy in order to be-long to those entities.

sentation formalisms can be used in order to describe the domain model in terms of classes and their

corresponding concepts. This approach will be presented in the following sections.

4.1.1 An ontology for HBAS environment modelling

Ontologies are means to represent knowledge by using well specified semantic and syntactic rules.

Occupants are modelled according to their preferences on the enabling conditions (i.e. pre-conditions)

associated to the activities they perform. At this point, a conflict can roughly be considered as an

interference between occupant’s preferences, or when conditions of an activity interfere with the ones of

another.

Each class requires a set of properties or conditions in order to be conceptualized. In other words, an

individual that satisfies those properties is considered to be a member of that class. An individual is only

considered to be an Occupant when it hasPreference for an Environment Variable ‘and’ hasPreference

for an Activity. An individual is only considered to be an Activity when it has at least one condition upon

an Environment Variable. An Environment Variable must be a condition of some Activity. A Service must

be offered by at least one Zone ‘and’ must act upon at least one Environment Variable. Finally, a Zone

28

must offer at least one Environment Variable ‘or’ host at least one Occupant.

Table 4.1 describes the purpose of each entity used in the ontology and a set of properties expressed

through logic formulas following OWL-DL that encodes the conditions mentioned above so that instances

can be automatically recognized by the reasoner as members of certain entity.

An instance diagram depicting a populated state of this ontology1 can be found in Figure 4.2. Data

properties, inverse properties, disjointness or equality are omitted for visual simplicity.

4.1.2 Ontological representation of conflict

This section focuses on possible conflict situations that may occur in the system state.

Consider a scenario of conflict following the ontology represented in Table 4.1 described as follows:

let ‘Alice’ and ‘Bob’ be the ‘Living Room’ performing the same activity ‘Read’, and have preferences

over the same environment variable ‘Light’. ‘Charles’ and ‘David’ are also inside the ‘Living Room’ but

intend to perform different activities, ‘Study’ and listen to ‘Music’. They share preferences over multiple

environment variables related to ‘Temperature’ and ‘Audio’. Potential conflict between Charles and David

can be seen as a multi-dimensional variant of the one between Alice and Bob. In the ‘BedRoom’,

however, ‘Frank’ and ‘Eve’ don’t have preferences over any environment variable, but both perform

different activities, ‘Sleep’ and watch a ‘Movie’ with pre-defined conditions over environment variables.

This scenario, illustrated in Figure 4.2, portrays preference divergence cases where users exhibit dis-

tinct inclinations regarding lighting, sound, temperature, air flow levels, as well as activity incompatibility

situations where conditions to start one activity interfere with the conditions to keep another running,

ultimately resulting in conflict. This sort of state must be automatically detected in order for the system

to dynamically adapt the environment’s conditions through device actuations in order to comply with the

preferences of both occupants and activity’s conditions, thus resolving conflict. To this aim, the system

performs a knowledge-based analysis upon the model by means of queries that extract information to

find states that represent conflicting situations like the ones represented in the example.

4.1.3 Querying for conflict detection

SPARQL is an RDF query language for ontology models and databases, capable of extracting and

manipulating information stored in the Resource Description Framework format. Essentially, SPARQL is

a graph-matching query language that can be used to extract knowledge from the model such as the one

proposed in this thesis. Given a data source D, a query consists of a pattern, which is matched against

D. The combinations of values resulting from this matching constitute the result of the query (Perez et al.,

2006).

Comparing to SQL, SPARQL is designed to query RDF while SQL is to relational data, respectively.

Both languages allow users to create, aggregate and consume structured data. However, SPARQL does

this by accessing a web of Linked Data while SQL does it by retrieving tables in relational databases.

SPARQL can be used to access relational data as well, though it was designed to merge distinct data

1http://web.ist.utl.pt/rui.camacho/Ontologies/automation.rdf

29

Read

Alice

Bob

LivingRoom LamphasPreCondition

isIn

isIn

hasPreference(Activity)

hasPreference(Activity)

hasPreference(Environment Variable)

hasPreference(Environment Variable)

David

Charles

Hi-Fi Player

Air Conditioner

isIn

isIn

Study

Music

hasPreCondition

hasPreCondition

hasPreference(Environment Variable)

hasPreference(Environment Variable)

hasPreference(Activity)

hasPreference(Activity)

SleepMovie EveFrank

BedRoom

Lamp

hasPreConditionhas PreCondition

isInisIn

performs

Ventilator

has PostCondition

has PostCondition

performs

Zone

Occupant

Audio

Hi-Fi Player

Temperature

AirFlow

EnvironmentVariable

Light

Activity

UserActivity

Object Property

Sub Class of

Instance of

Figure 4.2: A graph representation of the ontology reflecting the current state of the environment asdescribed in the scenario of section 4.1.2. Occupants have preferences over a set of environmentvariables depending on the activities they want to perform. Moreover, activities whose conditions mayinterfere with another’s, are taking place inside the same room. Ellipse-shaped objects represent indi-viduals sharing relationships, ultimately expressing the environment state. Rectangular-shaped objectsrepresent classes or sub-classes.

sources. RDF represents all data as a collections of simple binary relations. Therefore, most data can

be mapped to RDF and then queried and joined using SPARQL.

Moreover, SPARQL has strong support for querying semi-structured and tagged data, e.g. data with

an unpredictable and unreliable structure. SPARQL query variables may occur in the predicate position

to query unknown relationships, and the optional keyword provides support for querying relationships

that may or may not occur in the data, just like SQL left joins. SPARQL natively supports queries to

networked, web data sources identified by URIs. SPARQL is now a W3C Recommendation for RDF

data. There are some drawbacks regarding SPARQL. For one, there are not many data stores that can

be queried using SPARQL and it also lacks many dynamic organization strategies developed for SQL.

4.1.4 Model analysis using SPARQL

Shared spaces environments are dynamic and always changing. Thus, the ontology model must keep

up with state changes to accurately reflect the environment. The model analysis is performed by a

30

room variable occupant

Query 1 LivingRoomLight Bob

Alice

Temperature David

Charles

room variable activity

Query 2 BedRoomAirFlow Sleep

Movie

Sound SleepMovie

Table 4.2: Query results identifying that ‘Bob’ and ‘Alice’ may have conflicting preferences regarding‘Light’ in the ‘LivingRoom’. ‘Charles’ and ‘David’s’ preferences over ‘Temperature’ levels may also inter-fere. ‘Sleep’ conditions ‘AirFlow’ and ‘Sound’, which interfere with the conditions imposed by ‘Movie’.

module responsible for extracting information about the environment. Such information allows us to

know which occupants are installed in which rooms, which activities are being performed, and which

environment variables are being used. It is this information that enables determining possible conflicting

user preferences over the same environment variables or which activity conditions may interfere with

each other. Put differently, model analysis allows the system to recognize conflicting situations and

extract information in order to proceed with resolution.

Consider the system state depicted by Figure 4.2 that represents an environment state that depicts

possible conflicts among activities and user preferences. In this case, it consists on preference mis-

match situations between ‘Alice’, ‘Bob’, ‘Charles’ and ‘David’. The activities ‘Movie’ and ‘Sleep’ may

also interfere with each other due to environment conditioning conflicts. Therefore, analyzing the current

state of the environment to find information about this sort of conflict, undergoes querying the model for:

1. Any environment variable preferred by more than one occupant inside the same shared space.

2. Any environment variable that is conditioned by more than one activity inside the same shared

space.

Figure 4.3 presents the SPARQL queries that encode such logic. The query results are displayed

on Table 4.2. For simplicity reasons, data properties that express the preference intervals regarding

each environment variable levels are omitted. The extracted information provides relevant data about

possible conflict situations, that are crucial for the resolution process. This data will be used as input of

the resolution module.

4.2 Constraint solving for conflict resolution

Constraint programming is a paradigm where variables domains are defined in the form of constraints

(i.e. requirements). According to Bartak (1999), constraint programming is the study of computational

31

Figure 4.3: Example SPARQL queries that return concurrency information upon environment variablesfor each shared space and instances of activities whose conditions may interfere with the conditionsof another activity. The queries select the tuples that comply with a set of constraints: (a) occupantsmust be inside the same room and have preferences over the same sub-class of environment variable(i.e. Light, Temperature, Sound or Air Flow); (b) activities are in the same room and condition the sameenvironmnet variables.

systems in terms of constraints. The purpose of constraint programming is to solve instances of Con-

straint Satisfaction Problem (CSP) by defining constraints about the problem’s domain and finding a

solution that satisfies all of the constraints. From a mathematical point of view, a constraint is a condition

of an optimization problem that the solution must satisfy. In other words, a constraint is a logical relation

between several variables, each taking a value in a specific domain (Bartak, 1999).

Environment conditions can be expressed in terms of a set of environment variables and a set of

constraints that specify restrictions to the possible values a variable can take. The idea is to find a set

of values for each variables so that the specified constraints hold. If they do, it is said that the function

satisfies all the constraints therefore is a solution to the problem. When this sort of solution can not be

found then the problem defined by the set of constraints is said to be not satisfiable (Resendes et al.,

2013).

On the other hand, when no consistent solution can be found, the problem can take on another form

called MAX-CSP, where it is sought a solution where a number of constraints are allowed to be violated,

while maximizing the number of constraints satisfied.

The knowledge base represented by the ontology allows us to access to environment conditions.

However, performing knowledge based analysis is not enough to resolve all possible conflict situations

because conflicts may grow large in dimension and complexity. Moreover, when solutions are found,

the system is interested in choosing the most energy efficient one. Many different types of real-life

scheduling, resource allocation and configuration problems can be modelled as Constraint Satisfaction

32

Problem (CSP) and solved using constraint-programming techniques. Encoding the environment in-

formation as a set of boolean expressions is an adequate approach, since these expressions can be

manipulated by existing algorithms, namely SAT solvers.

A propositional formula, is a Boolean expression constituted by variables, operators AND, OR, NOT

and parenthesis. If there is any assignment of appropriate values to variables, that make the formula

evaluate to TRUE, then it is said that the proposition is satisfiable. Resolving conflict translates to finding

a an assignment to variables that makes all the environment restrictions imposed by user preferences

and activity’s conditions evaluate to TRUE. An assignment of variables that validates the the proposition

is in fact a system state that hold every user preferences and activity’s restrictions so that conflict does

not occur. The satisfiability problem SAT is NP-complete, which means there is no algorithm that can

solve every instance of SAT in polynomial time. Despite that, we believe that the instances of SAT related

to our problem can be resolved in sensible time.

4.2.1 Syntactic representation of the environment

The environment’s conditions syntax can be such that variables (X1, ..., Xn) are restricted by a set of

constraints C1, ..., Cn. A constraint system is denoted as P = C1, ..., Cn. Where θ is an assignment of

values to all variables, θ : X1 ∪ ... ∪Xn in their respective domain. When this mapping of values is such

that a constraint C holds, then θ is said to satisfy C, denoted θ |= C. If there is an assignment θ of

values, that satisfies all constraints in P at the same time, then θ is a solution for P, denoted θ |= P . If no

solution can be found it is said that P is unsatisfiable.

Now consider a three step example on how to model the problem depicted by Figure 4.2 using the

results attained from the conflict detection module. Suppose there is a conflict between Alice and Bob

regarding lighting levels expressed in Table 4.2. Moreover, preferences are [450, 550] and [560, 600] lux

respectively, as depicted in Figure 1.1 in the motivation.

1. The first step is to find the assignment of variables that holds every constraint regarding the domain

problem. The ambient restrictions that model the problem can be formally expressed as series of

disjoint conditions such as:

P := X ≥ 450 ∧X ≤ 550 ∧X ≥ 560 ∧X ≤ 600 (4.1)

or expressed in java as:

2. Regarding energy efficiency, when multiple solutions exist, we are interested in the assignment of

values that minimize the equation that represents the energy consumption by means of constraint

optimization techniques. In this case, the only environment variable at play is lighting represented

by X. Therefore, let Ec(X) represent the equation for energy consumption in function of lighting

levels. The problem is now formally expressed as:

33

Figure 4.4: Definition of finite domain variables in Java according to the scenario above.

min Ec(X) subject to

P := X ≥ 450 ∧X ≤ 550 ∧X ≥ 560 ∧X ≤ 600(4.2)

or expressed in Java as:

Figure 4.5: Definition of finite domain variables and a cost function in Java according to the scenarioabove.

3. The value intervals regarding both occupants preferences, [450, 550] and [560, 600] respectively,

do not overlap. Meaning that there is no possible assignment of values able to comply with every

constraint in P. In this case, we’re interested in finding the assignment of values that validates most

of the constraints in P. Since the problem is no longer finding a solution that holds every single

constraint in the system, the paradigm changes transforming the SAT problem into a MAX-SAT

problem. MAX-SAT problems are instances of CSP problems where a number of constraints are

allowed to be violated, and the quality of the solution is determined by the number of satisfied

constraints.

When the system is not able to guarantee that all user preferences are satisfied, it re-analyses the

environment’s conditions on other shared spaces in order to redirect the user to a location where

he can perform his activity without interfering with others and vice-versa.

34

Lighting

Study

hasPreference(Environment Variable)

Meeting

AC

Lamp

Classroom

hasPreference(Environment Variable)

hasPreference(Environment Variable)

hasPreference(Environment Variable)

SATISFIED

SATISFIED

NOT SATISFIED

NOT SATISFIED

isIn isIn Bad Activity

Normal Activity

15 Lux

0 Lux 800 Lux

0 Lux 800Lux

5 Cº

0 Cº 40 Cº

0 Cº 40 Cº

TemperatureB)A)

Figure 4.6: Example scenarios describing activity deadlock and starvation situations. (A) Activity dead-lock state expressed by a cross-preference scenario where satisfied conditions for Meeting are notsatisfied for Study and vice-versa. (B) Activity starvation state expressed by a scenario where an ac-tivity conditions absurdly low levels for environment variables providing it an upper hand in one on oneconflicts with other activities.

4.3 Conceptual Issues

Herein, we address the main conflict handling definitions that arose during the implementation process

such as activity or preference profile selection criteria during the resolution process, and conditions

under which an activity or person shall be redirected to another space. The following section addresses

each problem with further detail.

4.3.1 Resolution methodology

The conceptual model presented in Section 4.1 dictates that activities are a set of conditions over en-

vironment variables. Activities are satisfied according to those conditions and how they interfere with

others. Consequently, the resolution methodology faces the following dilemma:

• Shall the resolution process satisfy the majority of conditions or the majority of activities?

If an occupant with a set of conditions regarding a particular activity is inside a space that for some

reason cannot leave, it would be adequate if, even if the system is not able to satisfy all conditions,

it would at least satisfy the majority of them. On the other hand, consider the situation illustrated in

Figure 4.6, where two activities Meeting and Study have preferences over two environment variables

Temperature and Lighting each. Moreover, the system is able to satisfy one preference for each

activity. This results in a state where, although the majority of conditions were satisfied, none of the

activities are completely able to take place, resulting in an activity deadlock.

Selecting activities whose all conditions are able to be satisfied means that an activity is excluded

if one or more conditions are violated. Furthermore, the system prioritizes activities that have the most

energy efficient conditions. Consider the case where low environment variable levels mean less energy

consumption. If an activity with abnormally low levels of conditions would always win as long as it

is not outnumbered by other activities, resulting in activity starvation. Moreover, the high demand

for condition satisfaction for each activity means that few activities can coexist inside the same space,

compromising activity-to-space assignment efficiency. On the other hand, this approach guarantees that

activities can operate with fully satisfied conditions and mitigates activity-deadlock situations.

35

Default Activity User (Custom) Activity

Conflict Resolution Policy Maximize number of activities Maximize number of conditions

Orientation policy Not satisfied activity Activity with at leastone unsatisfied condition

Activity deadlock vulnerable NO YESActivity starvation vulnerable NO NO

Table 4.3: Conflict resolution methodology and orientation policy for each default activities and customactivities, as well as respective vulnerabilities to activity deadlock and starvation.

4.3.2 Advising methodology

Whenever an activity cannot be satisfied, the system is able to direct its intervenors to a space where that

activity is able to take place. However, depending on how the resolution method is carried out, whether

through maximizing satisfied environment conditions or maximizing satisfied activities, it is necessary to

establish the requirements under which the system shall suggest another space or not.

The angle where the system generates solutions based on an activity maximization policy, means

that activities are satisfied through and through, or they are not even taken into account. Occupants

performing the system’s discarded activities are then suggested with another space where they can per-

form it without interference. However, this situation becomes less trivial if the system adopts a condition

maximization policy, which means that activities can also be partially satisfied, resulting in the following

dilemma:

• What are the requirements under which the system shall redirect occupants performing a particular

activity to another space?

When activity conditions or preferences are partially met, it is difficult to know when an activity shall

be considered for redirection, due to the subjectivity and individualism of occupant’s preferences. In

other words, some occupants may not mind if one or two conditions are violated while others may do.

Furthermore, it is important that the system is able to perform an intelligent selection of activities to

re-allocate, because the more activities are taken into account, the more restrictions are added to the

redirector module’s calculations, potentially lowering the amount of solutions.

4.3.3 A solution to the conceptual problems

The resolution methodology and activity (and occupant) orientation issues represent conceptualization

problems that have to be dealt with before the implementation stage, thus new conceptions have to be

added to the original model expressed in Table 4.1, in order to address the issues at hand. Herein, we

present a conceptual solution that helps mitigate the problems related to the resolution methodology

and activity (and occupant) orientation functionalities.

According to the conceptual model presented in Table 4.1 and elaborated in Figure 4.2, activities

may also be User Activities. A user activity is in fact an individual customization of an already existent

activity according to the preferences of one occupant. Consider that Alice intends to Read, activity

36

Activity

● Conditions n Environment Variables

● isPerformedBy n Occupants

● occurs in only one Zone

UserActivity

● isPerfomedBy only one Occupant

Figure 4.7: Class diagram expressing the different requirements among Activities and UserActivities.UserActivity, as a sub-class of Activity, inherits the conditions that an object must satisfy in order to be amember of that class, as well as the conditions imposed by itself.

which is already modelled in the ontology with pre-defined conditions. Furthermore, those conditions do

not comply with Alice’s preferences. Alice is able to customize the activity’s conditions according to her

preferences, creating a personalized version of that activity. Custom activities are members of the class

UserActivity which inherits from Activity.

Figure 4.7 presents a class diagram that distinguishes both classes based on its requirements. User-

Activity inherits the requirements imposed by the class Activity and also specifies that a UserActivity

may be performed by only one and unique occupant.

The established conceptualization depicted by Figure 4.7, that defines distinct types of activities, can

be used to address the issues mentioned in Section 4.3.1 and 4.3.2 by applying different resolution

techniques and orientation policies depending on each activity type. In particular, user activities are an

individual specification of one occupant regarding an existing activity. Consequently, it would be sensible

for the system to take activities designed to be performed by large sets of people, ie. default activities, in

high priority, instead of accommodating lots of individualized activities, ie. custom activities, and different

customized conditions coexisting in the same space on an equal footing. In other words, default activities

are accommodated inside a space, and custom activities are, then after, accommodated inside the same

space if possible. Furthermore, occupants performing custom activities inside a space, from which for

some reason they cannot leave, would want most of their conditions satisfied, if not all. Therefore, the

conceptual model also establishes that default activities (members of the class Activity that are not

members of the class UserActivity) must to have all their conditions satisfied in order to be executed

inside a space, while custom activities (members of the class UserActivity) may have some conditions

violated and still take place inside a space.

The advisor functionality, in part, takes advantage of the differences between custom and default

activities in the sense that, default activities either have all their conditions satisfied or none at all,

therefore the system will suggest a new space, if available, to every unsatisfied activity. In the case of

custom activities, the advisor module only takes into account activities that have at least one violated

condition. However, we’re aiming at parametrizing the amount of violated conditions necessary to trigger

the advising analysis in future versions, due to the often wide range of users intentions.

Different advising analysis behaviour for each type of activity doesn’t represent all problems that may

arise regarding advising features. Consider that Alice intends to Study in the Meeting Room and the

system is not able to satisfy that activity. The system’s advisor module kicks in and suggests a new space

37

DetectConflictingActivities

FindSolutions

AnyUnsatisfied

Activity?

SuggestSpaces

activities results resultscommands& suggestions

Y

N

Decide which

commands to send

data

data

Figure 4.8: Main sequence of steps undertaken by the system since the moment the ontology is anal-ysed until when environment commands are sent to devices.

for Alice in order for her to perform her activity. However, the activity-to-space distribution at that time is

such that only the Lounge Room is available. Thereafter, other occupants finish their classes and aim at

spending the pause break somewhere. Since the system’s already accommodated Alice in the Lounge

Room, which would be the natural space for other people to enjoy their break time, the system would

not suggest that space any more. To avoid this sort of situation, each room offers services that actuate

on environment variables. Conditions imposed by services ultimately define the utility of each space so

that occupants do not perform activities they’re not supposed to in certain spaces. Consequently, the

system either suggests Alice to go to a proper studying space or makes no suggestion at all, instead of

mentioning other spaces that, although are able to accommodate that activity at the moment, are not

the natural spaces to host it.

Table 4.3 expresses the characteristics that distinguish default and user activities as well as their

respective vulnerabilities to activity deadlock and starvation.

4.3.4 Execution flow

The main sequence of steps undertaken by the system, from the moment when the ontology is analysed

to the moment when environment commands are sent, is illustrated by the pseudo-code presented in

Figure 4.8.

After querying the ontologies for conflicting activities, the system must convert each activity’s con-

ditions or preferences into finite domain variables that represent the acceptable environment variable

interval of values according to each according to each activity.

Since there are different types of activities defined in the conceptual model, i.e, default and custom

activities, the resolution methodology differs when calculating solutions for each type of activity conflict.

For custom activities, it is acceptable that some conditions are violated, therefore one solution calcula-

tion iteration is enough to find environment values that maximize satisfied conditions. On the other hand,

default activities must have all their conditions satisfied. Consequently, if one of the unsatisfied activities

is discarded and the solution computation process is repeated, it is possible that other previously unsat-

isfied activities can now be satisfied due to the removed restrictions imposed by the discarded activity

that turned out to make a difference in the outcome of others. Therefore, for default activities, the system

repeatedly calculates new solutions until all activities are satisfied.

Discarded activities, whether default or custom, are processed by the advisor module where spaces

38

are respectively suggested to each activity. Environment commands are only sent to devices that must

change their current environment levels in order to comply with the system’s generated solutions. In

other words, the system will not send environment commands to devices that are already set to an

acceptable solution at that time.

4.4 Technical framework

The framework proposed in this thesis will be developed in Java to facilitate integration with the automa-

tion system apparatus we are experimenting on. Furthermore, Java is well known as a mature language

for secure platform-independent applications (Arnold et al., 2000). Moreover, the system must provide

ease of development and deployment in real world scenarios.

The tools and frameworks used for the implementation of our prototype system in view of the pro-

posed framework, were depicted in Figure 4.1.

The querier module is implemented using Apache Jena2, an open source Semantic Web framework

for Java that provides and API to extract data from and write to RDF graphs among other tools to help

the development of semantic web and linked-data applications, tools and servers. Jena supports models

sourced with data from files, databases, URL’s or a combination of these.

The inference subsystem is designed to allow a range of inference engines or reasoners to be

plugged into Jena. Such engines are used to derive additional RDF assertions, which are entailed from

some base RDF together with any optional ontology information and the axioms and rules associated

with the reasoner. It makes sense to resort on Jena framework since the inferred information plays an

important role for the development of the presented solution. Plus other Java frameworks e.g. JSolver3,

which facilitates the development of most of the constraint solver components can be embedded in Jena

using the same language, in this case Java.

The resolution module employs JSolver, a tool that extends the object-oriented programming paradigm

of Java with constraint-based declarative programming, and offers constraint programming support

within an object-oriented Java environment (Chun, 1999). It provides essential classes needed to sup-

port constraint programming with boolean and integer constrained variables, which is a popular repre-

sentation for CSP algorithms. Moreover, it can be integrated into an application to perform run-time

operations. Thus it is adequate for scheduling systems that usually require continuous re-solving due to

changes in the problem definition. In other words, JSolver is suitable for solving dynamic problems that

involve user interactions at run-time events.

In the scope of this work, JSolver is used to to implement the resolution module, to deal with con-

straint problems modelled from context and environment conditions provided by the ontology in order to

perform conflict resolution tasks.

2http://jena.apache.org/3http://w3.pppl.gov/rib/repositories/NTCC/catalog/Asset/jsolver.html

39

40

Chapter 5

Validation

The validation process regarding the presented hypothesis consisted in implementing the prototype

framework. As expressed in previous chapters, the development process entailed three main steps: i)

development of the semantic model that would reproduce the environment-reflecting ontology; ii) per-

forming an environment analysis by extracting information from the ontology using SPARQL queries; iii)

generating environment solutions using constraint solving techniques.

The undertaken methodology for validating the proposed solution basically consisted of assuring the

semantic model consistency using ontology reasoners and validators, detecting conflicting environment

states, and finally producing valid solution values for well defined conflict scenarios in order to evaluate

the system’s response and attest its validity.

This chapter introduces an ontology validation procedure as well as several conflict oriented scenar-

ios with respective generated output and a practical discussion regarding the obtained results.

5.1 Ontology validation

The ontology model was developed using Protege1, an open source knowledge-base framework that

supports modeling ontologies in a variety of formats.

FacT++ is a Protege built-in reasoner implemented in C++ that supports OWL DL and OWL 2 DL

using optimized tableaux algorithms. The logic consistency of our ontology was validated by FacT++,

producing the following output that shows no inconsistent ontology exceptions.

Figure 5.1: Output produced by Protege during execution of FacT++ built-in reasoner.

Furthermore, the ontology was validated as an OWL 2 DL profile by the University of Manchester

1http://protege.stanford.edu/

41

Figure 5.2: Plot representation of the system set lighting levels in function of the entry of new occupantseach five minutes.

OWL Validator 2.

5.2 Test Cases

Herein, we present several practical test scenarios that aim at verifying the system performance regard-

ing the most diverse environment states. In other words, the test cases approach both custom and

default activity conflict as well as the space advising module decisions regarding different well defined

situations.

5.2.1 Motivation test case

The scenario presented in Section 1.1 specifies situation where the system performs environment ac-

tuations in function of the entry of users inside the space. The motivation section expresses the entry

of each new user as distinct individual cases in order to demonstrate the different system actions taken,

depending on whether there is a solution or not. However, if we look at the entry of each user as a

sequential even, in other words, different users enter the space one after the other, it can be seen as a

test case goaling at the analysis of the system’s environment adjustments over time.

Consider that Alice is inside the Living Room and specifies a preference interval regarding the

space’s lighting at 450-550 Lux. Bob enters the room with a preference interval of 490-590 upon the

same environment variable. Then Charles and David also enter the space at minute 10 and 15 with

505-550 and 560-660 preference intervals respectively. In this case, it is expected that the system tries

to satisfy each user as they enter the space, minimizing the number of unsatisfied users.

Figure 5.2 expresses the lighting levels in Lux in function of time in minutes during the process.

Results show that the lighting levels are set to 550 Lux at instant 0 minutes with Alice being already

inside the space. Normally, the system would set lighting levels to 500, which is the minimum lighting

level available inside Alice’s preference interval, in order to save power. However, for the sake of this

test scenario simplicity, that function was deactivated. Five minutes later, Bob enters the space with a

2http://mowl-power.cs.man.ac.uk:8080/validator/

42

Figure 5.3: Diagram representing the ontology that reflects the test case where four distinct activitiescompete for the resources of a space that offers a service that only complies with one of them.

Default Activity / Service

Space EnvironmentVariable

Activity/Service Condition Satisfied

RefrigeratorRoom Temperature

(Service)Refrigerate 0 - 5 True

ConserveMeat 1 - 4 True

Read 21 - 23 FalseMovie 20 - 22 FalseSleep 22 - 24 False

Solution: 2

Table 5.1: System’s produced results to the ontology that reflects the test case where four distinctactivities compete for the resources of a space that offers a service that only complies with one of them.

preference interval ranging 490-590 Lux. The current lighting levels already meet the preferences of

both users, therefore no actuation is necessary. At minute ten, Charles enters the space specifying his

lighting preferences at 505-550 and, in this case, the current lighting levels do not comply with all of

users preferences. Therefore, the system actuates, setting the lighting levels them to 527 Lux satisfying

everyone inside the space at that time. Finally, David enters the space with preference interval 560-660

Lux. As shown in Figure 5.2, no actuation is made leaving David’s preferences unattended. That is

because there is no possible solution to satisfy all four occupants, therefore the satisfied majority does

not include David which is notified of the system’s inability to comply with his preferences and, if possible,

is suggested to relocate to another space where his preferences are met.

5.2.2 Services Testing

The services offered by each space determine the purpose of which a given space shall be used for.

Services specify conditions over environment variables and activities to be executed in a space must

43

Figure 5.4: Diagram representing the ontology that reflects the test case where three distinct activitiescompete for the resources of the same room and the discarded are suggested to be executed insideother proper spaces.

comply with those services. As such, it is necessary to verify whether the system correctly fits candidate

activities with the services available inside the space they are to be performed.

Consider that a system managed refrigerator room, which sole purpose only applies to conserving

food. Furthermore, there are four distinct activities, Read, Movie, Sleep and Conserve Meat, three of

which are not meant to be carried out inside a refrigerator. All of them, specify preferences over the

same environment Temperature. Figure 5.3 represents the ontology that reflects the environment state

described above. Normally, the system satisfies the majority of the competing activities, however in this

case, only one activity complies with the offered service, so it is to be expected that the system overrides

that logic in order to avoid the space being used for the wrong purposes.

Table 5.1 express the system’s generated ouput solution to this particular test scenario. Results show

that although there is a majority of activities that can be satisfied, the system effectively choses to satisfy

the one that complies with the service. That is possible because the system immediately excludes the

activities that do not fit with the services offered by the space in which they are trying to be executed.

5.2.3 Advisor functionality testing

Consider the scenario where three distinct activities, Movie, Read and Meeting, are to take place inside

the same space Library and Lounge and Office spaces are empty. In this case, each space offers one

service, Read Environment, Watch Movie and Meeting Environment respectively, conditioning two

environment variables, Sound and Light, both also offered by all three spaces. Figure 5.4 depicts the

described environment state. Furthermore, consider that the set of preferences regarding sound and

44

Default Activity / Service

Space EnvironmentVariable

Activity/Service Condition Satisfied

Living Room Sound Reading 0 - 20 TrueSolution: 10

Living Room Light Reading 200 - 300 TrueSolution: 250

Living Room Sound Movie 58 - 65 FalseSolution: -

Living Room Light Movie 5 - 10 FalseSolution: -

Living Room Sound Meeting 60 - 65 FalseSolution: -

Living Room Light Movie 250 - 350 FalseSolution: -

Lounge Sound WatchMovie 0 - 65 True

Solution: 32

Lounge Light WatchMovie 0 - 600 True

Solution: 300

Office Sound MeetingEnvironment 0 - 65 True

Solution: 32

Office Light MeetingEnvironment 200 - 600 True

Solution: 400

Advisor Module

Movie goes to LoungeMeeting goes to Office

Table 5.2: System’s produced results to the ontology reflecting the test scenario where an automatedspace tries to host three default activities at the same time, but does not offer all the necessary servicesto accommodate all of them.

lighting is such that Read is the only activity that fits into the service offered inside the library, in this

case Reading Environment. It is expected that the system is not able to satisfy both Movie and Meeting.

Moreover, the two remaining rooms, Lounge and Office offer services that are able to accommodate the

activities that are not satisfied inside the Library. The system is also expected to suggest whoever is

trying to watch a movie and have a work meeting to relocate to the Lounge and Office respectively.

Table 5.2 represent the system output to the ontology associated to the described environment state.

Results show that the Meeting was immediately set aside because it was the less energy efficient activity

when competing against Read. Activity Movie was also discarded because the service offered by the

Library does not allow the execution of that particular activity, letting Read be the only activity occurring

inside that space at that time. However, the advisor module kicks in and analyses whether the discarded

activities may still be executed in different spaces. The ontology representing this test scenario still

indicates that there are two more spaces where activities can occur. Since activities Movie and Meeting

fit perfectly with the services offered in the Lounge and Office respectively, the advisor module suggests

users performing each activity to relocate, as shown in the results, to the right spaces.

5.2.4 Default vs custom activities

The environment state of the managed spaces is dynamic and ever changing. This environment state is

represented by the ontology individuals (instances) and relations among each other. Furthermore, oc-

45

Figure 5.5: Diagram representing the test scenario where default and custom activities are taking placeinside the same space.

Default Activity / Service

Space EnvironmentVariable Activity/ Service Condition Satisfied

Office Temperature Study 20 - 24 TrueOffice Light Study 500 - 505 True

Custom Activity

Space EnvironmentVariable User Preference Satisfied

Office Temperature Alice 23 - 25 FalseOffice Temperature Bob 20 - 22 True

Solution: 21

Office Light Alice 450 - 500 TrueOffice Light Bob 510 - 550 False

Solution: 500

Table 5.3: System’s produced results to the ontology reflecting the test scenario where an automatedspace hosts both services and user preferences conditioning the same environment variable.

cupants may opt to perform system default (i.e. predefined) activities or perform a personalized version

of those activities which specify the individual preferences of users. As such, it is not only possible but

inevitable that default and custom activities come to compete for the resources of a given space at the

same time.

Consider the case where occupants Alice and Bob are inside the Office where the default activity

Study is already taking place by a number of users, establishing preferences over the environment

variable Temperature. Moreover, both Alice and Bob also establish their own preferences over the

same environment variable. Figure 5.5 depicts the ontology that represents the environment state at

that time.

As mentioned in Section 4.3.3, it would be sensible that the system take default activities in high

priority over custom activities. Consequently, it is expected that, due to the presence of people trying

to perform default activities inside the Office, the system satisfy custom activities as long as they do

not interfere with the solutions found to settle the default activities. In other words, default activities are

solved first and custom activity preferences must fit inside those solutions in order to be considered

46

satisfied as well.

Table 5.3 expresses the system’s generated results to this particular scenario. Results show that

both preferences imposed by Alice and Bob are indeed satisfied and the produced solutions comply

with the service conditions.

47

48

5.3 Energy efficiency

Energy efficiency operations are carried out in the solution computation phase of the execution flow.

Ideally, the system would have an energy monitoring component, or module, in order for the system

to analyze energy consumption and engender a cost function in terms of environment variable values.

Given a generated set of possible solutions, the system would chose the one that minimized the cost

function, thus finding the most energy efficient environment variable value. However, no energy moni-

toring component was integrated in the system, making this approach unfeasible. On the other hand,

most ambient devices have an energy consumption proportional to the levels they are set to. As such,

the system choses the minimum value from the solution set in order to avoid unnecessary energy ex-

penditure.

5.4 Discussion

The previous sections presented ontology consistency and validation methodologies, as well as several

conflict scenarios to evidence the system’s efficiency and accuracy.

The analyzed system output showed to be valid solutions for the theoretical CSP formal expressions

for all presented scenarios and all experiments carried out during the implementation phase, making the

possibility of incorrect output almost negligible. Furthermore, there was no evidence non-deterministic

output for a static ontology, in other words, the system always produces the same solution for a constant

environment state. As such, the system’s output accuracy and reliability is attested.

The most time-consuming phase takes place in the resolution module during the execution of constraint-

solving operations. The time it takes to compute CSP operations varies in terms of variables and con-

straints. However, in the scope of HBAS it is possible to perform such operations in sensible time. In

this case, none of the presented conflict scenarios exceeded the 200 ms threshold, thus evidencing the

system’s efficiency.

As mentioned before, the time it takes for the system to generate solutions varies in function of

constraints and variables. More specifically, with the number of automated spaces and users/activities.

Basically, the system scalability fails only if the number of managed spaces is such that the time con-

sumed for generating an iteration output is greater than the time interval between iterations. It is inferred

that the system is able to manage a large set of buildings, depending in size or number of automated

spaces, before starting to reveal performance issues.

As for real-world applicability, it would be necessary to deploy the system inside an automated labo-

ratory and test it with real users. On the other hand, there were some implications that challenged this

approach. A network of sensors and a context-aware module would have to be provided and developed

respectively to feed the ontology. Unfortunately, those resources were not available. Nonetheless, it is

expected a good level of real-world practicality in future works, given the promising results presented by

this thesis.

49

Chapter 6

Conclusions

Developing highly intelligent and adaptive Home and Building Automation Systems (HBAS) is a complex

multi-domain problem that is knowing increasing relevance. However, with respect to solving conflict

arising in multi-user scenarios, HBAS are still to reach a maturity level that enables them to automatically

handle highly subjective contextual information regarding users intentions and interfering actuations,

namely with respect to solving conflicts arising in multi-user scenarios.

The prototype solution proposed herein for conflict detection and resolution is able to perform context

analysis based on an ontology that formally represents environment’s conditions. Conflict detection ca-

pabilities are powered by a knowledge-analysis module that enables the recognition of potential conflicts.

The conflict resolution operations are carried out by means of constraint solving enabling to respond au-

tomatically to a diversity of decision-demanding scenarios. Moreover, we presented a set of relevant

frameworks and libraries to be used in the prototype’s implementation.

In order to evidence the potential value addition and main contributions of our work, a real world

scenario is presented. We observe that our framework performs automatic environment adaptations

on behalf of users according to their comfort preferences while, at the same time, maximizes energy

efficiency by setting actuators to the least energy demanding configuration.

Future work will deal with a number of issues which must be tackled to allow the development of intel-

ligent automation systems that act predictively on behalf of users. One research direction worth pursuing

is to investigate how knowledge-based automation systems can be effectively integrated with context-

aware components. Another direction is to investigate whether it is possible to perform knowledge-

based analysis and constraint solving operations in a centralized architecture where actuations are sent

to clients deployed in remote buildings. Finally, it will be explored the possibility of optimizing the system

with learning capabilities to automatically infer user preferences based on observation.

In addition, we plan to integrate the proposed framework in a real-world building setting in the scope

of the smart campus1 project.

1http://greensmartcampus.eu/

50

Bibliography

Aarts, E. and Wichert, R. (2009). Ambient intelligence. In Technology Guide, pages 244–249. Springer.

Abowd, G. D., Dey, A. K., Brown, P. J., Davies, N., Smith, M., and Steggles, P. (1999). Towards a better

understanding of context and context-awareness. In Handheld and ubiquitous computing, pages 304–

307. Springer.

Alshabi, W., Ramaswamy, S., Itmi, M., and Abdulrab, H. (2007). Coordination, cooperation and conflict

resolution in multi-agent systems. In Innovations and advanced techniques in computer and informa-

tion sciences and engineering, pages 495–500. Springer.

Amason, A. C. (1996). Distinguishing the effects of functional and dysfunctional conflict on strategic

decision making: Resolving a paradox for top management teams. Academy of Management Journal,

39(1):123–148.

Armac, I., Kirchhof, M., and Manolescu, L. (2006). Modeling and Analysis of Functionality in eHome

Systems: Dynamic Rule-based Conflict Detection. In 13th Annual IEEE International Symposium and

Workshop on Engineering of Computer Based Systems (ECBS’06).

Arnold, K., Gosling, J., and Holmes, D. (2000). The Java programming language, volume 2. Addison-

wesley Reading.

Aros (2014). Aros: A truly brilliant air conditioner. https://www.quirky.com/aros. (Last accessed on

April, 2014).

Bartak, R. (1999). Constraint programming: In pursuit of the holy grail. In Proceedings of WDS99

(invited lecture), Prague, June, pages 205–224.

Bayazit, M. and Mannix, E. A. (2003). Should I stay or should I go? predicting team members’ intent to

remain in the team. Small Group Research, 34(3):290–321.

Bechhofer, S., van Harmelen, F., Hendler, J., Horrocks, I., McGuinness, D. L., Patel-Schneider, P. F., and

Stein, L. A. (2004). OWL Web Ontology Language reference. W3C Recommendation. Available at

http://www.w3.org/TR/owl-ref/.

Becker, C., Handte, M., Schiele, G., and Rothermel, K. (2004). Pcom-a component system for pervasive

computing. In Pervasive Computing and Communications, 2004. PerCom 2004. Proceedings of the

Second IEEE Annual Conference on, pages 67–76. IEEE.

51

Bell, D. A. and Grimson, J. (1992). Distributed Database Systems. Addison-Wesley, Boston, MA, USA.

Bensaid, N., Mathieu, P., et al. (1997). A framework for cooperation in hierarchical multi-agent systems.

Mathematical Modeling and Scientific Computing, 8.

Berners-Lee, T., Hendler, J., Lassila, O., et al. (2001). The semantic web. Scientific american, 284(5):28–

37.

Binmore, K. (1992). Fun and games, a text on game theory.

Bohn, J., Coroama, V., Langheinrich, M., Mattern, F., and Rohs, M. (2005). Social, economic, and ethical

implications of ambient intelligence and ubiquitous computing. In Ambient intelligence, pages 5–29.

Springer.

Bonino, D., Castellina, E., and Corno, F. (2008). The dog gateway: enabling ontology-based intelligent

domotic environments. Consumer Electronics, IEEE Transactions on, 54(4):1656–1664.

Bonino, D., Corno, F., and Razzak, F. (2011). Enabling machine understandable exchange of energy

consumption information in intelligent domotic environments. Energy and Buildings, 43(6):1392–1402.

Borst, W. N. (1997). Construction of engineering ontologies for knowledge sharing and reuse. PhD

thesis, Universiteit Twente.

Boton-Fernandez, V. and Lozano-Tello, A. (2011). Learning algorithm for human activity detection in

smart environments. In Proceedings of the 2011 IEEE/WIC/ACM International Conferences on Web

Intelligence and Intelligent Agent Technology-Volume 03, pages 45–48. IEEE Computer Society.

Camacho, R., Carreira, P., Lynce, I., and Resendes, S. (2014). An ontology-based approach to conflict

resolution in home and building automation systems. Expert Systems with Applications, 41(14):6161–

6173.

Capra, L., Emmerich, W., and Mascolo, C. (2003). Carisma: Context-aware reflective middleware system

for mobile applications. Software Engineering, IEEE Transactions on, 29(10):929–945.

Chun, H. W. (1999). Constraint programming in java with jsolver. In Proc. Practical Applications of

Constraint Logic Programming, PACLP99.

Conradi, R. and Westfechtel, B. (1998). Version models for software configuration management. ACM

Computing Surveys (CSUR), 30(2):232–282.

Corno, F. and Razzak, F. (2012). Intelligent energy optimization for user intelligible goals in smart home

environments. Smart Grid, IEEE Transactions on, 3(4):2128–2135.

Davy, S., Jennings, B., and Strassner, J. (2008). Using an information model and associated ontology

for selection of policies for conflict analysis. In Policies for Distributed Systems and Networks, 2008.

POLICY 2008. IEEE Workshop on, pages 82–85. IEEE.

Dey, A. K. (2001). Understanding and using context. Personal and Ubiquitous Computing, 5(1):4–7.

52

Dey, A. K., Abowd, G. D., and Wood, A. (1998). Cyberdesk: A framework for providing self-integrating

context-aware services. Knowledge-Based Systems, 11(1):3–13.

Echelon (2003). Echelon smart buildings. http://www.echelon.com/applications/

smart-buildings/. (Last accessed on April, 2014).

Fensel, D. (2001). Ontologies - a silver bullet for knowledge management and electronic commerce.

Springer.

Fisher, R. J. (1997). Interactive conflict resolution. Syracuse University Press.

Furlong, G. T. (2005). The conflict resolution toolbox. Wiley. com.

Galinsky, A. D. (2002). Creating and reducing intergroup conflict: The role of perspective-taking in

affecting out-group evaluations. Research on Managing Groups and Teams, 4:85–113.

Genesereth, M. R. and Nilsson, N. J. (1987). Logical foundations of artificial intelligence, volume 9.

Morgan Kaufmann Los Altos.

Gruber, T. R. (1993). A translation approach to portable ontology specifications. Knowledge Acquisition,

5(2):199–220.

Gu, T., Wang, X. H., Pung, H. K., and Zhang, D. Q. (2004). An ontology-based context model in intelligent

environments. In Proceedings of communication networks and distributed systems modeling and

simulation conference, volume 2004, pages 270–275.

Guarino, N., Oberle, D., and Staab, S. (2009). What is an ontology? In Handbook on ontologies, pages

1–17. Springer.

Haase, P. and Stojanovic, L. (2005). Consistent evolution of owl ontologies. In The Semantic Web:

Research and Applications, pages 182–197. Springer.

Hasan, M., Anh, K., Mehedy, L., Lee, Y., and Lee, S. (2006). Conflict Resolution and Preference Learning

in Ubiquitous Environment. In Computational Intelligence, volume 4114 of Lecture Notes in Computer

Science, pages 355–366. Springer.

Horrocks, I. and Patel-Schneider, P. F. (2003). Reducing owl entailment to description logic satisfiability.

In The Semantic Web-ISWC 2003, pages 17–29. Springer.

Hue (2013). Phillips hue connected light bulb: Personal wireless lighting. http://meethue.com/. (Last

accessed on April, 2014).

Huerta-Canepa, G. and Lee, D. (2008). A multi-user ad-hoc resource manager for smart spaces. In

World of Wireless, Mobile and Multimedia Networks, 2008. WoWMoM 2008. 2008 International Sym-

posium on a, pages 1–6. IEEE.

Jehn, K. A. (1995). A multimethod examination of the benefits and detriments of intragroup conflict.

Administrative science quarterly, 40(2):256–282.

53

Katz, D. (1965). Nationalism and strategies of international conflict resolution. International behavior: A

social psychological analysis. New York: Holt, Rinehart & Winston, pages 356–390.

Koegel, M., Herrmannsdoerfer, M., von Wesendonk, O., and Helming, J. (2010). Operation-based con-

flict detection. In Proceedings of the 1st International Workshop on Model Comparison in Practice,

pages 21–30. ACM.

Kung, H.-Y. and Lin, C.-Y. (2006). Application-Layer Context-Aware Services for Pervasive Computing

Environments. Innovative Computing ,Information and Control, International Conference on, 3:229–

232.

LIFX (2012). Lifx: The lightbulb re-invented. http://lifx.co/. (Last accessed on April, 2014).

Loseto, G., Scioscia, F., Ruta, M., and Di Sciascio, E. (2012). Semantic-based smart homes: a multi-

agent approach. In 13th Workshop on Objects and Agents (WOA 2012), volume 892, pages 49–55.

Lupu, E. C. and Sloman, M. (1999). Conflicts in policy-based distributed systems management. Software

Engineering, IEEE Transactions on, 25(6):852–869.

Masoumzadeh, A., Amini, M., and Jalili, R. (2007). Conflict detection and resolution in context-aware

authorization. In Advanced Information Networking and Applications Workshops, 2007, AINAW’07.

21st International Conference on, volume 1, pages 505–511. IEEE.

Maternaghan, C. and Turner, K. (2013). Policy Conflicts in Home Automation. Computer Networks,

57(12):2429–2441.

McGuinness, D. and Harmelen, F. V. (2004). OWL web ontology language overview. W3C recommen-

dation, 2004(February):1–12.

Merz, H., Hansemann, T., and Hubner, C. (2009). Building Automation: Communication Systems with

EIB/KNX, LON und BACnet. Signals and communication technology. Springer.

Moore, C. W. (2003). The mediation process: Practical strategies for resolving conflict. San Franscisco:

Joseey-Bass.

Morrill, C. (1995). The executive way: Conflict management in corporations. University of Chicago

Press.

Neisse, R., Wegdam, M., and van Sinderen, M. (2008). Trustworthiness and Quality of Context Informa-

tion. In Proceedings of the 9th International Conference for Young Computer Scientists (ICYCS’08),

pages 1925–1931.

Nest (2012). Nest: Learning thermostat. https://nest.com/. (Last accessed on April, 2014).

Park, I., Lee, K., Lee, D., Hyun, S. J., and Yoon, H. Y. (2005). A dynamic context conflict resolution

scheme for group-aware ubiquitous computing environments. In Proceedings of the 1st International

Workshop on Personalized Context Modeling and Management for UbiComp Applications (ubiPCMM

2005), pages 42–47.

54

Pascoe, J. (1998). Adding generic contextual capabilities to wearable computers. In Wearable Comput-

ers, 1998. Digest of Papers. Second International Symposium on, pages 92–99. IEEE.

Perez, J., Arenas, M., and Gutierrez, C. (2006). Semantics and Complexity of SPARQL. The Semantic

Web-ISWC 2006.

Ram, S. and Park, J. (2004). Semantic conflict resolution ontology (scrol): An ontology for detecting

and resolving data and schema-level semantic conflicts. Knowledge and Data Engineering, IEEE

Transactions on, 16(2):189–202.

Resendes, S., Carreira, P., and Santos, A. C. (2013). Conflict detection and resolution in home and

building automation systems: a literature review. Journal of Ambient Intelligence and Humanized

Computing, pages 1–17.

Retkowitz, D. and Kulle, S. (2009). Dependency management in smart homes. In Distributed Applica-

tions and Interoperable Systems, pages 143–156. Springer.

Sandole, D. J., Byrne, S., Sandole-Staroste, I., and Senehi, J. (2008). Handbook of conflict analysis and

resolution. Routledge.

Schilit, B. N. and Theimer, M. M. (1994). Disseminating active map information to mobile hosts. Network,

IEEE, 8(5):22–32.

Siemens (2012). Building automation systems maximum confort and perfect functional-

ity a minimum cost. http://www.buildingtechnologies.siemens.com/bt/global/en/

buildingautomation-hvac/building-automation/Pages/building-automation-system.aspx.

(Last accessed on April, 2014).

Silva, T. R. B., Ruiz, L. B., and Loureiro, A. A. (2011). Conflicts treatment for ubiquitous collective and

context-aware applications. Journal of Applied Computing Research, 1(1):33–47.

Silva, T. R. B., Ruiz, L. B., and Loureiro, A. A. F. (2010). How to conciliate conflicting users’ interests for

different collective, ubiquitous and context-aware applications? In Local Computer Networks (LCN),

2010 IEEE 35th Conference on, pages 288–291. IEEE.

Smart-Zone (2012). Samsung smart-zone: Air conditioning. http://www.samsung.com/au/

air-conditioning/smart-zone/. (Last accessed on April, 2014).

Smartthings (2012). Smartthings: Hello, smart home. http://www.smartthings.com/. (Last accessed

on April, 2014).

Staples-Connect (2013). Staples connect: Connected home made easy. http://www.staples.com/

sbd/cre/marketing/staples-connect/. (Last accessed on April, 2014).

Studer, R., Benjamins, V. R., and Fensel, D. (1998). Knowledge engineering: principles and methods.

Data & knowledge engineering, 25(1):161–197.

55

Thomas, K. (1992a). Conflict and Conflict Management: Reflections and Update. Journal of Organiza-

tional Behavior, 13(3):265–274.

Thomas, K. W. (1974). Thomas-Kilmann conflict mode instrument. Xicom Tuxedo, NY.

Thomas, K. W. (1992b). Conflict and conflict management: Reflections and update. Journal of Organi-

zational Behavior, 13(3):265–274.

Tjosvold, D. (1997). Conflict within interdependence: Its value for productivity and individuality. Using

conflict in organizations, pages 23–37.

Tonti, G., Bradshaw, J. M., Jeffers, R., Montanari, R., Suri, N., and Uszok, A. (2003). Semantic web

languages for policy representation and reasoning: A comparison of kaos, rei, and ponder. In The

Semantic Web-ISWC 2003, pages 419–437. Springer.

Tuttlies, V., Schiele, G., and Becker, C. (2007). Comity-conflict avoidance in pervasive computing en-

vironments. In On the Move to Meaningful Internet Systems 2007: OTM 2007 Workshops, pages

763–772. Springer.

Uszok, A., Bradshaw, J., Jeffers, R., Suri, N., Hayes, P., Breedy, M., Bunch, L., Johnson, M., Kulkarni, S.,

and Lott, J. (2003). Kaos policy and domain services: Toward a description-logic approach to policy

representation, deconfliction, and enforcement. In Policies for Distributed Systems and Networks,

2003. Proceedings. POLICY 2003. IEEE 4th International Workshop on, pages 93–96. IEEE.

Wallace, M. (2004). Principles and Practice of Constraint Programming-CP 2004: 10th International

Conference, CP 2004, Toronto, Canada, September 27-October 2004, Proceedings, volume 10.

Springer.

Wang, W. and Ting, S. (2011). Development of a computational simulation model for conflict manage-

ment in team building. International Journal of Engineering Business Management, 3(2):9–15.

Wang, X. H., Zhang, D. Q., Gu, T., and Pung, H. K. (2004). Ontology based context modeling and

reasoning using owl. In Pervasive Computing and Communications Workshops, 2004. Proceedings

of the Second IEEE Annual Conference on, pages 18–22. IEEE.

Weiser, M. (1991). The Computer for the Twenty-First Century. Scientific American, 3.

Weiser, M. (1993). Hot Topics: Ubiquitous Computing. IEEE Computer, 26(10):71–72.

WeMo (2013). Belkin wemo home automation. http://www.belkin.com/us/Products/

home-automation/c/wemo-home-automation/. (Last accessed on April, 2014).

Wicaksono, H., Rogalski, S., and Kusnady, E. (2010). Knowledge-based intelligent energy management

using building automation system. In IPEC, 2010 Conference Proceedings, pages 1140–1145. IEEE.

Youngblood, G. M., Heierman, E. O., Holder, L. B., and Cook, D. J. (2005). Automation intelligence

for the smart environment. In IJCAI International Joint Conference On Artificial Intelligence, pages

1513–1514.

56

Zimmer, T. (2004). Towards a Better Understanding of Context Attributes. In Proceedings of the 2nd

Conference on Pervasive Computing and Communications Workshops, IEEE, pages 23–27.

57

58