UNIVERSIDADETECNICADELISBOA´ INSTITUTO SUPERIOR …€¦ · Keywords: Building Automation Systems , Behaviour Speciﬁcation , Fuzzy Logic , Fuzzy Control Systems , Fuzzy Contexts

UNIVERSIDADE TECNICA DE LISBOAINSTITUTO SUPERIOR TECNICO

Specifying the Behaviour ofBuilding Automation Systems

Joao Eloi Trindade de Aguiam(Licenciado em Engenharia Informatica e de Computadores)

Dissertacao para obtencao do Grau de Mestre emEngenharia Informatica e de Computadores

Orientador: Prof. Doutor Paulo Jorge Fernandes Carreira

Co-orientador: Prof. Doutor Andreas Miroslaus Wichert

Presidente: Prof. Doutor Ernesto Jose Marques MorgadoVogais: Prof. Doutor Renato Caleira Nunes

Julho de 2011

placeholder

placeholder

placeholder

Abstract

Building automation systems have known an upsurge of interesting due to their en-ergy savings potential and for creating smart environments. However the devel-

opment of this type of systems consists essentially of embedded systems in hardwarecontrollers written in low level languages which are difficult to program.In situations where the actuation must vary continually based on the sensor inputs, de-velopment and testing becomes even harder. This work proposes a framework based ona declarative language to specify the behaviour of a building automation system. Thislanguage allows the specification of the behaviour without worrying about hardwaredetails. This language and framework proposed herein use the notions of fuzzy logicand temporal logic. The specifications developed using the proposed language describefuzzy control systems that interface with actuators through a different defuzzificationprocess.We validate our proposal by developing a simulator of the language semantics and an-imating a case study specification of the control system of an automated office room.For further validation we used sensor reading traces and observed the behaviour of ouranimated specification, analysing graphic representations of the actuators along the sim-ulation.

Keywords: Building Automation Systems , Behaviour Specification , Fuzzy Logic ,Fuzzy Control Systems , Fuzzy Contexts , Temporal Logic , Context-Aware Systems ,Expert Systems

v

placeholder

placeholder

placeholder

Acknowledgements

First of all, I would like to thank Prof. Paulo Carreira for having accepted orient-ing me and truly helped me in the development of this Master Thesis, which was

proposed by me to him. Without his orientation this final result would be much moredifficult to achieve. I also would like to thank Prof. Andreas Wichert for his orientationin the initial phase of this work. I also would like to thank Prof. Artur Ferreira da Silvafor making me discovering the interest for extra curricular activities and developing mysoft skills along my graduation.To all my friends of university, specially Andre and Paul, I would like to thank youfor the innumerable discussions and conversations we have had during our journey inthe university. To all my friends from a long time, specially Nuno, Joana, and Antonio, Iwould like to thank you for continuously being in my life and for still being truth friends.To my family and parents a special thanks is merited for trusting me all this time and onmy work, it was not easy for you also but in the end it is worth.In the beginning of 2010 I have joined the GASTagus groupwhich have changed my life.I have grown up a tremendous and become more conscious about the world, but what Ireally appreciate are the relationships I have made there. I really would like to thank allof you for having followed me in this work and this journey. I won’t specify all of youbecause fortunately you are not few, but you know who you are.Finally a special thanks to Rita for being always present in the most difficult phase ofthis work where I had to spend much time working on my own. Your support wasfundamental for me to have concluded this thesis.I would like to dedicate this work to my grandparents who I miss a lot.

ix

placeholder

Contents

Abstract v

Acknowledgements ix

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Hypothesis and Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Main Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Document Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Concepts and Related Work 52.1 Expert Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Rule-Based Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Fuzzy Logic Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 Fuzzy Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.2 Discrete and Continuous Fuzzy Sets . . . . . . . . . . . . . . . . . . 102.3.3 Membership Functions Types . . . . . . . . . . . . . . . . . . . . . . 112.3.4 Fuzzy Set and Fuzzy Logic Operations . . . . . . . . . . . . . . . . 112.3.5 Fuzzy Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.6 Fuzzy Inference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.7 Defuzzification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.8 Fuzzy Control Systems . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4 Temporal Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5 Context-aware Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.5.1 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5.2 Fuzzy Context-Aware Systems . . . . . . . . . . . . . . . . . . . . . 24

2.6 Building Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

xi

2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3 Language and Framework 293.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1.1 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.1.2 Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.1.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.1.4 Actuators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Context Description Language . . . . . . . . . . . . . . . . . . . . . . . . . 323.2.1 Syntax of Context Formulas . . . . . . . . . . . . . . . . . . . . . . . 333.2.2 Semantics of Context Formulas . . . . . . . . . . . . . . . . . . . . . 34

3.3 Fuzzy Inference Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.3.1 Fuzzy Antecedent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.3.2 Fuzzy Consequent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3.3 Defuzzification Process . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4 Case Study 434.1 Sensors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2 Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.1 Low Level Luminosity Contexts . . . . . . . . . . . . . . . . . . . . 454.2.2 Low Level Light Model Contexts . . . . . . . . . . . . . . . . . . . . 464.2.3 High Level Contexts . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.2.4 System’s Initial State . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.3.1 Fuzzy Context Operators . . . . . . . . . . . . . . . . . . . . . . . . 484.3.2 Fuzzy Consequent Operators . . . . . . . . . . . . . . . . . . . . . . 494.3.3 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3.4 Scenario Arriving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3.5 Scenario Leaving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3.6 Scenario Working at Desk . . . . . . . . . . . . . . . . . . . . . . . . 534.3.7 Scenario Working at Table . . . . . . . . . . . . . . . . . . . . . . . . 534.3.8 Scenario Walking Around . . . . . . . . . . . . . . . . . . . . . . . . 544.3.9 Scenario Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.4 Actuators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

xii

4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5 Validation 575.1 Validation Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.2 The Initial Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.3 Developing the Excel Simulator . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.3.1 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.4 The Interactive Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5.4.1 Development Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.4.2 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.5 Batch Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615.6 Results and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.6.1 Validating the Curtains Evolution . . . . . . . . . . . . . . . . . . . 615.6.2 Validating Partially Cloudy Weather Conditions . . . . . . . . . . . 625.6.3 Validating Working at Desk . . . . . . . . . . . . . . . . . . . . . . . 635.6.4 Validating the walking around activity . . . . . . . . . . . . . . . . 64

5.7 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6 Conclusions 676.1 Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.2 Main Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Bibliography 72

Appendixes 78

A Membership Functions Types 79A.1 Triangular Membership Function . . . . . . . . . . . . . . . . . . . . . . . . 79A.2 Trapezoidal Membership Function . . . . . . . . . . . . . . . . . . . . . . . 79A.3 Gaussian Membership Function . . . . . . . . . . . . . . . . . . . . . . . . . 80A.4 Bell Membership Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80A.5 Sigmoidal Membership Function . . . . . . . . . . . . . . . . . . . . . . . . 80

xiii

placeholder

List of Figures

2.1 Different fuzzy sets of the linguistic variable temperature . . . . . . . . . . 102.2 Representation of the most used membership functions types . . . . . . . 112.3 Graphic representation of the cylindrical extension operation . . . . . . . . 132.4 Two interpretations of fuzzy implication . . . . . . . . . . . . . . . . . . . . 142.5 Single fuzzy rule with multiple antecedents . . . . . . . . . . . . . . . . . . 162.6 Multiple fuzzy rules with multiple antecedents . . . . . . . . . . . . . . . . 172.7 Graphic illustration of most used defuzzification schemas . . . . . . . . . 192.8 Fuzzy Controller Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 192.9 Different fuzzy inference systems . . . . . . . . . . . . . . . . . . . . . . . . 273.10 Proposed framework architecture . . . . . . . . . . . . . . . . . . . . . . . . 303.11 Graphic representation of the fuzzy set TooMuchDeskIlluminated . . . . . 363.12 Graphic representation of some suggested fuzzy context operators . . . . 373.13 Graphic representation of the fuzzy consequent operator PartiallyOpened 384.14 Graphic representation of daylight and nightlight models . . . . . . . . . . 464.15 Graphic representation of the fuzzy context operators Insufficient, Suffi-

cient and TooMuch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.16 Curtains fuzzy consequent operators . . . . . . . . . . . . . . . . . . . . . . 504.17 Fuzzy consequent operators for luminaries . . . . . . . . . . . . . . . . . . 515.18 Simulator application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.19 Evolution of the curtains actuator along the day . . . . . . . . . . . . . . . 615.20 Simulation of arriving and leaving of the office . . . . . . . . . . . . . . . . 625.21 Illustration of the simulation of a cloud passing in the sky . . . . . . . . . 635.22 Illustration of the simulation of the activity working at the desk . . . . . . 635.23 Simulation of the activity working at the support table . . . . . . . . . . . 645.24 Simulation of the activity walking around . . . . . . . . . . . . . . . . . . . 64

xv

placeholder

Chapter 1

Introduction

Building Automation has its origins in the 1980s however in the last decade there hasbeen an upsurge of interest in this thematic. This interesting is essentially related

with the potential energy savings that a building can have if it is controlled automati-cally. However, in a residential environment there are also other research developmentsfocused on converting the home space into a more comfortable place for its inhabitants.In both residential and non residential buildings the area of Artificial Intelligence andSmart Environments have spurred the interest by the research community and of indi-vidual users.To address this situation most automation hardware manufacturers have created suitesof hardware modules that came with pre-packaged embedded applications that haveto be configured. In either case, to develop an automation system, the user must haveconsiderable expertise regarding hardware details. Besides this issue, the proprietarysystems and the intercommunication between different manufacturers devices is alsoa problem in building automation systems. In the same way, the majority of buildingautomation systems are based on C programs embedded in hardware controllers. Withthis approach, modifications and adjustments to the system are a difficult and sometimesimpossible task. To modify the logic of the programs it is necessary to reprogram thesecontrollers which must be done by an expert, making it very difficult or impossible forthe end-user to adapt the system to suit its needs. The development and testing of thesesystem are also time consuming and error prone. Ideally, there should be a clear sepa-ration between the hardware controller and the program logic. The specification of thebehaviour of the system should be done by the end-user in a friendly way. To this aim,we propose a declarative language for specifying the behaviour of Building AutomationSystems. By using a declarative language with a formally declarative language, the fo-cus of this proposal focuses on what the user wants the system to do instead of how to doit. This has the advantage of approximating the specification task to the domain of theend-user of the system due to the simplicity of this specification, allowing it to be speci-fied by non-expert users. Declarative languages also enable the automatic validation ofbehaviour specification.

1

2 CHAPTER 1. INTRODUCTION

1.1 Motivation

As a motivation example for this work, one can think on a simple case that illustratesthe behaviour of an office. This way we have thought on specifying the behaviour ofsimple office composed by a desk and a support table, which are two workplaces forthe user. As actuators imagine that there are two luminaries in the ceiling and curtainsin the window. As sensors suppose that we have one placed in the door to detect thearriving or leaving and others placed near the table and the desk to detect where theuser is working. Besides these ones, there could also be luminosity sensors to infer theamount of light in each part of the office. However, how can one specify the behaviourof such a building? Imagine that the desired behaviour require to control the curtainsaccording to the amount of light inside and outside the building in order to allow themaximum amount of natural light inside and at the same time avoid the excessive glarein the working place of the user.The answer to such a question is difficult and non-trivial. In traditional Building Au-tomation Systems one could embed the desired behaviour in the hardware devices bydevelopingC programs or using pre-packaged embedded applications that must be con-figured, which sometimes is not possible to reflect the desired behaviour. Despite beinga lengthy process it also requires a great amount of expertise by the user to define andimplement such a system. Trying to solve this issue was the greatest motivation of thiswork.

1.2 Hypothesis and Methodology

Our work started from the idea of converting an home into a real smart environmentwhich recognizes the patterns of the users and adjust its behaviour according to them.However, as we started this subject we started to narrow our goals due to the difficultyin inferencing behaviour rules from scratch. Therefore, we decided to start with a spec-ification of the behaviour of a building automation system and only therefore learningand adjust the building behaviour to users’ habits. However, the specification of thebehaviour of building automation systems is not well studied by the research commu-nity, which prevented us to go further in our work. This focuses the specification of thebehaviour in this type of systems due to its particularities and interesting challenges.With this work we approach the specification of behaviour in a building environment byanswering the following question:

• How to specify the logic behind the behaviour of a Building Automation System(BAS) where the actuators varies continuously based on sensors, in an easy way?

To answer this questionwe propose to specify the behaviour of BASswith a novel declar-ative language based on fuzzy logic that can be easily written by the user. The proposedframework is essentially focused on fuzzy logic systems and the fuzzy reasoning mech-anism inherent with it. Another important aspect is reasoning about time, so we investi-gated about the temporal logic and add their operators into this framework.

1.3. MAIN CONTRIBUTIONS 3

Finally, to validate this work as well as demonstrate how this framework can be appliedin a real case, we have defined a simple case study of a office room. Based on this casestudy, we developed a simulator to concrete this work and perform more exhaustivetests, which simulate hypothetical scenarios that could occur in a real building.

1.3 Main Contributions

This work proposes a declarative language for specifying the behaviour of BASs and hasthe following main contributions:

• A new framework to specify the behaviour of building automation systems basedon the fuzzy logic and temporal logic.

• A formal syntax and semantics of the language proposed drawing on conceptsborrowed from fuzzy logic and temporal logic.

• Adaptation of the concept of ”context” from ambient intelligence to fuzzy logic.

• A generalization of the temporal Until operator to deal with fuzzy propositions.

• A new approach to defuzzyfication process of fuzzy control systems that is compu-tationally less demanding than the Mandani fuzzy system but more flexible thanTsukamoto and Sugeno models.

• A detailed case study of a building automation problem that can be used as a basisfor further analysis and development.

1.4 Document Organization

The remaining chapters of this work are organized as follows. Chapter 2 describes theconcepts and related work, more specifically the subjects of expert systems, rule-basedsystems, fuzzy logic systems, temporal logic, context-aware systems and building au-tomation. In chapter 3 we present our language based on fuzzy logic and temporallogic. Chapter 4 illustrates a simple case study to exemplify the application of the lan-guage with a case study. This case study was used to develop the simulator that vali-dates this work, which is described in the Chapter 5. Finally, in Chapter 6 we present theconclusions and outline the future work.

placeholder

Chapter 2

Concepts and Related Work

Tis chapter introduces concepts related with this work and summarizes the literaturereview. Concepts start with an overview of Expert Systems to describe how rule

based systems work. The next two topics addressed are the core of this work as all thelogic inherent to it are based on Fuzzy Inference systems and temporal logic on whichthe semantics of the language that we propose is based. This chapter also presents somecontext-aware systems and its frameworks and introduces the subject of Building Au-tomation.

2.1 Expert Systems

In the 1960’s, Feigenbaum and Buchanan developed the Dendral system, a computersoftware to assist chemists with data interpretation (Buchanan & Feigenbaum, 1978).They have specialized the program in identifying unknown organic molecules throughthe analysis of their mass spectra and the usage of knowledge about chemistry, encodedby a human expert. This project introduced the concept of knowledge component sepa-rated from the reasoning. The advantage of this separation is that knowledge can changeand adapt to the domain of the problem that must be solved without changing the rea-soning component. Another important concept further developed in Dendral was theusage of heuristics to speed up searching in difficult reasoning problems. Heuristics sim-ulate the human reasoning by making decisions based on experience (discarding irrel-evant and unlikely solutions) thus reducing the number of possible solutions searched.This system was the first of a new class of systems, designated Expert Systems (Lindsayet al., 1993).Another expert system that marked the history of this area was the MYCIN system de-veloped in the early 1970’s. This project intended to assist physicians in the diagnosis ofinfectious diseases by asking the user a series of questions that emulate the expert way ofreasoning, thereby giving a list of diagnoses and a possible treatment. This was the firstsystem implemented in the medical field. The MYCIN project was implemented basedon if-then rules with certainty factors, which assign a confidence value to each rule. De-spite being a confidence value, hence a value between 0 and 1, this factor should not beconfused as a probability value for that rule to be true (Buchanan & Shortliffe, 1985).

5

6 CHAPTER 2. CONCEPTS AND RELATEDWORK

An Expert System is a computer program that simulates the reasoning of a human expertto solve problems or give advices to the user. The power of reasoning with knowledgeresides in the possibility of the system reaching to new and unpredictable situations, inmostly the same way as humans do. This reasoning process is focused on heuristics andapproximate methods which help the system to discover the right answer to a specificproblem. However, it is not guaranteed that the system always find the correct solution.Expert systems are also characterized by having an advice procedure and by being ca-pable of explaining to the user its own reasoning process. Overall, the study of ExpertSystems is arranged according to four topics (Jackson, 1998):

Knowledge Acquisition The acquisition of the expert problem solving expertise intothe system can be done by a series of interviews with the domain experts. How-ever, this may be a lengthy process. This process is difficulted by the differencesin the way the human expert express its knowledge and the way the system repre-sents it. Human uses natural language while a computer can only encode precisely(mathematical) representations. There also exists much common sense knowledgethat is difficult to identify and represent (Buchanan et al., 1983).

Knowledge Representation is a subfield of artificial intelligence focused on which in-formation should be stored and how it is associated in the human brain. However,in the domain of expert systems, knowledge representation tries to find ways inwhich large bodies of useful information can be formally described as symbolsand structures that represent various concepts and relationships between them.

Reasoning Control The most important feature of an expert system is its ability to rea-son correctly and search for a solution for a non-trivial problem. To accomplishthis, and expert system uses planing and control strategies when choosing whichquestions to ask and when, as well as which tests should be performed. One com-mon feature of these systems is the usage of rules in the reasoning process, as itwas done in MYCIN.

Solution Explanation Explanation is another important aspect of an expert system be-cause it enables different kinds of users (end-users, knowledge engineers, domainexperts, programmers and managers) to understand why the system has reacheda given conclusion, in other words, what the program is doing and why. With thisinformation the user can double check the correctness of the conclusion as well asdebug, improve and evaluate the knowledge on which it was based. To performwith this explanation, this component must interact with the controller in order tounderstand how it has achieved a certain solution.

Expert Systems are a wide area of research with many applications implemented. Ac-cording to Liao in his survey about expert systems from 1995 to 2004, they can be clas-sified into the following methodologies (Liao, 2005): rule-based systems, knowledge-based systems, neural networks, fuzzy expert systems, object-oriented methodology,case-based reasoning, system architecture, intelligent agent systems, databasemethodol-ogy, modelling and ontology; and in each of thesemethodologies, it can be sub-classifiedin their concrete applications. Liao also suggested that expert systems could be imple-mented in different scientific areas such as psychology, cognitive science, and human

2.2. RULE-BASED SYSTEMS 7

behaviour. Hence, they can conceivably be applied in the domain of Building Automa-tion Systems as well.According to the survey of Expert Systems from 1977 until 1993, Wong and Monaconoted that most expert systems applications were focused on improving business ar-eas (Wong &Monaco, 1995). Their application to other subjects like for example agricul-ture, energy, planning, science and many others was done from 1995 onwards.

