POLITECNICO DI MILANO
Industrial and Information Engineering
Department of Electronics, Information and Bioengineering
AUTOMATED RULE CONFLICT DETECTION FOR BUILDING MANAGEMENT SYSTEMS
Relatore: Prof. Matteo Giovanni Rossi
Tesi di laurea di: Davide Camurani Matr. 841977
A.A. 2015/2016
Sommario
L’Internet of Things (IoT) è considerato uno dei cambiamenti più profondi dell’era moderna, esso ha portato la possibilità di poter connettere oggetti di uso comune alla rete, e di raccogliere enormi quantità di dati. Uno dei campi di applicazione, che ha avuto il maggiore sviluppo nell’ultimo decennio, è quello degli smart building. Gli smart building più moderni sono composti da centinaia di dispositivi in grado di raccogliere informazioni dall’ambiente (tramite i sensori) e di modificarne il suo comportamento (tramite gli attuatori).
La loro coordinazione è gestita da un Building Management System (BMS) che definisce come agire sul comportamento del sistema, in base ai dati provenienti dal sistema stesso. Le scelte che compie un BMS vengono delineate tramite delle regole; tali regole utilizzano una logica di programmazione del tipo trigger-action: se la condizione di attivazione è verificata, allora viene eseguita l'azione ad esso collegata. L’evoluzione dei dispositivi ha portato con sé anche una maggiore semplicità di utilizzo, permettendo ad utenti senza elevate conoscenze tecniche di poter creare la propria rete di sensori e attuatori, e di definire delle regole di controllo. Essendo questi sistemi utilizzati da più persone contemporaneamente, nasce la necessità di verificare se le regole create possano generare conflitti tra loro; questa possibilità nasce dal fatto che utenti diversi, desiderino comportamenti diversi dallo stesso sistema. Con il termine conflitto vogliamo definire tutti quei casi in cui i dati, che il BMS vuole imporre su un parametro di un attuatore, siano inconsistenti. A tale scopo, sono disponibili alcuni
III
strumenti di diagnostica che ci permettono di rilevare e in alcuni casi di risolvere, i possibili conflitti. Tali strumenti sono utilizzabili solo per realizzare controlli run-time, quindi non ci permetto a priori (durante la fase di design del sistema) di rilevare possibili comportamenti pericolosi.
In questa tesi abbiamo cercato di trovare una soluzione a questo problema realizzando uno strumento in grado di rilevare conflitti di tipo Error e Warning, con un approccio offline di analisi. I conflitti di tipo Error sono derivati dalla simultanea attivazione di due regole, mentre quelli di tipo Warning da una sovrapposizione dei periodi di attivazione di due regole. L’idea per la sua implementazione si basa sulla teoria dei Satisfiability Modulo Theories (SMT).
Infine, tale strumento è stato implementato in un programma atto a riprodurre virtualmente uno smart building; in particolare, le parti che abbiamo implementato sono: gli utenti, gli spazi che compongono un edificio, gli oggetti che vi possono essere all’interno e le regole che lo governano.
IV
Abstract
The Internet of Things (IoT) is considered one of the most profound changes of the modern era, it brought the possibility to connect everyday objects to the network and to collect huge amounts of data. One of the application fields which had the greatest growth in the last decade, it is the field of the smart buildings. Modern smart buildings are composed of hundreds of devices able to collect information from the environment through the sensors) and to modify its state (by the actuators).
Their coordination is managed by a Building Management System (BMS) that defines how to act on the behavior of the system, according to the data coming from the system itself. The choices made by a BMS are delineated by the rules; these rules use a trigger-action programming: if the trigger condition has verified, then the action associated with it is executed. The evolution of the devices has also brought greater ease of use, allowing users without advanced technical knowledge to be able to create their own network of sensors and actuators, and to define the control rules. Since these systems are used by several people simultaneously, it becomes necessary to check whether the rules created may conflict with each other; this possibility arises because different users may desire different behavior from the same system. With the conflict term, we want to define all those cases in which the data, which the BMS wants to impose on a parameter of an actuator, are inconsistent. For this purpose, there are some diagnostic tools that allow us to detect, and in some cases to solve, the possible conflicts. However, these tools are only used to realize real-time controls, therefore their not allow us to detect possible problems during the design phase of the system.
V
In this thesis, we tried to find a solution to this problem with an instrument able to detect the Error and Warning conflicts with an offline analysis approach. The error-type conflicts are derived from the simultaneous activation of two rules, while those of warning-type by an overlap of the activation period of the two rules. The idea for its implementation is based on the theory of Satisfiability Modulo Theories (SMT).
Finally, this tool has been implemented in a program that virtually reproduces a smart building; in particular, the parts that we have implemented are: the users, the spaces that compose a building, the objects can be inside and the rules governing it.
VI
Content
AUTOMATED RULE CONFLICT DETECTION FOR BUILDING MANAGEMENT SYSTEMS ...... I
RINGRAZIAMENTI ...... ERRORE. IL SEGNALIBRO NON È DEFINITO.
SOMMARIO ...... III
ABSTRACT ...... V
CONTENT ...... 7
FIGURE INDEX ...... 11
TABLE INDEX ...... 14
CHAPTER 1 INTRODUCTION ...... 15
1.1 OVERVIEW OF SMART BUILDINGS ...... 15
1.2 BUILDING MANAGEMENT SYSTEMS ...... 17
1.3 CRITICAL ISSUES AND CONTROVERSIES ...... 19
1.4 PROBLEM DEFINITION ...... 20
1.5 OUTLINE ...... 21
CHAPTER 2 STATE OF THE ART ...... 25
2.1 CONFLICT DETECTION APPROACHES ...... 25
Multi-Agent System Approach ...... 25
Interest/Intention Approach ...... 26
Policy-Based Approach ...... 27
7
2.2 CURRENT CONFLICT TOOLS ...... 27
Low-Level Approaches ...... 27
High-Level Approaches ...... 28
Discussion ...... 29
2.3 RULE STRUCTURE ...... 29
Trigger-Action Programming Techniques Analysis ...... 30
Basic and Advanced Structure of Rules ...... 31
2.4 FRONTENDS ...... 32
Samsung® SmartThings ...... 33
Apple® HomeKit...... 34
ETS by KoNneX® ...... 36
PC Access by HAI® ...... 37
CHAPTER 3 BACKGROUND ...... 39
3.1 SMT PROBLEMS ...... 39
Available SMT Solvers ...... 40
3.2 THE Z3 SMT SOLVER ...... 42
SMT-LIB ...... 43
Z3 Solver API ...... 46
CHAPTER 4 MECHANISMS FOR RULE MANAGEMENT ...... 49
4.1 OVERVIEW ...... 49
4.2 INFORMAL DESCRIPTION OF RULES ...... 50
Data Handled by Rules ...... 53
A Further Improvement: WIFTTT Model ...... 55
4.3 FORMALIZATION OF CONFLICTS AS SMT PROBLEM ...... 56
8
Conflicts Producing Errors ...... 56
Conflicts Producing Warnings ...... 59
Conflict Formalization Output ...... 62
4.4 SMT INPUT DATA IMPROVEMENT ...... 63
WHEN Filter ...... 65
ACTUATOR Filter ...... 66
4.5 POSSIBLE ADDITIONAL CONSTRAINTS ...... 67
Physics Simulation ...... 67
Actuators Environment Manipulation ...... 68
CHAPTER 5 DESIGN OF SMART BUILDING CONCEPTS ...... 71
5.1 OVERVIEW ...... 71
5.2 ACTORS ...... 72
Use Cases ...... 75
5.3 SPACES ...... 76
Security Levels ...... 78
5.4 OBJECTS ...... 80
Datapack ...... 81
5.5 RULES ...... 82
CHAPTER 6 IMPLEMENTATION ...... 85
6.1 PROGRAM OVERVIEW ...... 85
6.2 USER MANAGER ...... 87
6.3 SPACE MANAGER ...... 89
6.4 OBJECT MANAGER ...... 90
6.5 RULES MANAGER ...... 91
9
How to Add a New Rule ...... 92
How to Perform a Conflict Detection ...... 95
CHAPTER 7 CONCLUSION ...... 97
7.1 OBTAINED RESULTS ...... 97
7.2 FUTURE DEVELOPMENTS ...... 98
APPENDIX A JAVA CODE ...... 99
A.1 ERROR FORMALIZATION METHOD ...... 99
A.2 WARNING FORMALIZATION METHOD ...... 99
A.3 METHODS FOR MAKE ASSERTIONS ...... 101
A.3.1 Boolean Constraints ...... 101
A.3.2 Numerical Constraints ...... 101
A.3.3 Range Constraint ...... 102
A.3.4 Tristate Constraint ...... 102
REFERENCES ...... 103
10
Figure Index
Figure 1.1 - Standard IT Architecture of a Smart Building 17
Figure 1.2 – Centralized (a) and Distributed (b) BMS Architecture 18
Figure 2.1 – SmartThings App View 33
Figure 2.2 – MyHome App View 35
Figure 2.3 – ETS Program View 36
Figure 2.4 – PC Access Program View 37
Figure 3.1 – Z3: Core System Components 42
Figure 4.1 – Example of a Rule that Evolves in the Time 54
Figure 4.2 – WIFTTT Rule Concept 56
Figure 4.3 – Example of a Possible Simultaneous Activation Between Two Rules 57
Figure 4.4 –List of Sensor of Two Rules 58
Figure 4.5 - Sampling of The Time Horizon to Analyze 58
Figure 4.6 – Zones Which Define the Constraints to Apply on the Variables 59
Figure 4.7 – Possible Warning Condition between Two Rules 59
Figure 4.8 – Warning Detection Iteration 60
Figure 4.9 – Constraint Zones in Warning Detection 61
Figure 4.10 – Trend of the Number of SMT Problems in function of the Number of Rules the Acting on a Room 65
11
Figure 4.11 – Example of Two Rules Which Are Filtered by the When Filter 66
Figure 5.1 – Special Actions Allowed only to Administrators 73
Figure 5.2 – UML Scheme of the Users Typologies in the Model 74
Figure 5.3 – Spaces Structure Expressed Through Set Theory 76
Figure 5.4 - Example of the Structure of a Home 77
Figure 5.5 – Security Levels 78
Figure 5.6 – Example of a Security Level Assignment Based On the Roles 79
Figure 5.7 – Example of The Use of Security Levels 79
Figure 5.8 – Sensor Class 80
Figure 5.9 – DataPack Class 81
Figure 5.10 – Rule Class 83
Figure 6.1 – Program’s Logic Structure 86
Figure 6.2 – Main View of the Program 87
Figure 6.3 – Login Procedure: (a) Menu Button, (b) Login Popup 87
Figure 6.4 – Role Manager’s Menu 88
Figure 6.5 – User Manager (Admin View): (a) Menu Button, (b) User Manipulation Tab 88
Figure 6.6 – Tree Structure of a Building 89
Figure 6.7 – Add New Room Space Procedure 89
Figure 6.8 – Room’s Shape and Planimetry Visualization 90
Figure 6.9 – Objects Manager Menu Option 91
Figure 6.10 – Object Manager View 91
Figure 6.11 – Rules Manager Menu Option 92
12
Figure 6.12 – Rules Manager View 92
Figure 6.13 – Rule Editor View 93
Figure 6.14 – Editing Panels: (a) Trigger Event, (b) Actuator Setting 94
Figure 6.15 – When Condition’s Editing Panel 94
Figure 6.16 – Rule Editor View: Rule Defined 95
Figure 6.17 – Offline Analysis Results: Error Conflict 96
Figure 6.18 - Offline Analysis Results: Warning Conflict 96
Figure 7.1 – System Interfacing Menu 98
13
Table Index
Table 2.1 – Basic and Advanced Requirements of a Rule 32
Table 3.1 – List of the Most Used SMT Solver in Last Years 41
Table 5.1 - Action Allowed per User Typology (Part 1 of 2) 75
Table 5.2 – Action Allowed per User Typology (per 2 of 2) 76
14
CHAPTER 1 INTRODUCTION
In this chapter we provide an overview about smart buildings. First, we define what the term “smart” means in this thesis and which are the main features of a smart building. Then we analyze the structure of the current building management systems and which are the most critical aspects of these systems, both from the point of view of their rule management and conflict resolution. Finally, we define the goals of this thesis.
1.1 Overview of Smart Buildings
Smart Buildings have been explored and developed over the last three decades, but they have gained more and more interest in the last few years, indeed the term smart has started to appear more frequently in roadmaps and industrial reports [21].
Having a clear statement of what a smart building is within this thesis is a fundamental step, since the term smart has not a shared meaning for all the different stakeholders interested in this topic [20]. In fact, the potential final users could call smart a building that can be remotely accessed to turn devices on and off. Otherwise, from the researchers and IT experts point of view, a building is smart when it is responsive to its inhabitants and it is able to adapt autonomously in sophisticated ways, e.g., using intelligent machine learning algorithms to predict user occupancy and control the heating system.
15 Chapter 1
In our thesis we define smart a building that permits the cooperation between objects (e.g., sensors, devices, appliances) and systems that have the capability to self-organize according to some policies [19] and which are able to deal with different fields.
In particular, it should guarantee:
. The users comfort: that means improving the wellness of the occupants of a building by controlling different aspects of the home environment as: the temperature, the humidity, the brightness, the air quality of the ambience and so on.
. The user safety: that means improving the user security both in case of system failures (fire, short circuit, etc.) and in case of intrusions.
. The energy efficiency: that means reducing the waste (e.g., do not irrigate if is raining) and use the resources as economically as possible (e.g., do not cool an empty room) without impacting negatively on the user experience.
. The user life: that means adapting the system’s behaviors in way to meet the user’s needs.
From a technological point of view, a smart building is a distributed control system, where dozens of modules [19] are exploited to increase the safety, the comfort and the efficiency of the construction itself. The Figure 1.1 shows a basic scheme of the standard IT architecture of a smart building.
The standard IT architecture of a smart building is divided into several parts. In the lowest level part of the structure, we find the hardware level that includes: a network of sensors, which are distributed throughout the control area and that collect data, and a network of actuators, which change the behavior of the system. Sensors and Actuator networks interact with a controller called Building Management System (BMS, the middle layer of Figure 1.1) that, based on the information coming from the sensors, decides how acting on the actuators. Finally, in order to easily interact with this
16 Introduction
system, there is an additional level (the highest layer of Figure 1.1) that provides a communication interface between the user and the system.
Figure 1.1 - Standard IT Architecture of a Smart Building
1.2 Building Management Systems
As introduced in the previous section, the core of each smart building is its Building Management System (BMS).
A BMS, otherwise known as a Building Automation System (BAS), is a computer-based system that controls and monitors the building’s mechanical and electrical equipment, such as: ventilation, lighting, power systems, fire systems, and security systems.
Figure 1.2 shows two possible alternatives for the architecture of a BMS, these can be:
17 Chapter 1
Centralized: this type of structure has all the system components (sensors and actuators) connected to a single central module which control directly each element of the system. Even if this solution is simple to implement it suffers of a lack scalability and requires a central unit with a high-capacity computing.
Distributed: this type of structure has the main BMS connected to several gateways, which also implement the BMS’s capabilities, which manage the information coming from the sensors and actuators connected to them. The purpose of these gateways is to decentralize the decision process, in order to cut down the computational tasks performed by the main BMS. This kind of architecture has a much more complex design but it provides also a higher level of scalability and can manage larger buildings without the need of a central powerful machine.
Figure 1.2 – Centralized (a) and Distributed (b) BMS Architecture
18 Introduction
Gartner has predicted that a typical family home could contain more than 500 smart devices by 2022 [25], due to the lower price of the components and the users’ desire to expand the features of their buildings; indeed, the distributed architecture is the solution adopted in future systems.
1.3 Critical Issues and Controversies
In the current practice, the number of manufactures which produces hardware technologies for the smart buildings is increasing. Actually, we have different hardware solutions which we can use for transform a building into a “smart building”, at least from a theoretical point of view. Unfortunately, its implementation in a real context is not so simple; since the variety of home automation devices, in terms of both hardware variations and differences in the software running on them, makes the task of coordinate all these components very difficult. As a consequence of these differences, the field of home automation suffers from platform fragmentation and lack of technical standards.
Furthermore, a smart home is comparable to an amorphous computational system. With the term amorphous computing we refer to computational systems that use very large numbers of identical, parallel processors each having limited computational ability and local interactions [22]. As amorphous computing, a smart home can be composed by dozens of sensors and actuator which are characterized by: limited memory and computational capabilities, and a lack of knowledge of the system in which they are positioned.
Since sensors and actuators are unable to understand their purpose within a system, it is necessary to define management policies. The coordination of all these rules is not trivial; moreover, the rule creation is no longer carried out by a limited number of technical people, but it can involve more and more people with different backgrounds and know-how. In addition, involving more users in the rule definition introduces the possibility to generate
19 Chapter 1
conflicts, due to the fact that each user defines the rules with different purpose. This possibility increases especially in a shared environment. In conclusion, these problems must be recognized by the system.
Currently, there exist different tools that allow the system designers to verify possible inconsistent states, but they can work only at run-time, hence only after that the system has been deployed (see Section 2.1). Besides, in order to verify beforehand if some rules do not affect negatively the user’s experience, these approaches are not sufficient.
Finally, the survey of frontends presented in Section 2.1 shows that current BMSs do not provide any solution to carry out a preliminary investigation of possible conflicts.
1.4 Problem Definition
The discussion above highlights that a first problem concerning BMSs regards the definition of models which describe all the different aspects of a smart building. In particular, we need to define a model for:
. The spaces: it is necessary to define a space manager which allows the system designers to describe the physical structures that compose a building.
. The objects: the use of different brands also leads to create a model with a high level of abstraction so as to be able to describe the greatest number of objects; moreover, it is necessary to define an object manager that allows system developers to organize objects based on their physical locations and not on the network structure.
Then, as shown in Section 1.3, it is no longer possible to assume that only few users with technical backgrounds interact with the system. This requires to model a further element:
. The users: we need to identify who is manipulating the system and the role that (s)he has in it.
20 Introduction
Furthermore, since a smart building autonomously decides its behavior, and, consequently, it influences the life of its occupants, people are generally worried about the fact that their life is strongly influenced by something they cannot understand or directly control. It is then necessary to simplify the human-machine interface of smart buildings in order to allow people, even without a technical background, to interact with the control system.
Finally, it is necessary to find the right abstraction level for the policies’ model which control a system, in order to be compatible with the rule’s structure of the current service providers. Moreover, the rule definition process must be simple and intuitive, since, as demonstrated in [26], inexperienced users are not able to directly interact with sensors and actuators (see also Section 4.1).
A first goal of this thesis is to develop an application that manages spaces, objects, users and rules and which permits designers to:
. define the physical structure of a building;
. manage the users who are part of it;
. define the position of objects in the system;
. define the rules which act on devices.
In addition, a second goal of this work is to realize a tool which, possibly in collaboration with the current run-time conflict detectors, allows system configurators to execute, at design time, a preliminary analysis of the system in order to find possible conflicts and behaviors that can negatively impact the user’s experience.
1.5 Outline
Given the concept and the problems exposed above, the next chapters provide an overview of the work done with this thesis. In particular, this thesis aims at realize a tool able provide a preliminary analysis of the system’s rules in order to avoid beforehand possible logic-based conflicts. Moreover, we aim
21 Chapter 1
also to implement this tool into an application which manages spaces, users, abject and rules.
In Chapter 2, we introduce the state of the art. The first part of this chapter is dedicated to an overview of the current detections approaches. Then we analyze the tools for the conflict detection by discussing their positive and negative features. Next, we proceed by considering the actual rule’s structure by defining the basics and advanced rules’ requirements. Finally, we analyze the current applications which allow users to interact with smart buildings.
In Chapter 3, we provide a theoretical explanation of the SMT problems and how they can be solved. Then, we introduce the tools which allow us to implement the techniques for the SMT problem resolution by discussing their pros and cons. Finally, we discuss about the Z3 solver, the one which we have used in our thesis, and how we can generate its input data.
In Chapter 4, the details about our approach for the conflict detection are introduced. First, we present how we have structured the rule model in order to satisfy the advanced requirements defined in the Chapter 2 and how their data are described inside our application. Then, we proceed by explaining the formalization procedure. Finally, we show some improvement0s for the conflict detection’s procedure.
In Chapter 5, we describe through the use of the UML language, how we have defined the other classes used in our application: Actors, Spaces and Object; and how they work together.
In Chapter 6, we show how we have implemented the elements defined in the Chapter 5. In particular, we describe the different managers which compose our application and how they permit to design the various parts of a smart building: users, spaces, objects and rules. Finally, we focus on the Rule Manager, especially on the procedure for the rule definition and on the use of the conflict detector.
22 Introduction
In Chapter 7, we report our conclusions about the obtained results respect the initial objectives defined in the previous section, and the possible future developing
23
CHAPTER 2 STATE OF THE ART
In this chapter we present a survey about the state of the art of smart building management systems. First, we focus on some frontends used for modeling and managing the system structures and the rules. After that, we concentrate on the rule structure by introducing the trigger-action programming technique. Finally, we describe a first approach concerning how detect and solve conflicts.
2.1 Conflict Detection Approaches
Since conflict resolution in smart environments is still a relatively new topic; this section introduces different theoretical approaches for the conflicts detection and resolution, which have been developed by the scientific community. By the term conflict, we define a case in which there is an inconsistency in the data of a system’s element.
Multi-Agent System Approach
A first technique for the conflict detection (and resolution) is based on the idea of treating a smart building as a multi-agent system.
Alshabi et al. [32] have proposed a solution where each system’s object can independently decide whether to cooperate or not with the other agents of the
25 Chapter 2
system. In case of conflict, the agents try to solve it by adopting one of these three negotiation strategies: arbitrary leader election, chaining or cloning (these strategies are detailed in [33]).
Jacak and Proll have proposed a heuristic approach [34]. In their solution each agent is able to: perceive and react to the environment, plan and execute an action and negotiate with other agents; this allows agents to coordinate their actions in order to achieve a common global goal, trying to avoid conflicts.
Interest/Intention Approach
This approach involves to define goals for each users and uses this information in order to avoid or resolve conflicts.
Tuttlies et al [38] define a conflict as a context change that leads to a state of the environment which is considered inadmissible by the user. Their solution is based on the information available in a database with a context model representing the environment state, and a database of conflicting situations.
Armac et al [39] propose to specify components as services, where each service consists of actions that denote state transitions on resources; then, the admissible state transitions are captured by an automaton associated with each resource. A conflict situation is detected when a service attempts to transition a resource from a state previously set by another service. Conflict resolution is handled by a rule-based mechanism and handled with priorities.
Park et al. [40] propose a dynamic conflict resolution scheme for resolving conflicts between different context-aware applications in smart environments, which incorporates users’ intentions and preferences. They model the user intentions and preferences as cost functions. Based on this information, the solution to a conflict is determined by minimizing the overall cost of all users’ cost functions involved in the conflict.
26 State of the Art
Policy-Based Approach
This types of approaches are the most modern, and those that are closer to the idea is smart building; they define a Rule as a description of a well- defined behavior, which the system runs in certain situations; actually the rules’ structure is based on the trigger-action programming; its details are analyzed in Section 2.3. Since different users, which have different intentions, interact with the system by creating distinct rules, the conflict possibility of conflict increase, especially in large-scale systems [8].
These resolution techniques are still not very advanced. The idea shared by them is a run-time approach that involves the users in the conflict resolution process, allowing them to define how the system should operate in case of conflict.
2.2 Current Conflict Tools
As introduced in the previous section, the conflict detection and resolution techniques in a smart building systems are based on two main ideas. The first does not involve the end-user during the resolution phase, we call the set of these solutions: Low-Level Approach; the second idea requires the end-user intervention, the set of these solutions is named High-Level Approach.
Low-Level Approaches
This category of tools resolve conflicts based on predefined settings, which are defined by the system designers that have not a priori knowledge of the system structure. In particular, all the following solutions are priority-based. Indeed, each action is characterized by a priority level and in case of conflict the ones with the highest priority is executed. Therefore, the user is not directly involved into the resolution procedure but can only decide beforehand the importance of an action respect to another.
27 Chapter 2
BACNet [28] is a data communication protocol for Building Automation and Control Networks. A data communication protocol is a set of rules governing the exchange of data over a computer network. The rules take the form of a written specification that spells out what is required to conform to the protocol. All the devices on a BACNet network can write to the writable properties of another device's objects, this can generate conflicting commands. The conflict resolving mechanism is based on a priority table. All the rules are sorted according to their importance then it is executed the one with the highest priority.
SensorAct [10] manages permissions through a combination of priority and guard-rules; it is a script that specifies validation conditions based on time, date, duration, location and the frequency of operation.
BOSS [11] treats each command as a transaction and save them in order of arrival (priority based on the order of arrival). Each transaction has a lease time during which actions are valid and can be executed. When the lease expires, a revert sequence restores the control of the system to the next scheduled controller. Actions may also be reverted on a partial failure, depending on the error policy.
Finally, BuildingDepot [27] proposes a solution similar to BACNet by incorporating a priority array and adding a conflict-default value, used as a fallback in case there are two or more users with the same priority level.
High-Level Approaches
Since the actual system’s models cannot fully describe the behavior of a smart building, a better approach for the conflict resolution is to involve the users into the resolution process itself, thereby taking advantage of his/her greater knowledge of system.
CARISMA [12] supports runtime dynamic policy conflict detection and resolution. Conflicts are defined as the inconsistencies that arise when contradictory behaviors are requested by the same application as a reaction
28 State of the Art
to a context change, or when cooperating applications don’t agree on a common behavior to be applied. Its creators argue that conflicts cannot be resolved statically at the applications’ design time, but rather need to be resolved at run-time by the user.
Discussion
From the analysis above, we can assert that the choice of the approach to use is based on the decision to include or not the end-user during the resolving procedure. Moreover, the above approaches do not find a permanent solution to the conflicts such that they cannot happen again, but they only avoid that the system does not have inconsistent data in case of conflict. Another important point is the fact that both approaches are run-time so, they do not allow us to perform a preventive analysis of the possible conflicts.
A better approach is to define an offline solution, that can be executed without a running system. In this way, errors can be found in advance and not only when they occur.
Another aspect that should be improved is the interaction between users and solver. As mentioned in Section 2.2.2, the users know better the behavior of the system with respect to the model, so their intervention in the resolution of a conflict must be more incisive; moreover, it would be useful to direct the user to a possible solution.
The approach implemented in this thesis follows the idea to analyze pairs of rules that govern the same environment, and based on their information (described in Section 4.1), it defines a SMT problem with the objective to verify if there exists at least one case in which the rules are in conflict.
2.3 Rule Structure
The initial technologies, that enable home automation and smart homes, have been around for decades, they have been expensive and complex [4]. As
29 Chapter 2
a result, smart homes have mostly been embraced by a small community of affluent and technically proficient early adopters [5]. In the last years, however, companies have begun to market “smart devices” to average consumers at much lower price points. As a result, an increasing number of users have the possibility to create their own smart systems. Moreover, as shown in Section 2.4.1 and in Section 2.4.2 the tools, which are used for define the system behaviors, are becoming more and more easy to use, simplifying the interaction with the end-users. The logics behind these programming tools often takes the form:
If trigger Then action which we define as trigger-action programming.
Trigger-Action Programming Techniques Analysis
Despite the literature and nascent real-world implementations of trigger- action programming for smart devices, a key question remains. Where should we find the balance between expressiveness and ease of use? For example, IFTTT [7] restricts users to a single trigger and single actions. Do users need more flexibility? Can they handle more flexibility? Does additional programming experience change this equation? Are important elements missing from the model?
All the above questions have been analyzed. Based on a study conducted on a sample of 318 workers on Mechanical Turk [6], we can try to find the answers to previous questions. The study has evolved in these steps:
STEP 1: In way to determine whether trigger-action programming captures smart-home behaviors that users actually desire, they have investigated the following hypotheses about smart-home behaviors:
. H1: Many desired behaviors for a smart home are expressible using trigger-action programming;
. H2: Some behaviors require multiple triggers or actions;
30 State of the Art
Unlike the affordances of IFTTT, 22% of programming behaviors required more than one trigger or action. This result means that the one-to-one rule’s structure is not sufficient flexible.
STEP 2: With to purpose to test whether customizability is even necessary for smart home programming, they have investigated the following hypothesis:
. H3: In practice, users combine triggers and actions in a large number of unique ways;
From this step they have been able to define that the complexity of the rules created is highly diversified.
STEP 3: Participants were randomly assigned to use either an interface that supports only a single trigger and a single action (simple interface) or one that supports multiple triggers and multiple actions (complex interface). Then, they have investigated the following hypotheses:
. H4: Participants perform with equivalent accuracy and speed using either the simple or complex interface;
. H5: Prior programming experience and experience using trigger- action programming increase speed and accuracy;
They found no significant differences in participants’ performance or satisfaction between the simple and complex interfaces, supporting H4. Furthermore, participants using the complex interface were able to complete complex tasks at a similar rate of success. H5 was only partially confirmed; programming experience did not provide a significant advantage.
Basic and Advanced Structure of Rules
Based on the observations of the strong and weakness points of the main service provider’s solutions (see Section 2.4) and the results of the study discussed in the previous section, we have concluded that use the classical
31 Chapter 2
form of IFTTT logic is not always sufficient to describe the rules that control our system.
In way to define a starting point for our rule model, we need to delineate the basic requirements that must be satisfied by the rules. Moreover, we define also the advanced requirements that the rule model should reach in order to satisfy even more complex problems and provides more flexibility and freedom action to user.
The following table collects the basic and advanced requirements for different rule’s attributes.
Field Basic Advanced *Number of Elements One-to-One Many-to-Many **Time in which the Rule is Active Only one Range Multi Range ***Behavior of the Rule Instantaneous Dynamic Trigger Event Single Data Multi Elements Table 2.1 – Basic and Advanced Requirements of a Rule
* It indicates how many sensors and actuators are involved in the rule.
** It indicates the time periods in which it is possible to make the rule valid.
*** It indicates whether the result or event control of the rule trigger is instant or can evolve.
2.4 Frontends
In this section we analyze some programs that allow users to have almost a full control of every aspect of their home, such as: energy management, lighting control, security, entertainment, watering and so on.
In order to define how the current service providers on the market have structured their solutions. In the following, we have analyzed four different applications: two of these are mobile applications, while the other two are desktop solutions which are adapt to more professional purpose. These choices were made in order to analyze the simplicity of the mobile applications, and how complex projects are handled in the most professional solutions.
32 State of the Art
In order to define a rule’s model, which can be compatible with the larger number of existent solutions, a particular attention has been given to the analysis of the rule’s structure. Moreover, we analyze also the system’s model in order to also define a structure for our program.
Samsung® SmartThings
SmartThings [1] is building an open platform for smart building management developed by Samsung®.
(a) (b) (c) Figure 2.1 – SmartThings App View
The SmartThings native mobile application allows users to control, automate, and monitor their home environment using their mobile device. The area called “SmartSetup” into the app, that is accessible from the app's dashboard, facilitates the procedure that allow the users to add a new device. Customers can use the app to connect multiple devices through the use of an “auto-search procedure” or follow a dedicated path to configure one device at time.
33 Chapter 2
The devices compatible with the SmartThings’s app are: motion sensors, presence sensors, moisture sensors, locks, electrical outlets, garage door openers, speakers and thermostats.
The user interface of the program is very simple and intuitive. Through the "My Home" view (Figure 2.1 (a)) you can see the rooms list of the system; and, by pressing the menu button on the top right corner, is possible to add new rooms. Moreover, a user can be added through the menu called “Family”. The items connected to the system can be chosen using the “Marketplace” view (Figure 2.1 (b)) and assigned to a specific room.
This solution does not permit directly to setup rules; this procedure is possible through the use of third-part applications installable from the menu “SmartApps”. Some routines, which contains a list of commands, can be created in way to define lists of commands to execute quickly by clicking the corresponding routine icon (Figure 2.1 (c)). Finally, we have noted that any conflict detector is implemented.
Apple® HomeKit
HomeKit [2] is an app developed by Apple®. Users can control and configure the connected accessories in their homes, regardless of the manufacturer. The app helps the users in the following tasks:
. Setting up a Home;
. Managing users;
. Adding and removing sensors and actuators;
. Defining Scenes;
34 State of the Art
Figure 2.2 – MyHome App View
The HomeKit space structure is based on three type of locations: Rooms, Zones, and Homes. In particular, the rooms, such as "Living Room” or “Bedroom,” are the main space descriptors and they may contain any number of sensors and actuators. Moreover, zones are collections of Rooms, such as “Children Rooms”. All the rooms and the zones (optional) are contained within a home. Users must specify at least one Home to use as base location of their accessories.
Regarding the user managing, the app provides different ways to manage them, in particular, the admin can decide who is allowed to control the accessories in a home. When a new account is added to a home, the account holder is able to adjust the characteristics of the accessories. Moreover, when an account holder is specified as an admin, it is also able to add new accessories, set up homes and spaces, and create scenes.
The application automatically searches for new accessories and present them in the main program view. The configuration of a new element includes
35 Chapter 2
assigning a name, home, room, and optionally a zone. In way to conclude the adding procedure an admin must enter the accessory’s setup code (included with the hardware documentation or packaging).
Finally, the settings of new rules follow the IFTTT logic (see section 2.3). Also in this case, a conflict detector is not present.
ETS by KoNneX®
ETS stands for Engineering Tool Software; this program is a manufacturer independent configuration software tool, used to design and configure intelligent home and building control installations based on the KNX technology [3].
Figure 2.3 – ETS Program View
As shown in Figure 2.3, this program has not a user-friendly GUI due to the fact that it was created for expert user and for business purpose. On other hand, it permits to define more settings respect the previous mobile applications.
The building structure is composed by buildings, floors and rooms; rooms are contained into a floor, then, a set of floors is contained into a building. Inside
36 State of the Art
each one of this spaces, is possible to set up different objects. The information related to each element, that can be added into the project, comes from an internal database. These elements can be edited in way to setting up: name, address, location, connection type and many other data.
In the program is not present a user manager.
The procedure for defining a new rule appears complex and not intuitive for novice users, but, as in the previous cases, the logic behind them is the trigger- action programming. Also in this program, a conflict detector has not been implemented.
PC Access by HAI®
PC Access is the software used to program all HAI Omni and Lumina family home control systems. It provides to us different features as: a user set up, the programming and monitoring appliance over a network, serial or modem connection.
Figure 2.4 – PC Access Program View
This program allows users to manage very larger project. Strong points of this program are: the user manager and the rule creator.
37 Chapter 2
Regarding the user manager, it is important to denote how the users are descripted. Each user is characterized by particular attributes that define their personal routine and preferences. In particular, a user is described by personal data, many numerical data (e.g. preferred temperature or preferred humidity level), times data related to personal routines (e.g. working hours), dates (e.g. birth date), days of the week (e.g. define the free days), etc.. All this information can be used during the rule definition for programming wake-up times, lighting scenes, comfort temperatures and other conditions in way to improve the user comfort. Each of these user settings can then be easily modified by the user.
Concerning the rule creation, it consists of several features and structures that allow you to take full advantage of the powerful programming capabilities of this solution. In particular, the rules:
. May have multiple triggers, multiple conditions, and multiple actions;
. Can be triggered cyclically by defining a period of time which can last minutes, seconds or hours;
. Conditions can be created by using Boolean operator;
. Conditions can reference properties of zones, units, thermostats, temperature/humidity sensors, messages, security status, time/date, audio, access control, constants as well as user settings.
As in the others programs, also this application does not offer a diagnostic tool.
38
CHAPTER 3 BACKGROUND
In this chapter we introduce the concept of decision problems, in particular we discuss the SMT problems. Then, we give an overview about the actual SMT solvers and their resolution techniques. The second part is focused on the Z3 solver: we provide a description of the tool and an explanation of how define its input data through the use of two different input methods.
3.1 SMT Problems
A Boolean Satisfiability Problem (denoted as SAT) is a problem which determines if there exists an interpretation that satisfies a given Boolean formula. In other words, it asks whether the variables of a given Boolean formula can be consistently replaced by the values TRUE or FALSE in such a way that the formula evaluates to TRUE. If this is the case, the formula is called satisfiable. On the other hand, if no such assignment exists, the function expressed by the formula is FALSE for all possible variable assignments and the formula is unsatisfiable.
Satisfiability Modulo Theories (SMT) generalizes SAT problems by extending to the first-logic equality reasoning, arithmetic, fixed-size bit- vectors, arrays, quantifiers, and other useful first-order theories.
SMT problems that use linear arithmetic (LA) will typically involve two types of variables: the traditional SAT (Boolean) variables as well as real-valued variables. An LA formula is defined as a collection of Boolean formulas where
39 Chapter 3
each literal is either a Boolean variable or a linear inequality over the real- valued variables.
The procedure for solve SMT problems is generally based on two levels. The background theory sentences are treated as SAT variables, which leads to a SAT problem that is solved with standard SAT solving techniques. When a solution is found for the SAT problem, the consistency of the set of sentences that were assigned to TRUE is tested by an external solver (depending of the strategy of the SMT solver). If this external solver finds this set inconsistent, it returns a subset of incompatible sentence that are turned into a clause that is added to the SAT problem. This process is repeated until a solution is founded or until the problem is considered unsatisfiable.
Available SMT Solvers
An SMT solver is a tool for deciding the satisfiability (or dually the validity) of formulas. Moreover, SMT solvers can be used in different applications, such as: extended static checking, predicate abstraction, test case generation, and bounded model checking over infinite domains, to mention a few.
Currently, many tools are avaiable to solve SMT problems. The Table 3.1 summarizes some of the most used SMT solvers. In particular, the first two columns of the table contain information about the platform: the name of the solver and the list of the compatible operational systems respectively. Then, the other columns define the features: the columns named "SMT-LIB", “CVC” and “DIMACS” indicate the compatibility of the solver with the corresponding languages, the column “Bulit-in Theories” shows which type of data can be handle and the last column defines for which programming language there exist an API.
40 Background
Platform Features SMT- Name OS LIB CVC DIMACS Built-In Theories API Rational and integer linear arithmetic, arrays, tuples, records, Linux, Mac inductive data CVC4 OS, Yes Yes types, bitvectors, C++ Microsoft strings, and equality over uninterpreted function symbols Linux, Mac C/C++, MathSAT OS, Yes Yes Python, Microsoft Java Partial Non-Linear MiniSMT Linux v2.0 arithmetic Empty theory, Linux, Mac Partial differences, linear OpenSMT OS, Yes C++ v2.0 arithmetic, Microsoft bitvectors Real and integer raSAT Linux v2.0 nonlinear arithmetic Uninterpreted Linux, Mac functions, linear SMTInterpol OS, V2.0 real arithmetic, Java Microsoft and linear integer arithmetic Linux, C/C++, OpenBSD, Partial Python, STP Yes Bitvectors, arrays Windows, v2.0 OCaml, Mac OS Java Empty theory, C/C++, linear arithmetic, Linux, Mac .NET, nonlinear OS, OCaml, Z3 V2.0 Yes arithmetic, Windows, Python, bitvectors, arrays, FreeBSD Java, datatypes, Haskell quantifiers, strings Table 3.1 – List of the Most Used SMT Solver in Last Years
41 Chapter 3
From the list of SMT Solvers, we filter those that are compatible with our working conditions: Java Environment and Microsoft OS. These conditions reduce the possible choices to the solvers: MathSAT [13], SMTInterpol [14], STP [15] and Z3 [16]. We have decided to use the Z3 SMT solver.
3.2 The Z3 SMT Solver
Z3 is a very popular SMT Solver from Microsoft Research. It is targeted at solving problems that arise in software verification and software analysis. Consequently, it integrates support for a variety of theories. Users can interact with Z3 by using either a textual format or a binary API. Three textual input- formats are supported: The SMT-LIB [17], the Simplify [18], and a low-level native format in the spirit of the DIMACS format for propositional SAT formulas.
Figure 3.1 – Z3: Core System Components
The structure of the Z3 integrates a modern DPLL-based SAT solver [35][36], a core theory solver that handles equalities and uninterpretable functions,
42 Background
satellite solvers (for arithmetic, arrays, etc.), and an E-matching abstract machine (for quantifiers). A schematic overview of Z3 is shown in the Figure 3.1.
Therefore, in order to meet the needs of this project we have decided to use the solution offered by the solver Z3 [16]. Moreover, this solution is continuously developed by different communities for improving its performance and compatibility, furthermore, it has always achieved high results into the SMT-competition of the last three years [29][30][31].
SMT-LIB
As introduced in the previous section the Z3 solver supports different input formats, in this paragraph we analyze the SMT-LIB format. This choice is due to the fact that this format incorporates all the theories that are handled by the other two.
In particular, the supported Z3 input format is an extension of the classic form and it is descripted by the SMT-LIB 2.0 standard [17]. In the following, we try to describe how create a basic script, by introducing the syntax of the most important commands that are used for define variable, functions and constraints. Then, we will use them in an example.
Let’s start from the declaration of variables and functions. The commands that consent the declaration actions are the following:
. declare-const: It is used for declare a new variable, the syntax of this command require to insert a name and a sort (type).
For example, the following code line declares a new integer variable named a:
(declare-const a Int)
. declare-fun: It is used to declare a new function; the syntax of this command requires to define a name, the parameters’ types and the returned type.
43 Chapter 3
As an example, the following line declares a new function named f which takes as input two parameters (one integer and one Boolean) and returns an integer value:
(declare-fun f (Int Bool) Int)
Note that the declaration of a function does not permit us to define the behaviors of the function itself. A function defined in this way is used into problems with a different purpose. In particular, the solver tries to search a function’s structure that can satisfy the constraints in which the function is used.
We proceed by introducing another way that can be used for create a function. This approach uses the command define-fun; through which it is possible to declare a function and to provide a definition for the function’s structure. For example, by recovering the form of the function f introduced in the last example, we define a function which returns 21 if the integer value and the Boolean value, passed as parameters, are equal to 21 and false respectively.
Before show the syntax of the command define-fun, it is necessary to introduce the ite (if-then-else) command, which has the following structure:
(ite (logic_condition) true_result false_result)
Now, we can define the function as:
(define-fun f ((x!1 Int) (x!2 Bool)) Int (ite (and (= x!1 11) (= x!2 false)) 21 0) ) Once defined how create variables and functions, we show how define the constraints that govern them. The command for introducing a new constraint is based on a single parameter. This command is named assert; its syntax is the following:
(assert (logical_condition))
Once defined variables and constraints, in order to check the satisfiability of the problem, we use the command check-sat; which returns a value equal to
44 Background
sat if the problem is satisfiable, unsat otherwise. In addition, if the problem is satisfiable, we can also use the command get-model, that shows which values were assigned to the variables. Moreover, in the case where we have declared (not defined) functions, the get-model command shows also how they have been initialized.
In the following, we show a basic script the can help the reader to better understand how define a problem through the SMT-LIB textual-format.
Example
The variables of the problem are composed by two declarations: the first is a variable (line 1), the second is a function (line 2). Then, we define two constraints: the first is related to the variable a, which must be greater than 10; the second is about the function, which must return a value lower than 100 when we pass as input a (can vary), and true (fixed). Finally, we ask to the solver if there is a solution to this SMT problem.
1. (declare-const a Int) 2. (declare-fun f (Int Bool) Int) 3. (assert (> a 10)) 4. (assert (< (f a true) 100)) 5. (check-sat)
The result of this problem is positive: the value sat is returned. In way to know which values have allowed to satisfy the problem, we add the command get- model; and we relaunch the script. The obtained result is:
(model (define-fun a () Int 11) (define-fun f ((x!1 Int) (x!2 Bool)) Int (ite (and (= x!1 11) (= x!2 true)) 0 0)) )
45 Chapter 3
Z3 Solver API
Since our application has been developed using the Java language, the previous input method cannot be used. In order to be able to create variables, function and constraints of a SMT problem in Java, we must use the Z3’s Java API.
On the line of the previous section, we introduce the main aspect of the problem construction through the use of the Java API. Below, we first introduce the main objects that are necessary. All the methods showed below have been used in our application (see Appendix A).
The object Context offers the main interaction with the solver. It permits define: a new solver, variables and constraints. The methods which we can call up from it and that need a particular attention are related to:
. The initialization of new solvers; in which we can choose between two methods:
mkSolver: this method is used for create a new solver, in other words, it permits to initialize an empty solver;
mkOptimize: similar to the previous one, this method initializes a new solver that can be used for solve problems which have an objective function (min-max problems).
. The variables and function definition, in which the methods are:
mkBoolConst: define a new Boolean variable;
mkRealConst: define a new Real variable;
mkFuncDecl: define a new Function.
It is also possible define other types of variables or create new ones, the three showed before are those used in the application.
. The logical conditions, we are able to create both logical and mathematical conjunctions:
46 Background
mkAnd, mkOr, mkNot: define logical conjunctions;
mkEq, mkGe, mkGt, mkLe, mkLt: define mathematical conjunctions.
All the previous conjunctions can be concatenated; in this way it is possible define any type of constraint.
In way to better understand how handling these methods, we use them in an example by comparing the java code with the syntax introduced in the previous section.
Example
In this example, we define a problem that contains two integer variables, and , and three constrains. The goal is to maximize the values of the two variables. The problem, in mathematical form, is: + = 10 ≥0 ℎ , ∈ℤ ≥0
The Java source code for defining this problem is the following: 1. //Define an optimization problem 2. Context ctx = new Context(); 3. Optimize opt = ctx.mkOptimize(); 4. 5. //Define the variables 6. IntExpr xExp = ctx.mkIntConst("x"); 7. IntExpr yExp = ctx.mkIntConst("y"); 8. 9. //Define the constraints 10. opt.Add(ctx.mkEq(ctx.mkAdd(xExp, yExp)),ctx.mkInt(10))); 11. opt.Add(ctx.mkGe(xExp, ctx.mkInt(0))); 12. opt.Add(ctx.mkGe(yExp, ctx.mkInt(0))); 13. 14. //Set objectives functions 15. Optimize.Handle mx = opt.MkMaximize(xExp); 16. Optimize.Handle my = opt.MkMaximize(yExp); 17. 18. //Print on the console the results 19. System.out.println(opt.Check()); while, the SMT-LIB source code is
47 Chapter 3
1. ;Define the variables 2. (declare-const x Int) 3. (declare-const y Int) 4. 5. ;Define the constraints 6. (assert (>= x 0)) 7. (assert (>= y 0)) 8. (assert (= (+ x y) (10))) 9. 10. ;Check the satisfiability, and find the max of x and y 11. (check-sat) 12. (maximize x) 13. (maximize y) the result of this problem exists, so the problem is satisfiable. The output showed are the same for both the problem and equals to:
sat (model (define-fun y () Int = 10 10) ↔ =0 (define-fun x () Int 0) )
48
CHAPTER 4 MECHANISMS FOR RULE MANAGEMENT
In this chapter we introduce the concept of rule: describing its features and information that brings with it. Next, we explain how we have formalized conflict resolution in the form of a SMT problem. Finally, we analyze the constraints that compose these problems.
4.1 Overview
As introduced in Section 2.2.3, the current solutions are limited to the decision to include or not the user in their resolution process. In addition, these solutions are designed to perform only a run-time analysis, whereby; we cannot perform an offline analysis. Moreover, these approaches do not find a permanent solution to conflicts but only prevents an inconsistency in the system’s data; therefore, the same problem may occur again. By analyzing the limits of the current conflict detectors, we have decided to create a tool that can perform a conflict detection at design level.
Then, we have delineated two goals of our solution:
1. Since the actual solutions capture a data inconsistency only when they happen (run-time approach), some potential conflicts may not be detected due to the fact that the triggering of a rule depends on the system, which we cannot directly control. An approach that identifies potential conflicts before they happen enables us to avoid all the
49 Chapter 4
harmful situations beforehand (offline approach) and does not require a running system.
2. The conflict resolution technique should involve users; in particular, by informing them of the problem and by allowing them to add or change rules.
In the first part of this chapter we explore the concept of Rule, by describing how we have evolved its structure and the data that describe it (see Section 4.2). In the Section 4.3, we analyze the formalization process, by defining the variables and constraints that compose the SMT problem. Finally, in the Sections 4.4 and 4.5, we show some possible improvement and additional features.
4.2 Informal Description of Rules
In this section we show how we have modeled the Rules. Starting from the form introduced in the section 2.3, we have enhanced it in order to satisfy more advanced requirements (see Table 2.1).
The starting model is the IFTTT, which is characterized by the following features:
. One trigger event
. One action (also called actuator setting)
. Enabled in a single period of time
. Static behavior
The simple structure of these policies allows users to easily create basic control rules even without an advanced knowledge of the trigger-action programming. However, even if the simple structure of the rules allows users to easily define rules, it is more complicated (or impossible) to implement a resolution process that does not involve the deleting of one of the two conflicting rules.
50 Mechanism for Rule Management
As an example, considering the following rules acting on the same room, which are defined using the IFTTT logic:
“If someone in the room then turn on the light”
“If brightness is sufficient then turn off the light”
These two rules might conflict when a person enters the room and this is lit. The most intuitive solution is to add the trigger “and the room is dark” to the first rule, but it is not feasible for this model.
Therefore, we need to increase the number of sensors and actuators which compose a single rule. In this model, the features of a rule become:
. n trigger events
. n actuator settings
. Enabled in a single period of time
. Static behavior
In particular, the increased number of trigger events allows us to extend the complexity of the rules and give more flexibility to the users without affecting their experience [6].
On the other hand, the increasing number of actuator settings has been necessary to avoid redundancy of rules. For example, if in a room there are multiple light points, with the previous model of rule it would have been necessary to define one rule for each lamp, which are characterized by the same triggers; increasing the number of actuators allows users to create only one rule that controls all lamps (as actuators). Moreover, also this improvement gives more flexibility to the users and reduces the number of SMT problems to formalize.
51 Chapter 4
Using this model, it is possible to solve the conflict of the previous example, obtaining the following rules:
“If someone in the room AND the room is dark then turn on the light”
“If brightness is sufficient then turn off the light”
After extending rule patterns as above, we pursuit the following research questions: is the level of abstraction of our model enough? Can it satisfy the structure of the rules implemented in modern systems?
At first, the answer was yes, but with the creation of increasingly complex rules we have realized that conditions and settings like
“If someone is in the room for 10 minutes then …” or
“If the window is open for at least 15 minutes then …” or
“… then keep the light on for 30 minutes” or
“… then keep the AC on for 10 minutes”, could not be controlled using the current rules model.
Therefore, it has been necessary to further refine the rule model by introducing new parameters that specify a range of time, both for the trigger events and actuator settings.
For the trigger events, this time value indicates for how long the related trigger event’s condition must be satisfied before it can be considered verified. Instead, for the actuator setting, the time value identifies how long we want that this setting remains active after its activation.
Consequently, in this third form, the features of the rules are:
. n trigger events;
. n actuator setting;
. Enable in a single period of time;
52 Mechanism for Rule Management
. Dynamic behavior;
These rule patterns allow the system developer to define dynamic conditions and settings, and not only instantaneous changes.
Some examples of rules definable with this model are:
“If the window is open for 10 minutes then turn off the heating”
“If someone is in the room then keep the light on for 30 minutes”
Data Handled by Rules
Since the final rule model defined above embeds differ kinds of data, before introducing the encoding techniques for the SMT problem formalization it is necessary to have a clear statement of what is a rule. In particular, in this section we provide: a description of the trigger events and the actuator settings which compose a rule, a description of the data which describe a rule and a definition of two sets which will be useful for the subsequent formalization procedure.
A rule is made up of trigger events and actuator settings. An actuator setting (AS) describes the action that manipulates the system status; in particular, it describes the value to be imposed to an actuator’s parameter and for how long this value must be held. Moreover, an AS is characterized by: an actuator that it is composed of different parameters, the value to impose on each parameter and a time duration. A trigger event (TE) describes the condition that must occur, before performing the corresponding ASs. In particular, a TE is characterized by: a sensor that it is composed of different parameter and a time duration. A further analysis of the rules is presented in Section 5.5.
Therefore, we define a rule as a tuple = 〈 , , , , , 〉 where:
. is the rule’s actuator set;
. , = , is a function which returns the setting value ∈ , ,
where , is the set of the possible values of , associated with a
53 Chapter 4
generic actuator ∈ and its parameter ∈ , where defines all
possible ;
. is the rule’s sensor set;
. , = , is a function which returns the trigger value ∈ , ,
where , is the set of the possible values of , associated with a
generic sensor ∈ and its parameter ∈ , where defines all
possible ;
. : → gives the range of time whereby a given condition must be verified to be considered validated.
. : → gives the range of time whereby a particular setting must remain valid after the successful triggering of the rule.
The Figure 4.1 shows the evolution of a rule over time. The blue line and the yellow line identifying the evolution over time of the trigger events and the actuator settings respectively.
Figure 4.1 – Example of a Rule that Evolves in the Time
Then, we proceed to define two different sets. The first called Conflicting Actuator Settings pairs (CASp) and second named Overlapping Trigger Event pairs (OTEp).
The CASp set contains all the possible pair of actuator settings between two rules which use the same actuator parameter and which set different values for it. Hence, given two rules, and , we write:
= , | , ≠ , ∧ = (4.1)
54 Mechanism for Rule Management
The CASp set is used to recognize possible hazard situations and in the actuator filter explained in the Section 4.4.2.
Then, we define the OTEp as a set containing all the possible pairs of trigger events between two rules which use the same sensor parameter. Therefore, given two rules, and , we write:
= , | = (4.2)
The OTEp set establishes which trigger events are in common between two rules, this information is used during the constraint definition.
A Further Improvement: WIFTTT Model
Although the final model of rules was satisfactory, the range of time in which a rule is active remains static.
In order to expand the concept of the rule’s active time period, we have decided to develop further our rule model in way to obtain the called WIFTTT model, in which the activation period can change dynamically. This acronym is reflected in the concept:
When condition If trigger Then action
A condition can be defined by using: one or more sensors of the system, the classical day/time values or the building’s variable. If the condition is verified the program continues the control of the classical IFTTT part.
This new condition allows us to reach a higher level of abstraction and define rules that are enabled by the condition of the system and not only over a single period of time.
As examples:
“When outside is dark if someone is in the room then turn on the lights for 30 minutes”
“When the home status is AWAY if someone is in the room then turn on the hooter”
55 Chapter 4
Figure 4.2 – WIFTTT Rule Concept
4.3 Formalization of Conflicts as SMT Problem
In this section we analyze in detail the formalization process, defining how the trigger conditions of the rules are transformed into constraints for SMT problems.
The conflicts that are searched are of two types: Errors and Warnings. In this thesis, an Error-type conflict is defined as a simultaneous activation of two rule which trying to set different values on the same actuator’s parameter (see Figure 4.3). On the other hand, we define as Warning-type conflicts all that cases in which a rule becomes active while another, that is acting on the same actuator, is already imposing to maintain a different value (see
Figure 4.7).
The formalization process does not consider the WHEN clause because this condition manipulates the instants of time in which the rule is active; this information does not affect the conflict detection. Its use is explained in detail in Section 4.4.1.
Conflicts Producing Errors
In order to detect an inconsistency in the actuator data, we need to define an appropriate SMT problem which tries to generate a chain of assignments for the triggers’ variables, such that, it is possible to activate rules in the same instant.
In the set CASp defined in the Eq. (4.1) we have all the pairs of actuators which risk to generate an error between two rules. In the case where ∅ the two rules have not any actuator which can generate an inconsistency;
56 Mechanism for Rule Management
otherwise, it is necessary to proceed with the SMT problem formalization. The procedure for the definition of the set CASp is presented in Section 4.4.2.
If the search has a positive result, we will end up with one or more actuators which risk to have multiple settings simultaneously.
Figure 4.3 – Example of a Possible Simultaneous Activation Between Two Rules
We start the analysis of formalization procedure through the help of an example. We take two rules, X and Y, for which ≠ ∅. Each rule has a | | | | number and of trigger events respectively.
For each pair of trigger events inside the set (Eq. (4.2)), we need to determine a time horizon for which we define variables and constraints. The dimension of that time horizon will be the maximum between the maintaining times of the i-th pair’s trigger events. Therefore, taken , ∈ , , we define:
= max , (4.3)
All the trigger events that are not in common between the two rule are independent; since they are able to generate a chain of values, such that, their condition will be verified at the desired instant of time. As shown in the Figure 4.4, the sensor of type “Z” is not used by the rule B, it is independent and we can neglect it.
57 Chapter 4
Figure 4.4 –List of Sensor of Two Rules
Once defined the time horizon on which we operate; the next step is the discretization of the problem. The interval is sampled with periods of length equals to the minute (default sampling). The default sampling period has chosen relying on the fact that the smallest unit of time, in our system model, is the minute, but can be further divided into smaller parts (see Figure 4.5); this choice is left to the users.
Figure 4.5 - Sampling of The Time Horizon to Analyze
Then, we must create a new variable for each sample, which is shared between the two rules, and use them during the definition of the constraints. Before analyze which kind of constraints is possible to impose, we need to introduce a final concept. Therefore, we define two different areas (see Figure 4.6):
. ZONE 1: is the period of time, that start from until ; in which only one trigger event is active.
58 Mechanism for Rule Management
. ZONE 2: is the range of time that starts from until the moment of
the rule activation ( ). Here, both trigger events must be verified.
For each variable related to the zone 1, we must impose the constraints of the rule with the longest maintaining time, while the constraints of the other one can be avoided except for the first instant before the zone 2 ( in Figure 4.6), in which we must require that the constraints of the shortest rule are not verified to avoid a premature triggering. Moreover, for each variable related to zone 2, the constraints must be satisfied by both the rules.
Figure 4.6 – Zones Which Define the Constraints to Apply on the Variables
Conflicts Producing Warnings
As already discussed in Section 4.1, the actuator settings are described also by a holding time which define how long, from the moment in which the rule’s trigger condition is verified, the imposed setting value must be maintained. This option could create a conflict of the type Warning.
Figure 4.7 – Possible Warning Condition between Two Rules
Moreover, since the basic concept of a home automation system is to apply the rules’ settings according to the most updated information of the system, this allows, through appropriate controls, to create a system that aligns the status of its actuators to the variations of the environmental conditions. From
59 Chapter 4
this idea, such conflicts are managed as an alert, because their overlap may be good and wanted behavior by the system’s designers.
Let us present the formalization process through an example of two rules, X and Y, that for simplicity are characterized by:
| | | | = = 1
≠ 0, = 0 (4.4)
, ∈ ,
So, we want to verify if the rule Y can happen during the holding time of the rule X.
Figure 4.8 – Warning Detection Iteration
First of all, we have to define the time horizon on which we perform the formalization. Its characterization is slightly more difficult as in the error formalization because, in this case, this period of time changes dynamically as the search progresses with the progress of the search. As shown in the Figure 4.8 we need to iterate the procedure until we find at least a warning condition.
Then, taken a couple of trigger event , ∈ , the range of time that must be analyzed is:
= ∆ + max , − ∆ (4.5)
60 Mechanism for Rule Management
in eq. (4.5) Δ is the offset between the trigger instants of the two rules; it is defined as (see Figure 4.7).:
Δ = , − , (4.6)
In the case where Δ = 0, we fall back in the previous case (error search), whereas, if Δ > 0 we are defining the search of a warning. The variation of this value depends only on translating rule ( in the example above) which is dragged forwards of one step at each iteration. The dimension of a step is equal to the size of an interval between two samples.
Then, the period of time that must be analyzed has been define, we sample it as in the previous case (see Figure 4.5).
Consequently, we must create a variable for each sample, which is shared between the two rules, and define the constraints apply on them according to the working area, whose list (see Section 4.3), it is extended with a new zone (see Figure 4.9):
. Zone 3: this range of time starts from the trigger instant of the “fixed”
rule ( , ) until the trigger instant of the translating rule ( , ).
In this period of time, the constraints must be fulfilled by the translating rule while the fixed rule could impose environmental constraints due to its activation (see Section 4.5.2 for mode details).
Figure 4.9 – Constraint Zones in Warning Detection
61 Chapter 4
Conflict Formalization Output
The two previous formalization of procedures define the variables and constraints using the formalism introduced in Section 3.2.2. Moreover, a more detailed description of the Java code is provided in the Appendix A.
In the following examples, we show how acts the rules formalization process. We define two rules as:
“When Always If Temperature > 23° for 3 minutes Then Turn ON AC”
“When Always If Temperature < 25° Then Turn OFF AC” with a default sampling time.
First we apply the WHEN filter (see Section 4.4.1). In this case both rules are always active, and therefore have an overlapped period of activation. WHEN the filter is exceeded.
Then we apply the ACTUATORS filter (see 4.4.2). The set CASp contains only one pair, which is formed by the actuators of the two rules, both focused to the same parameter of the same object but with different settings. Since ≠ ∅, then there is a possibility of conflict Afterward, both actuator settings have holding times equal to zero, so we can only verify the occurrence of a conflict of the Error category.
We proceed by defining the set TECp, it contains a single pair, composed of sensors of the two rules, as both measure a temperature. For such pair, we define the time horizon:
= max 3,0 = 3
Since the sampling time is equal to 1 minute (default value), we define two variables: , and .
In , we are inside the zone 1. Only the first rule must be active, so we impose:
62 Mechanism for Rule Management
> 23
In , we are still in zone 1, but in the instant of time just before the zone 1. Hence, we must impose that the condition of the first rule is verified and that the condition of the second rule is not verified:
> 23 ∧ > 25
In , we are in zone 2, so both rule must be verified. We impose:
> 23 ∧ < 25
Finally, the set of constraints is equal to:
> 23 > 23 > 25 > 23 < 25
If we translate this problem with formalism introduced in Section 3.2.1, we obtain:
1. (declare-const tn2 Real) 2. (declare-const tn1 Real) 3. (declare-const tn Real) 4. (assert (> tn2 23) 5. (assert (> tn1 23) 6. (assert (> tn1 25) 7. (assert (> tn 23) 8. (assert (< tn 23)
4.4 SMT Input Data Improvement
As explained in section 2.3.1 and, we know that: the structure of a rule can be very complex and that a user can combine sensors and actuators in different ways creating unique rules. These causes a rapidly increase of the rule to be managed, especially into very populated building (as an office).
63 Chapter 4
By assuming that a room is controlled by rules. I first coarse way for check possible conflict is a brute-force approach. Then, the number of SMT problems that we must generate is:
= + (4.7) where the first term identifies the number of SMT problems constructed to identify a possible error and the second determines the number of SMT problems related to the research of possible warnings.
The amount of SMT problems that are necessary for the error-type conflicts is the combination of elements of class 2.
! − = = = = (4.8) , 2 − 2 ! 2! 2
Then, considering the worst case, we assume the all the rules have a ≠0 in at least one actuator, this condition force us to create two SMT problems for search of a warning-type conflict for each pair of rules, because we need to check if a rule does not create warning on another and viceversa. Therefore, we need to check:
! = = = − (4.9) − 2 !
Notice that the number of the SMT problems related to the warnings is not the real one, because, as explained in the Section 4.3.2, the procedure for the warning detection is iterative inside. To have an idea of the number of the minimum possible SMT problems we assume that the warning is found at the first iteration of the research.
Now, recalling the eq. (4.7), the total number of the SMT problems to implement is equal to:
3 = + = − (4.10) 2
This causes an exponential increasing of the number of SMT Problems that must be implement (see Figure 4.10).
64 Mechanism for Rule Management
Figure 4.10 – Trend of the Number of SMT Problems in function of the Number of Rules the Acting on a Room
In the following sections, we have tried to reduce the number of SMT problems by introducing some filters.
WHEN Filter
A first approach for reduce the number of SMT problems to be solved is to filter the rules using their when clauses (see 4.2.1). The concept behind this filter is simple:
“If two rules cannot be active in a shared period of time, then, they cannot generate a conflict.”
As example, we define two rules characterized by the following WHEN conditions, that for simplicity only using a period of time as data. Then, we analyze two different cases, which are described by the following information:
Case A Case B Rule A: from 08.00 to 20.00 Rule A: from 08.00 to 20.00 Rule B: from 03.00 to 07.00 Rule B: from 03.00 to 11.00
In the first case, the two rules have not a shared period of time (see Figure 4.11 (a)). Therefore, even if the actuator settings of the rules say to set different variable to the same actuator; it is useless to create an SMT problem for check an eventual conflict because it is not possible that the triggering of the two rules happens in the same instant.
65 Chapter 4
In the second situation, we have incremented the range in which the second rule is active. This change causes an overlapping between the periods of times in which the rules are active (see Figure 4.11 (b)). In this case, if the two rules share an actuator setting whit different setting values it is necessary to realize an SMT problem that searches possible conflicts.
(a)
(b)
Figure 4.11 – Example of Two Rules Which Are Filtered by the When Filter
ACTUATOR Filter
This filtering technique eliminates all those pairs of rules that meet the following conditions:
. The actuators used are all different.
. The actuator is the same but using different parameters.
. Actuator, parameter and value to impose are the same.
66 Mechanism for Rule Management
The first case is trivial, two rules which set values of different actuators do not generate conflict.
“… then turn on the light”
“… then turn off the AC”
The second, identifies those cases in which on the same actuator are imposed different values for different parameters.
“… then led’s RED level to 134”
“… then led’s GREEN level to 97”
The last case, is also trivial:
“… then set temperature to 24°”
“… then set temperature to 24°”
The search for these cases, it may be performed looking for its dual, which corresponds to CASp.
In conclusion, if the = ∅, then the two rules cannot conflicting and we can avoid to formalize a SMT problem that lead to a trivial solution. Otherwise, it is necessary to proceed with the formalization.
4.5 Possible Additional Constraints
Even if the model that we have defined for the rules is quite sophisticated the constraints imposed during the formalization are very simple. The following sections introduce some ideas for the definition of more complex constraints that allow us to represent more complex behavior of the system.
Physics Simulation
If on one hand our model is able to represent physical quantities of different nature, on the other they are not bound by any limits.
For example, we take the rule:
67 Chapter 4
“If the temperature is greater than 20° for 5 minutes then …”
From a mathematical point of view, its trigger condition can be verified by an infinite number of solutions. Let us take two particular cases:
. = 22°, = 26°, = 23°, = 23,4°, = 23,5°
. = 100,3°, = 100°, = 99,9°, = 100°, = 100,4°
In the first case, it is highlighted the fact that the variations from one variable to the next should be monitored. In particular, knowing that the maximum time frame between samples has a maximum of one minute, a change of 4° between the first and the second sample is not realistic; as the change of 3° between the second and third value. A first possible solution to this problem is to define constraints between values as:
| − | <
In the second case, the temperature values, even if they vary properly, are not compatible with values that can be found under normal conditions in a home. A solution can be to provide an upper limit (and lower limit) the all the variable as:
< 50°
Actuators Environment Manipulation
As introduced in Section 4.3.2, the procedure for detecting a Warning involves the introduction of a new zone called Zone 3. In this period of time one of the two rules is active. In particular, we know which actuators are acting on the system.
The idea is to define additional constraints deriving from the action that the actuators have on the system; in other words, we need to understand the effects that these actions have on the environment.
For example, if we are verifying a warning condition in which the active rule is the following:
68 Mechanism for Rule Management
“… then turn on the AC for 20 minutes”
Knowing that this rule is active, we can assume, that from the moment of its activation, it will affect the temperature data (or energy consumption). So, we can introduce additional constraints on the temperature trend in Zone 3, which must be a decreasing one. An example of possible constraints is:
− < 0, − <0, …
69
CHAPTER 5 DESIGN OF SMART BUILDING CONCEPTS
In this chapter we introduce the models which describe all the parts of a smart building. In Particular, we analyze: the actors which manipulate the system and the actions that they can perform; the spaces and the concept of security level; the objects and how we have described their data; and the rule model. Finally, we provide an overview of the software architecture.
5.1 Overview
In order to apply the formalization mechanisms introduced in the previous chapter we have made a program that allows us to create a virtual version of a smart building. This chapter describes in detail, using the UML formalism, the classes which form our system. In particular, we analyze: Users who have access to the system, the physical structure of the building, the objects contained in it, and the rules that govern it.
First, we analyze the actors' model. We have decided to define three different types of actors: Users, Administrators and Guests. In the Section 5.2, for each type of actor, we describe: its characteristics and the actions that it can perform in the system.
71 Chapter 5
In the Section 5.3, we introduce the models that describe system’s areas: Buildings, Floors and Rooms. In addition, we introduce the concept of security levels that allows us to reduce the possibility of conflicts.
In the Section 5.4, we define the models for the sensors and the actuators. In particular, we formalize the parameter structure through the introduction of the Datapack concept.
Finally, the Section 5.5 resumes the concept of rule, introduced in Section 4.2, by defining its model.
In the next chapter, we show how the models are implemented and how they cooperate.
5.2 Actors
As stated in Section 1.4, modern smart buildings are used by an increasing number of people. The idea that a single entity with a complete knowledge of the system’s structure is acting on it, is no longer valid and implies to consider that a system is composed by different actors. In particular, in our application, we define three types of users: Administrators, Users, and Guests.
The Administrators are the main characters of the system. They have more freedom of action than the other two categories and are those who define the system’s structure, that the other two types of users can after use and customize. The Figure 1.1 shows the action permitted only to the Administrators.
72 Design of Smart Building Concepts
Figure 5.1 – Special Actions Allowed only to Administrators
We define then the class that describe the largest part of the system users, named User. These actors may or may not be expert, and they use (live or work into) the system in a continuous manner.
Lastly, we introduce the figure of the Guests. This type gives us the possibility to describe the external entities (guests, maintainers, etc.) which access the system for a limited period of time.
The data that describe these classes are:
. ID [String]: String that allows us to uniquely identify our user.
. name [String]: String that allows us to save the user’s name.
. surname [String]: String that allows us to save the user’s surname.
. userName [String]: String in which we save the user’s username used for to log into a project (access to a system).
73 Chapter 5
. password [String]: String in which we save the user’s password, which combined with the userName, allows the user to log into the project.
. role [String]: String that contains the role that the user has within the project (example Chairman, Employs, Dad, Child). That string is also used to define the access level that the user has into the project.
. accessLevel [int]: Level of access to the system; it is defined by the use of the role parameter, that it is converted into a numerical level by using a pre-defined table.
. expiringDate [Date] (only for guests): Date indicating the end of the period of access to the project.
Figure 5.2 – UML Scheme of the Users Typologies in the Model
74 Design of Smart Building Concepts
Use Cases
Once a user log into a project, the program evolves its structure according to the logged user’s type.
The Table 5.1 and the Table 5.2 shows the actions that can be performed in our program, highlighting, for each of the categories of actors who may or may not perform them.
Function Admins Users Guests Where Create New Project Y Y Y Open Project Y Y Y Save Project Y Y Y Main Close Project Y Y Y Window Login Procedure Y Y Y Open the User Manager Y Y Y
Change Name/Surname Y N N Change Y Y Y Username/Password Change Role Y N N Users Change Expiring Date - - N Manager View Other Users Y Y N Add New User Y N N Edit Users Data Y N N Delete User Data Y N N
Add/Delete Buildings Y N N Add/Delete Floors Y N N Add/Delete Rooms Y N N Edit Building Name Y N N Spaces Edit Floor Name Y N N Manager Edit Room Dimension Y Y Y Edit Room Polygon Y N N Change Room’s Y N N Security Level Table 5.1 - Action Allowed per User Typology (Part 1 of 2)
75 Chapter 5
Function Admins Users Guests Where Add/Remove Elements Y Y Y Edit Room’s Element Objects Y Y Y Name Manager Add Personal Elements Y Y Y
Add Rules Y Y Y Remove Own Rules Y Y Y Edit Own Rules Y Y Y Rules Remove Other Rule Y Y Y Manager Edit Other Rule Y Y Y Use the Conflict Y Y Y Detector Table 5.2 – Action Allowed per User Typology (per 2 of 2)
5.3 Spaces
The idea of the structure remembers the one of a matriosca (see Figure 5.4. Considering a single project as the outer container, inside it we find first the buildings; they define the most external physical structure. Inside it they are contained one or more floors which in turn contain one or more rooms. A single project can contain one or more buildings. In the following figure is show the structure of a generic project.
Figure 5.3 – Spaces Structure Expressed Through Set Theory
76 Design of Smart Building Concepts
Figure 5.4 - Example of the Structure of a Home
The rooms are the central point of the model. In particular, users can assign some objects to each of them, and use them to create rules.
The data that haracterize the rooms are:
. ID [String]: String that identifies the room uniquely.
. name [String]: String that contains the assigned room’s name which is displayed to the user.
. roomDraw [Polygon]: This object, contains inside it the coordinates of the polygon’s angles describing the shape of the room. These coordinates are used to draw the shape of the room in the floor layout, highlighting its position.
. securityLevel [int]: As the User class and its children, also the rooms are characterized by a level of security. In this way, we can limit the access to a rule to specific users, thus limiting the growth of possible conflicts during the creation of rules.
. dimension [Dimension]: New data type that contains all the information about the dimension of the room.
. sensorList [Sensor []]: List of sensor present in the room.
. actuatorList [Actuator []]: List of actuators present in the list.
. ruleList [Rule []]: List of rules acting on the room.
77 Chapter 5
Security Levels
As has already been introduced, we identify a security level for both users and rooms. These two data can be combined by administrators for limiting the access to certain rooms of the system.
As example, if in an office there is a room used as server room, we should ensure a certain temperature and humidity in order to maintain the equipment in a good working condition. Therefore, in order to avoid unsafe working conditions we can set a high access level to the server room, thus limiting the number of user that can modify its rules.
We have decided to introduce five different security level: from 0 to 4. Each room and each user is characterized by a security level.
Level 4
Level 3
Level 2
Level 1
Level 0
Figure 5.5 – Security Levels
In particular, the rooms’ security level can be edited only by the system administrator. Instead, the users’ security level is based on their role; each role has a corresponding security level, that can be customized.
78 Design of Smart Building Concepts
Figure 5.6 – Example of a Security Level Assignment Based On the Roles
In conclusion, we can use a simple comparison between the security levels of rooms and users in way to limit the number of people who can handle the rules of a room. In the Figure 5.7 we have an example of the use of security levels. We have two rooms: one with a security level equals to 1 (Server Room LV1) and one with a security level equals to 3 (Server Room LV3). The current logged user has a security level equals to 2; therefore, the access to the Server Room LV3 is not allowed.
Figure 5.7 – Example of The Use of Security Levels
79 Chapter 5
5.4 Objects
The modeling of objects that compose our system is a key part of our application. With the advent of the world of the Internet of Things (IoT) sensors and actuators that can be used in a system have grown exponentially both in their number and in their complexity. This involves having to deal with data of different types, such as Boolean, Numeric or String; beside, more and more often, a single object can measure (or set) different data.
The class structure that describes the sensors is the following, the same structure is used for the actuators (even if the two classes are equal, we have kept them separate for further developments).
Figure 5.8 – Sensor Class
The attributes of these classes:
. ID [String]: String that allows us to uniquely identify the object.
. name [String]: It defines the object’s name.
. typology [String]: String that identifies the macro-category of the object (Mechanical, Lighting, Motor, etc.).
80 Design of Smart Building Concepts
. subtype [String]: String identifying more specifically the type of the object (Light, Led Light, Shade Motor, Power Meters, etc.).
. data [dataPack]: New type of data that contains all the possible information which the object can read or set.
. visualClass [String]: This string identifies the name of the class used to make the current sensor a graphical object in the program.
Datapack
This class derives from the necessity to generalize the data that a sensor can read or an actuator can set. In particular, the class dataPack, allows us to save different data of different types: Boolean, Numeric, Numeric Range and Tristate.
Figure 5.9 – DataPack Class
The attributes of this class are the following:
. numberOfData [Static Int]: Total number of the possible information.
81 Chapter 5
. dataName [String []]: This array of strings contains the information’s names as: “temperature”, “state”, “brightness level” and so on (a null name identifies a variable not in use).
the remaining attributes are the data that a single element may contain, in this thesis we have defined four types of information that are:
. state [Boolean]: This Boolean value is used by elements characterized by a logic state. For example, a button can be in a state of rest or active, or a light bulb can be switched on or off.
. numericValue [Double]: This numerical value is used by elements which perform measurements or set a threshold. For example: the value of the temperature measured by a thermostat, or the brightness intensity of a bulb.
. numericRange [Double []]: This data defines a generic range, as the minimum and maximum threshold of a thermostat.
. triState [Boolean []]: This Boolean vector is used for those elements that have a state of high impedance as engines. For example, the motor of a roller shutter can go up, down or not move.
This class is easily expandable in order to manage more complex data.
5.5 Rules
Resuming the concept of rule introduced in Section 4.2, we briefly describe the rule model in UML form.
82 Design of Smart Building Concepts
Figure 5.10 – Rule Class
The attributes of this class are:
. ID [String]: This string identifies each rule uniquely.
. active [Boolean]: Identify if the rule must be verified.
. name/desc [String]: These strings contain the name and description of the rule respectively.
. tST/tFI [Time]: These data identify the period of time, in a single day, in which we must consider the rule in the conflict detection procedure.
. days [Boolean []]: This Boolean vector has a dimension equal to 7. Each space of this vector corresponds to a day of the week and, if set to true, indicates that the rule is active on that day.
. creator [User]: This attribute identifies the user which have created the rule. the last three attributes are objects that contain the data introduced in Section 4.2.1.
83
CHAPTER 6 IMPLEMENTATION
In this chapter we show how we have implemented the element introduced in the previous section. First, we provide an overview of the program. Then, we analyze all the managers that govern the different parts of the system and how a user can use them, particular attention is given to two aspects: add a new rule and how perform a conflict resolution.
6.1 Program Overview
This program has been completely developed with the Java programming language through the use of the IDE called Eclipse.
Java is a general-purpose computer programming language that is concurrent, class-based, object-oriented [23], and specifically designed to have as few implementation dependencies as possible. It is intended to let application developers "write once, run anywhere" (WORA) [24], meaning that compiled Java code can run on all platforms that support Java without the need for recompilation.
Eclipse is an IDE for “anything, and nothing at all”, meaning that it can be used to develop software in any language, not just Java.
85 Chapter 6
Figure 6.1 – Program’s Logic Structure
The structure of the program is based on four different parts. Each part is independent but it cooperates synergistically with the others. The four parts are:
. The User Manager: allows us to manage the users, their access and their data manipulation.
. The Space Manager: permits us to handle the spaces of the project;
. The Object Manager: allows to decide which object add to the system and where locate them;
. The Rule Manager: permits us to define new rules and verify possible conflicts.
86 Implementation
The mainly view of the program is showed in the following figure.
Figure 6.2 – Main View of the Program
6.2 User Manager
In this section, we analyze the tool through which is possible manipulate the users who have access to the system.
At the creation of a new project file, a default admin is automatically created. Otherwise, if a previously created project file is opened again, a user must insert valid credential in order to be able to manipulate it (see Figure 6.3).
(a) (b) Figure 6.3 – Login Procedure: (a) Menu Button, (b) Login Popup
87 Chapter 6
In order to simplify the user's experience within the program, we have created an action menu to manage the project's users. The menu item named User Manager allows us to access to the user manager that permit us to: add, remove or edit users in the system (see Figure 6.5). This menu item is active only when a valid user logs in, above all, the frame of the User Manager changes its appearance depending on the logged in user type in way to observe the specifications in the Table 5.2. Finally, the menu voice named Role Manager allows us to add or remove a role from the role’s list (see Figure 6.4).
Figure 6.4 – Role Manager’s Menu
(a) (b)
Figure 6.5 – User Manager (Admin View): (a) Menu Button, (b) User Manipulation Tab
88 Implementation
6.3 Space Manager
In this section we analyze the methods for add, remove, and manipulate the objects representing our system space.
The reason that led us to realize this part of the program has been the intention to provide to the users a clear and essential vision of how the system is composed. As already introduced in the section 5.3, it has been chosen to represent the physical structure of a system through the use of a tree diagram (see Figure 5.4 and Figure 6.6).
Figure 6.6 – Tree Structure of a Building
In the program, we have simplified this process through a simple right click of the mouse (see Figure 6.7).
Figure 6.7 – Add New Room Space Procedure
89 Chapter 6
In conclusion, it is possible to associate a planimetry to a floor and a shape to the rooms of that floor in way to have a better visualization of the spaces as show in the Figure 6.8.
Figure 6.8 – Room’s Shape and Planimetry Visualization
6.4 Object Manager
In this section we discuss the possibility to add, remove and edit the object of our system.
In way to access to the object manager we must select a room, then through a right click on the selected room a popup menu appears. Then, by selecting the menu voice named Element Manager we can access to the manager view (see Figure 6.9).
Once the menu voice has been pressed a new frame is opened (see Figure 6.10). In this view we find two lists: the sensors list and the actuators list. In order to add or remove an object from a room is sufficient click the appropriate button.
Actually the sensors and actuators lists are generated by collecting data from a default data base.
90 Implementation
Figure 6.9 – Objects Manager Menu Option
Figure 6.10 – Object Manager View
6.5 Rule Manager
In this section we discuss how we have decided to manage the rules and the conflict detector tool.
From each room in our system is possible define one or more rule that control the behavior of it. In order to access to the rule editor is necessary to do a right click on a room node of the tree and select the voice Rule Manager from the popup menu (see Figure 6.11). This option is enabled only when at least a sensor and an actuator are assigned the room’s elements list.
91 Chapter 6
Figure 6.11 – Rules Manager Menu Option
Then, a new frame is opened. Within it we find a list of rules that have been already imposed and the buttons for add, remove or edit a rule. Moreover, in the bottom right corner we find the button that starts the procedure for the conflict detection.
Figure 6.12 – Rule Manager View
How to Add a New Rule
The main point of the program is the definition of rules. In this section we introduce the procedure that allows us to add a new rule.
The procedure starts by clicking the button with the green plus symbol on it, located in the left-bottom part of the view showed in the Figure 6.12. After pressing the button, the following screen appears.
92 Implementation
Figure 6.13 – Rule Editor View
The panel named “If this happens” permits to insert the IF condition. By clicking the edit button on the right side of the panel a popup frame appears; inside it we find all the sensors that have been added to the room through the object manager. By ticking the sensor’s selection box, the corresponding sensor is automatically added to the rule’s condition (see Figure 6.14 (a)).
In the same way, we can add the actuators to the “Then Do This” panel (THEN condition), also in this case by accessing to the actuator through the edit button on the right side (see Figure 6.14 (b)).
Finally, we can optionally add the WHEN condition by editing the element in the middle panel. In this case, in addition to the sensors and the actuators it is possible define a range of time, the week’s days and a system condition in which that if verified make the rule active. These conditions are optional, but in order to allow the execution of the conflict detection’s algorithm a default range of time (equals to the entire day) and a default selection of the weekdays (all days selected) in which the rule is active are automatically used as when condition (the default WHEN condition is “always”).
93 Chapter 6
(a) (b)
Figure 6.14 – Editing Panels: (a) Trigger Event, (b) Actuator Setting
Figure 6.15 – When Condition’s Editing Panel
Once the sensors, actuators and WHEN conditions have been chosen, we can edit them in order to define the desired behavior (see Figure 6.16); their customization can be done through the pull-down menus that show the parameters of each object and through the insertion of other data in the
94 Implementation
appropriate textbox. Then we give a name and a description (optional) to the rule. Finally, we can save it using the "Add Rule" button located at the bottom right part of the frame.
Figure 6.16 – Rule Editor View: Rule Defined
How to Perform a Conflict Detection
Once we have defined two or more rules within a room, we can perform the search for possible conflicts. The search procedure can be started by pressing the button located at the bottom right corner of the rule manager, which is shown in Figure 6.12. A background process of the program performs the algorithm for the formalization of the rules introduced in Section 4.3; the code of this algorithm is partially shown in Appendix A.
The results of this procedure are then shown in two tables: the first shows the rules that have generated an error-type conflict (see Figure 6.17), the second shows the rules which generated a warning-type conflict (see Figure 6.18).
In addition, when one of the error-type conflicts is selected, the right section shows the values assigned to the variables, which have been created during the formalization procedure, and that have generated the conflict condition. Moreover, for such conflicts warning, we can see which actuator cannot pursue the behavior which had been fixed and values assignment as before.
95 Chapter 6
Figure 6.17 – Offline Analysis Results: Error Conflict
Figure 6.18 - Offline Analysis Results: Warning Conflict
96
CHAPTER 7 CONCLUSION
7.1 Obtained Results
As introduced in Section 1.4, this thesis had set several goals. Specifically, our goals were: the definition of a model able to describe a smart building, and manage conflicts generated between the rules that control the behavior of the system.
The first objective has been solved by the definition of the various classes described in the 0. These classes allow us to define the various parts that compose a smart building, which are: users, spaces and objects that it contains and the rules that govern it. In particular, we analyzed in more detail the concept of rule. The WIFTTT form, which we have achieved, allows us to define rules with a high level of complexity and to define rules perfectly compatible with those used by the current service providers, which are analyzed in Section 2.2. The classes have been implemented in an application that allows us to simulate the functioning of a real system, its features are described in the 0.
For the second objective, supported by the theory the SMT problems, we were able to define a procedure for the detection of conflicts. The results obtained, however, do not fully exploit the potential that the level of the rules’ modeling allows us. In particular, our research of potential conflicts is based on the constraints defined only by the rules, and does not take into account the different nature of the variables and other information given by the actuators; as described in Section 4.5.
97 Chapter 7
7.2 Future Developments
To conclude, we would like to mention some possible directions for future activities and investigation.
Currently, our constraints only check whether there is an overlap between the domains of two rules, and does not take into account the physical nature of the variables involved; and the settings information of the actuators (only during the search of the warnings). Therefore, a first improvement that must be reached regards the complexity of the constraints created during the formalization process. This development has already been treated in Section Figure 4.5 theoretically.
Another problem is the ability of integration with other systems. In particular, to make the system more open, we should implement the ability to communicate with external devices in order to:
. Taking as input the information on the objects of the real system and create rules with them.
. Transforming the rules created in rules for a real system.
Figure 7.1 – System Interfacing Menu
This solution, however, requires interfacing with a solution that allows to collect the data of objects of different manufacturers; to this end we have decided to use OpenHAB [37].
98
APPENDIX A JAVA CODE
A.1 Error Formalization Method
/** * Method which check if the two rules passed as parameter can * be enter in error * @param r1: First Rule * @param r2: Second Rule * @param accuracy: Accuracy that will be used into the * analisys (default = 1) * @return TRUE if the two rule can be in error, FALSE * otherwise */ public Boolean checkError(Rule r1, Rule r2, int accuracy){ //Apply WHEN filter if(this.whenFilter(r1, r2)){
//Apply ACTUATOR SETTING FILTER if(this.actuatorSettingFilter4Error(r1, r2)){
//Create the SMT Problem Optimize opt = this.solverConstructor( r1, r2, accuracy, 0);
//Check the solution return opt.Check() == Status.SATISFIABLE; } } return false; }
The method for the Warning is analogous.
A.2 Warning Formalization Method
/** * Method which check if the two rules passed as parameter can be generate a * warning * @param r1 * @param r2 * @param accuracy * @return */ public WarningList checkWarning(Rule r1, Rule r2, int accuracy){ //Create a warning list WarningList wl = new WarningList();
//Apply WHEN FILTER if(this.whenFilter(r1, r2)){
99 Appendix A
//Foreach couple of actuator setting which can create a warning i //call the solver RuleActuatorSetting[] as1 = r1.getActuatorSettings(); RuleActuatorSetting[] as2 = r2.getActuatorSettings();
//Create a warning flag Boolean warning = false;
//Apply ACTUATOR SETTING FILTER //Scroll the actuator settings of the first rule for(int i = 0; i < as1.length; i++){ //Scroll the actuator settings of the second rule for(int l = 0; l < as1.length; l++){ //FIRST CHECK - Verify if the actuator are the same if(as1[i].getActuator().getID().equals (as2[l].getActuator().getID())) { //SECOND CHECK - Verify if the actuator settings used //data are equals if(as1[i].getActuatorUsedData() == as2[l].getActuatorUsedData()) { //THIRD CHECK - Verify that almost one setting //have a duration if(as1[i].getSettingDuration().toMinute() != 0 || as2[l].getSettingDuration().toMinute() != 0){
//Set the value of “warning”, check if the parameters’ //value are different. Not reported because too long
//If there is a possibility of warning we check it if(warning){ //Setting 1 duration > 0 if(as1[i].getSettingDuration().toMinute() > 0){
for(int delta = 1; delta <= as1[i].getSettingDuration().toMinute(); delta++){ Optimize opt = this.solverConstructor(r1, r2, accuracy, delta);
if(opt.Check() == Status.SATISFIABLE){ wl.add(as1[i], as2[l]); break; }}}
//Setting 2 duration > 0 if(as2[l].getSettingDuration().toMinute() > 0){ for(int delta=1;delta<=as1[i].getSettingDuration().toMinute(); delta++){ Optimize opt = this.solverConstructor(r2, r1, accuracy, delta);
if(opt.Check() == Status.SATISFIABLE){ wl.add(as2[l], as1[i]); break; }}} warning = false; }}} //Already found an actuator setting match, we can skip the rest of the vector break; }}}} return wl; }
100 Java Code
A.3 Methods for Make Assertions
In this section, we show the methods which create the constraints based on the used data typology.
A.3.1 Boolean Constraints
/** * Creates a Boolean constraint based on the trigger event * passed as parameter * @param te: Trigger event from which take the data * @param b: Variable on which apply the constraint * @return The constraint, null if something goes wrong */ private BoolExpr createBooleanConstraint(RuleTriggerEvent te, BoolExpr b){ //Constraint creation:
A.3.2 Numerical Constraints
/** * Creates the numerical constraints based on the trigger * event passed as parameter * @param te: Trigger event from which take the data * @param r: Variable on which apply the constraint * @return The constraint, null if something goes wrong */ private BoolExpr createNumericalConstraint( RuleTriggerEvent te, RealExpr r){ //Decide which constraint implement switch(te.getComparization()){ case "equals to":{ return ctx.mkEq(r, ctx.mkReal(te.getDatapack().numericValue.toString())); } case "greater than":{ return ctx.mkGt(r, ctx.mkReal(te.getDatapack().numericValue.toString())); } case "equals or greater than":{ return ctx.mkGe(r, ctx.mkReal(te.getDatapack().numericValue.toString())); } case "lower than":{ return ctx.mkLt(r, ctx.mkReal(te.getDatapack().numericValue.toString())); } case "lower or equals than":{ return ctx.mkLe(r, ctx.mkReal(te.getDatapack().numericValue.toString())); } case "between":{ return ctx.mkAnd(ctx.mkGe(r, ctx.mkReal(te.getDatapack().numericValue.toString())),
101 Appendix A
ctx.mkLe(r,ctx.mkReal(te.getDatapack(). numericValue.toString()))); } default:{ return null; } } }
A.3.3 Range Constraint
/** * Create the numerical range contraints based on the trigger * event passed as parameter * @param te: Trigger event from which take the data * @param r: Variable on which apply the constraint * @return The constraint, null if something goes wrong */ private BoolExpr createRangeConstraint(RuleTriggerEvent te, RealExpr r){ switch(te.getComparization()){ case "contains":{ return ctx.mkAnd(ctx.mkGe(r, ctx.mkReal(te.getDatapack().numericRange[0].toString()) ),ctx.mkLe(r, ctx.mkReal(te.getDatapack().numericRange[1].toString()) )); } case "not contains":{ return ctx.mkOr(ctx.mkLt(r, ctx.mkReal(te.getDatapack().numericRange[0].toString()) ), ctx.mkGt(r, ctx.mkReal(te.getDatapack().numericRange[1].toString()) )); } default:{ return null; } } }
A.3.4 Tristate Constraint
/** * Create the tristate constraint based on the trigger event * passed as paramenter * @param te: Trigger event from which take the data * @param b: Variable on which applay the constraint * @param : Variable on which apply the constraint * @return The constraint, null if something goes wrong */ private BoolExpr createTristateConstraint(RuleTriggerEvent te, BoolExpr[] b){ return ctx.mkAnd( ctx.mkEq(b[0],ctx.mkBool(te.getDatapack().triState[0])), ctx.mkEq(b[1],ctx.mkBool(te.getDatapack().triState[1])), ctx.mkEq(b[2],ctx.mkBool(te.getDatapack().triState[2]))); }
102
References
[1] “SmartThings https://www.smartthings.com/. Date of Visit: September 2016.
[2] Apple Inc., “HomeKit User Interface Guidelines”, https://developer.apple.com/homekit/ui-guidelines/. Date of Visit: September 2016.
[3] KNX, “ETS Lite Download”, https://www.knx.org/knx- it/software/ets/download/indice.php. Date of Visit: September 2016.
[4] Brush, A. B., Lee, B., Mahajan, R., Agarwal, S., Saroiu, S., and Dixon, C. “Home automation in the wild: Challenges and opportunities”. In Proc. CHI, 2011.
[5] Mennicken, S., and Huang, E. M. “Hacking the natural habitat: An in- the-wild study of smart homes, their development, and the people who live in them”. In Proc. Pervasive, 2012.
[6] Blase Ur, Elyse McManus, Melwyn Pak Yong Ho, and Michael L Littman. “Practical triggeraction programming in the smart home”. Proceedings of the ACM SIGCHI Conference on Human Factors in Computing Systems, 2014.
[7] “IFTTT”, https://ifttt.com/. Date of Visit: September 2016.
[8] S. Resendes, P. Carreira, and A. C. Santos. “Conflict detection and resolution in home and building automation systems: a literature review”. Journal of Ambient Intelligence and Humanized Computing, pp. 1-17, 2013.
[9] S. T. Bushby. “Bacnet: a standard communication infrastructure for intelligent buildings”. Automation in Construction, vol. 6, no. 5, pp. 529-540, 1997.
[10] P. Arjunan, N. Batra, H. Choi, A. Singh, P. Singh, and M. B. Srivastava. “Sensoract: a privacy and security aware federated middleware for
103
building management”. In Proceedings of the Fourth ACM Workshop on Embedded Sensing Systems for Energy-Efficiency in Buildings. ACM, pp. 80-87, 2012.
[11] S. Dawson-Haggerty, A. Krioukov, J. Taneja, S. Karandikar, G. Fierro, N. Kitaev, and D. Culler. “Boss: building operating system services”. In Proceedings of the 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI), 2013.
[12] L. Capra, W. Emmerich, and C. Mascolo. “Carisma: Context-aware reflective middleware system for mobile applications”. Software Engineering, IEEE Transactions on, vol. 29, no. 10, pp. 929-945, 2003.
[13] “MathSAT”, http://mathsat.fbk.eu/. Date of Visit: September 2016.
[14] “SMTInterpol”, http://ultimate.informatik.uni- freiburg.de/smtinterpol/. Date of Visit: September 2016.
[15] “STP”, http://stp.github.io/. Date of Visit: September 2016.
[16] “Z3 Solver”, https://github.com/Z3Prover/z3. Date of Visit: September 2016.
[17] S. Ranise and C. Tinelli. “The Satisfiability Modulo Theories Library (SMT-LIB)”. www.SMT-LIB.org, 2006.
[18] D. Detlefs, G. Nelson, and J. B. Saxe. “Simplify: a theorem prover for program checking”. J. ACM, 52(3):365–473, 2005.
[19] ICT Labs. European Institute for Innovation and Technology ICT Labs. 2014.
[20] Sarah Mennicken, Jo Vermeulen, and Elaine M Huang. “From today’s augmented houses to tomorrow’s smart homes: new directions for home automation research”. In Proceedings of the 2014 ACM International Joint Conference on Pervasive and Ubiquitous Computing, pages 105–115. ACM, 2014.
[21] A.H. Buckman M. Mayfield Stephen B.M. Beck “What is a Smart Building?”, Smart and Sustainable Built Environment, Vol. 3 Iss 2 pp. 92 – 109, 2014.
[22] By Harold Abelson, Don Allen, Daniel Coore, Chris Hanson, George Homsy, Thomas F. Knight, Radhika Nagpal, Erik Rauch, Gerald Jay Sussman, Ron Weiss, “Amorphous Computing” Communications of the ACM, Vol. 43 No. 5, Pages 74-82, May 2000.
104
[23] Gosling James, Joy Bill, Steele Guy, Bracha Gilad, Buckley Alex, “The Java® Language Specification”, 2014.
[24] Nick Langley, “Write once, run anywhere?”, 2002. http://www.computerweekly.com/feature/Write-once-run-anywhere. Date of visit: November 2016.
[25] Gartner Special Report "Digital Business Technologies", http://www.gartner.com/technology/research/digital-business- technologies/. Date of Visit: November 2016
[26] Luigi De Russis and Fulvio Corno. “Homerules: A tangible end-user programming interface for smart homes”. In Proceedings of the 33rd Annual ACM Conference Extended Abstracts on Human Factors in Computing Systems, pages 2109–2114. ACM, 2015.
[27] Thomas Weng, Anthony Nwokafor, and Yuvraj Agarwal. “Buildingdepot 2.0: An integrated management system for building analysis and control”. In Proceedings of the 5th ACM Workshop on Embedded Systems for Energy-Efficient Buildings, pages 1–8. ACM, 2013.
[28] Steven T Bushby. “Bacnet: a standard communication infrastructure for intelligent buildings”. Automation in Construction, 6(5):529–540, 1997.
[29] “Results of the SMT-Competition”, 2014, http://smtcomp.sourceforge.net/2014/results-toc.shtml.
[30] “Results of the SMT-Competition”, 2015, http://smtcomp.sourceforge.net/2015/results- summary.shtml?v=1446209369.
[31] “Results of the SMT-Competition”, 2016, http://smtcomp.sourceforge.net/2016/results- summary.shtml?v=1467876482
[32] Alshabi W, Ramaswamy S, Itmi M, Abdulrab H, “Coordination, Cooperation and Conflict Resolution in MultiAgent Systems”. In: Innovations and Advanced Techniques in Computer and Information Sciences and Engineering, Springer, pp 495–500, 2002.
[33] Ramachandran V, Ramaswamy S, Rajan P, “Complex Negotiation Protocols For A Distributed Simulation”, 2001.
[34] Jacak W, Proll K, “Heuristic Approach to Conflict Problem Solving in an Intelligent Multiagent System”. In: Computer Aided Systems
105
Theory – EUROCAST 2007, Lecture Notes in Computer Science, vol 4739, Springer, pp 772–779, 2007
[35] Davis, Martin; Putnam, Hilary, "A Computing Procedure for Quantification Theory". Journal of the ACM, 1960.
[36] Beckford, Jahbrill; Logemann, George; Loveland, Donald, "A Machine Program for Theorem Proving". Communications of the ACM, 1962.
[37] “OpenHAB Site”, http://www.openhab.org/. Date of Visit: November 2016.
[38] Tuttlies V, Schiele G, Becker C, “COMITY: Conflict Avoidance in Pervasive Computing Environments”. In: On the Move to Meaningful Internet Systems 2007: OTM 2007 Workshops, Lecture Notes in Computer Science, vol 4806, Springer, pp 763–772, 2007.
[39] Armac I, Kirchhof M, Manolescu L, “Modeling and analysis of functionality in eHome systems: dynamic rulebased conflict detection”. In: 13th Annual IEEE International Symposium and Workshop on Engineering of Computer Based Systems, 2006. ECBS, 2006.
[40] Park I, Lee D, Hyun S, “A Dynamic Context-Conflict Management Scheme for Group-Aware Ubiquitous Computing Environments”. In: 29th Annual International Computer Software and Applications Conference, 2005. COMPSAC 2005., IEEE Computer Society, vol 1, pp 359–364, 2005
106
107