2.2 Rule-Based Systems

To simulate the reasoning process of humans, automatic reasoning systems incorporaterules to represent knowledge and use them to reason about the facts of the surroundingworld. This kind of systems are called rule-based systems, and are composed of twodifferent components: (i) the knowledge base which contains the rules of the system,and (ii) the inference mechanism which is responsible for the reasoning process basedon the rules of the system.In a rule-based system, knowledge consists of a set of if-then rules where each one hastwo different parts, the if part named by antecedent, and the then part called consequent.This rules have the representation:

if A then C,

where A is the antecedent condition and C is the consequent part which consists ofactions and assertions. It is important to notice that the conditions used in these rulesare boolean conditions. Hence, the antecedent can only assume the value true and false.Ruled-based systems can be called deduction systems or reaction systems. These termsare strongly related with the the behaviour of the consequent part of the rules. Whenrules produce new assertions to be placed in the working memory, these systems aredenominated by deduction systems. On the other hand, if the consequent part of therules specifies an action to be performed by the system, it is called a reaction system.The working memory in a rule based system contains the assertions that are present inthe system at that instant. This memory can be modified by adding or removing anassertion, which is what happen in a deduction system.As referred above, we can divide these systems into two components: the knowledge-base and the inference mechanism. Rules are evaluated by the inference mechanisminstalled in the system which will perform an action or produce a new assertion in theworking memory. This reasoning mechanisms can be performed in two different meth-ods: forward chaining and backward chaining.In forward chaining, the inference procedure consists of moving from the antecedent tothe consequent, i.e. identify the correct rule to use by evaluating the conditions of theif part and then perform the actions/assertions of the then part. This chaining methodis also seen as a bottom-up reasoning because it moves from the facts to the goal. Inthis reasoning process we say that an antecedent is satisfied whenever its conditions areverified, a rule is triggered whenever all of its antecedents parts are satisfied and that arule is fired whenever it is triggered and its consequent establishes a new assertion or


performs an action. It is important to notice that this kind of reasoning can be appliedboth in deduction and reaction systems.Backward chaining has the same purpose of forward chaining, however it consists inthe process of moving backward from the then part to the if part, i.e. starting from anhypothesis towards the conditions necessary for its establishment. This process is alsocalled top-down reasoning because it inferences from the goal to the facts). This methodmay only be used in a deduction systems where the rule produces a new assertion.The decision on which reasoning methods should be used takes into account the typeof the rules present in the system. Wintson suggests using the metrics of fan in and fanout of a system to assist this decision, by comparing the number of conditions and thenumber of conclusions presented in the system. A system is said to have a high degreeof fan in if there are many different ways to reach a particular conclusion but the facts canonly reach a few number of conclusions. When this is the case, forward chaining mustbe used. On the other hand, a system is said to have a high degree of fan out if thereare many conclusions but few ways to reach that particular conclusion. In this case, themethodmust be backward chaining. However, sometimes it is not possible to determinewhether a system has a high degree of fan in or fan out. In these cases, if no facts havebeen gathered and only one of many possible conclusions is true, backward chainingmust be used. Conversely, if all the possible facts are available and it is necessary toconclude everything from those facts, forward chaining must be used.In a rule-based systemmore than one rule can be triggered simultaneously, however ona reaction system only one rule can be fired at a time. This poses a problem of conflictbetween the rules triggered: which rule should be chosen? Conflict is specially criti-cal when more than one rule that can be triggered performs contradictory actions onthe same object. In building automation system one rule may state to turn on the lightwhile another states it should be turned off. To solve this issue, there are some conflictresolution strategies that may be implemented depending on the situation:

• Rule ordering - Prioritize all the rules and use the highest priority triggered rule;

• Context limiting - Separate the rules into groupswhere only some of them are activeat a time, reducing the conflict likelihood;

• Specifity ordering - Use the superset of the triggered rules that deals with the mostspecific situations (i.e. rules which have a greater number of conditions);

• Recency ordering - Use the least recently used rule;

• Refractoriness - Prevent a rule from being fired more than once on the same data.

An alternative way of solving conflicts is by usingmeta-rules. These are rules that spec-ify the reasoning about which if-then rule of the system should be fired. These rulesare not used in reasoning about the domain itself. Despite being used in the reasoningabout rules, meta-rules can also includes particular knowledge about the domain thatwill help this process, or alternatively they can be domain free, aiming at reducing thesearch space of the rules. It is important to note that in order to achieve its goals in atimely fashion, a system should not spend much time processing the meta-rules (Jack-son, 1998; Winston, 1992).

2.3. FUZZY LOGIC SYSTEMS 9

2.3 Fuzzy Logic Systems

In the previous section we have introduced the notion of rule-based systems where thebehaviour of the system is supported by rules that have been defined by an expert in therespective domain. These rules are boolean rules, i.e., their conditions can only be val-ued either true or false. However, human reasoning does not restrict to discrete binarytruth values. Instead, a proposition may be partially true or partially false. One simpleexample can be whether a place is considered hot or not. Defining precisely the crite-rion whereby a place is considered hot, can be difficult. Defining a temperature abovewhich a place is considered hot and under that temperature it is not, does not reflect oneimplicit definition of a hot place. In our minds being hot is a gradual concept with acontinuous truth value. There is no crisp boundary. Modeling this notion of fuzzinesswas addressed by Zadeh in the mid 60’s when he introduced the notion of a fuzzy setand, later on, the concept of fuzzy logic (Zadeh, 1965).

2.3.1 Fuzzy Sets

Going back to the example of a hot place, in classical set theory one can define all placesconsidered hot to be, for instance, every place with a temperature higher than 25ºC ,which can be represented by the set A. Let t be the temperature of a place p. The predi-cate hot(p) is defined as hot(p) iff t ! A where A = {x|x > 25}. From this definition, ifa place has a temperature of 24ºC it is not considered hot because it does not belong tothe set A.This crisp boundary arises from the classical set theorywhich does not reflect the humanway of defining predicates. In the human brain the transition from completely false tocompletely true is gradual aswell as the notion of setmembership. Fuzzy set theory aimsat reflecting this behaviour through the generalization of the set membership notion bymeans of a membership function (MF).

DEFINITION 2.1: Membership function Given a domain X represented generically by x, amembership function is any function fromX " [0, 1] denoted by µX(x). A membership functioncan have one or more dimensions.

DEFINITION 2.2: Fuzzy set Let X be a collection of objects where each object is denoted generi-cally by x and µA(x) be the membership function over X, a fuzzy set A is a set of pairs formallydefined as follows:

A = {(x, µA(x))|x ! X}.

A MF is any function whose result is a value between 0 and 1 that indicates the degreeto which a certain object x belongs to a fuzzy set X. The value 0 represents the notcontained, the value 1 contained and the values between 0 and 1 reflect different degreesof containment. A MF can be represented by a mathematical function and illustrated ina graphical representation as well. Membership functions are also characterized by itssupport range, which are all x values such that µ(x) > 0.Classical set theory can be seen as a particular case of fuzzy set theory, where the MFis a characteristic function defined as (x, 0) if x /! A and (x, 1) if x ! A, #x ! X. It is


0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35

Mem

bers

hip

Deg

ree

X = Temperature

HotPlace

(a) Hot place example

0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35

Mem

bers

hip

Deg

ree

X = Temperature

ColdPlace HotPlace

MildPlace

(b) Linguistic values of linguistic variable tem-perature

Figure 2.1: Different fuzzy sets of the linguistic variable temperature (a) Graphic representa-tion of the MF for a hot place fuzzy set depicting a continuous transition from 0 to 1 which isspecified by a sigmoid function. (b) Simultaneous graphic representation of the three fuzzylinguistic values of the linguistic variable temperature. A cold place has a temperature less than10ºC while a hot place has a temperature higher than 25ºC. A mild place has its temperaturesituated between the previous two.

important to notice that besides being represented by a number between 0 and 1, themembership degree of an object belonging to a fuzzy set is not related with the proba-bility of the object x belonging to this fuzzy set, instead it is related to the uncertainty ofthe membership (Jang et al., 1997).

2.3.2 Discrete and Continuous Fuzzy Sets

Fuzzy sets can have two types of universe of discourse: continuous or discrete. In a fuzzyset with a discrete universe, its universe X is composed of a finite number of objectsand each one has a µ(x) associated, so the fuzzy set A is a discrete collection of pairs(x, µ(x)),#x ! X. A fuzzy set with a continuous universe is represented by its MF whichis a continuous function over the continuous domain X. This manuscript emphasizesfuzzy sets with a continuous universe as they are the most commonly used.In the example of a hot place, if a place has a temperature of 24ºC it is not considered ahot place. Using the fuzzy set theory, the notion of a hot place can be defined as a fuzzysetB which represents the set of hot places. The universe of discourse of this fuzzy set isa set that represents the temperature of a place. The fuzzy set is then described by its MFµB(x) with the correspondent graphic representation (see Figure 2.1(a)). Through thegraphic representation, it is possible to understand that the transition from a 0 degree ofmembership until a completely degree of 1 is continuous.In fuzzy logic terminology, a universe X is called a linguistic variable. Each linguisticvariable have associated one or more fuzzy sets that describe a certain interval of theuniverse. These fuzzy sets are called a linguistic value (Zadeh, 1973, 1975). To exemplifythis situation, the fuzzy set hot place (which is called linguistic value) is defined in thelinguistic variable temperature. However, this variable can also have more linguisticvalues associated with it such as ’cold place’, ’mild place’ among others, as it is illustratedin the figure 2.1(b) (Jang et al., 1997).


0

0.2

0.4

0.6

0.8

1

0 0.2 0.4 0.6 0.8 1

(a) Triangular

0

0.2

0.4

0.6

0.8

1

0 0.2 0.4 0.6 0.8 1

(b) Trapezoidal

0

0.2

0.4

0.6

0.8

1

0 0.2 0.4 0.6 0.8 1

(c) Gaussian

0

0.2

0.4

0.6

0.8

1

0 0.2 0.4 0.6 0.8 1

(d) Bell

0

0.2

0.4

0.6

0.8

1

0 0.2 0.4 0.6 0.8 1

(e) Sigmoid

Figure 2.2: Representation of the most used membership functions types (a)triangle(x, .3, .5, .9) (b) trapezoid(x, .2, .4, .6, .8) (c) gaussian(x, .5, .1) (d) bell(x, .15, 4, .5) (e)sigmoid(x, 30, .7)

2.3.3 Membership Functions Types

In the definition 2.1 we have defined the notion of membership function as any func-tion whose result is a value between 0 and 1. This definition gives a great freedom inthe functions that can be used to represent a membership function, however there aresome types of functions more used than others. The figure 2.2 illustrate the most com-monmembership functions types: triangular, trapezoidal, gaussian, bell and sigmoid. Thesefunctions can be distinguished by two characteristics: smoothness of its graphic repre-sentation and the monotonousness of the function.From the graphic representation of figure 2.2 one can see that both the triangular andtrapezoidal functions are non-smooth. This means that the transition in the corners isabrupt and non continuous. By this reason, these two types of functions are the leastused as the experts prefer to use one of the other threes (gaussian, bell or sigmoid) dueto its continuousness in their universe of discourse.These five types can also be distinguished by the monotonousness of their graphic rep-resentation. Only the sigmoid function belongs to the set of monotonous functions asit is only increasing or decreasing over its domain. When the sigmoid function is in-creasing (as it is represented in the figure 2.2(e)) it is also said that it is open right be-cause the limx!+" sigmoid(x) = 1, while if it is decreasing is said to be open left andlimx!#" sigmoid(x) = 1.In the Appendix A there are more details about each of these five types of functions.

2.3.4 Fuzzy Set and Fuzzy Logic Operations

The operations of classical set theory can be generalized to fuzzy sets by defining theelemental set operations in turns ofmembership functions (Jang et al., 1997; Zadeh, 1965).

DEFINITION 2.3: Union Given fuzzy sets A and B (over the same universe X), with member-ship functions µA(x) and µB(x) respectively. We define the union of A with B, represented by


A $B, as a fuzzy set C in the same universe of discourse X with a membership function µC(x),

C = µC(x) = max(µA(x), µB(x)).

DEFINITION 2.4: Intersection Given fuzzy sets A and B (over the same universe X), withmembership functions µA(x) and µB(x) respectively. We define the intersection of A with B,represented by A % B, as a fuzzy set C in the same universe of discourse X with a membershipfunction µC(x),

C = µC(x) = min(µA(x), µB(x)).

DEFINITION 2.5: Complement Given fuzzy set A over the universe of discourse X, with mem-bership function µA(x), we define the complement of A as A with membership function µA(x),

A = µA = 1& µA(x).

Besides this three basic operations, there are two more which are useful in the reasoningof fuzzy logic systems. These operators are also a generalization of the same operatorsin the classical set theory.

DEFINITION 2.6: Cartesian product Let A and B be two fuzzy sets over the universes X andY respectively, with membership functions µA(x) and µB(y). We define the Cartesian productin the fuzzy space A'B as

A'B = µA$B(x, y) = min(µA(x), µB(y)).

DEFINITION 2.7 : Co-product Let A and B be two fuzzy sets over the universes X and Yrespectively, with membership functions µA(x) and µB(y). We define the co-product in the fuzzyspace A+B as

A+B = µA+B(x, y) = max(µA(x), µB(y)).

We have just defined some of the possible operations that can be done with fuzzy sets.However, in fuzzy reasoning systems one pretends to reason about fuzzy propositionswhich uses fuzzy logic operators. In these reasoning there is a close relationship be-tween the fuzzy logic operators and the fuzzy set theory. Fuzzy sets are used to expressthe propositions used in the reasoning while the fuzzy set operations are analogous tothe fuzzy logic operators. This way, the operators and (conjunction), or (disjunction) andnegation can be seen as the fuzzy set operations intersection, union and complement.Let A and B be two fuzzy propositions seen as two fuzzy sets over X represented byµA(x) and µB(x) respectively, we have:

A (B = min(µA(x), µB(x)

A )B = max(µA(x), µB(x)

¬A = 1& µA(x)


(a) Base fuzzy set A (b) Cylindrical extension of fuzzyset A

Figure 2.3: Graphic representation of cylindrical extension operation. The figure (a) repre-sents the graphic of the fuzzy set Awhile the figure (b) represents the cylindrical extension ofthe fuzzy set A over the domain Y (Jang et al., 1997).

2.3.5 Fuzzy Reasoning

Rule based systems, as introduced in section 2.2, are based on boolean rules, i.e. the an-tecedent part and the correspondent conditions can only assume two values. To applythe notion of fuzzy logic in rule-based systems, a new notion of rules were introduced:fuzzy rules. These rules have fundamentally the same structure as the rules describedin classic rule-based systems, however the truth value of the antecedent is fuzzy. More-over, the consequent holds with a varying degree depending on the truth value of theantecedent. This kind of rules usually assumes the form

if x is A then y is B,

where A and B are linguistic values defined by a fuzzy set in X and Y respectively. Theantecedent part is composed by the ”x is A” and the consequent part by ”y is B”. Theantecedent part can also be a set of conditions where each one has the form presentedabove and are connected by a fuzzy logic operator (conjunction, disjunction and nega-tion).These rules are often written as A " B, to describe a relation between the linguisticvalues A and B, which are represented by the variables x and y. This way, a fuzzyrule denotes a binary fuzzy relation R over the product space X ' Y . As we can see,this relation R relates the fuzzy sets A and B, however A is over X while B is over Y ,i.e. they are in different spaces. To understand how this relation is computed we willfirstly introduce the notion of cylindrical extension. The cylindrical extension allows thetransformation of a fuzzy set over X into a fuzzy set over the product space X ' Y byprojecting the µA(x) value over the space Y (see figure 2.3).

DEFINITION 2.8: Cylindrical extension Let A be a fuzzy set over X and µA(x) its respectivemembership function. The cylindrical extension of A over Y is a fuzzy set c(A) in the spaceX ' Y defined by

c(A) =

!

X$YµA(x)/(x, y).

The relation R = A " B can be interpreted in two different ways. One interpreted as


(a) Coupled (b) Coupled

Figure 2.4: Two interpretations of fuzzy implication (Jang et al., 1997). (a) A coupled with Bwhich can be interpreted as A !B (b) A entails B which can be interpreted as ¬A "B

A%B, which is called A coupled withB (figure 2.4(a)), and the other interpreted as ¬A$Band is named as A entails B (figure 2.4(b)). The former interpretation is the most used infuzzy logic systems and is represented as

R = A " B = A'B =

!

X$YµA(x) ( µB(y)/(x, y),

where the integration symbol represents the union of all x, y in the continuous spaceX ' Y and the symbol / is only a marker. Both

"and / don’t imply the integration and

division operations respectively, they are only a notation.It is interesting to note that as the relation R = A " B results in a fuzzy set in thespaceX'Y , so it can be seen as fuzzy set with a two-dimensional membership functionµR(x, y):

µR(x, y) = f(µA(x), µB(y)) = f(a, b),

where f is called the fuzzy implication function. There are many different implementa-tions of fuzzy implication functions, but we are not going to detail them in this work. Wesuggest the reading of the book of Jang et al. (Jang et al., 1997) and the paper of Fukamiet al. about fuzzy conditional inference (Fukami et al., 1980).

2.3.6 Fuzzy Inference

Fuzzy reasoning is an inference procedure that uses fuzzy rules defined in the systemand the known fuzzy facts of the world to achieve its conclusions. In the traditionaltwo-valued inference, the inference is modus ponens, where one can infer about the truthof proposition B through the truth of proposition A and the implication A " B. Forexample, we have A as ”the tomato is red”, B as ”the tomato is ripe” and A " B as ”if thetomato is red then the tomato is ripe”. With these propositions and the fact that the tomatois red, in traditional logic one can infer that the tomato is ripe. This is illustrated as:


premise 1 (fact): x is A,premise 2 (rule): if x is A then y is B,consequence (conclusion): y is B.

Suppose that the propositionA changes to ”the tomato is more or less red” becoming a newproposition A%. Using the same implication A " B, the derived conclusion should be”the tomato is more or less ripe”. In the traditional modus ponens this is not possible as theproposition A (used in the inference implication) is different than A. To cover this issuea generalized modus ponens is used in fuzzy inferencing and can be written as:

premise 1 (fact): x is A%,premise 2 (rule): if x is A then y is B,consequence (conclusion): y is B %,

where A% and B% are fuzzy sets close to A and B respectively.

DEFINITION 2.9:Fuzzy implication Let A and A% be fuzzy sets over X, B and B% fuzzy setsover Y , a fuzzy implication A " B is a fuzzy relation in the fuzzy space X ' Y with a member-ship function µR(x, y), where the fuzzy set B% is induced by ”x is A%” and the fuzzy rule ”if x isA then y is B”. The membership function of B% is defined by

µB!(y) = maxxmin[µA!(x), µR(x, y)]

= )x[µA!(x) ( µR(x, y)].

Generalized modus ponens, as explained above, can be applied in the case of a singlerule with a single antecedent or extended to other cases where there are more than oneantecedent and more than one rule. In the case of a single rule with a single antecedent,the induced fuzzy set B % is represented by its membership function µB!(y) as defined inthe definition 2.9. However it can be simplified as:

µB!(y) = )x[µA!(x) ( µA(x)] ( µB(y)

= w ( µB(y),

where the coefficient w is the degree of compatibility between A and A %. This coefficientcan also be seen as the degree of belief of the antecedent part that will be propagated bythe if-then rule to the consequent part.By extrapolating the generalized modus ponens to the case of having a single rule withmultiple antecedents one can write it as:

premise 1 (fact): x is A% and y is B%,premise 2 (rule): if x is A and y is B then z is C ,consequence (conclusion): z is C %.


Figure 2.5: Graphic representation of a fuzzy system with a single fuzzy rule with multipleantecedents (Jang et al., 1997). The values w1 and w2 are the degrees of compatibility of thefuzzy sets A and B respectively. By applying the min operator with the values w1 and w2,the value w is achieved which represent the firing strength of the rule. This value w is used tocalculate the resultant fuzzy set of this rule, C!.

This rule can be seen as A ' B " C where the induced fuzzy set C % is defined by themembership function µC! :

µC!(z) = )x,y[µA!(x) ( µB!(y)] ( [µA(x) ( µB(y) ( µC(z)]

= )x,y[µA!(x) ( µB!(y) ( [µA(x) ( µB(y)] ( µC(z)]

= {)x[µA!(x) ( µA(x)]# $% &w1

} ( {)y[µB!(y) ( µB(y)]# $% &w2

} ( µC(z)

= (w1 (w2)# $% &firing strength

(µC(z),

where w1 and w2 are the degree of compatibility of A and B respectively and w1 ( w2

represents the firing strength of the rule. In this case the fuzzy connector used in theantecedent part of the rule is the conjunction, however the disjunction can also be used.In such a situation, the firing strength is then calculated using themax operator insteadof themin, as it is explained in the section 2.3.4. The figure 2.5 is an illustration of fuzzyinference of a single rule with multiple antecedents.In the case of havingmultiple rules with multiple antecedents the procedure is similarwith the previous one, however we are dealing with more than one rule in the inference.This problem can be written in a generalized modus ponens as:

premise 1 (fact): x is A% and y is B%,premise 2 (rule): if x is A1 and y is B1 then z is C1,premise 2 (rule): if x is A2 and y is B2 then z is C2,consequence (conclusion): z is C %.

In this reasoning process one has to firstly calculate the induced fuzzy set of each rule, i.e.the fuzzy sets C !

1 and C!2 by applying the formula of µC!(z) (defined in the equation 2.1)

for each rule. After having the induced fuzzy sets of each rule, the resultant fuzzy set ofthe multiple rules is calculated by making the union of all generated fuzzy sets. In thecase of having two rules (illustrated in the 2.6), the fuzzy set C % is calculated as

C % = C!1 $ C

!2.


Figure 2.6: Graphic representation of a fuzzy system with multiple fuzzy rules with multipleantecedents (Jang et al., 1997). In the first rule (first line of graphics), the value of the resultantfuzzy setC!

1 is achieved through the firing strength of the rule which is calculated by applyingthe min operator with the degrees of compatibility of the two fuzzy sets A1 and B1. In thesecond rule (second line of graphics), the process is analogous. However, the resultant fuzzyset C!

2 is achieved with the fuzzy sets A2 and B2. The resultant fuzzy set of the system com-posed by these two rules(C !) is generated by applying the max operator with the resultantfuzzy sets of the rules.

To summarize the fuzzy inference process, one can divide it in four steps (Jang et al.,1997):

1. Calculate the degrees of compatibility for each fuzzy set in the antecedent part,i.e. the values w1, . . . , wn of each rule.

2. Combine the different degrees of compatibility of each rule to calculate the firingstrength having into account the fuzzy connector used in the rule (( or )). Thefiring strength indicates the degree of satisfaction of the antecedent part of eachrule.

3. Propagate the firing strength of the antecedent part to the consequent part in eachrule by calculating the resulting C!

n fuzzy set.

4. Aggregate the resultant fuzzy sets of each rule to calculate the overall fuzzy set ofall rules.

2.3.7 Defuzzification

So far we have only talked about fuzzy sets, either as input or output of the fuzzy rea-soning process. However, sometimes it is needed to convert the resultant fuzzy set into


a crisp value, which is what happens in a controller system. The process of transforminga fuzzy set into a crisp value is called deffuzification. In literature there are many differenttechniques to do so, however, we will focus only on the most common ones, which aredetailed in what follows. In each technique the resultant crisp value is obtained from thefuzzy setA in the universe of discourse Z with a membership function µA(z) (Jang et al.,1997).

Centroid of Area (COA) The method centroid of area is the most widely adopted asa deffuzification strategy. This method calculates the the center of gravity of thefuzzy set A, which correspond to the center of the area under the membershipfunction µA(z). The crisp value of the fuzzy set A using this technique (zCOA) iscalculated as:

zCOA =

"Z µA(z)zdz"Z µA(z)dz

.

Bisector of Area (BOA) The bisector of area is such a value z that satisfies! zBOA

!µA(z)dz =

! "

zBOAµA(z)dz,

where ! and " are the minimum and maximum values z ! Z respectively. Theresultant crisp value zBOA corresponds to the value z that divides the area underthe membership function µA(z) into two regions with the same area value.

Mean of Maximum (MOM) In this technique, the crisp value zMOM is the average ofthe set of values z where µa(z) reach the maximum value µ&. The value zMOM isachieved by

zMOM =

"Z! µA(z)zdz"Z! µA(z)dz

,

where Z % = {z|µA(z) = µ&}. It is important to notice that if there is a single maxi-mum at z = z&, then zMOM = z&.

Smallest of Maximum (SOM) The smallest of maximum, in the same way as the previ-ous method, also leads with the values z where µA(z) is the maximum µ&. How-ever, in this case the crisp value is the minimum value z where µA(z) = µ&.

Largest of Maximum (LOM) This technique is similar with the SOM, however the re-sultant crisp value is the maximum value z where µA(z) = µ&.

The presented defuzzification strategies are the most common ones. These methodscan be used with some adaptations according to the system where they are applied aswell as the type of framework followed in the fuzzy reasoning system as we will see inthe following section. The figure 2.7 illustrates graphically the different defuzzificationschemas presented above.


Figure 2.7: Graphic illustration of most used defuzzification schemas (Jang et al., 1997). Inthis figure we can see, for the same fuzzy set A, the resultant crisp value z when applyingeach of the most used defuzzification methods.

Figure 2.8: Fuzzy Controller Architecture (Passino & Yurkovich, 1998). A fuzzy fuzzy con-troller is usually composed by four components: fuzzification, rule-base, inferencemechanismand defuzzification.

2.3.8 Fuzzy Control Systems

One of the most used applications of the fuzzy reasoning process are in controllers sys-tems. This kind of systems are usually denominated as fuzzy control systems or fuzzyinference systems. In a fuzzy inference system, the resultant output is a fuzzy set, whilein a fuzzy control system the output must be a crisp value in order to control a certainobject. Due to this requirement, this kind of systems needs an additional component totransform the resultant fuzzy set into a single crisp value, which will be used to actuatethe controlled object. This process is called defuzzification and has been explained insection 2.3.7.A fuzzy control system is composed of four different components: (1) a fuzzificationcomponent which transforms the crisp input into a fuzzy one, recurring to the mem-bership functions defined in the system; (2) a rule-base which contains the fuzzy rulesof the system; (3) an inference mechanism that performs the fuzzy reasoning and (4) adefuzzification component to convert the fuzzy output into a single crisp value. Thesefour components are represented in the architecture illustrated in the figure 2.8.When developing a fuzzy control system one can use one of the existent frameworkswhich will avoid the need to build it from scratch. These frameworks have slightlydifferences that should be taken into account in the decision of which one to choose.


We will describe three of the most common fuzzy inference systems illustrated in theliterature (Jang et al., 1997; Passino & Yurkovich, 1998).

Mamdani Fuzzy Inference System The Mamdani fuzzy inference system (Mamdani &Assilian, 1975) was proposed with the aim of controlling a steam engine and boilercombination. They built this system based on a set of linguistic control rules ob-tained from experienced human operators. This model has the particularity ofreceiving crisp inputs instead of a fuzzy set as we have explained in the previoussections. However, to fuzzify these values, the membership function of each fuzzyset must be used with these values as input. After this process, the firing strengthof each rule is calculated, usually through the operatormin, and propagated to theconsequent part of the rule that will generate a fuzzy set for each one. These fuzzysets are then aggregated through the operator max which represent the union offuzzy sets. As the systemmust return a single crisp value, a defuzzification schemamust be used to extract this crisp value from the aggregated fuzzy set. Mamdanisuggest to use the centroid of area as it is the most representative deffuzzificationmethod. The Figure 2.9(a) illustrate the Mamdani fuzzy inference process.

Sugeno Fuzzy Model This model was originally proposed by Takagi, Sugeno and Kang(Sugeno & Kang, 1988; Takagi & Sugeno, 1985) in ”an effort to develop a systematicapproach to generating fuzzy rules from a given input-output data set”, and is also calledTSK fuzzy model. It is characterized by defining the consequent part of a rule asa crisp function in the fuzzy region space specified by the antecedent of the rule.These rules have the following structure

if x is A and y is B then z = f(x, y),

where the function f must describe the output of the model. The figure 2.9(b)shows the fuzzy reasoning process of a Sugeno fuzzy model with a first orderpolynomial function. The deffuzification procedure used by this model is a simpleweighted average, as each rule already outputs a single value instead of a fuzzy set.It is important to notice that in this model the deffuzzification process is anticipatedto the calculation of the output of each rule. This way, the fuzziness of these rulesonly resides in the antecedent part of it. This method avoids the time-consumingprocess of defuzzification, however it can lead to the loss of membership linguisticmeanings as it is not able to propagate the fuzziness from inputs to outputs in anappropriate manner.

Tsukamoto Fuzzy Model The Tsukamoto fuzzy model (Tsukamoto, 1979) is a modelthat can be placed in between the Mamdani system and the Sugeno model, as itallows the propagation of the fuzziness from the antecedent to the consequent ofeach rule, however it also avoids the heavy computation effort to deffuzy the out-put into a crisp value. This is possible because in this model the consequent mem-bership function has to be monotonical, so the propagation of the firing strengthinto these membership functions only generate a single value. This way, in thedeffuzzification method the systemwill only have to deal with these single values.The deffuzzification technique applied in the Tsukamoto model is the weightedaverage, as it is also done in the Sugeno model. The figure 2.9(c) illustrates thismodel.

2.4. TEMPORAL LOGIC 21

2.4 Temporal Logic

Classical propositional logic does not allow reasoning about time. To solve this issue,Arthur Prior introduced the Temporal Logic (TL), where propositions are qualified interms of time (Prior, 1957). This logic is linked with a modal logic. Modal logics intro-duce the operators possibly and necessarily used to qualify the truth of a proposition indifferent possible states (Hintikka & Suppes, 1966). In propositional logic, formulas areinterpreted by an assignment of truth values to propositions, i.e. a state. However, modallogic considers the sequences of states reachable from one another that are modelled asa graph. The operators possibly and necessarily are used to reason about the ”evolution”of the truth value of a formula on a given state and on all states reachable from that state.Writing ”necessarily p” means that p is true in a given state s and in all states reachablefrom s; writing ”possibly p” means that p is true in some state reachable from s. Theseoperators become the temporal operators eventually and always in temporal logic. Theseoperators can be used to write logic formulas to express properties such as ”The light willalways be turned on” or ”The room will eventually be occupied”, which capture sequences ofevents occurring in the system. Writing ”always p” means that p is true in a given states and in all states reachable from s. Writing ”eventually p” means that p will be true insome state reachable from s. Over the years, TL has been extended with other operatorssuch as until or since which are binary operators (Kamp, 1968).Temporal Logic can be classified into two categories considering the model of time flow:Linear Temporal Logic (LTL) and Branching Temporal Logic (BTL). In LTL the model timeflow is ordered in a linear sequence, i.e. each state can only leads to a single next state.On the other hand, in BTL, there may be several distinct future states, which model anon-determinism, i.e. we do not know a priori how the system will behave. Usually,BTL formulas denote trees .It is important to notice that both these two categories onlyhave one history time flow. In this work we will focus on LTL. For more details aboutBTL we recommend the works of Clarke et al. and Emerson et al. (Clarke & Emerson,1982; Emerson & Halpern, 1986; Emerson & Srinivasan, 1989).The common interpretation of LTL formulas is a linear path of states, where each statecorrespond to an observation of the system in a certain instant t. A path is represented as# = s0, s1, . . . , sn, where st is the state observed in the system at the instant t, 0 * t * n.Reasoning in LTL is made through the analysis of the states in a certain path # accordingto a specified formula.

DEFINITION 2.10: Syntax of LTL formulas (Emerson, 1990) Let + stands for true, p be anatomic proposition, $ be a LTL formulae, ¬ and ( be the boolean operators for negation andconjunction respectively, , and U be the temporal operators next and until, a formula $ is definedby the following grammar:

$ ::= + | p | ¬$ | $1 ( $2 | , $ | $1U$2.

Besides the operators expressed in the definition 2.10, other boolean connectors such as),- and. can be derived by the standard definitions and used in a formula. Other TLoperators can also be derived from the operators stated in the definition 2.10. We use/ (false), 0$ (eventually), !$ (always) and $1R$2 ($1 releases $2) to abbreviate ¬+, +U$,


¬(+U¬$) and ¬(¬$U¬%) respectively (Strejcek, 2005).

DEFINITION 2.11: Valid formula Let $ be a formula, # = s0, s1, . . . , sn be a path and si bea state observed in the path # at instant i. The validity of a propositional LTL formula $ can bedefined recursively in the structure of $. We say that $ is valid for the state si of the path # (withi < n, where n is the lenght of #) writing si |= $ iff:

si |= p iff p ! si

si |= ¬$ iff si ! $si |= $1 ( $2 iff si |= $1 ( si |= $2si |= ,$ iff si+1 |= $ and i+ 1 * n

si |= $1U$2 iff 1k(k 2 i) such that sk |= $2 ( #j(i * j < k - sk |= $1))

The meaning of the first three formulas (p, ¬$ and $1 ($2) is easily understood from theboolean logic interpreted at a given state. The operator next (,$) says that $ holds in thenext state to be observed in the path. The formula $1U$2, using the temporal operatoruntil, means that $1 holds since now until the moment that $2 holds, which can be eithernow or somewhere in the future.Temporal logic is frequently used in the formal verification of the correctness of pro-grams. For example, to specify the safety of something one can define it has!¬$, whichmeans that something bad never happens. TL allows the reasoning about past, presentand future observations of an observed state which allows us to formally verify the cor-rectness of a program by specifying its properties in this logic (Pnueli, 1977). A specifica-tion of the behaviour of the program is translated into a graph of state transition. Then,properties about the desired program behaviour written as temporal logic formulas areevaluated over this model. This is known as model-checking (Clarke, 1997).

2.5 Context-aware Systems

In a landmark text about the computer for the 21st century, Weiser defends that com-puters, besides gathering the human environment, should also become invisible into theuser’s background in order to allow users to focus on their activities and goals and donot worry or notice about the system involved. This vision of incorporating computersystems into humans’ daily life and at the same time hiding them from the users hasdriven to the development of Context-aware Systems (Weiser, 1995).A context-aware system (CAS) is a system that adapts to the surrounding environmentwhere environment can be understood as space, people or objects. In CASs, the envi-ronment is abstracted through the notion of context. Thus, a context-aware system is onethat gathers information related to context and reasons about it to take a certain action.Defining a context is nevertheless challenging since there is no consensus about a singledefinition. Each author gives a different definition of context and adapts it to its owngoals (Baldauf et al., 2007; Dey & Abowd, 1999). However, most of these definitions in-volve enumerating a list of possible things that may represent a context such as aspectsof the current situation, location, nearby people, changes in the objects, time, users’ iden-tity and emotional state. Essentially, a context is any information that characterizes the

2.5. CONTEXT-AWARE SYSTEMS 23

situation and is relevant for the interaction between the user and the system. A contextis an abstract state which is inferred from the user’s environment.Gathering context information can be done in two ways: it can be input by the user orcollected from sensors installed in the system. Ideally, to become invisible to the user thesystem should gather as much information from sensors as possible and avoid prompt-ing the user for any kind of input. Ideally, contexts should reflect the real world situ-ation. However, sensors have limitations and capturing data from multiple sensors isstill insufficient to characterize the surrounding world. Hence, context must be inferredfrom different kinds of sensors presented in the system applying different inference tech-niques from artificial intelligence, logic or statistics, which can be seen as a data fusionprocess (Meyer & Rakotonirainy, 2003). According to Schmidt and Van Laerhoven, threekinds of artificial intelligence methods are appropriate to deal with contexts, if-then rules(used with few sensors and a small set of contexts), clustering algorithms (used to dealwith noisy data, create new clusters and associate it with a context) and Markov chainmodels (to check if a transition between contexts is probable) (Schmidt & Van Laerhoven,2001).

2.5.1 Frameworks

The development of context-aware systems is no longer an ad hoc process, instead someframeworks exist that can be used and adapted for a specific system. This avoids build-ing such a system from scratch by using APIs already developed. However, some issuesmust be taken into account since some of the frameworks target particular characteristicsof the specific application, like for example, the home environment.Most frameworks for creating context-aware systems clearly separate the applicationlogic from context acquisition and inference mechanism. The application can interactwith the other modules of the system through an API or a client-server way (either syn-chronous or asynchronous). Another common aspect in all frameworks is the separationof the sensors layer from the rest of the modules. The differences between the existentframeworks have to do with the way they deal with raw data, as well as how contextinference and storage is performed. Other approaches with similar purpose define amiddleware component responsible for deriving and inferencing the contexts that aresituated between the sensor data capture and the application (Biegel & Cahill, 2004; Fahy& Clarke, 2004).Baldauf and Dustar, in their survey about context-aware systems, identify an abstractlayer architecture for CAS with five layers: (1) sensors that can be physical sensors orany data source for the system, (2) raw data retrieval which is a kind of API to allow thesystem accessing the sensors, (3) preprocessing that creates an higher abstraction level ofthe context data, (4) storage/management which is responsible to organize the gathereddata and provide it through a public interface to the clients applications and finally thelayer (5) application which is the client that will use the context information (Baldaufet al., 2007). Schmidt and Van Laerhoven focus their framework on cues which are anabstraction of physical and logical sensors. In this framework it is suggested to use sta-tistical functions to implement cues. Applying this strategy reduces the amount of data


provided by the sensors (Schmidt & Van Laerhoven, 2001). Dey et al. developed a con-ceptual framework with the aim of separating the application from context derivationand acquisition. This way, it is possible have a system responsible to gather and derivea context and multiple applications interested in these contexts (Dey et al., 2001).In the case of an home environment, privacy is one of is one of the biggest issues dueto the big amount of personal information present, so the existent frameworks must beadapted. Meyer and Rakotonirainy developed a framework composed of three middle-ware layers: a hardware layer where the physical installation of devices and sensors isdecoupled from the software, a context manager where the context is derived and theartificial techniques applied and a privacy manager which ensures that only selected in-formation can leave the system to protect the inhabitants (Meyer & Rakotonirainy, 2003).

2.5.2 Fuzzy Context-Aware Systems

To deal with the uncertainty inherent to the human way of reasoning, some authorshave introduced the fuzzy logic in context-aware systems. Acampora et al. developed asystem to control certain aspects of the environment (such as lighting, temperature andblinds) which relates multiagents paradigm and fuzzy logic (Acampora et al., 2010). Thissystem is focused on its fuzzy services component, which is a fuzzy inference engine thatmakes its decisions according to the contexts derived from the active space. Besides thesefuzzy services, this work also proposes the concept of policies. The policies can be seenas fuzzy rules while the contexts are the conditions of these rules gathered based on thesurrounding environment.Mantyjarvi and Seppanen, in their work, introduce the concept of fuzzy context in thedevelopment of a context-aware system, more specially in handheld devices (Manty-jarvi & Seppanen, 2003). The definition of fuzzy context aims at modelling the humans’perceptions of the environment, which are also fuzzy. They allows the launching of ap-plications in a handheld device according to the contexts informations by proposing asystem with a focus on the fuzzy context representation as well as on a context basedapplication control block in the architecture of the system.Park et al. developed a context-aware music recommendation system which is basedon fuzzy Bayesian networks with utility theory (Park et al., 2006). They gather contextinformations from sensors and from the internet which are then pre-processed in a fuzzysystem to generate a fuzzy membership vector. This vector is then input in the Bayesiannetwork in order to infer the contexts of the system. Finally, to calculate the music scorehaving into account the user preference, the utility theory is applied. The application offuzzy Bayesian networks to infer the contexts instead of a traditional Bayesian networks,allow the system to deal with continuous values instead of discrete ones avoiding theloosing of information in the inference process.Ranganathan et al. proposed a system for dealing with uncertain contexts (Ranganathanet al., 2004). They have developed a model that uses probabilistic logic, fuzzy logic andBayesian networks in their reasoningwith the aim of facilitating the task of incorporatinguncertainty in their context-aware applications.Cao et al. also introduce the fuzzy logic theory into context-aware applications, more

2.6. BUILDING AUTOMATION 25

specially in the adaptation model which is concerned in the reconfiguration of the ser-vices of such a system according to the user’s current context (Cao et al., 2005). To ac-complish this, the authors propose the design of a fuzzy-based service adaptation modelwhich uses fuzzy theory. This model is similar to the traditional fuzzy control process, asit also has a fuzzification phase, an inference engine and a defuzzification phase whichselects the best policy for delivering the service under the current context situation.

2.6 Building Automation

The concept of Building Automation (BA) has its origins in the 1980s and has been dis-cussed since then. However, it has known an upsurge of interest over the last decade.BA is a very wide topic that touches the subjects of control, automation, energymanage-ment, learning and intelligence applied in buildings. Sometimes BA is also equated withSmart Buildings and Smart Homes, as all these concepts refer to automating and con-trolling buildings. However, these two concepts are rather general concepts while BArefers to concrete technological solutions. We can divide BA into two different domains,the domain of homes and the domain of facilities. This distinction is important becausein homes the automation system is more focused in the comfort of the inhabitant, whilein the buildings the aim of its automation system lies on the efficiency and reductionof costs of the building operations (Kastner et al., 2005). Despite having different goals,BA systems aims at controlling electric devices such as luminaries, HVAC systems (heat-ing, ventilation and air-condition), window blinds, among other in order to reproducethe desired behaviour in the building. All types of Building Automation Systems (BAS)have in common three components: the sensors, controllers and the actuators. Both sen-sors and actuators are devices installed in the building. The formers give information tothe controller in order for it to reason about the building state and perform actions in theactuators, which will define the behaviour of the building.In literature, we find BA organized according to three major interest subjects such as:technology, energy efficiency and intelligent control. The former research areas in the do-main of BA focus on the technology used by the devices and how to integrate them in thesystem. In this area the protocols were and still are one of the most studied topic. Thereare some successful fieldbus protocols such as LonWorks (Kim et al., 2000), KNX (Crijns,2004), ZigBee (Zigbee, 2005) among others. Some of the existent protocols are propri-etary protocols. This means that the integration of devices from different technologiesis difficult. Some others are open standards, like BACnet (Haakenstad, 1999), which fa-cilitate this interoperability. The integration of different types of devices and protocolsis also an area that have been widely investigated (Dibowski et al., 2010; Kastner et al.,2005; Praus et al., 2009).Another interesting subject that has sprung interest in the development of BAS are theenergetically efficient buildings. With the proliferation of BAS, the automatic controlof the buildings becomes easier than ever before, which helps the building to adjustits devices according to a specified pattern in order to reduce the energy consumption.These systems are also known as Building Energy Management Systems and essentiallyfocused on controlling the HVAC devices, which are the greatest energetic loads in a


building. However, lighting is also an important aspect of these systems that is not be-ing ignored by researchers of this area. Despite being interested on reducing the amountof energy spent in a building, a BAS should not forget the users’ comfort. Usually, thereasoning of an energetic efficiency building is made through a set of rules that em-bodied the polices and model to reduce the amount of energy spent by the controlleddevices (Doukas et al., 2007; Dounis & Caraiscos, 2009).Besides the technology and energy efficient research areas, the third one is related withthe smart buildings and the inherent intelligent control. These systems intend to giveintelligence to the building, instead of just controlling the devices based on a set of rules.The idea is transforming the building into a smart environment, which autonomouslyacquires knowledge about its users and the surrounding environment in their daily ac-tivities. This process is called knowledge acquisition. The smart environment createdby these systems should adapt the behaviour of the building to the preferences of itsusers, with the ultimate goal of improving their experience in that environment (Cook& Das, 2005). One central idea is that buildings should learn and adapt their behaviouraccording to the users’ past experience, i.e. adjust its rules through a learning mecha-nism (Rutishauser et al., 2005). In the area of smart buildings, residential market is theone with the biggest investment and improvements, mostly due to the need of adapt-ing the house to the users’ preferences and automatically execute its preferred actions.Another reason to deeply explore the residential market is related with the diversity ofinhabitants and possible tasks that can be done in this environment (Chan et al., 2008;Intille, 2002).In this thesis we will essentially focus on this third subject of intelligent control for thesmart building. However we will not address the learning aspects. Instead, we directour efforts to the specification of the behaviour at a building.

2.7 Summary

In this chapter we have introduce the main research topic in the area of this work with agreat emphasis in the fuzzy logic and its systems. We have mainly introduced the con-cepts instead of extensively enumerate all the works that relates the building automa-tion subject and these topics as, besides being building automation system, they are notstrongly connected with the main focus of this work. We preferred to better explain theconcepts behind this work for better understanding their application as it is done in theframework proposed.From this chapter one can understand the connection between an expert system and arule-based system, however with this type of reasoning we are limited to the classicalboolean logic where a proposition can only be true or false. By using fuzzy logic weintroduce the notion of uncertainty in the reasoning by allowing a proposition to have adegree of truth between 0 and 1. Besides this introduction of fuzziness, we also introducethe notion of time through the explanation of the temporal logic and its operators, whichare then used in the proposed framework. Beyond these subjects, we briefly explain theconcept of a context-aware system and the concept of building automation, as they arestrongly related with this work.

2.7. SUMMARY 27

(a) Mandani fuzzy inference system

(b) Sugeno fuzzy model

(c) Tsukamoto fuzzy model

Figure 2.9: Different fuzzy inference systems (Jang et al., 1997). In all these systems thedegrees of compatibility of each fuzzy set is calculated by applying the respective fuzzy setswith the values x or y. (a) In theMandani system the firing strength of each rule is calculatedwith the operator min which will be used to generate the resultant fuzzy set for each rule.The resultant fuzzy set of the Mandani System is achieved by applying themax operator withthe resultant fuzzy sets. The defuzzification method used in this system is the centroid ofarea. (b) In the Sugeno model the firing strength w1 and w2 can be calculated either by usingthe min or the product operators. The consequent part of the rule, is given by a user-definedpolynomial function which is used to calculate the return value of each rule, the values z1 andz2. These values are then used to calculate the return value of this model, which is calculatedusing a weighted average with the values z1 and z2 as well as the values w1 and w2. (c) TheTsukamoto model is similar with the Sugeno one, however instead of having a polynomialfunction to calculate the values z1 and z2, they are calculated using a monotonous fuzzy setwith the correspondentw’s values. The defuzzification process is also done by calculating theweighted average.

placeholder

Chapter 3

Language and Framework

This chapter describes the language and framework to deal with the specification ofbuilding automation behaviour. This framework consists of four components: (1)

the sensors to acquire the data from the surrounding environment; (2) the contexts todefine the states in the system that represents the external environment; (3) the scenariosthat specify the actuation rules based on the contexts and (4) the actuators ultimately tocontrol the behaviour of the building. The described framework is based on a fuzzy con-trol system with slightly adaptations in the logic operations and its architecture. Thesecomponents as well as the language used to specify the contexts are detailed in whatfollows on this chapter.

3.1 Architecture

Automation systems consists of three main elements: sensors, actuators and controllersthat drive actuators from information provided by sensors. In a sense, the automationsystem is an execution environment (hardware) for the logic embededd in the controllermodule (software).Herein, we propose a language that can be used to specify the logic that goes into thecontrol element of the BAS. Specifications written in the language that we propose de-note fuzzy control systems and can be developed incrementally by describing instancesof contexts and scenarios - two abstractions that are precisely described in this chapter.A specification, at the logical level, can be translated (i.e. compiled) automatically tomachine instructions that can be deployed in the execution environment, in particular,within the BAS controller. Contexts are defined from information obtained from sen-sors and the actuators are driven according to attribute assignments determined by thescenarios. Since sensors and actuators are very heterogeneous in nature, our model as-sumes the existence of sensor and actuator drivers that abstract the specificities of thedifferent types of sensors and actuators. Figure 3.10 illustrates these ideas.

29

30 CHAPTER 3. LANGUAGE AND FRAMEWORK

Sensors Controller Actuactors

Logical LevelScenariosContextsSensors Actuators

Execution Level

Figure 3.10: Proposed framework architecture. This architecture can be analysed in twodistinct levels, the logical level and the execution level. The execution level is composed bythree components, the sensors and the actuators which are hardware devices that interactwith the surrounding environment, and the controller which is the core component of thesystem where the inference process is performed. In a logical level, which is installed in thecontroller component, the sensors and actuators must have an interface component in orderto interact with the physical devices. The reasoning process is based on the contexts andscenarios components.

3.1.1 Sensors

Sensors are devices that capture data from the environment. These devices perceivephysical properties and environment attributes which will be used in the definition ofthe contexts.In this work we will not get deep into the sensors component, however there are somesensors’ characteristics that must be analysed when implementing a language such asours, such as: Accuracy, Threshold,Noise among others (Fowler& Schmalzel, 2004). Mitchellet al. also list some characteristics of sensors that should be taken into account when se-lecting the appropriate sensors such as its function, performance, output and state. Whenmultiple sensors are presented in a system some relational properties of them should beanalysed like for example its distribution, redundancy, synchronous or asynchronous, granu-larity among others (Mitchell, 2007).Another important issue to have in mind when dealing with sensors is related with tim-ing. Should the system be event triggered or time triggered? In the former, the systemreacts and interprets the event from the sensors as soon as it happens, while on the otherone the system checks the state of the environment with a predefined time interval oftime. Time triggered systems are better for safety-critical real time applications becausethe scheduling is deterministic. However, in this system we propose an event triggeredapproach as the system aims at reacting to user’s actions; it must respond immediatelyto a change in the environment.Sensors’ measurements are not always deterministic, they return an estimate of the mea-sured physical property which introduce a degree of uncertainty. This kind of uncer-tainty arises from three types of errors: (1) random errors essentially caused by noise inthe sensors, i.e. readings from sensors that do not represent the state of the physicalproperty - this kind of errors are quite common and should be an issue to take into ac-count; (2) systematic errors which are characterized by consistent and repeatable errors,like calibration, loading, environmental and common representation format errors; and

3.1. ARCHITECTURE 31

(3) spurious readings which are non-systematic errors, like for example a detection of anobstacle when, in fact, that obstacle does not exist (Mitchell, 2007).Sometimes the measured data provided by the sensors have slightly differences fromthe previous readings which, at a high level, must be considered as the same value, sinceminor variations are indistinguishable by the specifications. In fact, if a system reactedto each small change in the sensors readings, the majority of the computation would beuseless because the output would be the same. To avoid this, the open standard BACnethave introduced the concept of change of value (COV) in the configuration of the sensors.This concept is defined through the parameter COV Increment in the attributes of thegiven sensor. With this parameter, the system will only be notified when the value ofthe sensor have had a significant change which is given by this value, otherwise it is notnotified (Haakenstad, 1999).

3.1.2 Contexts

In literature, there are many different definitions of contexts (see section 2.5), but es-sentially all of them define a context as an abstract state computed from informationgathered from the environment. In this work, we consider a context as a combining ofinformations frommultiple inputs (sensors or other contexts) and represented by a valuebetween 0 and 1. This value can be seen as a degree of truth of the system being in thatcontext. This notion of context can be related with the fuzzy logic theory explained insection 2.3. One can see a context as a fuzzy set, where its membership function is givenby the expression that defines the context. In section 3.2 we will see how the languagedescribes and define contexts.We have considered two types of contexts in our system: low level contexts and high levelcontexts. A low level context represents a normalized value of a given sensor, which isan intermediate level between the sensors and the main high level contexts. There aresome sensors that must be normalized and fuzzified before being used by the contexts,so in such cases a low level context must be defined. Low level contexts define sensordrivers.The high level contexts, instead of dealing directly with sensors, deal with normalizedvalues. These values can be both from sensors or from other contexts. It is importantto notice that, even if these kind of contexts are on a high level, they can also deal withvalues from sensors, however theses values must be normalized, i.e. must have valuebetween 0 and 1. An example of this situation is a binary sensor which can assume onlytwo values (0 or 1), so it can be used directly in a high level context.All the low level contexts must have an initial pre-defined value, so that the system canbe started and work even before the first readings arrive. By default, the initial value of acontext is 0, but for specific implementations the programmer may want to define thesevalues by itself, so we suggest that the user may have the possibility to define the initialvalue of each context.


3.1.3 Scenarios

Scenarios specify the behaviour of the system given the values of the different contexts.The behaviour is specified by rules. Scenarios abstract a set of aggregating related rules.This specification of concerns is important in terms of engineering: it allows modellingthe system behaviour into different sub scenarios which can also be divided into othersub scenarios and so on.Despite having considered this abstraction for the user, in the end only the rules areimportant. Due to this, the rules must be self-complete in the way that they specify allthe dependences and all the behaviour on them. One can also see this component as aknowledge base where the rules that specify the behaviour of the system are defined andthe reasoning is processed. The rules specified in this system are if-then fuzzy rules inthe form: if antecedent then consequent.These rules have a similar structure to the ones presented in the description of fuzzylogic (see section 2.3). The antecedent part of the rule specifies the fuzzy condition. Onthe other side, the consequent part specifies the action that should be performed by therule. These actions are usually assignments variables that control devices installed in thebuilding.These rules can be easily defined and understandable by the user. More details aboutthese fuzzy rules and the fuzzy inference process are described in section 3.3. One ex-ample of a fuzzy rule is:

if TooMuch(DeskIlluminated) ( Day then Curtains = SomewhatClose

3.1.4 Actuators

The actuators are the physical devices that receive input values and transform theminto physical actions. Examples of such actions can be: changing light levels, changingcurtain position, turning on or off some device, or any other type of action. In our frame-work we are not interested in the details about how this process is performed (e.g. howthe communication between the system and the device is established). We will assumethat the actuator component will react to an assignment. The steps needed to convertthat value into a real physical action are outside the scope of this work. For example,in this kind of systems, sometimes there are devices that cannot interpret all ranges ofvalues. They may only interpret a discrete set of values which can lead to an ambiguitywhen setting a device value. For th moment we are not addressing this issue.

3.2 Context Description Language

This section proposes the language thatwill be used to describe contexts. This is a declar-ative language based on fuzzy logic (see section 2.3) and temporal logic (see Section 2.4),however we have introduced some modifications to adapt the operators to fit our aims.As described in Section 3.1.2, a context is defined as a combination of different informa-tions from the environment. Contexts themselves are represented by a value between 0

3.2. CONTEXT DESCRIPTION LANGUAGE 33

and 1 and defined through a formula specified in the language.

3.2.1 Syntax of Context Formulas

The definition of a context is based on a formula expressed by operators. These operatorsare adaptations of the operators from the fuzzy logic and temporal logic. A context canbe compared with the notion of proposition used in the fuzzy and temporal logic, whichcan be either fuzzy or crisp, although in this case, a context is a fuzzy proposition. Aformula that specifies a context can be defined as what follows. The degree of truth ofa context is defined by a formula which depends on the value of sensors and contexts.The syntax of such a formula is given by the definition 3.1.

DEFINITION 3.1 : Syntax of context formula Let c a constant number between 0 and 1,f(r t(s)) a function f : S " [0, 1] where r t(s) is a sensor reading at instant t of the sensors and S its domain; 3, 4, ¬, (, ), (b and 'U be the operators raise transition, fall transition,negation, conjunction, disjunction, combination and until respectively; b a factor between 0 and1; context C can be defined by the following grammar:

C ::= c | f(rt(s)) | 3 C | 4 C | ¬C |C1 ( C2 |C1 ) C2 |C1 (b C2 |C1'UC2

To calculate the value of a context, the system has to check the values of the sensors andother contexts. So, when one of these values changes, the value of all the contexts thatdepend on that value have to be calculated.The operators used in these language have the following meaning:

Raise Transition This operator reflects an increment in the value of a context returningthe difference between the current value of the context and the value observed inthe previous instant in the case of increment, otherwise it returns 0. This operatoris represented by the symbol 3.

Fall Transition This operator is similar with the raise transition, however it checks ifthe value of the context has decrement, returning its difference in that case and 0otherwise. This operator is represented by the symbol 4.

Negation This operator represents the complement of a context which has the samedefinition used in the fuzzy logic. It is represented by the symbol ¬.

Conjunction This operator has the same definition of the correspondent operator in thefuzzy logic and makes the conjunction between two context, which is given by theminimum value of these two contexts. It is represented by the symbol (.

Disjunction The same thing happenswith this operator, however the disjunction of twocontexts is given by the maximum operation between them, and is represented bythe symbol ).

Combination This operator is a weighted multiplication between two context by a cer-tain factor b between 0 and 1. We represent it by the symbol (b, however de-spite using the symbol (, this operator is not related with the conjunction, it is


inly a notation. It is important to notice that this operator can also be written asC1 b ( C2 = C1 (1#b C2.

Until This operator does not have the same behaviour of the until operator from thelinear temporal logic. This operators holds (in a fuzzy way) since the value ofthe first context argument holds until the value of the second one holds. Besidesthis difference in the behaviour, this operator is used to reason about the presentinstant and the previous ones, instead of looking to the future as it is explained inthe section 2.4. It is represented by the symbol 'U

Function f(rt(s)) The usage of a function f : S " [0, 1] allows the user to use the valueof the sensor reading to define a context by normalizing it or making any othercustomization to its value.

3.2.2 Semantics of Context Formulas

This language has a notion of time in the same way as in linear temporal logic. We referby # a sequence of sensor readings (rt(s)) of a given sensor s or context c over the time,e.g. # = r0(s), r1(s), . . . , rn(s).

DEFINITION 3.2: Sensor Reading Let t be a time instant, s a sensor, a sensor reading corre-sponds to value read at the time instant t in the sensor s and is represented by rt(s).

Some of the operators used in this language model reason over the sequence # by eval-uating past values of sensors and contexts to calculate its value. Therefore, given a path# of sensor readings, the value of a context C at instant t can be defined recursively inthe definition of C . The semantics of a context is given by a mapping [[.]]t : C " [0, 1]defined as follows:

DEFINITION 3.3: Interpretation of a context formula Let C , C1 and C2 be contexts and b afactor between 0 and 1, for a given instant t, the interpretation of a context formula is given by:

[[ 3 C]]tdef=

([[C]]t & [[C]]t#1 if [[C]]t & [[C]]t#1 > 0

0 otherwise

[[ 4 C]]tdef=

([[C]]t#1 & [[C]]t if [[C]]t#1 & [[C]]t > 0

0 otherwise

[[¬C]]tdef= 1& [[C]]t

[[C1 (C2]]tdef= min([[C1]]t, [[C2]]t)

[[C1 )C2]]tdef= max([[C1]]t, [[C2]]t)

[[C1 (b C2]]tdef= (1& b)' [[C1]]t + b' [[C2]]t

[[C1'UC2]]t

def=

(min(max([[C1]]t, [[C1

'UC2]]t#1), 1 & [[C2]]t) if t > 0min([[C1]]t, 1& [[C2]]t) if t = 0

3.3. FUZZY INFERENCE PROCESS 35

3.3 Fuzzy Inference Process

In the section 3.1.3 we have described a scenario as a set of fuzzy rules where these ruleshave the following representation:

if antecedent then consequent.

This type of rules can be divided into two parts, the antecedent and the consequent, whichare detailed in the following sections. In addition to detailing the structure and operatorsused in these two parts, the fuzzy inference process is also describe throughout thissection. To better understand how this process is done and how the rules are specified,we will use an example of a rule that verifies if there is too much light over the deskand the user is working there, then the curtains must be partially opened in order toreduce the glare over the desk. This rule example is used throughout all this section andis written as:

if WorkingDesk ( TooMuch(DeskIlluminated) ( Day

then Curtains = PartiallyOpened (3.1)

3.3.1 Fuzzy Antecedent

In the section 2.3 we have described how fuzzy logic work, specially the fuzzy rules.We have stated that the antecedent part of a rule would take the form: ”x is A”, whereA is a fuzzy set and x an object belonging to the domain A. To adapt the behaviour ofthe fuzzy logic to our system, we state the antecedent part of the rule through a fuzzycondition.The antecedent part can be one or multiple sub-antecedents, which are connected by afuzzy connector (e.g. fuzzy ( or )with the same behaviour as in the fuzzy logic section.Each of these sub-antecedents are a fuzzy condition expression, which we now define.

DEFINITION 3.4: Fuzzy Condition Let C be a context, & a fuzzy context operator and ¬ thenegation operator; a fuzzy condition cond is given by the following grammar:

cond ::= C |&(C) | ¬cond

In the example rule 3.1, the antecedent part consists of two sub-antecedents which aretwo fuzzy conditions. The first condition simply verify if the user is working at the deskby evaluating the context WorkingDesk. The second condition uses the fuzzy contextprefix operator TooMuch applied to the context DeskIlluminated. This condition veri-fies if the desk is too much illuminated by applying the operator TooMuch to the contextDeskIlluminated.It is important to note that the contexts used in these conditions are essentially highlevel contexts. This is so because high level contexts aggregate the information fromthe sensors and from the low level contexts and are nearer to the user’s universe ofdiscourse. However, it is not mandatory that contexts be only high level. Low levelcontexts can be used as well.


0

0.2

0.4

0.6

0.8

1

0 0.2 0.4 0.6 0.8 1

TooM

uch

Des

kIllu

min

ated

Context DeskIlluminated

TooMuchDeskIlluminated

Figure 3.11: Graphic representation of the fuzzy set TooMuchDeskIlluminated generated bythe application of the fuzzy context operator TooMuch to the context DeskIlluminated. Theaxis x is the value of the context DeskIlluminated, which is the universe of discourse of thegenerated fuzzy set, while the y axis is the membership value of the generated fuzzy set.

The input of a fuzzy context operator is a contextC and its output a value between 0 and1 which is used in a fuzzy condition. The application of the fuzzy context operator toa certain context C results in a fuzzy set characterized by a membership function givenby the function f denoted as µ#(c) where c is the value of the context C . This fuzzy setrepresents the degree of truth of the context C modified by the application of the fuzzycontext operator.

DEFINITION 3.5 : Fuzzy Context Operator A fuzzy context operator & is a function & :[0, 1] " [0, 1].

The application of a fuzzy context operator to a certain contextC generates a fuzzy set. inrule 3.1, the operator TooMuch is applied to the contextDeskIlluminated to generate afuzzy set with a universe of discourse of the contextDeskIlluminatedwhich is describedby its membership function µTooMuchDeskIlluminated(c). This fuzzy set is illustrated infigure 3.11.The user may need to define other fuzzy context operators to specify the behaviour ofthe system, however defining such fuzzy sets individually for each context is a time-consuming process. An interesting observation is that fuzzy context operators tend tohave the same behaviour independently of the context to which they are applied to. Thishappens because the meaning of such operators is similar for each context and all thecontexts have the same domain, i.e. they range between 0 and 1. With this in mind, wesuggest that some pre-defined fuzzy context operators be implemented in the system increating fuzzy rules. Some interesting pre-defined operators are: No, Little, Some, Enough,Much, Too Much and Full. These operators are illustrated in the figure 3.12.Figure 3.12 is illustrating possible graphic representations for the pre-defined fuzzy con-text operators. Besides having these pre-defined operators, the user may need to makesome customizations depending on the particular context the operator is to be appliedto, due to semantic reasons.The user should be able to define define new fuzzy context operators, therefore it is use-ful to support customization of existing context operators. Using this customization theuser can create rules that are easier to read, making the descriptionmore understandable


0

0.2

0.4

0.6

0.8

1

0 0.2 0.4 0.6 0.8 1

Fuzz

y C

onte

xt O

pera

tor V

alue

Context Value

nolittle some

enoughmuch

too much

full

Figure 3.12: Graphic representation of some suggested fuzzy context operators

as a while. To define new fuzzy context operators, the user must specify its correspon-dent fuzzy sets, by giving a mathematical function. As stated in Section 2.3.3, there aredifferent types of functions that can be used and adapted to define a fuzzy context op-erator, however it is important to mention again that the universe of discourse of thesefuzzy sets is restricted to the domain of contexts.

We will now discuss how fuzzy conditions are evaluated. To evaluate the antecedentpart of a rule, one has to evaluate each sub-antecedent and then calculate the overallvalue of the antecedent having into account the fuzzy connectors used between eachsub-antecedent. If the fuzzy connector is the and, the result of themin operation betweenthe two sub-antecedents is returned, while if the connector is the or, the result of themaxoperation is returned instead (please refer to Section 2.3 for details). The calculated valueof the antecedent part of the rule is then propagated to the consequent part as we will seefurther. The calculation of the return value of each fuzzy condition depends on the typeof fuzzy condition used. In the case where a fuzzy condition is given by a context, thereturn value is the value of the context itself; in the case where a fuzzy condition is givenby a fuzzy context operator followed by a context C , the return value is the applicationof the membership function of the fuzzy set generated by this fuzzy context operator tothe value of the context. Finally, the negation operator is evaluated by complementingthe input arguments.

3.3.2 Fuzzy Consequent

The scenarios component consists of a set of fuzzy rules where each rule has an an-tecedent part and a consequent part. In this section we will discuss the consequent partof a rule and its evaluation. In fuzzy logic the consequent part of a fuzzy rule takes theform of ”z is C”( see Section 2.3). However, in our framework we will slightly adapt thisformat. For simplicity of presentation, we consider the interface with an actuator to beachieved through an assignment to serve attributes, which will be generically designatedas actuator

DEFINITION 3.6: Fuzzy Consequent Let actuator be an attribute of a device, the symbol =be a fuzzy assignment and ' be a fuzzy consequent operator, then a fuzzy consequent can be


0

0.2

0.4

0.6

0.8

1

0 20 40 60 80 100Curtains

PartiallyOpened

Figure 3.13: Graphic representation of the fuzzy consequent operator PartiallyOpened. Thisoperator is used to set the curtains to be partially opened-

defined by the following grammar:

consequent ::= actuator = '

The fuzzy assignment defined above will set the actuator to the value resulting fromthe fuzzy consequent operator '. This fuzzy consequent operator returns a fuzzy set,however we aim to control a certain device, and thus we have to set it to a single crispvalue, instead of a fuzzy set. Therefore, this fuzzy set must be defuzzied. This processwill now be discussed further.

DEFINITION 3.7: Fuzzy Consequent Operator A fuzzy context operator, represented by ', isa fuzzy set in the universe of discourse of the device actuator attribute. A fuzzy context operatoris defined by (i) the correspondent membership function of its fuzzy set as well as (ii) the inversefunction of its membership function in order to transform a fuzzy value into a crisp one.

The fuzzy consequent operator is similar with the fuzzy context operator in the samesense that it also specifies a fuzzy set. However, this fuzzy set is defined in the universeof discourse of its respective actuator (A) instead of a context (as it happens in the fuzzycontext operator). A fuzzy consequent operator is represented by its membership func-tion µ$ : A " [0, 1]. As a consequent operator is specific for a certain type of actuator,its definition is specific of each implementation so the pre-definition of some commonfuzzy consequent operators make less sense. The user has to define its own fuzzy con-sequent operators for its device actuators. For each operator the user has to provide itsmembership function as well as its inverse function. These operators can be illustratedgraphically. Figure 3.13 illustrates the fuzzy set associated to the fuzzy consequent oper-ator PartiallyOpened applied to the device actuator Curtains as exemplified in rule 3.1.

3.3.3 Defuzzification Process

The aim of our framework is to control the actuators of a building in order to performthe desired behaviour. To accomplish this, rules must, in the end, denote values to setthe actuators to reflect the intended behaviour. However, as we have said, a fuzzy conse-quent operator defines a fuzzy set that in practice, cannot be assigned to actuators since


they can only assume crisp values as control input. To solve this issue, a deffuzificationstrategy must be applied.In literature, there are many different deffuzification schemas used in transforming afuzzy set into a single representative crisp value (see Section 2.3.7) and some differentways of implementing a fuzzy control a system (see Section 2.3.8). These approachesdiffer essentially in the deffuzification process. The most representative defuzzificationschema is the Mandani deffuzication schema that uses the centroid of area of the fuzzyset resulting from all rules that actuate on a certain device. Despite being the most rep-resentative method, its computation is heavy due to the difficulty in computing the gen-erated fuzzy set of multiple rules and calculate its centroid of area. In the Tsukamotomodel, the deffuzification is a simple weighted average of the values returned from therules. This is possible because of the restriction of having a consequent fuzzy set rep-resented by a monotonous membership function, which generates a single crisp value.In our approach we propose an intermediate solution between the Mandani fuzzy infer-ence system and the Tsukamoto fuzzy model.To simplify the Mandani system and not imposing any restriction to the developer ofthe fuzzy consequent operator, we propose a solution where the propagation of the an-tecedent value to the consequent generates a crisp value as it happens in the Tsukamotomodel, regardless of the fuzzy consequent operator chosen. We propose that the propa-gation of the antecedent value, when intersected with the consequent fuzzy set, insteadof generating a fuzzy set, will opt to choose a single crisp value at once. Depending onthe consequent fuzzy set, the intersection of the antecedent value of the rule with its con-sequent fuzzy set may produce more than one value since the resulting fuzzy may notbe a function. However in a fuzzy control systemwe will have to choose only one value.We propose therefore that the value chosen be the value closer to the current value of theactuator. This heuristic tries to perform the most conservative assignment based on thedistance to the current value. However, if the distance between the current value and thecandidate values for defuzzification, the systemdoes not knowwhich value to choose. Inorder to solve these cases, the developer must indicate whether the system must favourthe maximum value or the minimum one between the intersected values. For each ruledefined, the process of calculating the crisp consequent value must be performed, whichmay result in multiple attributions to the actuator.Since there can be many rules actuating on the same device, different values must beset on it but only one value can be chosen. To solve this conflict, we opt to choose themethod used both in the Sugeno and in the Tsukamoto models, which calculates theweighted average of the antecedent value with the resultant consequent crisp value ofeach rule. The weighted average is the application of the centroid of area method whenthere are only crisp values. This method considers both the strength of a rule as well asits resultant value, by weighting them. This fuzzy inference process can be divided intothree steps similar to the ones described in section 3.3:

1. Calculate the antecedent value of each rule which is defined using a fuzzy con-text operator or simply a context as described in section 3.3.1. This value will bedenoted by wi and is named by firing strength

2. Propagate the firing strength of the antecedent part to the consequent part in each


rule by retrieving the resultant single crisp value zi. This propagation is describedin the Section 3.3.2.

3. Aggregate the resultant crisp values for each actuator by calculating its weightaverage given by the following formula:

actuator =

)i wizi)iwi

.

3.4 Summary

In this chapter we described our proposed framework to build a system that specifiesand automates the behaviour of a building based on fuzzy logic and temporal logic. Thearchitecture behind this framework consists of four components: sensors, contexts, sce-narios and actuators. The sensors are responsible to capture the information from thesurrounding environment which will be the input to the definition of the context. Thecontexts describe abstract concepts that represents the external environment. The scenar-ios encapsulate the actuators based on the values of contexts. These assignments to ac-tuators are described in a fuzzy way. The actuators are then responsible to convert thesefuzzy values into physical changes in a certain device to reflect the desired behaviour.In this chapter we also described the fuzzy inference process which is responsible forderiving the specified behaviour.

placeholder

placeholder

Chapter 4

Case Study

To illustrate the application of our framework, we have created a demonstrative casestudywhere each component of the system is defined and specified. This case study

aims at simulating a real application of a BAS.This case study consists of a simple office with a desk and a support table used for meet-ings. In the ceiling there are two luminaries, one closer to the window and anothercloser to the inner wall. The desk where the occupant usually works is located near thewindow, while the support table is located near the inner wall. To prevent excessive in-side glare and ensure privacy of the occupants, the windows have curtains that can beadjusted throughout the day.By using sensors and actuators, the office can adjust the light level in room in order tobalance the comfort and needs of the occupant’s activity, having in mind the the energysaving issue. It is important to mention in this case study, for simplicity, we have onlyconsidered the presence of one user at each time.

4.1 Sensors

In the specification of the behaviour of the building we need to know if someone is insidethe room and where it is working. We envision the presence sensors can be installedin the office to accomplish this task: one placed in the chair of the desk and one nearthe support table, which detects if someone is working at the desk or at the supporttable respectively. There is also a sensor in the door to detect if it has been openedor closed, which indicates if someone is entering or leaving the room. Besides thesepresence sensors, light sensors are also needed to detect the level of luminosity insideand outside the room. There is one luminosity sensor outside the office and two inside.The values of these three sensors are weighted to compute the level of luminosity atdifferent places inside and outside the room.In our example we have not taken into account the existence of noise disturbances inthe data reading of the sensors. We have considered that some filtering is performedby some sensor driver and the values read are already noiseless, so it expresses exactlywhat it is happening in the office.

43

44 CHAPTER 4. CASE STUDY

Door Sensor This sensor detects if someone is crossing the door. As we will make theassumption that there will only be one person in the room at the same time, wecan infer only from this sensor and the previous contexts if someone is enteringor leaving the office. This is a binary sensor where the true value represents thatsomeone crossed the door on that instant. We will refer to this sensor as DoorSen.If instead of knowing that someone is crossing the door we would like to knowthe direction of the crossing (it would be needed if we have more than one personin the room) we could use pressure sensors, light barriers or distance sensors as it isdescribed by Burgstaller (Burgstaller, 2007). This way it would be possible to adaptthe case study to more than one user at the same time in the office.

Table Sensor To detect the presence of the occupant near the support table, there is apresence sensor near the table. With this sensor we can infer if someone is work-ing at the support table or not. The signal 1 represents that someone is near thetable and 0 otherwise. It is important to take into account the noise that this kindof sensors can generate, however in this case study we will not worry with thatproblematic as we consider that this issue is solved by the sensor itself. We willrefer to this sensor as TableSen.

Desk Sensor Instead of having a presence sensor near the desk, as it is done with thesupport table, we have chosen to have a pressure sensor in the desk chair. Thissensor will be activated if someone is seated in the chair and inactive otherwise.This way we can detect if the occupant is working at the desk or not. In the sameway as the table sensor, we consider that the return of this sensor is noiseless. Wewill refer to this sensor as DeskSen.

Interior Luminosity Sensors In this case study there are more than one interior lumi-nosity sensor in the office, one closer to the window (referred as WindowLumSen)and another closer to the inner wall (referred as WallLumSen). These two sensorsallow us to predict more precisely the luminosity level in each different workplaceinside the room. This way it is possible to better adjust the level of artificial lightin the room.These sensors may have different spectral responses depending on its type andmanufactures (Doulos et al., 2008). Another important characteristic of these kindof sensors is that their response is a function of the luminance distribution of allsurfaces that are visible by the sensor and not only a reliable measure of the work-place luminance. According to Ehrlich et al. these sensors should be strategicallymounted either on the ceiling or under the luminary close to the daylight aper-ture (Ehrlich et al., 2002).

Exterior Luminosity Sensor To detect the amount of luminosity outside of the office, weplace a luminosity sensor near the window in the exterior facade of the building.This sensor will be referred as ExteriorLumSen.

Time Sensor This sensor is a virtual one as it is not a physical device installed in theoffice. It is used to allow reasoning about the time of day in the definition of thecontexts, particularly in the definition of the light models that needs to access tothat value. It will be referred as TimeSen.

4.2. CONTEXTS 45

4.2 Contexts

The contexts are abstractions of the reality that can be defined based on sensors installedin the office or from theoretic models. These abstractions we explained before (Section3.1.2) represent concepts used by the user in the reasoning process. In this case study wehave both approaches: we use the sensors defined in the Section 4.1 and we also specifysome light models to better reason about the daylight and night conditions. Moreover,as described in Section 3.1.2, the contexts can be distinguish in two types: low level andhigh level contexts. In this case study the low level contexts are used to manipulate andnormalize the luminosity sensorswhile the high level ones represent concepts in the useruniverse of discourse.

4.2.1 Low Level Luminosity Contexts

Luminosity sensors have their own interval of response values and the same measuredmay not represent the same amount of light. For example, an exterior luminosity sensormay measure a value much higher than a sensor placed inside the office. However, forthe user, the perception inside the office may bemuch higher than outside. This happensbecause the perception of the natural light for humans is different from the perceptionof light for sensors which indicate much more light than what human perceives. Sincethey are sensitive to flooding by other wavelengths. Therefore the creation of a low levelcontext that normalizes these values is required. In this case study, we will use a linearnormalization function to convert the value of the luminosity sensors to a normalizedvalue between 0 and 1. For each luminosity sensor a minimum and maximum valuemust be specified where the minimum value represents the degree of 0 of the contextwhile the maximum corresponds to the degree of 1. This normalization function couldbe a more sophisticated one, however a linear normalization function is a simple modelthat fits our purposes.The contextWallIlluminated represents the amount of luminosity near the wall convert-ing the luminosity sensorWallLumSen to a value between 0 and 1. In the same way, thecontextNaturalLightInside evaluates if there is natural light inside or not coming from thewindow, which is done by checking the WallLumSen. The last low level context relatedto luminosity is the context LightOutside, which represents the amount of light outside.This context is fed by the sensor positioned outside the building: the ExteriorLumSen.Please note that the constants used in the normalization functions are particular of ourcase-study. In a real application system these values take into account the sensors char-acteristics and the physical place where they are positioned.

WallIlluminated 5 LinearNorm(WallLumSen, 320, 500)

NaturalLightInside 5 LinearNorm(WindowLumSen, 320, 500)

LightOutside 5 LinearNorm(ExterirorLumSen, 8000, 30000)


0

0.2

0.4

0.6

0.8

1

0 5 10 15 20

Day

light

Time

(a) Daylight Model

0

0.2

0.4

0.6

0.8

1

0 5 10 15 20

Nig

hlig

ht

Time

(b) Nightlight Model

Figure 4.14: Illustraction of daylight (a) and nightlight (b) models. These models illustratesthe normal light level during the day and the night at the same points in time.

4.2.2 Low Level Light Model Contexts

Low level contexts can also be used to define some models, i.e. predictions of certainparameters to adjust the behaviour of the system according to them. In this case study,we have defined twomodels that predict if there is daylight or night at a certain point intime. We could also have implemented other models like for example a weather forecastmodel for the location of the office or we could have used models developed by otherauthors, like the one developed by Lindelof for daylight (Lindelof, 2007). However wepretend a simpler model just to illustrate this functionality.To represent the Daylight and the Nightlight (see figure 4.14) models we decide to use aGaussian function as it represents the position of the sun and the respective amount ofdaylight as night at successive points in time. For each daylight and nightlight modelwe specify different parameters, i.e. different mean and standard deviation values. Wenote that the Gaussian function used in the definition of these contexts can be the sameused in the definition of the fuzzy consequent operators.

Daylight 5 Gaussian(T imeSen, 12, 2.5)

Nightlight 5 Gaussian(T imeSen, 0, 2.5) )Gaussian(T imeSen, 24, 2.5)

4.2.3 High Level Contexts

This kind of contexts, as explained in Section 3.1.2, deals only with normalized valueswhich can be other contexts or sensors that only return values between 0 and 1, like forexample the presence sensors. These contexts aim at represent high level informationthat will be used in the rules belonging to the scenarios.These contexts often abstract theuser’s activity, a state or other useful high level information. To implement the require-ments of this case study we have defined some high level contexts that are described inthe following paragraphs.

Arriving and leaving contexts The context Arriving represents the arriving of someonein the office and holds when the DoorSen has raised and there is no one in theroom. The context Leaving is similar with the previous one however it checks ifthe DoorSen has fallen instead. These two contexts only holds for a single instant

4.2. CONTEXTS 47

at a time, due to characteristics of the sensor placed at the door as it detects if thedoor has been opened. Along with these two contexts, we also define the contextInTheRoom, which holds since someone arrives until someone leaves the room. Tocalculate the value of this context, the operator until is applied to the contexts Ar-riving and Leaving. By looking to the definitions of these three contexts we can seethat they form a recursive dependence as the contexts Arriving and Leaving aredefined based on the InTheRoom context and the InTheRoom context is definedbased on the Arriving and the Leaving contexts. This issue is solved by firstly cal-culating the contexts Arriving and Leaving by accessing to the value of the contextInTheRoom at the previous instant. On the other hand, the context InTheRoom iscalculated by accessing to the just calculated values of the contexts Arriving andLeaving. These contexts can be defined as follows.

Arriving 5 3 DoorSensor ( ¬InTheRoom

Leaving 5 3 DoorSensor ( InTheRoom

InTheRoom 5 3 Arriving 'U 3 Leaving

Activity contexts To detect the activity the user is doing inside the office room, we recurto the motion sensors deployed in the office, to defining three different contexts.The contextsWorkingDesk andWorkingTable are just a direct mapping of the motionsensor placed near the support table and the other presence sensor placed in thedesk chair. The third context, theWalkingAround, is defining based on the previoustwo as follows: If the user is not working at the table nor at the desk but, then theuser is inside the room, though it is walking around.

WorkingDesk 5 DeskSensor

WorkingTable 5 TableSensor

WalkingAround 5 ¬WorkingDesk ( ¬WorkingTable (( InTheRoom

Luminosity high level contexts Besides these high level contexts, we may also want todescribe some luminosity high level contexts to predict the amount of luminosity ina given place inside the roomwhich is influenced by different luminosity low levelcontexts. To predict these levels, the values of the luminosity low level contextsmust be weighted to compensate for their respective placement.

TableIlluminated 5 WallIlluminated (0.3 NaturalLightInside

DeskIlluminated 5 NaturalLightInside (0.4 WallIlluminated

RoomIlluminated 5 NaturalLightInside (0.5 WallIlluminated

Day and night contexts Other high level contexts of this system are the contexts of Dayand Night. They are defined according to the light models described previously


weighted with the LightOutside context, which represents the measured light bythe exterior luminosity sensor.

Day 5 Daylight (0.7 LightOutside

Night 5 Nightlight (0.6 ¬LightOutside

4.2.4 System’s Initial State

In the definition of the contexts of this system we should indicate the initial values ofthese contexts. In this case study we consider that there is no one in the room when thesystem starts to run, so all contexts related with the user’s activity have the value 0. Asthe low level contexts depend exclusively on sensors and models, they don’t depend onother contexts or previous values, the initial value for that sensors are irrelevant. Thedefinition of the initial value for the high level context related with the light are alsoirrelevant as they do not access to the context values in previous instants, only on theactual one.

4.3 Scenarios

The actuation behaviour of the system is specified in the scenarios by defining rulesthat specify the behaviour of the system and how it will react according to the contextspresent in the system.As it is explained in the scenarios section of the proposed framework (Section 3.1.3),scenarios are an abstraction for the user and are important in terms of engineering andmodelling of the system. Scenarios specified in this case study reflect the activity of theuser which is strongly related with its respective context. Despite this strong connection,all the rules have to be self-complete and independent, i.e. their conditions specify allthe dependencies of the rule. We do not consider scenarios to be dependent on a certaincontext. In this case study we have defined the following scenarios: Arriving, Leaving,Working at the Desk,Working at the Table,Walking Around and Privacy.Before specifying the scenarios and the rules that they contain, we first have to definethe fuzzy context operators and the fuzzy consequent operators that will be used by therules, as suggested in the framework specification.

4.3.1 Fuzzy Context Operators

To specify the conditions of the rules of this case study one may define some fuzzy con-text operators that will qualify the degree of truth of other contexts. In this case we onlyneed to define three different fuzzy context operators: Insufficient, Sufficient and TooMuch.The fuzzy context operators Insufficient, Sufficient and TooMuch are presented in fig-ure 4.15. These operators can be applied to the contextsRoomIlluminated,DeskIlluminated,TableIlluminated and Night. In this case study we opted to choose the same definition

4.3. SCENARIOS 49

0

0.2

0.4

0.6

0.8

1

0 0.2 0.4 0.6 0.8 1

Fuzz

y C

onte

xt O

pera

tor V

alue

Context Value

SufficientInsufficient TooMuch

Figure 4.15: Graphic representation of the fuzzy context operators Insufficient, Sufficient andTooMuch.

of these operators for all the contexts. Nevertheless we could have specified differentgraphic representations according to the context in the argument. The definition of theseoperators is represented below.

Sufficient(C) = Sigmoid(C, 20, 0.55)

Insufficient(C) = Sigmoid(C,&20, 0.45)

TooMuch(C) = Sigmoid(C, 40, 0.8)

4.3.2 Fuzzy Consequent Operators

In the consequent part of a fuzzy rule one must specify a value to set the actuator, whichin this framework is given through a fuzzy consequent operator. This type of operatorsrelate the fuzzy antecedent values with actuators, by specifying a fuzzy set in the domainof the actuator. To obtain the value that should be set in a certain actuator we will needto have to inverse function of the fuzzy set membership function must be used as it isexplained in the Section 3.3.2.In this case study we have defined some operators in order to control the actuators in-stalled in room. These operators are described in what follows. Firstly we have definedthe operators related with the actuator curtains (see figure 4.16) and then the operatorsrelated with the luminaries (see figure 4.17). Despite being two luminaries controlledindependently, the fuzzy consequent operators to control them can be the same.

Completely Closed This operator is used to control the actuator curtains installed nearthe window in the office. The range of values of the curtains actuator varies be-tween 0% and 100% which represents completely opened and completely closedrespectively. The fuzzy set of this operator is represented in the figure 4.16 and itshows that the curtain are nearly closed for any value of the antecedent part of therule. The definition of its inverse function is needed in order to choose the value toset the curtains based on the antecedent value.


0

0.2

0.4

0.6

0.8

1

0 20 40 60 80 100

Fuzz

y An

tece

dent

Rul

e Va

lue

Curtains

CompletelyClosedCompletelyOpened

PartiallyOpened PartiallyClosed

Figure 4.16: Curtains fuzzy consequent operators. These operators represent the differentstates that a curtain can assume before setting the curtains of the room with a certain value.

CompletelyClosed(Curtains) =Sigmoid(C, 1.3, 95)

CompletelyClosed#1(y) =Sigmoid#1(y, 1.3, 95)

Completely Opened This operator is similar with the previous one, but instead of clos-ing it is used to open the curtains. The completely opened operator is a sigmoidfunction near the 0% and its definition together with its inverse is:

CompletelyOpened(Curtains) =Sigmoid(C,&1.3, 5)

CompletelyOpened#1(y) =Sigmoid#1(y,&1.3, 5)

Partially Closed We have considered that the curtains are partially closed if its value isnear the 75%. This operator is defined through a Gaussian function with a centerin 75% as follows:

PartiallyClosed(Curtains) =Gaussian(C, 75, 8)

PartiallyClosed#1(y) =Gaussian#1(y, 75, 8)

Partially Opened In a way similar to the previous operator, this one is also a Gaussiandistribution, however its center value is 25%. The fuzzy set generated by this op-erator is displayed in the figure 4.16 with the following mathematical functions

PartiallyOpened(Curtains) =Gaussian(C, 25, 8)

PartiallyOpened#1(y) =Gaussian#1(y, 25, 8)

Now we will define the fuzzy consequent operators related with the luminaries which

4.3. SCENARIOS 51

0

0.2

0.4

0.6

0.8

1

0 20 40 60 80 100

Fuzz

y An

tece

dent

Rul

e Va

lue

Luminary

NormalLightFewLight MuchLight

Figure 4.17: Fuzzy consequent operators for luminaries. These operators represent the differ-ent intensity states that a luminary can assume and are used to set the luminaries of the officeto a certain value.

are illustrated in the figure 4.17.

Normal Light Sometimes there is not enough natural light in the office, this creates aneed to turn on the luminaries of the room. This is expressed through the fuzzyrules defined in the system. Some of these rules use the normal light operator to setthe luminaries to a value that illuminates the room into a normal value, i.e. enoughlight for the user to be able to work. In this case study, the luminaries value canrange from 0% to 100% which is the percentage of intensity of the luminary. Thenormal light operator is represented by a Gaussian function with a center in 75%as follows

NormalLight(Luminary) =Gaussian(L, 75, 8)

NormalLight#1(y) =Gaussian#1(y, 75, 8)

Few Light In the same way as the previous operator, in this case study we also needto define an operator that indicates the amount of ”few light”. This operator isonly used when the lights should be reduced to a minimum level because thereis already some light in a certain workplace, which is represented by a Gaussiandistribution with center in 35

FewLight(Luminary) =Gaussian(L, 35, 8)

FewLight#1(y) =Gaussian#1(y, 35, 8)

Much Light Besides the operators NormalLight and FewLight, sometimes it is neededto fully turn on the luminaries. This way we have defined this operator which isrepresented by a sigmoidal curve near the 100% of intensity.


MuchLight(Luminary) =Sigmoid(L, 0.5, 90)

MuchLight#1(y) =Sigmoid#1(y, 0.5, 90)

4.3.3 Constants

In certain cases it is desired to set a given actuator to a single crisp value, which is notpossible to be done with a fuzzy consequent operator. This way we can use constants toreflect this behaviour. In this case study we have only define one constant.

Off This constant is used with the luminaries actuators to turn it off, by setting it to thevalue 0.

4.3.4 Scenario Arriving

The first scenario defined in this case study is the scenario related with the arriving ofthe occupant to the office. This scenario is composed of the following rules:

if Arriving ( Insufficient(RoomIlluminated)

then LumWall = NormalLight (4.2)if Arriving ( Insufficient(RoomIlluminated)

then LumWindow = NormalLight (4.3)

The rules defined for this scenario are used to control the value of both luminaries in-stalled in the office. Since as we have two luminaries in this case study, each conditionused to control them must be repeated in two distinct rules, one for each luminary. Thisway, the rules of this scenario will set both luminaries to a normal light value whensomeone enters the room if there is insufficient light in the room.

4.3.5 Scenario Leaving

This scenario corresponds to the leaving of the user from the office. The behaviour re-flected by the rules of this scenario corresponds exclusively to the turning off of all lumi-naries in order to reduce the energy consumption of the office. To turn them off we usethe constant off defined above because the notion of turning off is not a fuzzy notion,but a crisp one.

if Leaving then LumWall = off (4.4)if Leaving then LumWindow = off (4.5)

4.3. SCENARIOS 53

4.3.6 Scenario Working at Desk

This scenario is related with the activity working at desk. Its behaviour is described bythe rules specified below:

if WorkingDesk ( Sufficient(DeskIlluminated)

then LumWall = FewLight (4.6)if WorkingDesk ( Sufficient(DeskIlluminated)

then LumWindow = NormalLight (4.7)if WorkingDesk ( Insufficient(DeskIlluminated)

then LumWindow = MuchLight (4.8)if WorkingDesk ( Insufficient(DeskIlluminated)

then Curtains = CompletelyOpened (4.9)if WorkingDesk ( TooMuch(DeskIlluminated)

then Curtains = PartiallyOpened (4.10)

The first two rules specify the behaviour of the luminaries when there is sufficient lightat the desk which will set the LumWall to a low level of light and the LumWindow toa normal level of light. The rules 4.8 and 4.9 control the behaviour of the LumWindowand the Curtains when there is insufficient light at the desk. In this case the LumWindowshould be set to a high level of light and the curtains should be completely open in orderto allow the maximum amount of natural light inside. Finally, the last rule will adjustthe curtains to avoid the excessive glare at the desk.

4.3.7 Scenario Working at Table

This scenario is similar with the previous one, however its rules are active when the useris working at the support table.

if WorkingTable ( Sufficient(TableIlluminated)

then LumWindow = FewLight (4.11)if WorkingTable ( Sufficient(TableIlluminated)

then LumWall = NormalLight (4.12)if WorkingTable ( Insufficient(TableIlluminated)

then LumWall = MuchLight (4.13)if WorkingTable ( Day

then Curtains = CompletelyOpened (4.14)

In this scenario, if the table is well illuminated, the luminary near the window must re-duce its intensity. On the other hand, if there is insufficient light at the table, the LumWall


should be set to a high level of light. Finally, if the user is working at the table and it isday, the curtains should be completely opened, which is done in the last rule.

4.3.8 Scenario Walking Around

This is the last scenario related with the user activity of this case study and correspondsto the third type of activity the user can do in the office, the walking around. In thisscenario the conditions are essentially focused on the context RoomIlluminated as it rep-resents if the room is illuminated as a whole.

if WalkingAround ( Day

then Curtains = CompletelyOpened (4.15)if WalkingAround ( Sufficient(RoomIlluminated)

then LumWindow = NormalLight (4.16)if WalkingAround ( Sufficient(RoomIlluminated)

then LumWall = NormalLight (4.17)if WalkingAround ( Insufficient(RoomIlluminated)

then LumWindow = MuchLight (4.18)if WalkingAround ( Insufficient(RoomIlluminated)

then LumWall = MuchLight (4.19)

Similarly towhat happens in the scenario working at the table, in this scenario, wheneverit is day, the curtains should remain completely opened. Excessive glare is not an issue ifthe user is not working at the desk. If the amount of light in the room is insufficient, thetwo luminaries should be set to a high level of intensity, while if there is sufficient lightthe luminaries should be set to a normal level.

4.3.9 Scenario Privacy

Besides the scenarios related with the user activity, we decided to include another sce-nario responsible with user privacy. This scenario is concerned preventing walking-bypeople outside to look into the office room, specially during the night. To this end, thisscenario closes the curtains during the night and open them back during the day. Toaccomplish this behaviour, this scenario is composed of two rules (i) one that closes thecurtains if it is too much night and (ii) other that opens it if it is day. By evaluating ifthere is too much night instead of only checking the context night, as it is done in theother rule with the context day, the system tends to have the curtains more opened thanclosed. This way more natural light can enter the office and only when it is really nightthe curtains are closed. It is important to notice that this scenario is only active if some-one is inside the room, otherwise no changes in curtains should happen. The rules thatcompose this scenario are described in what follows.

4.4. ACTUATORS 55

if InTheRoom ( TooMuch(Night) then Curtains = CompletelyClosed (4.20)if InTheRoom ( Day then Curtains = CompletelyOpened (4.21)

4.4 Actuators

Aswe have seen in the rules described in the previous section, in our case studywe havethree distinct actuators. TheCurtains, which are used to control the the amount of naturallight entering the office as well as to avoid that anyone can see inside, specially duringthe night. The other two actuators presented correspond to two luminaries. We haveinstalled one near the inner wall and other closer to the window and we refer to themas LumWall and LumWindow respectively. These luminaries provide artificial light in theroom and can be controlled independently in order to better control the light inside ofthe room.Note however that the actuators are not the focus of this work, so we are not worriedabout the communication details between the system and the devices, neither how theactuator converts the attribute assignments into the correspondent physical behaviour.We assume that all these three actuators receive values between 0 and 100. Therefore,the actuator will have to transform and adjust this value to one that the physical devicecan understand and communicate with it.

4.5 Summary

In this chapter we have described a simple case study and described how to apply frame-work we defined defined in the Chapter 3. This case study reflects a simple office witha desk and a support table used for meetings. In the ceiling there are two luminaries,one closer to the window and another to the inner wall. Near the window there is adesk where the occupant usually works. Near the inner wall a support table is placed.To prevent the excessive inside glare and ensure privacy of the occupants, the windowshave curtains that can be adjusted automatically throughout the day.This case study aimed exemplifying how our framework can be applied and this wayperforming a conceptual validation. This case study also sets the basis for all the valida-tions performed to which will described in the following chapter.

placeholder

Chapter 5

Validation

Tis chapter we describes the validation of the framework proposed in this thesis. Wewill start by specifying our validation strategy and then detailing the development

of this validation phase. We then discuss the results we have obtained and discuss theirgenerically, highlighting some of the limitations of our validation process.

5.1 Validation Strategy

After having developed a case study using our framework, a more formal validationstrategy is required. In order to fully validate this work, we need to develop a simulatorof the semantics of the context description language and of the fuzzy inference systemthat drives the actuators. The initial concept validation was done by quickly developingan Excel spreadsheet simulator to test a few simple sensor-actuators scenarios. Despitebeing a good way to quickly test the concept of our framework, it was not very robust,so we decided to develop a graphical simulator of our case study where one can interactwith the system simulating in real-time the events occurring in a building. Finally, formore robust validation tests, we have converted it to a non-graphical simulator in orderto accept input files and outputting a csv file that could be analysed with more detail andgenerate graphics that illustrate the behaviour of the system. Analysing these graphicswe could check if the output generated by the simulator was produced according to thestream of input events, which would be impractical to do with the interactive simula-tor. These input files simulate some particular event scenarios that could happen in realcases. The scenarios specified in the case study were also tested with independent inputfiles. Each phase of the methodology is described in the following sections.

5.2 The Initial Approach

In order to drive the development of our framework we have created a case studywherethe framework would be applied. This case study is the basis of the validation of thisframework and all the validation procedures illustrated in this chapter (see Chapter 4).Our initial approach aimed at quickly testing the framework and adjusting some rules

57

58 CHAPTER 5. VALIDATION

and, if needed, language operators as well, in order to fit the desired behaviour. To dothis we decided to implement a simulator using an Excel spreadsheet which performedall the computation steps of the proposed framework (sensors, contexts, scenarios, ac-tuators) defined allowing us to observe the details of these components as well as theirvalues at each instant.

5.3 Developing the Excel Simulator

This simulator uses as inputs, possible sensor readings for successive instants to simulatesimple scenarios. These values are the input of the system, specially for the calculationof the contexts. The idea is that in the end an update to a sensor reading will triggeran update in the actuators without the user being aware of the intermediate calculationsdone by the system, such as the contexts and rule values.With all the sensors readings listed, the contexts can then be calculated. However, aswe have proposed, the logic used inherent to the contexts component is different fromthe regular logic operators altered in Excel. Therefore, we hat to define the operatorsproposed in the framework as user defined functions in Excel. These functions andoperators were then used in the definition of each context. It is important to note that wehave also defined the initial values of the contexts at the instant t = 0 (the initial state),as it is required by the framework. These initial values have been defined to be 0.After the contexts, the rules had to be defined. In this phase the ability of Excel toallow the development of user-defined functions was essential, otherwise this frame-work could not be quickly tested. We have defined both the fuzzy context operatorsand the fuzzy consequent operators as user defined functions. With these functions im-plemented, the definition of the rules and its values was trivial. For each instant, wedivided the value of a rule into two parts for each instant, the antecedent value and theconsequent value. The calculation of the antecedent value used the fuzzy context oper-ators defined while the consequent used the antecedent value as well as the functionscorrespondent to the fuzzy consequent operators. This way we could better understandwhy a rule is computing a given value and what is influencing this computation.To finish the initial development phase, the actuator values had to be calculated as well.For each instant the actuator’s value was calculated based on the value of the rules. Eachrule produces a value for a certain actuator with an weight given by the antecedent valueof it, as explained in Section 3.3.3. So, the value of an actuator is calculated through anweighted average of the antecedent value and the consequent value of the rules thatcontrol that actuator.

5.3.1 Lessons Learned

With this initial approach we could refine our rules by making some adjustments onthem to produce our desired behaviour. The usage of the Excel as an initial method tovalidate this framework reveals a good strategy because without great effort we imple-mented it quickly and tested it for our case study. However for a deeper evaluation ofour framework we needed to test its behaviour in real-time. To this end, we decided to

5.4. THE INTERACTIVE SIMULATOR 59

Figure 5.18: Simulator application. This image illustrates the simulator application windowdeveloped to test the proposed framewor, where at the left side it is possible to interact withthe application by generating a sensor event. On the right there are the three actuators definedin this case study with its values.

develop an interactive simulator.

5.4 The Interactive Simulator

In a second approach to the validation of this work, we decided to concrete an interactivereal time simulator. The initial development described in the previous section was alsobeneficial because the logic operators, the fuzzy context and consequent operators werealready defined, and the logic behind the system was also already thought out. Thissimplified the development of the simulator.This simulator consists of a simple graphical application where one can simulate a newevent of a sensor and observe the resulting effect on the actuators. Each time a newsensor updates its value, i.e. the user simulates a new event, the system calculates thevalue of the contexts, the rules and finally the resulting value for the actuators. Thisnew event corresponds to a new instant in the system. We assume without any lossof generality that, at each instant, only one sensor can be updated. This is a differencebetween the this approach and the initial approach using Excel, where it was possible totest the resultant value of the actuators for a certain set of sensors values at once, it wasnot needed to simulate the happening of each events. However, a real system is moresimilar with the approach followed in this simulator as it is also an event-driven system,i.e., it reacts to a new event instead of checking the values in periodical intervals of time.Figure 5.18 illustrates the simulator developed.


5.4.1 Development Details

This simulator was developed in the Netbeans IDE environment and written in Java. Wedivided this application into three main classes, the Simulator which is the definition ofthe graphical application, the KB which is the core class of this project and where thesensors, the contexts, the rules and the actuators of the system are defined, and the classFunctions where some auxiliary functions are defined such as the logic fuzzy operators,the fuzzy context operators and the consequent operators. The core of this simulatorresides on the Knowledge Base (KB) class, which stands for knowledge base, where allthe knowledge of the system is specified. We would like to single out how contexts andrules are coded (see listing 5.1 and 5.2).

tmp = Functions.And(Functions.Raise(getPreviousValueSensor("DoorSen"),

getActualValueSensor("DoorSen")),getActualValueContext("InTheRoom"));

newContextValue("Leaving",tmp);

Listing 5.1: Example of a context definition

rule = Rules.get(10);rule.IF = Functions.And(getActualValueContext("WorkingDesk"),

Functions.Fully(getActualValueContext("Day")));tmp = Functions.PartiallyOpened(rule.IF, getValueActuator("Curtains"));rule.THEN = Functions.ComputeThen(rule.IF, tmp);

Listing 5.2: Example of a rule definition

These code examples show that the definition of contexts and rules is easy and wellstructured. Besides the graphical interface, this simulator also presents to the user somedebug information at each instant t such as the values of the sensors, the contexts, boththe antecedent and consequent values of the rules and the values of the actuators. Thisinformation was useful to test and debug the values of each component when a certaininput was introduced.

5.4.2 Lessons Learned

Developing this interactive simulator allowed us to test ad-hoc possible situations. Byinteracting with the system simulating events we could understand how the systemwasreacting through the analysis of the actuators values. This interaction made us aware ofsome incorrect definitions in the simulator engine as well as in case study itself. In theend of the adjustments in the system, the interactive simulator reacted correctly to theevents the user was generating. An interactive simulator is fundamental in a validationprocess as it allows the interaction of the programmer with the system in order to refinethe rules behind it.

5.5. BATCH SIMULATOR 61

Figure 5.19: Evolution of the curtains actuator along the day displaying the Privacy scenariowhich closes the curtains during the night and remains them opened during the day. The verti-cal axis represents the percentage of the curtains, where the 100 corresponds to the completelyclosed while the 0 corresponds to the completely opened. The horizontal axis represents thehour of the day.

5.5 Batch Simulator

The interactive simulator did no allow us to validate more complex cases regarding theevolution of sensor values in time. Therefore, we developed a batch simulator that re-ceives a flat file with the sequence of events and returns a csv file containing the valuesto be assigned to the actuators at each instant. This batch simulator allowed us to makeexhaustive tests to our case study andwith different scenarios to analyse in greater detailthe sequence of changes in the actuators validating the semantics we have proposed inthe Chapter 3. In the same way as in our initial approach and in the interactive simu-lator, this phase of tests also resulted in the identification of minor adjustments in rulesto better suit the desired behaviour. The analysis of these results is explained in thefollowing.

5.6 Results and Discussion

During the development of the simulator, some ad-hoc tests have been performed, how-ever they have not been registered, they were just experiment tests. After having therules completely specified and the simulator developed, we decided to test the scenar-ios and the rules defined in the case study. To accomplish this, we created some simplescenarios examples where we included all the rules specified in our case study. In thissection we will describe in greater each of these simulations and discuss the results illus-trating the evolution of the actuators during the simulation. We will enter our analysison the results modeled by the batch simulator.

5.6.1 Validating the Curtains Evolution

The first example we would like to discuss corresponds to the evolution of the curtainsalong the day. In this simulation we only consider the exterior luminosity gathered bythe luminosity sensor placed outside the room and the evolution of the time. We simu-late the simulating of the day since the 0h until the 24h. This evolution is presented in


Figure 5.20: Simulation of arriving and leaving at the office events. This graphic representsthe changes in both luminaries when the user enters the room, then he leaves it and come backagain. The vertical axis corresponds to the percentage of the luminaries, while the horizontalaxis represents each instant of the events. The first peak corresponds to the first entrance inthe room which willturn on of the luminaries. This turning on is made twice in two sets dueto the specificity of the DoorSen because firstly an event is generated with the value of theDoorSen at one. In both this instant the system is considered to be in the context Arriving andWalkingAround, these contexts will influence the value of the luminaries. However, as soonas the door is closed, represented by the event of the DoorSen = 0, the system is no longer inthe context Arriving, so only the context WalkingAround is active which will increase the lightto the value 100%. The same thing happens in the second peak when the user comes back tothe room. The other thing to notice in this example is when the user leaves the room, all theluminaries are then turned off. In this period, if for example the amount of natural light insidethe room increases, as no one is inside, the luminaries will remain turned off until someonecomes back again. In this example the amount of light in the wall and in the desk was with alow level in order to have insufficient light inside the room.

the Figure 5.19. During the night, i.e., from 18h until 6h the curtains remain closed whileduring the day they are completely opened. This behaviour results from the Privacy sce-nario of described case studywhich pretends to ensure the privacy of the user by closingthe curtains specially during the night.To test the scenarios Arriving and Leaving, we created a single simulation that includesboth scenarios. We intended to simulate a user arriving, then leaving the room for awhile and coming back again later. The output is illustrated in figure 5.20, which de-picts the evolution of the luminaries installed in the office. We can observe two distinctpeaks, which corresponds to the two entrances in the room where the system turns onthe luminaries to 100% due to the insufficient amount of light in the room. Besides thesepeaks, there is another interesting note which is the turning off of the luminaries. Thiseffect corresponds to the period when the user is outside the office. During this period,the luminosity inside and outside may change but it will not correspond to a change inthe actuators of the room as there is no one inside.

5.6.2 Validating Partially Cloudy Weather Conditions

Even in a sunny day, a cloud can suddenly cover the sun abruptly reducing the amountof light present in room. In such a situation the BAS must react by increasing the lightand open the curtains to take advantage of themaximum amount of natural light. To testthis particular situation we created a scenario that simulates the passing of a cloud in thesky. This result of simulation is illustrated in the figure 5.21, where one can observe theincreasing of the light and the opening of the curtains.

5.6. RESULTS AND DISCUSSION 63

Figure 5.21: Illustration of the simulation of a cloud passing in the sky. The horizontal axisrepresents the instants of the events while the vertical axis represents the level of the actuatorsat each instant. The passing of a cloud in the sky reduces the amount of light inside the roomtriggering an increase in the intensity of the luminaries. This effect is visible in two top linesof the graphic which represent the LumWindow and the LumWall respectively. The curtainsare completely opened to take advantage of the maximum amount of light from the outside,which can be observed from the bottom line displayed in the graphic.

Figure 5.22: Illustration of the simulation of the activity working at the desk. The horizontalaxis represents the time instants while the vertical axis the value of the actuators. This graphicdisplays the effect on the three actuators corresponding to the case study when there is suffi-cient light in the room (until the instant t = 4). When the light reduces provoking insufficientamount of light in the desk (between the instants t = 4 and t = 10) and when the amount oflight increases by resulting in too much light (from the instant t = 10).

In the case study described in Chapter 4, the user can be doing one of three differentactivities at a time: working at the desk, working at the support table or walking around.In order to test these three activities we have created distinct inputs scenarios, whichnevertheless are quite similar. It is possible to test the differences of behaviour of thesystem depending on the activity being performed. These examples aims at exercisingthe reaction of the system in each activity when there is sufficient light in the room andin each workplace, when the light reduces inside the room andwhen the amount of lightincreases to a level where there is too much light in the office room.

5.6.3 Validating Working at Desk

When the user is working at the desk a series of events make the LumWindow contexthave an higher value than the LumWall, however both of them vary in the same way.The variance illustrated in the figure 5.22 corresponds to the decreasing of the amountof light inside the room, which make luminaries increase their intensity values. Curtainshave a contrary behaviour as they are to be completely opened whenever a reduction of


Figure 5.23: Simulation of the activity working at the support table. The horizontal axis rep-resents the time instants while the vertical axis the value of the actuators. The graphic showsthe effect on the three actuators of the case study: when there is sufficient light in the room(until the instant t = 4), when the light reduces provoking insufficient amount of light in thetable (between the instants t = 4 and t = 10) and when the amount of light increases by beingtoo much light (from the instant t = 10).

Figure 5.24: Simulation of the activity walking around. The horizontal axis represents the timeinstants while the vertical axis the value of the actuators. This graphic shows the effect on thethree actuators of the case study when there is sufficient light in the room (until the instantt = 4), when the light reduces provoking insufficient amount of light in the room (betweenthe instants t = 4 and t = 10) and when the amount of light increases by being too much light(from the instant t = 10).

light takes place. When there is too much light at the desk, the curtains close a little inorder to avoid excessive glare in the desk area.The simulation of the scenario WorkingTable displays a behaviour similar to the previ-ous example (illustrated in the figure 5.23). However, in this scenario the luminary withthe highest value is driven by LumWall because the user is now working closer to thewall. Another aspect to notice in this example, that does not happen in the previous one,is the behaviour of the curtains. Curtains remain with the same value as the glare doesnot disturb the work at the support table.

5.6.4 Validating the walking around activity

The third activity is walking around, which is not associatedwith a particular zone room.In this case the room is seen as a whole. For this reason, both LumWall and the LumWin-dow contexts have the same value, which can be seen in the figure 5.24. Despite being ina different activity, the behaviour of the luminaries is in line with the previous examplesas they increase their value when the amount of light reduces inside the room. In this

5.7. LIMITATIONS 65

example the curtains have exactly the same behaviour has the working at table examplebecause the glare do not disturb the work of the user.With the application of these scenarios examples in the simulator, we could check howthe proposed framework reacts to certain situations. All situations reflect how the con-ditions and the initially foreseen behaviour are implemented by the rules. In fact, thevalidation process aimed at testing and validating the case study, which in turn aimedat validating our framework. By having defined a case study, applying the proposedframework on it, and running the above mentioned tests, we can say that the frameworkconfirms the behaviour in a building automation system with such a framework.

5.7 Limitations

Despite the fact that our tests supply re-inferencing evidence that our framework is agood method to specify the behaviour of a BAS, there are some limitations that shouldbe taken into account, which we now :

Lack of customization support The behaviour model is the same for all persons enter-ing the office and does not account for personalization and customization accord-ing to the user needs or preferences.

Scenarios may cancel each other When multiple scenarios are active at the same timethey may cancel each other. For example in the case study we have described, thePrivacy scenario is active whenever someone is inside the room, so it will be activewhile some other scenario while some other scenario corresponding to the useractivity, such as the scenario WorkingDesk. Suppose that a cloud suddenly coversthe sky and the light inside the room falls to low, the system should completelyopen the curtains. However, the Privacy scenario considers that it is night andorders. This cancellation process happens because in a fuzzy control system all therules influence the return values.

Single case study By using only one case study as a demonstrative example, the valida-tion performed may not be exaustive as this case study is not representative of allpossibilities in the specification of behaviour in a building automation system.

Scalability Our conclusions are based and limited by the size of our case study in thesense that we do not have evidence that this approach would scale to a large build-ing possibly with hundreds of sensors and actuators.

The lack of validation in a real environment This validation is performed on a simu-lated environment. A real environment would be greatly beneficial to perform areal-world validation of this work.

5.8 Summary

In this chapter we have described the implementation and the process of validationof the proposed framework. We detail our initial approach in the Excel application to


quickly test and refine the rules. Then we describe the simulator developed in Java withgraphical and non-graphical interfaces to test and analysis particular situations of thecase study. After the description of the implementation process we detail the exhaustivetesting phase and discuss the results through the analysis of generated graphics. Thesetests validate the proposed framework as a goodway to specify the behaviour of a build-ing automation system. However, we finish this chapter by listing the limitations of theproposed framework that should be taken into account when implementing it.

Chapter 6

Conclusions

This work aimed to create a language for the behaviour of a building automationsystem in an easily and understandable way for the user. This is a complex and

challenging issue since one needs to specify actuations that vary continuously, depend-ing on the input values.To accomplish this task we started by studying related subjects such as expert systems,rule-based systems, context-aware systems, building automation systems. We realizedthat classical Boolean logic was not enough to specify this type of behaviour due totheir discrete nature. To solve this we studied the concepts of fuzzy logic and continuedpromising (i) how fuzzy logic reflects the humanway of reasoning and (ii) its continuousnature. Our hypothesis was whether there would be a way to specify the control of aBuilding Automation System, which is of a continuous nature, in a straightforward anduser friendly fashion. To fulfil our hypothesis, we propose a novel framework based ona declarative language which applies fuzzy rules that can be easily written by the user.We developed a case-study and carried out exhaustive validation tests on a simulatorthat implements the semantics of the language that we propose.

6.1 Retrospective

In this work we mixed the concepts of fuzzy logic with operators from the temporallogic. This combination enabled, besides reasoning in a fuzzy way, the system to alsoreason about time, specifically about past events. The operators from the fuzzy logicand temporal logic are used in the definition of the contexts, fundamental concepts inthe proposed language. Fuzzy context allow the system to reason about its surroundingenvironment as it happens in a context-aware system. In the specification of the rules, theuser can use its own terms both in the fuzzy conditions and in the fuzzy consequent. In afuzzy control system, there is the need of a deffuzification phase to convert the generatedfuzzy set into a single crisp value. We have developed an intermediate strategy betweenthe Mandani and the Tsukamoto fuzzy models, where each rule instead of generating afuzzy set they generate a single fuzzy value and this value of the actuator is weightedwith the average of the outputted rules controlling that actuator. This approach resultedin a defuzzification less demanding than the Mandani fuzzy system but more flexible

67

68 CHAPTER 6. CONCLUSIONS

than the Sugeno and Tsukamoto models.To validate our framework we have developed a simple case study where the frame-work is applied. Using this case study proved to be a good strategy for validating theproposed framework. It also provided a demonstration example that can be used to sup-port further implementations and developments of this framework. The validation wasperformed in three phases: in the first one an Excel model was developed to quickly testour ideas, the second phase creating a real-time interactive simulator for more robusttests, with a graphical interface. The third phase required the development of a batchsimulator to test the response of our framework to more complex event sequences. Withthis validation and the discussion of the results, we have concluded that the proposedframework with such a declarative language is a good way to specify the behaviour ofa building automation system. Concerning usability we anticipate being easy for theuser to configure and adjust the rules of the system, in order to better reflect the desiredbehaviour.

6.2 Main Contributions

This work resulted in the proposal of a declarative language for specifying the behaviourof building automation systems with the following main contributions:

• A new framework to specify the behaviour of building automation systems basedon the fuzzy logic and temporal logic.

• A formal syntax and semantics of the language proposed drawing on conceptsborrowed from fuzzy logic and temporal logic.

• Adaptation of the concept of ”context” from ambient intelligence to fuzzy logic.

• A generalization of the temporal Until operator to deal with fuzzy propositions.

• A new approach to defuzzyfication process of fuzzy control systems that is compu-tationally less demanding than the Mandani fuzzy system but more flexible thanTsukamoto and Sugeno models.

• A detailed case study of a building automation problem that can be used as a basisfor further analysis and development.

6.3 Limitations

Besides the validation limitations, the work as a whole also have some limitations:

Single user model The proposed only allows one person in a space at each time.

Absolute values The proposed type of rules only allows to set the actuator to values.However it does not allow to express ”close the curtains a little” which is a relativestatement. This behaviour would be useful but is not possible in our framework.

6.4. FUTUREWORK 69

Past values Although our framework can reason about past events, it is not possibleto set the actuators to the values previously seen. This would be interesting forexample when the user leaves the room for a short period, so when he come backthe room would be set again as it was when the user left.

The reasoning about time intervals This would be interesting to detect a short break,since we do not have fuzzy operators for time. We cannot express the structure ”awhile ago” in our framework.

6.4 Future Work

During the development of this work our initial aim was to study and propose a strategyto recognize patterns in a building environment by making the building automationsystem learning them. Howeverwe faced a big issue, whichwas how amachine learningapproach can generalize to identify behaviour paterns from an input stream of eventsproduced at human level (a sample set of examples). A model of the system behaviourhad to be developed first. Therefore, we refocused our strategy to firstly study anddevelop a framework that explicitly specifies the behaviour of the building, and afterhaving this behaviour specified we could then apply a learning strategy. However, asthe time of development of this work is reduced, we choose to go deeper in the issuesrelated to the specification of buildings’ behaviour and create a solid base that could beextended afterwards to apply learning.

Learning the user preference The learning of the routines and the readjustment of thebehaviour of the building automation system is the most promissory task that canbe done based on this work. To go in this direction we suggest investigating theneuro-fuzzy logic which introduce the learning in the fuzzy logic, by consideringthe fuzzy logic system as a neural network (Jang et al., 1997).

Implementing real world simulation The validation we have performed does not com-prise the real environment. Only simulated situations were tested. For a better val-idation of the proposed framework we suggest the implementation of this frame-work in a real BASwhere the influence of the users can reveal new insights. Unfor-tunately this real test environment was not possible due to the limitations of timeand by not having a physical space where it could really be tested with a continu-ous utilization of that room. Some real test takes too much time because we wouldneed to monitor the system for a long period of time (hours or days) in order totest the specified behaviour. Another important thing to add when testing in a realenvironment is a way to gather the feedback of the user without interfering its nor-mal routine. This can be done by observing the punishments and rewards of theuser to the system, for example when the system turns off a light and the user turnit on again, it should be considered a punishment to the system.

Developement environment In this work we have just proposed a framework but nota real development system. It would be interesting to develop real systems basedon this framework that could be compiled easily to any physical implementationwithout changing the code of the system. To achieve this, a graphical drag and

70 CHAPTER 6. CONCLUSIONS

drop interface definition of the rules that constitute the system would be inter-esting. This way, anyone with a basic knowledge in computer applications couldinstall and specify the behaviour of the system without great effort.

Extension language expressivity Related to the expressivity of the language there arealso some improvements that could be done. The limitation of a single person in-side the room is a major limitation, so it should be reviewed in order to acceptmultiple users inside the room. The personalization and customization of the be-haviour according to the user inside the room should also be allowed, since theproposed framework does not support it. Reasoning about time in the proposedframework is limited to the observation of past events, it is not possible to set theactuators of the building as theywere at a certain instant in time. This functionalitycould be interesting for example if one wants to simulate the leaving of the roomfor a short period of time, which should set the actuators as they were when theuser has left. Similarly, the reasoning about interval of times would also be inter-esting for example to express the following proposition: ”the light is turned on fortoo much time”. Related with the inference process, the actuation in the proposedframework is limited to set the actuators to a predefined fuzzy value. However,it would be interesting to be able to order the actuator to increase or decrease itsvalues using a fuzzy quantificator. For example the action ”close the curtains a littlebit” would be useful for the programmer of the rules.

placeholder

placeholder

Bibliography

ACAMPORA, G., GAETA, M., LOIA, V. & VASILAKOS, A. (2010). Interoperable andadaptive fuzzy services for ambient intelligence applications. ACMTransactions on Au-tonomous and Adaptive Systems (TAAS), 5, 1–26.

BALDAUF, M., DUSTDAR, S. & ROSENBERG, F. (2007). A survey on context-aware sys-tems. International Journal of Ad Hoc and Ubiquitous Computing, 2, 263–277.

BIEGEL, G. & CAHILL, V. (2004). A framework for developingmobile, context-aware ap-plications. In Pervasive Computing and Communications, 2004. PerCom 2004. Proceedingsof the Second IEEE Annual Conference on, 361–365.

BUCHANAN, B. & FEIGENBAUM, E. (1978). Dendral and Meta-Dendral: Their Applica-tions Dimension. Artificial Intelligence, 11, 5–24.

BUCHANAN, B. & SHORTLIFFE, E. (1985). Rule-based expert systems: the MYCIN experi-ments of the Stanford Heuristic Programming Project. Addison-Wesley Reading, MA.

BUCHANAN, B., BARSTOW, D., BECHTAL, R., BENNETT, J., CLANCEY, W., KU-LIKOWSKI, C., MITCHELL, T. & WATERMAN, D. (1983). Constructing an expert sys-tem. Building expert systems, 127–167.

BURGSTALLER, W. (2007). Interpretation of situations in buildings. Vienna University ofTechnology, Institute of Computer Technology, Diss.

CAO, J., XING, N., CHAN, A., FENG, Y. & JIN, B. (2005). Service adaptation using fuzzytheory in context-aware mobile computing middleware.

CHAN, M., ESTEVE, D., ESCRIBA, C. & CAMPO, E. (2008). A review of smart homes–present state and future challenges. Computer Methods and Programs in Biomedicine, 91,55–81.

CLARKE, E. (1997). Model checking. In Foundations of software technology and theoreticalcomputer science, 54–56, Springer.

CLARKE, E. & EMERSON, E. (1982). Design and synthesis of synchronization skeletonsusing branching time temporal logic. Logics of Programs, 52–71.

COOK, D. & DAS, S. (2005). Smart environments: technologies, protocols, and applications,vol. 43. Wiley-Interscience.

CRIJNS, H. (2004). Knx system architecture.

73

74 BIBLIOGRAPHY

DEY, A., ABOWD, G. & SALBER, D. (2001). A conceptual framework and a toolkit forsupporting the rapid prototyping of context-aware applications. Human-Computer In-teraction, 16, 97–166.

DEY, A.K. & ABOWD, G.D. (1999). Towards a better understanding of context andcontext-awareness. In In HUC ’99: Proceedings of the 1st international symposium onHandheld and Ubiquitous Computing, 304–307, Springer-Verlag.

DIBOWSKI, H., PLOENNIGS, J. & KABITZSCH, K. (2010). Automated design of buildingautomation systems. Industrial Electronics, IEEE Transactions on, 57, 3606–3613.

DOUKAS, H., PATLITZIANAS, K., IATROPOULOS, K. & PSARRAS, J. (2007). Intelligentbuilding energy management system using rule sets. Building and environment, 42,3562–3569.

DOULOS, L., TSANGRASSOULIS, A. & TOPALIS, F. (2008). The role of spectral responseof photosensors in daylight responsive systems. Energy and Buildings, 40, 588–599.

DOUNIS, A. & CARAISCOS, C. (2009). Advanced control systems engineering for energyand comfort management in a building environment–a review. Renewable and Sustain-able Energy Reviews, 13, 1246–1261.

EHRLICH, C., PAPAMICHAEL, K., LAI, J. & REVZAN, K. (2002). Amethod for simulatingthe performance of photosensor-based lighting controls. Energy and Buildings, 34, 883–889.

EMERSON, E. (1990). Temporal and modal logic.Handbook of Theoretical Computer Science.

EMERSON, E. & HALPERN, J. (1986). “sometimes” and“not never” revisited: on branch-ing versus linear time temporal logic. Journal of the ACM, 33, 151–178.

EMERSON, E. & SRINIVASAN, J. (1989). Branching time temporal logic. Linear Time,Branching Time and Partial Order in Logics and Models for Concurrency, 123–172.

FAHY, P. & CLARKE, S. (2004). CASS-middleware for mobile context-aware applications.InWorkshop on Context Awareness, MobiSys, 304–308, Citeseer.

FOWLER, K. & SCHMALZEL, J. (2004). Sensors: The first stage in the measurement chain.Instrumentation & Measurement Magazine, IEEE, 7, 60–65.

FUKAMI, S., MIZUMOTO, M. & TANAKA, K. (1980). Some considerations on fuzzy con-ditional inference. Fuzzy Sets and Systems, 4, 243–273.

HAAKENSTAD, L. (1999). The open protocol standard for computerized building sys-tems: BACnet. In Control Applications, 1999. Proceedings of the 1999 IEEE InternationalConference on, vol. 2, 1585–1590, IEEE.

HINTIKKA, J. & SUPPES, P. (1966). Aspects of inductive logic, vol. 49. North Holland Pub.Co.

INTILLE, S. (2002). Designing a home of the future. IEEE pervasive computing, 76–82.

BIBLIOGRAPHY 75

JACKSON, P. (1998). Introduction to Expert Systems. Addison-Wesley Longman PublishingCo., Inc., Boston, MA, USA.

JANG, J., SUN, C. & MIZUTANI, E. (1997). Neuro-Fuzzy and Soft Computing-A Com-putational Approach to Learning and Machine Intelligence [Book Review]. AutomaticControl, IEEE Transactions on, 42, 1482–1484.

KAMP, J. (1968). Tense logic and the theory of linear order.

KASTNER, W., NEUGSCHWANDTNER, G., SOUCEK, S. & NEWMANN, H. (2005). Com-munication systems for building automation and control. Proceedings of the IEEE, 93,1178–1203.

KIM, B., CHO, K. & PARK, K. (2000). Towards lonworks technology and its applicationsto automation. In Science and Technology, 2000. KORUS 2000. Proceedings. The 4th Korea-Russia International Symposium on, vol. 2, 197–202, IEEE.

LIAO, S. (2005). Expert system methodologies and applications–a decade review from1995 to 2004. Expert Systems with Applications, 28, 93–103.

LINDELOF, D. (2007). A simplified daylight model suitable for daylight controllers.

LINDSAY, R., BUCHANAN, B., FEIGENBAUM, E. & LEDERBERG, J. (1993). DENDRAL:a case study of the first expert system for scientific hypothesis formation. ArtificialIntelligence, 61, 209–261.

MAMDANI, E. & ASSILIAN, S. (1975). An experiment in linguistic synthesis with a fuzzylogic controller. International Journal of Man-Machine Studies, 7, 1–13.

MANTYJARVI, J. & SEPPANEN, T. (2003). Adapting applications in handheld devicesusing fuzzy context information. Interacting with Computers, 15, 521–538.

MEYER, S. & RAKOTONIRAINY, A. (2003). A survey of research on context-aware homes.In Proceedings of the Australasian information security workshop conference on ACSW fron-tiers 2003-Volume 21, 159–168, Australian Computer Society, Inc.

MITCHELL, H. (2007).Multi-sensor data fusion: an introduction. Springer.

PARK, H., YOO, J. & CHO, S. (2006). A context-aware music recommendation systemusing fuzzy bayesian networks with utility theory. Fuzzy Systems and Knowledge Dis-covery, 970–979.

PASSINO, K. & YURKOVICH, S. (1998). Fuzzy control. Citeseer.

PNUELI, A. (1977). The temporal logic of programs. In 18th Annual Symposium on Foun-dations of Computer Science, 46–57, IEEE.

PRAUS, F., GRANZER, W. & KASTNER, W. (2009). Enhanced control application devel-opment in building automation. In Industrial Informatics, 2009. INDIN 2009. 7th IEEEInternational Conference on, 390–395, IEEE.

PRIOR, A.N. (1957). Time and Modality. Clarendon Press, Oxford.

76 BIBLIOGRAPHY

RANGANATHAN, A., AL-MUHTADI, J. & CAMPBELL, R. (2004). Reasoning about un-certain contexts in pervasive computing environments. IEEE Pervasive Computing, 3,62–70.

RUTISHAUSER, U., JOLLER, J. & DOUGLAS, R. (2005). Control and learning of ambienceby an intelligent building. Systems, Man and Cybernetics, Part A: Systems and Humans,IEEE Transactions on, 35, 121–132.

SCHMIDT, A. & VAN LAERHOVEN, K. (2001). How to build smart appliances? IEEE [seealso IEEE Wireless Communications] Personal Communications, 8, 66–71.

STREJCEK, J. (2005). Linear temporal logic: Expressiveness and model checking.

SUGENO, M. & KANG, G. (1988). Structure identification of fuzzy model. Fuzzy sets andsystems, 28, 15–33.

TAKAGI, T. & SUGENO, M. (1985). Fuzzy identification of system and its applications tomodelling and control. IEEE Transactions on Systems, Man, and Cybernetics, 15, 116–132.

TSUKAMOTO, Y. (1979). An approach to fuzzy reasoning method. Advances in fuzzy settheory and applications, 137–149.

WEISER, M. (1995). The computer for the 21st century. Scientific American, 272, 78–89.

WINSTON, P.H. (1992). Artificial Intelligence. Addison Wesley Longman.

WONG, B. & MONACO, J. (1995). Expert system applications in business: A review andanalysis of the literature (1977-1993). Information & Management, 29, 141–152.

ZADEH, L. (1965). Fuzzy sets*. Information and control, 8, 338–353.

ZADEH, L. (1973). Outline of a new approach to the analysis of complex systems anddecision processes. Systems, Man and Cybernetics, IEEE Transactions on, 28–44.

ZADEH, L. (1975). The concept of a linguistic variable and its application to approximatereasoning–I* 1. Information sciences, 8, 199–249.

ZIGBEE, A. (2005). Zigbee specification. ZigBee document 053474r06, version 1.

placeholder

placeholder

Appendix A

Membership Functions Types

In this appendix we will detail the most common types of membership functions bydefining its mathematical representation as well as its inverse function, which is neededin the inference process.

A.1 Triangular Membership Function

The triangular membership function represented by the graphic in figure 2.2(a) is spec-ified by three different parameters {a, b, c}, which are the left vertex of the triangle, thetop vertex and the right vertex respectively, with a < b < c.

triangle(x; a, b, c) =

*++,

++-

0 , x * ax#ab#a , a * x * bc#xc#b , b * x * c0 , c * x

triangle#1(y; a, b, c) = y(b& a) + a ) & y(c& b) + c

A.2 Trapezoidal Membership Function

This type of function is similar with the triangle but instead of a top vertex, we have aplateau, so four parameters are needed to define each vertex of the trapezoid, a, b, c, d.This membership function is represented in the figure 2.2(b).

trapezoid(x; a, b, c, d) =

*++++,

++++-

0 , x * ax#ab#a , a * x * b1 , b * x * c

d#xd#c , c * x * d0 , d * x

trapezoid#1(y; a, b, c, d) = y(b& a) + a ) & y(d& c) + d

79

80 APPENDIX A. MEMBERSHIP FUNCTIONS TYPES

A.3 Gaussian Membership Function

This type of membership function reflects a Gaussian distribution with a center in c anda width of (. This membership function can be seen as a smoothness of the triangularmembership function.

gaussian(x; c,() = e#12(x"c

!)2

gaussian#1(y; c,() = (.

&2ln(y) + c ) & (.

&2ln(y) + c

A.4 Bell Membership Function

The Bell membership function is also called Cauchy membership function due to thedirect generalization of the Cauchy distribution used in probability theory. The Bellmembership function is represented in figure 2.2(d) and has as parameters {a, b, c}. Theparameters c and a can be changed to vary the center and the width of the bell respec-tively while the parameter b is used to adjust the slope of the curve as well as the itsshape. If b has a negative value the bell becomes an upside down.

bell(x; a, b, c) =1

1 + |x#ca |2b

bell#1(y; a, b, c) = c+ a 2b

/1

y& 1 ) c& a 2b

/1

y& 1

A.5 Sigmoidal Membership Function

This type of membership functions represents a sigmoid that can be open left or openright. This property can be achieved by the parameter a, if it is negative the curve is openleft while if it positive the sigmoid is open right. The other parameter c is the crossoverpoint of the function, which is the value xwhere the membership function’ output is 0.5.

sigmoid(x; a, c) =1

1 + e#a(x#c)

sigmoid#1(y; a, c) =ln(1#y

y )

&a+ c

placeholder

Documents

UNIVERSIDADETECNICADELISBOA´ INSTITUTO SUPERIOR …€¦ · Keywords: Building Automation Systems , Behaviour Speciﬁcation , Fuzzy Logic , Fuzzy Control Systems , Fuzzy Contexts