A Domain Specific Language to Specify Complex

ASL: A Domain Speciﬁc Language to Specify Complex Alarm Conditions in the Energy Domain

Alberto Filipe de Carvalho e Lomba Viana

Thesis to obtain the Master of Science Degree in Information Systems and Computer Engineering

Supervisor(s): Prof. Paulo Jorge Fernandes Carreira

Examination Committee Chairperson: Prof. José Manuel da Costa Alves Marques Supervisor: Prof. Paulo Jorge Fernandes Carreira Member of the Committee: Prof. Alexandre Paulo Lourenço Francisco

November 2015 ii Energy and persistence conquer all things. Benjamin Franklin

iii iv Acknowledgments

Acima de tudo agradeço a` minha mae˜ por todo o apoio prestado durante a universidade e ao longo de toda a minha vida. Demonstrou sempre ser uma mae˜ exemplar e a sua ajuda foi essencial para que pudesse concluir com exitoˆ esta etapa tao˜ importante. Este trabalho e´ dedicado a ti. Agradeço ao Prof. Paulo Carreira por me ter providenciado o seu apoio, exigencia,ˆ sugestoes˜ e sobretudo por ter acreditado desde o in´ıcio em mim e nas potencialidades deste trabalho. Finalmente, agradeço aos meus amigos pelo apoio cont´ınuo que me prestaram desde o primeiro momento. Sem vocesˆ esta jornada teria sido mais dif´ıcil e menos divertida.

v vi Resumo

Na gestao˜ de energia agir no momento adequado e´ um aspecto crucial. Isto ocorre maioritariamente porque a rapida´ detecçao˜ de problemas permite tomar decisoes˜ rapidamente, permitindo assim resolver os problemas. A combinaçao˜ de sistemas de gestao˜ de energia (EMS) com alarmes torna poss´ıvel detectar e reportar anomalias aos gestores de energia dos edif´ıcios. Contudo, o desenho efectivo de alarmes envolve tipicamente um grande conhecimento acerca do dom´ınio e tambem´ um grande esforço de programaçao,˜ especialmente quando estao˜ envolvidas condiçoes˜ complexas. De facto, a definiçao˜ de alarmes nos EMS requer a especificaçao˜ de condiçoes˜ sobre dados recolhidos continuamente de medidores e sensores, nao˜ existindo ainda uma soluçao˜ sistematica.´ Este trabalho tem como objectivo criar uma soluçao˜ para suportar os gestores de energia dos edif´ıcios na especificaçao˜ de alarmes espec´ıficos a este dom´ınio, que envolvem condiçoes˜ complexas sobre dados de medidores e sensores. Esta soluçao˜ vai permitir que os utilizadores criem novos alarmes usando apenas uma interface sem a necessidade de modificar o codigo´ da aplicaçao.˜ Usando esta soluçao˜ os gestores de energia dos edif´ıcios temˆ maior controlo sobre os alarmes existentes e as condiçoes˜ que os activam. Para validar esta soluçao˜ realizamos testes de usabilidade.

Palavras-chave: Gestao˜ de Energia, Alarmes, Processamento de Dados, Linguagem Es- pec´ıﬁca de Dom´ınio

vii viii Abstract

In energy management timeliness is a fundamental aspect, mainly because faster problem detection enables faster decision making and timely actions in order to solve problems. The combination of energy management systems (EMS) with alarms makes it possible to detect and report anomalies to building energy managers. Effective alarms design typically involves a great deal of domain knowledge and also programming hours — specially when complex conditions are involved. Indeed, EMS alarm definitions require specifying conditions over streams of data collected from meters and sensors for which no adequate systematic solution exists yet. This work aims to create a solution to support building energy managers in the specification of domain specific alarms involving complex conditions over energy meters and sensor data. This solution will enable users to create new alarms that capture complex patterns over streaming data through a graphical interface without the need to modify the application code. Us- ing this solution building energy managers are able to get more control regarding existing alarms and conditions triggering them. To validate this solution we performed usability tests.

Keywords: Energy Management, Alarms, Data Processing, Domain Speciﬁc Language

ix x Contents

Acknowledgments...... v Resumo...... vii Abstract...... ix List of Tables...... xv List of Figures...... xvii Glossary...... xix

1 Introduction 1 1.1 Problem Statement...... 3 1.2 Methodology...... 4 1.3 Document Organization...... 4

2 Concepts 7 2.1 Energy Management Systems...... 7 2.2 Alarms and Alerts...... 8 2.2.1 Alarm Management...... 10 2.2.2 Anomaly Detection...... 11 2.2.3 Challenges of Anomaly Detection...... 12 2.3 Streaming Data...... 12 2.3.1 Monitoring Applications...... 13 2.3.2 Real-Time Data Processing Requirements...... 13 2.4 Events and Patterns...... 14 2.4.1 Basic Patterns...... 14 2.4.2 Dimensional Patterns...... 15 2.5 Domain Speciﬁc Languages...... 15

3 Related Work 17 3.1 Data Mining for Anomaly Detection...... 17 3.1.1 Anomaly Detection Techniques...... 17 3.1.2 Real-Time Business Intelligence...... 19 3.2 Industrial Solutions...... 20 3.2.1 Fault Detection and Diagnosis...... 20

xi 3.2.2 Alarm Quality Requirements...... 21 3.3 Languages Supporting Event Detection...... 23 3.3.1 Automation Service Languages...... 23 3.3.2 Visual Programming Languages...... 23 3.3.3 Languages for Industrial Environments...... 24 3.4 Stream Processing Engines...... 24 3.4.1 Stream Processing Engine Approaches...... 24 3.4.2 Query classiﬁcation...... 25 3.4.3 Stream Query Languages...... 26 3.4.4 Stream Query Languages Operators...... 27 3.4.5 DSMS vs DBMS...... 29 3.5 A Survey of existing EMS...... 29 3.6 Systematization of Alarm Conditions...... 31 3.7 Discussion...... 34

4 Solution 35 4.1 Architecture Overview...... 35 4.2 Alarm Speciﬁcation Language...... 36 4.2.1 Literature-based Domain Analysis...... 37 4.2.2 Language Design...... 37 4.2.3 Language Syntax...... 41

5 Implementation 43 5.1 Information Presentation Stage...... 43 5.2 Data Processing Stage...... 46 5.2.1 Data Processing Stage API...... 46 5.2.2 Applying the Interpreter Design Pattern...... 47 5.2.3 Semantics of the Language Elements...... 49 5.2.4 Language Conversion Examples...... 53 5.3 Data Acquisition Stage...... 55

6 Validation 57 6.1 ASL Validation...... 57 6.2 Alarm System Validation...... 59 6.3 Methodology and Participants...... 60 6.4 Results...... 61 6.4.1 Results of the ASL Validation...... 61 6.4.2 Results of the Alarm System Validation...... 62 6.5 Lessons Learned...... 63 6.6 Discussion...... 63

xii 7 Conclusions 65 7.1 Impact...... 66 7.2 Future Work...... 66

Bibliography 69

A Grammar of the Alarm Speciﬁcation Language 83

B Domain Model of the Alarm Speciﬁcation Language 85

C Feature Model of the Alarm Speciﬁcation Language 87

D Alarm System Representation 89

E Validation Questionnaire 91

xiii xiv List of Tables

2.1 Characteristics of alarms...... 8 2.2 Examples of alarm types...... 9 2.3 Alarm priority distribution...... 9 2.4 Categories of anomalies and respective descriptions...... 12

3.1 The tree activities of fault detection and diagnosis...... 20 3.2 Symptoms of unsatisfactory alarm management...... 21 3.3 Methods for alarm suppression...... 22 3.4 Examples of stream query languages and their support to the stream processing requirements...... 27 3.5 Some differences between DBMS and DSMS...... 29 3.6 Survey of energy management systems...... 30 3.7 Alarm conditions gathered from the literature review...... 32 3.8 Classiﬁcation of the alarm conditions gathered from the literature review...... 33

4.1 Classiﬁcation of the pattern detected by each language element...... 41

5.1 REST API provided by the data processing stage...... 47

6.1 Usability evaluation approaches...... 57 6.2 ASL validation questions...... 58 6.3 Alarm system validation questions...... 59 6.4 Proﬁles of the participants involved in the validation...... 60 6.5 Results of the language validation questionnaire...... 61 6.6 Results of the alarm system validation questionnaire...... 62

xv xvi List of Figures

1.1 Value of the information obtained from data as a function of time...... 1 1.2 Methodology diagram...... 5

2.1 Flow of data into action...... 7 2.2 Alarming workﬂow...... 10 2.3 Alarm management life-cycle...... 11

4.1 Architecture overview...... 36 4.2 Elements of the Alarm Speciﬁcation Language...... 38

5.1 Interface to manage active alarms...... 44 5.2 Interface to manage existing alarms...... 44 5.3 Interface to create a new alarm...... 45 5.4 Example of an alarm specification...... 48 5.5 Interpreter design pattern...... 49 5.6 Example of an alarm specification and the corresponding queries when using an unary Upper Limit Threshold...... 53 5.7 Example of an alarm specification and the corresponding queries when using an unary Variation element...... 54

A.1 Grammar of the Alarm Speciﬁcation Language...... 84

B.1 Domain model of the Alarm Speciﬁcation Language...... 86

C.1 Feature model of the Alarm Speciﬁcation Language...... 88

D.1 Alarm system representation...... 90

E.1 Page 1 of the validation questionnaire...... 92 E.2 Page 2 of the validation questionnaire...... 93 E.3 Page 3 of the validation questionnaire...... 94

xvii xviii Glossary

API Application Programming Interface ASL Alarm Speciﬁcation Language CEPS Complex Event Processing System DBMS Database Management System DSMS Data Stream Management System EMS Energy Management System FDD Fault Detection and Diagnosis JSON JavaScript Object Notation REST Representational State Transfer RT-BI Real-Time Business Intelligence SPE Stream Processing Engine URI Uniform Resource Identiﬁer

xix xx Chapter 1

Introduction

Up-to-date information improves the decision making process, mostly because building energy managers are able to diagnose and react quickly to anomalous situations [44]. A crucial aspect in energy management is timeliness. As time passes, the window of opportunity for action shrinks and consequently the value of the information obtained from data decreases [116, 157]. Figure 1.1 illustrates this idea. Due to this fact, anomalies should be discovered as soon as possible — if possible in real-time or in near real-time — enabling the implementation of a corrective action [30, 71, 72, 116, 157]. Previous research has demonstrated that the exploration of time series data, related with energy consumption, for anomaly detection enables reduction in the amount and cost of consumed energy [88]. This task can be done through anomaly detection that refers to the detection of abnormal situations or, in other words, to the detection of events or situations not behaving as expected [34, 111]. Alarms are ﬁred when an anomaly is detected, thus enabling building energy managers to decide and act faster. An alarm is a notiﬁcation that an anomaly has occurred and a user response is required [7, 98, 135, 149]. The primary use of alarms is to react promptly in order to solve volatile issues, in other words, to solve problems that have a short lifespan. For instance, in the case of a building, an alarm caused by a variation in the consumption patterns can alert the building energy manager that something is not working in the expected way, like a room with its lights turned on and nobody inside it, or a damaged equipment that is consuming more than usual. Real-time data processing can be explored synergistically

Figure 1.1: Value of the information obtained from data as a function of time (adapted from [116, 157]).

1 with alarms to reduce the time required by building energy managers to detect anomalies in energy and equipment usage. With this approach major savings can be achieved in energy consumption. Alarms, or more precisely, alarm conditions need to be detected from data arriving in real-time. Stream processing engines (SPEs), for instance data stream management systems (DSMSs) and complex event processing systems (CEPSs), have been developed to overcome the multiple difficulties that arise in scenarios requiring large quantity of real-time data to be processed in real-time, such as the care of data produced by sensors. The main objective of DSMSs is to process multiple data streams as input and provide new data streams as a result. CEPSs treat the input as a stream of event notifications, which need to be filtered and combined to reason with what is happening in terms of higher-level events. SPEs provide stream query languages enabling the creation of continuous queries that can be used, for instance, to process data or for pattern matching [1, 12, 47, 140]. SPEs can be used by applications that monitor continuous data streams, called monitoring applications, in order to achieve the goal of up-to-date information [31]. Generally, monitoring applications monitor multiple data streams, leading to processing rates bigger than ones supported by a traditional database management system (DBMS). In order to provide timely results they should use a DSMS as an alternative to a DBMS [31, 33, 47, 67, 140]. Monitoring applications, using a DSMS as underlying technology, are used in other business environments like in the monitoring of stock market trades [35], health sensor data [89, 161], social networks [130], and network traffic [4, 46, 141]. Alarm management when performed by building energy managers enable them to get enhanced control regarding existing alarms and the conditions triggering them. This is an important task when it is necessary to redefine an alarm — for instance to modify the alarm trigger condition — or to create a new one. Thus, considering (i) the capability of a DSMS to timely process energy data — data streams — and (ii) the possibility to deploy on the fly a query — corresponding to the alarm trigger condition — on a DSMS, we can conclude that a DSMS is an adequate solution to timely detect the alarm conditions. Domain specific languages (DSLs) are languages designed specifically for a domain [147, 164]. Us- ing domain notions a DSL becomes more expressive, resulting in a language that is easier for users to learn, understand, and apply for a specific problem category [96, 112, 164]. Using the results of a systematization of alarm conditions, performed through a literature review and interviews with experienced building energy managers, this work aims to develop a visual DSL to specify alarms regarding the building energy management domain. Additionally, using a DSMS as underlying technology, this work aims at creating an alarm system to support building energy managers to specify domain specific alarms involving complex conditions. This system will allow users to create new alarms just using the visual DSL on an interface without the need to modify the application code. An advantage of this system is that building energy managers will be able to get enhanced control regarding existing alarms and conditions triggering them. Another possible advantage will be the reduction of the alarms number, helping building energy managers with the immense quantity of generated alarms. The proposed solution was validated through the validation of both the DSL and the alarm system developed. To validate the DSL we performed interviews with experienced building energy managers,

2 using a DSL validation methodology based on the literature that assesses the DSL effectiveness, efﬁ- ciency, satisfaction, accessibility, reliability, and productivity. The alarm system was assessed through its usability and performance characteristics. The results show that the DSL is easy to use and has a good domain coverage, being the system easy to use and efﬁcient in the production of information.

1.1 Problem Statement

Sensors installed in buildings collect large volumes of data from energy meters, equipment operation status, and a plethora of environment sensors including temperature, humidity, or occupancy sensors. This data can be processed to enable building energy managers to ﬁnd patterns, trends, and anomalies assisting them in reducing equipment failure rate and improve energy use [88].

In order to provide information in a timely way, decision support systems, like energy management systems, should analyse data as timely as possible to detect patterns of inefﬁcient energy use. One promising solution consists of analysing continuous data streams using a data stream management system (DSMS). Alarms present information to users, being thus a possible path to provide up-to-date information since they enable the timely recognition of anomalies [7, 98, 135, 149]. However, to date, no alarm processing infrastructure based on a DSMS has been described in literature. Decision support systems collect data from multiple sources and store them in a database to be analysed in an off-line manner, being this approach slower than analysis of continuous data streams [99].

DSMSs are also highly flexible in enabling new queries to be deployed on the fly. Conceivably, users may create new alarms based on a set of predefined (possibly complex) patterns, that can be easily deployed without the need to modify the application code [63]. However, to the best of our knowledge, these kind of solutions are not currently available.

We note also that a systematization of the existing alarms (and the queries representing them), based in patterns not conforming with normal behaviour, and their respective classes is not currently available in literature. This aspect is of utmost importance to understand the requirements of alarm processing and to develop an adequate solution. In addition to this, there are no clear deﬁnitions for alarms and other associated concepts.

Existing energy management systems in buildings with alarm functionalities as well as monitoring systems in general, generate a large number of alarms overloading users with redundant information, a situation known as alarm ﬂooding [43, 104, 131]. This observation leads to the logical conclusion that designing a solution, like the one this work proposes, is challenging also from a user interface point-of- view. Weak alarm management, especially in alarm ﬂood situations, hampers the capacity of users to accomplish their tasks. Indeed, it has been demonstrated that it is not possible to reliably interpret and act when a large number of alarms is generated [48, 92, 104]. Therefore, enabling user-customization is important to avoid information overload and allow users to adjust the tool to accommodate their own needs and priorities [63].

3 1.2 Methodology

This work has two main objectives. The first consists in a literature review identifying the essential set of alarm conditions in the building energy management domain. The importance of this literature review rests on the following. To the best of our knowledge, a literature review related with this topic especially with respect to the energy domain does not exist. The second objective of this work is to develop a visual DSL and an alarm system to support building energy managers to specify domain specific alarms involving complex conditions. To timely process data streams collected from energy sensors the solution architecture will be based on a DSMS. This solution will allow users to create new alarms just using the DSL on a dashboard without the need to modify the application code. Using this solution, building energy managers will be able to get enhanced control regarding existing alarms and conditions triggering them. With this approach another possible benefit will be the reduction of the alarms number, thereby helping building energy managers dealing with the huge quantity of generated alarms. To address these research objectives this work will be conducted as follows:

• Systematization of concepts regarding energy management and alarms.

• Survey the techniques used in anomaly detection.

• Analyse existing solutions on alarm management.

• Survey the literature on dashboards, and available solutions, to understand how to display alarms in an effective way.

• Understand the nature of languages that use visual elements to ﬁnd out effective ways to specify alarm conditions visually.

• Characterize the essential operators of stream query languages to ﬁnd out how they can encode the alarm patterns.

• Identify in the literature alarm conditions used for real-time condition monitoring in the energy management domain.

• Develop and validate a visual DSL to support building energy managers on the speciﬁcation of domain speciﬁc alarms involving complex conditions.

• Develop an alarm system prototype and validate it through its usability and performance characteristics.

An overview of the methodology to be followed during this work is represented in Figure 1.2.

1.3 Document Organization

This manuscript is structured as follows. Section 2 introduces the fundamental concepts of EMSs, alarms, streaming data, events, and DSLs. Section 3 surveys the related work of alarms in the energy

4 Figure 1.2: Overview of the methodology to be followed during this work. Gray boxes capture the main deliverables and objectives of this work. Lines capture precedence relationships. domain. First, the techniques used in anomaly detection and existing solutions in real-time business intelligence are surveyed. Second, solutions of fault detection and diagnosis and alarm quality requirements are analysed. Third, we analyse languages for event detection and the feasibility of using stream processing engines as underlying technology for this work. Finally, is presented a survey of existing EMS, and a systematization of alarm conditions is developed based in a literature review and interviews with experienced building energy managers. Sections 4 and 5 outline the architecture and implementation of the prototype solution, and the development of a DSL. Section 6 describes the validation of both the conceived DSL and the alarm system prototype, and ﬁnally, Section 7 presents the conclusions.

5 6 Chapter 2

Concepts

A series of relevant concepts are described in this section in order to better understand the problem discussed in this work. We start by describing EMSs and some concepts regarding alarms. Then, we detail the requirements of monitoring applications and real-time data processing systems. Finally, we outline categories of patterns, and describe domain speciﬁc languages.

2.1 Energy Management Systems

Energy management systems (EMSs) are a collection of performance monitoring software, data acquisition hardware, and communication systems used to store, analyse, and display information related with energy consumption performance [71, 72]. Energy data consists in time series records acquired from energy meters and sensors (e.g. occupation, equipment status, and environment indicators) that are combined during analysis activities (like benchmarking, energy performance tracking, and anomaly detection) to produce information. This information should be updated and displayed regularly, preferably in real-time or in near real-time, within a 15 minutes deadline, in order to timely help decision makers transforming it into actions affecting building energy efficiency — a continuous transformation flow is depicted in Figure 2.1[30, 72, 114, 116, 157]. A key aspect of EMSs is, therefore, the timely and early detection of inefficient energy usage. For instance, equipment operating unnecessarily or operating sub-optimally due to lack of servicing or other condition. These are examples of patterns that should be discovered as soon as possible, enabling the implementation of an adequate corrective action. A way to detect poor performance (e.g regarding energy consumption) consists in comparing actual performance with performance indicators (also known as targets), generating an alarm when a

Figure 2.1: Flow of data into action (adapted from [72]).

7 divergence is detected. Examples of performance indicators can be energy consumption, but may also include other efﬁciency measures such as [71, 82]:

• Benchmarking building energy performance against other similar buildings (cross-sectional benchmarking), or its own historic performance (longitudinal benchmark).

• Comparing actual performance against the best performance that could be achieved or has been achieved in the past.

• Reduction to desired level of performance (e.g. 15% under the benchmark).

• Measurement of budget performance against a predeﬁned goal.

Performance monitoring frequency will depend of the application. For instance, in a complex process that consumes much energy a proper report rate should be 15 minutes, particularly if process changes can be made in answer to the generated performance alarms [82]. Still, according to Hooke et al. [82], EMSs operating in real-time have the following advantages: (i) anomalies are identiﬁed in a timely way, enabling the application of corrective actions, (ii) a better comprehension of the historical operations, (iii) better targets (models) can be produced, (iv) results of activity-based costing are improved, and (v) exists data collection consistency because input data is produced in real-time.

2.2 Alarms and Alerts

An alarm is defined as a notification that a particular event — related with detected faults, or abnormal conditions — has occurred and a timely user response is required [7, 98, 135, 149]. Consider- ing the EEMUA 191 guideline, good alarms must respect standardized characteristics, such as, being unique, timely, and relevant to the user [56]. These characteristics are summarized in Table 2.1. More- over, according to the ANSI/ISA 18.2 standard, depending on the type of condition, alarms can be classified into alarm types (see Table 2.2). The taxonomy of alarm types is extensible since it may be necessary to define new ones depending on the context of their application [7].

Characteristic Description

Relevant Provides value to the user Unique There are no duplicated alarms Timely The alarm indication should occur in a moment that enables the user to take a corrective action Prioritizable Should have a clear priority to be followed by the user in the problem resolution Understandable The alarm message is understandable Diagnosable Identiﬁes the source of the problem Advisory A corrective action is suggested

Table 2.1: Characteristics of alarms and corresponding descriptions (according to EEMUA 191 [56]).

8 Alarm Type Description

Absolute A threshold is exceeded Deviation The difference between two analogue values exceeds a limit Change rate The deﬁned limit to the change of a variable per unit time is exceeded Discrepancy The actual state is not the expected one Calculated Generated from a calculated value rather than a direct measure Statistical Generated based on statistical processing of one or more variables System diagnostic A fault in the hardware or software was detected by the system Instrument diagnostic Signaled by a device to indicate a fault

Table 2.2: Examples of alarm types (adapted from [7]).

An alert is a notiﬁcation that an event requires awareness. However in contrast with an alarm, an alert does not require a prompt user response, and therefore, it is not delivered using the alarm system [7, 128].

Alarm systems are hardware and software systems that handle the detection of alarm conditions and present alarm notiﬁcations to users [7]. A good alarm system provides alarms with the standard characteristics mentioned before. In addition, it should enable the user to focus on the most important alarms and provide capabilities to analyse alarm system performance metrics, towards continuous improvements [56, 106]. Overall, alarm systems should help users in the prevention of abnormal situations and in the mitigation of safety incidents [28].

A technique used to focus the attention of users on the most important alarms within an alarm system consists in deﬁning alarm priorities. An alarm priority descriptor indicates the importance that should be assigned to an alarm, taking into account the perceived impact of the situation, and the urgency of response. According to ANSI/ISA 18.2 standard, to maximize user effectiveness, an alarm system should not provide more than three or four different categories of alarm priorities and lower priorities should be more frequent than higher ones (see Table 2.3)[7, 106].

During the life time of an alarm, its state varies depending on two conditions: (i) if the alarm trigger condition was detected, and (ii) whether the alarm indication has been acknowledged by the user. The evaluation of these states can be deﬁned by an automaton as presented in Figure 2.2. Initially, the alarm condition is false and the alarm indication is considered acknowledged (state inactive, acknowledge), this will be the alarm state during normal situations. After the alarm condition becomes true there are two possible paths to reach the initial state. In the ﬁrst one, the alarm condition becomes false being the

Priority categories Approximate Recommended Distribution

Low, Medium, High 80% Low, 15% Medium, 5% High Low, Medium, High, Highest 80% Low, 15% Medium, 5% High, 1% Highest

Table 2.3: Relative distribution of alarm priorities using three or four scale priority categories, as prescribed by ANSI/ISA 18.2 alarm standard [7].

9 user acknowledge Inactive, start Unacked

condition condition Inactive, activated Active, deactivated Acked Unacked

user acknowledge Active, Acked

condition deactivated

Figure 2.2: Alarming workﬂow (adapted from [2,7]), where Acked means that the alarm indication was acknowledged by the user. state (inactive, unacknowledged) reached. This is an optional state and only exists when is necessary to inform the user about the occurrence of an abnormal situation, even when the alarm condition no longer holds. The second possibility to reach the initial state refers to the situation when the user acknowledges the alarm indication being the state (state active, acknowledge) reached. Using this state alarm re-announcements to the user are prevented until the alarm condition becomes false [2,7].

2.2.1 Alarm Management

The process of determining, documenting, designing, operating, monitoring, and maintaining an alarm system is known as alarm management. This process defines the development and operations life-cycle of an alarm system. During the alarm management life-cycle (see Figure 2.3) the first step focuses on the creation of an alarm philosophy document that formalizes the requirements for the alarms of a given domain. This document should define, for instance, how to classify and prioritise alarms. For new alarm systems it is the base for the requirement specification document. In the second step, documents describing equipment characteristics (including expected energy consumption), good manufacturing practices, and safety requirements are used to identify potential alarms. During this step is also important to consult decision makers (e.g building energy managers), enabling the identification of high level goals that will be used in the alarm identification. This way it is possible to meet the decision-makers requirements [132]. Then, an alarm rationalization is done taking into account the alarm philosophy document, receiving each alarm a classification and a priority. At the end of this phase each alarm has clear documentation, including, for example, the consequences of the situation that motivates the alarm existence and the corrective action that should be applied by the user. In the design phase, choices about the alarm development are taken and the alarm attributes are specified and designed, using the documentation created during the rationalization phase. Next, the

10 Figure 2.3: Alarm management life-cycle (adapted from [7]). alarm or the alarm system (when a new system is being created) is installed and put into operation. It is important to test the system and train users because new alarms are added or modified. The performance of the system is continuously compared against performance goals defined in the alarm philosophy document, enabling the identification of needs for modifications and maintenance in the system. This way the system is continuously monitored and assessed. To ensure that the system functions as designed, during maintenance the system is tested or repaired if necessary. In the management of change step, modifications to the system are proposed and approved, including for instance the change of a threshold of an alarm trigger condition [7].

2.2.2 Anomaly Detection

As we have seen before, an alarm notifies the occurrence of an anomaly that requires a timely user response. Anomalies (also called outliers) are patterns in data not conforming to a well defined notion of normal behaviour [34, 80]. Anomaly detection, also addressed as outlier detection, refers to the problem of discovering patterns in data that do not comply to the expected characteristics [34, 111, 125]. For instance, abnormal energy consumption can be found detecting deviations from normal consumption [71]. In a computer network, an anomalous traffic pattern may be associated with a hacked computer send- ing sensitive data to unauthorized destinations [103, 163]. It is well known that credit card fraudulent activities are found detecting anomalies in credit card transaction events [115, 124]. Anomalies can be classified into three categories as presented in Table 2.4. Point anomalies can appear in any data set and collective anomalies can appear only in data sets in which data instances are related. On the other hand, contextual anomalies arise with the availability of context attributes in the data. An example of context may be the year season, being a temperature observation of 30 degrees considered normal in the summer and considered abnormal in the winter. When evaluated within a context, point or collective anomalies can additionally be classified as contextual anomalies [34]. The percentage of data that is correctly classified as an anomaly is known as detection rate. False alarm rate, also known as false positive rate, is the percentage of data that is wrongly classified as an

11 Anomaly Category Description

Point Anomalies An individual data instance that can be evaluated as anomalous with respect to the rest of the data Contextual Anomalies An observation that is classiﬁed as anomalous in a particular context and normal in another one Collective Anomalies Collection of data instances that are anomalous with respect to the all data set. Each of the individual data instances that forms the collective anomaly may not be anomalies by themselves, however their occurrence collectively as a collection is anomalous

Table 2.4: Categories of anomalies and respective descriptions (adapted from [34]). anomaly [111]. Ideally, anomaly detection solutions should provide a high detection rate and a low false alarm rate. It is really important that a system has a low false alarm rate, otherwise users will abandon it due to unnecessary calls that augment costs and reduce the work quality [53, 84, 121].

2.2.3 Challenges of Anomaly Detection

Based in the deﬁnition of anomaly, a straightforward anomaly detection approach consists in deﬁning a space that represents normal behaviour, and considers as an anomaly any data observation that does not belong to this normal space [34]. Despite being conceptually simple, a number of aspects make it challenging, in particular [34]:

1. The boundary that separates normal behaviour from anomalous behaviour is often a fuzzy deﬁni- tion. Thus, an anomalous observation that is close to the boundary can be in reality a normal one, and vice versa. Consequently, the false positive alarm rate may increase considerably.

2. The deﬁnition of normal and anomalous behaviour may evolve with time due to changes of equipment characteristics or reference values, being this issue known as concept drift [3, 66, 75].

3. The existence of noisy and imprecise data makes the distinction between anomalous and normal behaviour harder.

4. Distinct application domains have different understandings of anomaly. A small divergence from normal behaviour in some areas are considered an anomaly (e.g in medicine when a variation in the blood pressure occurs) and not in others (e.g a variation of a stock value in the stock market).

2.3 Streaming Data

An increasingly large number of data intensive applications require data to be modelled as data streams instead of persistent relations [12]. A data stream is an ordered sequence of tuples (implicitly by arrival time or explicitly by timestamps) that can only be read a single time or a small number of times using ﬁnite computing and storage capabilities [67]. Each tuple corresponds to an observation about an event or variable. EMSs are an example of this class of applications because they receive continuous data

12 streams as input and have to produce results in a timely way, being unfeasible to load the data into a database for later processing them.

2.3.1 Monitoring Applications

Applications that monitor continuous data streams, called monitoring applications, can be used to support a timely decision making process. This kind of applications can be found in ﬁnancial monitoring of stock data obtained from multiple sources and in tracking applications used to monitor the locations of an ample number of objects (e.g. to monitor the locations of borrowed equipment), among other. Monitoring applications have the following requirements that should be meet [31]:

1. Sources of data are external (e.g. sensors) instead of humans issuing transactions.

2. The data required is not merely the last recently reported values but also historical data. An example where historical data may be necessary is the following one: “what are the sensors where the energy consumption of the last 10 minutes is 20% higher than in the homologue 10 minutes of the past year”. In this example, to produce results it is necessary to access historical data because the homologue period is always changing.

3. All monitoring applications can possibly monitor multiple data streams (possibly in the order of thousands) and ﬁre alarms if anomalous situations are met. This aspect calls for the need of using a DSMS as an alternative to a DBMS because the processing rate required is bigger than the supported by traditional DBMS.

2.3.2 Real-Time Data Processing Requirements

The correct operation of a real-time software system depends on both the results produced and the time taken to generate those results [136]. Due to the intrinsic nature of data streams and continuous queries to produce real-time results a system must meet the following assumptions [70]:

1. Real-time monitoring applications must be capable of processing data in a timely way, reacting quickly to unusual data values. This way, it is possible to detect anomalies in due time enabling users to react.

2. Data model and query semantics must enable order-based and time-based operations (e.g. know the tuples that have arrived in the last 10 minutes).

3. Due to performance and memory constraints and since data streams are transient, stream processing algorithms process each data stream only once.

4. The interval of arrival of tuples may change over time (stream rate). Due to this, long duration queries may ﬁnd changes in system conditions all over their execution lifetimes, however these queries must provide a correct answer in a timely manner.

13 5. Since it may be impossible, in practice, to store a complete data stream in memory, summary structures must be used. As a consequence, the answers to certain queries may have to be an approximate one.

6. In order to have systems able to timely process data under overload periods it may be necessary to deﬁne a policy to discard input data.

7. Blocking operators that require processing all the input to produce any results should be avoided, otherwise the computation of a result for unbounded data streams would never return a result.

2.4 Events and Patterns

According to Etzion and Niblett, an event is something that happened within a system or domain. It can be defined as a detectable condition that can trigger a notification [59, 60]. A combination of events is known as an event pattern. Given a set of events, a subset of those events satisfies a pattern when all events match the pattern [59, 81]. Event patterns can be classified into the following two categories, namely basic and dimensional patterns. Inside each category there are more specific sub-categories [58, 59]. In the following pattern categories, the term participant event set refers to the subset of events analysed at a given moment.

2.4.1 Basic Patterns

Basic patterns are created through the application of simple operations to a combination of events. These category of patterns do not depend on the order of the events that compose them [58, 59].

Logical are based on logical operators, namely conjunction, disjunction, and negation. Examples operator of these patterns include the all (conjunction) pattern, any (disjunction) pattern, and the patterns absence (negation) pattern. For instance, the all pattern is satisﬁed when all the events that form the pattern have occurred until now.

Threshold compare the result of an aggregation operation against a threshold value. The aggregation patterns operations used include, for instance, the count, maximum, minimum, and average operators.

Subset select a subset of events from an event collection using various criteria. These patterns can selection be used, for instance, to select from an event collection the events that have the n highest patterns or lowest values of a given attribute.

Modal have an assertion and check if it is satisfied by all the events in the participant event set patterns or just by some ones. The always and sometimes patterns are examples of modal patterns. For instance, the sometimes pattern is satisfied when at least one event satisfies the assertion.

14 2.4.2 Dimensional Patterns

Dimensional patterns are related to the time or space dimensions, or to a combination of both [58, 59].

Temporal are patterns where time plays a fundamental role. An example of this category of patterns order is the sequence pattern where a given pattern is satisfied when: (i) the participant event patterns set contains at least one instance of all the events previously defined in the pattern and (ii) the order of the events in the participant event set is equal to the one defined in the pattern.

Trend trace the value of an attribute over time. The order of arrival of the events is also con- patterns sidered. A possible example of these patterns is the increasing pattern, where the value of a given attribute (e.g. the energy consumption) increases as we advance through the sequence of events.

Spatial are satisfied considering the distance between the values of the location attributes (when patterns they exist) of events. An example is the min distance pattern that is satisfied when all the events in the participant event set have a pre-defined minimal distance between them.

Spatio use the location attribute (when it exists) of events to determine spatial trends over time. temporal These patterns can be used, for instance, to detect the movement of an object. patterns 2.5 Domain Speciﬁc Languages

The interest in language engineering — in other words, the act of creating languages — has increased over the last years [95]. Consequently, the Software Language Engineering (SLE) emerged as an application of a systematic, disciplined, and quantifiable methodology to the development, usage, and maintenance of software languages [16]. Typically, a SLE starts with the domain analysis, in order to identify the domain concepts, followed by the language design that captures the domain concepts and their relationships. Finally, the language is implemented and documented [14]. Domain Specific Languages (DSLs) are languages designed specifically for a domain. In contrast with general purpose languages, DSLs are focused in the domain of the problem and not in the computational solution, therefore they are more expressive and easy to use [95, 147, 148, 164]. Using domain notions in the solution makes DSLs more expressive, resulting in a language that is easier for programmers and non-programmers to learn, understand, and apply for a specific problem category [96, 112, 164]. Another DLSs benefit is that despite reducing flexibility, DSLs are more productive and reliable [42, 148]. This fact enables to reach the market quicker, diminish the maintenance cost, and have a higher optimization potential [146]. DSLs are also recommended by their quality, due to the fact that they produce less errors and more efficient code [16, 79, 148].

15 16 Chapter 3

Related Work

To understand the feasibility of applying automatic techniques to deﬁne and detect complex alarm conditions, we investigated existing techniques in anomaly detection and the underpinnings of a real- time business intelligence architecture. Fault detection and diagnosis are also addressed to understand how commercial solutions operate. Since we want to provide useful information to users, we explored alarm quality requirements and consequently alarm processing techniques. Considering that our solution will enable building energy managers to specify alarms involving complex conditions, we explored different languages supporting event detection. To assess the feasibility of a DSMS-based architecture for alarm systems we reviewed the capabilities of stream processing engines, specially regarding the expressiveness of stream query languages operators. In order to understand the features supported by EMS solutions present on the market we performed a survey of existing EMS. Finally, a systematization of alarm conditions is developed based in a literature review and interviews with experienced building energy managers.

3.1 Data Mining for Anomaly Detection

Data mining is the process of discovering knowledge from data [74]. A particular application of data mining is the discovery of anomalies, that may be announced to the user through alarms [119]. To obtain information from data in real time, business intelligence is starting to consider real-time as a new dimension analysing data as it gets into the organization, ideally with zero latency [76]. During this section we investigate the applicability of automatic techniques to deﬁne and detect alarm conditions.

3.1.1 Anomaly Detection Techniques

A solution to identify anomalies consists in comparing a pattern, representing normal behaviour, with data instances, in order to detect those that signiﬁcantly differ from the pattern. According to literature, there are three approaches that can be considered in the anomaly detection techniques: unsupervised, supervised, and semi-supervised. Supervised and semi-supervised anomaly detection techniques have

17 two phases. First, in the training phase, training data is used to build a classifier. Then, in the testing phase using the classifier, of the previous phase, each test instance is classified as normal or anomalous. These three approaches are described below [34, 80, 111, 162]:

1. Unsupervised anomaly detection does not require prior knowledge of the data, in other words, pre- labelled data is not required and for that reason this is the most widely used approach. Techniques following this approach have the assumption that the frequency of normal instances, in the test data, is higher than the anomaly frequency. If this assumption is false, high false alarm rate will occur.

2. Supervised anomaly detection require data to be pre-classiﬁed as normal and anomalous. New data instances are classiﬁed by comparison against the model. Two issues emerge with this approach. First, the number of anomalous instances is in general much smaller than normal instances. Second, obtaining accurate and representative instances for the case of anomalous situations is not always easy.

3. Semi-supervised anomaly detection aims at defining a normality boundary where only normal pre- classified instances are required. An instance that is outside the boundary is classified as an anomaly.

Classification based techniques can be used as supervised anomaly detection techniques, including for instance: neural networks, bayesian networks, support vector machines, and nearest neighbour. These techniques can be organized in two categories, namely multi-class and one-class. Multi-class classification techniques consider that pre-classified instances of various classes are available in the data set, and a test instance is recognized as anomalous if it is not classified as normal by any of the classifiers. On the other hand, one-class classification techniques assume that only one class label exists in all training instances [34]. A technique that can be used in unsupervised anomaly detection consists in building groups (i.e. clusters) of similar data instances. This technique is known as clustering and can be organized in two categories. The first one asserts that normal instances are in clusters and anomalies are not. In the second category, anomalies constitute by themselves a cluster, and normal instances are in large and dense clusters while those representing anomalies are not. Finally, we should note that the main difference between techniques based on clustering and those based in nearest neighbour is that clustering evaluates the distance between each instance to a representative of the cluster (the cluster centroid), while nearest neighbour techniques measure the distance among each instance and its neighbourhood [34, 37, 57, 105]. Traditional anomaly detection techniques do not work well in settings where data is arriving continuously. Moreover, continuously keeping the instances to compare with is infeasible in practice, due to processing and memory capacity limitations [3, 111, 119]. In addition, the issue of concept drift, i.e. what is considered as normal at an instant may be an anomaly in the future and vice-versa, poses an extra challenge to build a reliable classification mechanism [3, 75].

18 Despite the fact that classification and clustering in data streams are still challenging, traditional techniques with modifications can be used [3, 120]. For example, in the nearest neighbour techniques, the classification is done using the class label of the nearest neighbour of the instance. Considering that the nearest neighbour cannot be defined over the entire data stream, a data stream sample is used during the classification [3].

A survey of possible approaches to solve the data stream classification problems was done by Zhang et al. The authors propose model-based and graph-based methods. Model-based methods build a model to describe the statistical behaviour of data streams and consider as anomalies the points that diverge from the model. Again it may be difficult to build an accurate model to represent all the data [162]. Graph-based methods estimate the data stream distribution in order to identify anomalies. Applications of graph-based methods are used, for instance, in the detection of anomalies in telecommunication, financial trading, and opinion networks [5].

3.1.2 Real-Time Business Intelligence

The transformation of data into useful information to decision makers is known as business intelligence (BI) [55, 61]. Since agility and timeliness are increasingly important requirements for decision makers [118], there is an upsurge of interest in real-time business intelligence (RT-BI) that consists in analysing data as it gets into the organization, ideally with zero latency [76].

Regarding the timeliness of decision making, BI activities can be arranged into strategical, tactical, and operational dimensions. The first dimension addresses the accomplishment of long-term business goals through historical data. The second one is centred on short-term goals of the business, using historical data. Finally, the operational dimension manage and optimize daily business operations [50, 157]. In addition to the three above-mentioned dimensions, real-time can be considered as a fourth one, that characterizes RT-BI. RT-BI has a specific architecture usually found in several applications, such as anomaly detection, financial markets analysis, and in supply chain management [76].

Hang and Fong describe the underpinnings of the RT-BI architecture which is organized according to four layers [76]: business operational, real-time data processing, real-time analytics, and real-time presentation. The ﬁrst layer deals with the collection of historical data available in information systems (e.g. ERP, CRM, Financial, among other). The real-time data processing layer takes care of the collection and processing of the data that is arriving in real-time. Then in the real-time analytics layer, the system checks if there is a relation between the received data and an established model. If it exists the system matches the data with the rules and the business intelligence result is created. Otherwise, is used data-mining to discover new rules that will be added to the existing model. Finally, in the last layer a summary of the discovered information is returned and presented as the RT-BI result [76].

19 3.2 Industrial Solutions

Alarms are extensively used in industrial environments [128], particularly due to their ability in notifying the occurrence of anomalies requiring a timely user response to solve immediate problems. To understand how commercial solutions operate we identiﬁed the activities of fault detection and diagnosis and the fundamental methods used to detect and diagnose faults. Considering that we want to provide useful information to users we explored alarm quality requirements and consequently alarm processing techniques.

3.2.1 Fault Detection and Diagnosis

The process of detecting faults in physical systems and diagnose their causes is called fault detection and diagnosis (FDD) [91]. Formally, a fault is an unauthorized deviation of at least one system property [62]. The primary objective of a FDD system is to detect faults early and diagnose their causes, enabling the fault correction and consequently preventing service loss or equipment damage [91]. Since faulty equipment typically consumes more energy, an effective FDD also contributes to minimize energy consumption. In buildings, FDD can prevent 10 to 30% of the energy waste that is related with HVAC systems. However, FDD commercial tools supporting these systems only now are beginning to appear [71]. These tools should be designed to be adaptable to the users needs in order to meet their requirements [52]. FDD can be described as a process consisting of three activities, namely fault detection, fault isolation, and fault identification (described in Table 3.1). Fault isolation and identification activities are commonly referred to as fault diagnosis [62, 71]. FDD activities can be done manually (through visual inspection of charts and trends) or automatically. The automatic way is preferable because, for instance, in the context of building management HVAC systems are extremely complex and energy managers have very few resources available, especially in terms of time and tools [45, 71]. Automatic analysis also enables detecting problems faster [71, 102]. The existing methods used to detect and diagnose faults can be distinguished according to the knowledge used to formulate the diagnostics. They may be based on a-priori knowledge or driven empirically. A-priori knowledge defines a model to identify and evaluate differences between actual operating states and the expected ones. Approaches driven empirically do not use a-priori knowledge and derive be- havioural models exclusively from measurement data obtained from the monitored process, plant, or system [62, 91].

Activity Name Description

Fault Detection Determines that a fault has occurred in the system Fault Isolation Isolates the fault and determine its type, location, and time Fault Identiﬁcation Determines fault’s size and its time-variant behaviour

Table 3.1: The tree activities of fault detection and diagnosis [71, 91].

20 Usually the methods employed in commercial FDD solutions are rule-based methods, typically clas- siﬁed as ﬁrst-principle quantitative models. These methods use a priori knowledge to extract a set of if-then rules and an inference mechanism that searches through the rule-space to obtain conclusions. Rule-based methods also have some drawbacks, in particular [71, 91]:

1. The methods are speciﬁc to a system or a process.

2. It is difﬁcult to guarantee always the applicability of all rules, and to ﬁnd a complete set of rules, mostly when the system is complex.

3. These methods depend on the expertise and knowledge of the developer.

4. The simplicity is lost with the addition of new rules aiming to extend the existing ones or accommodate special circumstances.

3.2.2 Alarm Quality Requirements

An alarm system may not have a good alarm management when it shows symptoms related, for instance, with alarm floods, cascading alarms, or standing alarms (see Table 3.2)[137]. Despite the existence of some solutions, this problem is not solved yet [151]. Monitoring systems (as well as EMSs with alarm functionalities) generate a large number of alarms, overloading users with redundant information, a situation known as alarm flooding [21, 43, 104, 131]. The typical origin of alarm flooding occurs when a single fault or anomaly raises a lot of alarms in a short time interval [48, 131]. Another cause of alarm flooding is low quality data that often leads to false alarms [83]. Weak alarm management, especially in alarm flooding situations, hampers the capacity of users to accomplish their tasks. Indeed, it has been demonstrated that it is not possible to reliably interpret and act when a large number of alarms is generated [2, 48, 92, 104]. These aspects have been studied in other areas such as industry [87, 156] and medicine [93], where it has been reported that users ignore or

Symptom Description

Alarm ﬂoods Occurs when a large number of alarms are generated during abnormal situations, overloading the system user Cascading Group of alarms that always occur together alarms Nuisance alarms Alarms that are annunciated excessively and unnecessarily Standing alarms Users are continuously overloaded with alarms even in normal situations Usefulness alarm Alarm messages do not provide useful information to the system user messages Overload of high Excessive high priority alarms are presented to the user and due to this some of them priority alarms are not be treated according to their priority

Table 3.2: Symptoms of unsatisfactory alarm management [137].

21 Suppression method Description

Shelving A mechanism used by the user to temporally suppress an alarm Suppressed by design The alarm indication to the user is prevented by any system mechanism taking into account a condition different of the one used to deﬁne the alarm Out-of-service An alarm indication is temporally suppressed, for instance, during maintenance

Table 3.3: Methods for alarm suppression [7].

shut down the system in order to do their job correctly [53, 139]. Due to this, intelligent alarm processors have to address the following requirements [92]:

1. Reduce the number of alarms.

2. Give clues for the possible root cause of the problem.

3. Recommend a corrective action.

There are different alarm processing approaches that aim primarily at reducing the number of existing alarms, in order to present a manageable number of useful alarms to the user [159]. Some tools allow users to control what information is displayed using display selection and information masking [27]. Another class of techniques is related with alarm compression and alarm suppression. In alarm compression [135], multiple occurrences of the same alarm are replaced by a new generated alarm. Alarm suppression is a technique used to prevent the alarm indication to the user when the base alarm condition is true, examples of suppression methods are presented in Table 3.3[7]. An example of alarm suppression use occurs in the presence of multiple alarms where only the one with the highest priority is displayed and the other ones are temporary inhibited [135].

It is also possible to reduce the number of alarms by combining related alarms using grouping rules, applied for instance to the time between alarms and their types [131]. More informative alarm messages can be generated through the combination of simpler ones [2, 92]. Nuisance alarms can be reduced using on-delay and off-delay techniques. The first technique is used to prevent unnecessary alarms when a threshold is temporally exceeded, being the alarm triggered only when the threshold is exceed during a specified period of time. The off-delay technique, is similar and is used to lock the alarm indication during a defined period after the alarm trigger condition becomes false [7].

Traditionally, alarms are showed on a summary list chronologically sorted. During alarm ﬂoods, this approach presents a huge usability problem because an alarm summary disappears in the display, faster than the user can process it. Other disadvantage of this speed occurs when the user do not see high priority alarms being these ones untreated. An user interface strategy to deal with alarm ﬂoods, consists of using two separated lists, or panels, where primary and secondary alarms are split into distinct windows [29].

22 3.3 Languages Supporting Event Detection

Our solution will enable building energy managers to specify alarms involving complex conditions using a visual language. This section presents different visual languages supporting event detection, describing the provided elements and possible uses.

3.3.1 Automation Service Languages

A number of web automation tools have been emerging to support some forms of event detection. Services such as IFTTT (“if this then that”)1 and Zapier2 use trigger-action programming, where recipes containing a trigger and an action, selected from a predefined catalog, are created to define the system behaviour [110, 145]. This kind of tools were used in home automation by Ur et al. In this research, there are two types of recipes, one where only a single trigger and a single action are used (simple interface), and another where each recipe may have multiple triggers and actions channels (complex interface). All triggers are combined using the “AND” operator, and to create a recipe users have to select a channel and a specific event or action built into that channel [145].

3.3.2 Visual Programming Languages

Visual programming languages emerged to help non-programmers in the development of simple software applications [10, 109]. Examples of visual programming languages include Scratch 3, BYOB/SNAP! 4, Google Blockly 5, MIT App Inventor 6, Lego Mindstorms 7, and Waterbear 8 [11]. Scratch is used as ﬁrst step into programming in universities, such as Harvard and University of California, Berkeley, and is also used in elementary and high schools [127]. These languages present procedimental constructs, including, for instance, sequences, loops, and conditionals [10]. MIT App Inventor is a drag-and-drop visual programming tool for designing and building mobile applications for Android that uses a trigger-action programming model. Its interface has two elements, namely a Designer used in the selection of the application components, and a Blocks Editor used in the deﬁnition of the application behaviour in order to reduce the frustration level experienced in text-based programming environments. The blocks library include conditionals, procedures, variables, and data structures [122]. Nowadays, this programming language, like Scratch, is used in colleges, high-schools, and universities [144, 152]. In order to make household devices programmable to users without prior experience in programming, Ash et al. propose a solution based in BYOB, a variant of Scratch [10]. They propose that each of

1https://ifttt.com/ 2https://zapier.com/ 3http://scratch.mit.edu/ 4http://byob.berkeley.edu/ 5https://code.google.com/p/blockly/ 6http://appinventor.mit.edu 7mindstorms.lego.com 8http://waterbearlang.com/

23 the language primitives be object centred because users see each device as a separate object. Inputs for this language consists of data from sensors, physical interaction with individual devices (e.g. a button pressed by a user), and state queries (like “Device Is On?”). State changes will be the output of each object. This solution enables each device to communicate with the others, for instance a toaster can send the message “Turn On Coffe Maker” and a coffee maker would listen the broadcast and responds ap- propriately because it has the corresponding script written by the user. Iteration, conditionals, relational and logical operators are the control structures supported by this solution. Other areas of research are also using and developing visual query languages. Some examples include visual programming languages used in multimedia [54, 155], robotics [160], XML manipula- tion [143], and creation of a language used for computer-aided music composition [26].

3.3.3 Languages for Industrial Environments

Industrial environments are characterized by an ample variety of equipment, especially sensors, which continuously produce many data streams, making difﬁcult to industrial engineers and data analysts to query and interpret data. Bauleo et al. proposed a visual query system that runs on top of a DSMS enabling users, namely industrial engineers, to graphically build queries over data streams [20]. This solution supports visual queries connecting the query elements available in the visual query editor. Types, functions, selections, and conditions are the fundamental visual query elements. Where selections and conditions represent the elements that will be mapped into the select and where clauses of the queries. The boolean operators “AND” and “OR” are supported in the condition clause of the queries. Queries built with this solution can be used by industrial engineers to monitor systems, processes, and products, evaluating their current state, and detect and diagnose abnormal behaviour [20].

3.4 Stream Processing Engines

Stream processing engines (SPE) appear motivated by the need to process a wide quantity of arriving data in a timely way. In addition to produce results in a timely manner, they enable the deployment of queries on the ﬂy and are prepared to run multiple queries simultaneously [1, 12, 47, 123, 140].

3.4.1 Stream Processing Engine Approaches

Despite having the same goal, distinct SPE systems display a number of differences between them related with data models, processing mechanisms, query languages, and architectures. Two main models of SPE have emerged: Data Stream Management Systems and Complex Event Processing Systems [47]. We describe them in turn.

Data Stream Management Systems aim at processing multiple input data streams and provide new data streams as a result [12]. They can be viewed like an evolution of DBMSs in order to support

24 the processing of streaming data. In fact, DBMSs engines were used as a basis to design some of the original DSMSs [73, p.29], like NiagaraCQ [38], TelegraphCQ [134], and Cougar [158].

Complex Event Processing Systems treat the input as a stream of event notiﬁcations, which need to be ﬁltered and combined to reason what is happening in terms of higher-level events. The target of this model is to detect patterns of (low-level) events, on the event sequence, and produce more complex ones, that express events with an higher level, that have to be announced to the interested parties when they occur [47].

Another difference between DSMSs and CEPSs is the language model used. CEPSs use a pattern- based language model (e.g. CEL [51]), in contrast with DSMSs that use a declarative model (e.g. CQL [8]) or an imperative language (e.g. SQuAL [32]). Despite the existence of differences between DSMSs and CEPSs, Chakravarthy and Jiang argue that a CEPS complements a DSMS. Indeed, these authors argue that a combination of a DSMS and a CEPS is essential to many stream-based applications [33]. Esper 9 is an example of a DSMS that presents language capabilities for data and event stream processing as well as for pattern matching.

3.4.2 Query classiﬁcation

Taking into account the users requirements a query can be classiﬁed based in a number of criteria, such as: frequency, trigger-mechanism, result accuracy, and delay of query results [12, 65].

One-time vs continuous queries One-time queries are evaluated only once over the current state (snapshot) of the database being the result returned to the user. On the other hand, continuous queries are continuously evaluated against the arriving data streams. The result of the continuous query evaluation is another data stream or a value that is constantly updated in order to reﬂect the last arrived data stream.

Predefined vs ad-hoc queries Predefined queries are supplied to the system before the arriving of data, enabling the system to evaluate them in a more efficient way. Ad-hoc queries are registered in the system after data has already started to arrive.

Spatial-aggregate vs temporal-aggregate queries In a spatial-aggregate query users request data aggregated from different sensors. Temporal-aggregate queries are the ones where data is aggregated from an unique sensor in different points of time.

Time-based vs event-based queries A query triggered by a timer that expires in a regular way, for instance every half hour, is called a time-based query. The result of an event-based query is created when a deﬁned condition is satisﬁed, for example when the temperature returned by a sensor is above 100 degrees.

Accurate vs approximate queries Approximate queries show the error tolerance of users including an error threshold. This kind of errors has as origin, for instance, faults during the collection of data in

9http://www.espertech.com/products/esper.php

25 sensors or in data propagation because of node and link failures. Accurate queries are the ones where an accurate result can be provided to the users.

Urgent vs delay-tolerant queries In an urgent query the response time is critical in contrast with delay- tolerant queries. A possible example of urgent queries may be the ones used to detected volatile issues, like a room with its lights turned on and nobody inside it. In this example, a timely detection enables a corrective action that would not be possible if the problem was only detected when too much time has passed.

3.4.3 Stream Query Languages

Stream query languages support the speciﬁcation of continuous queries over unbounded data streams. There are two classes of operators, namely blocking and non-blocking operators. When an operator needs to read the entire data stream to produce results we are in the presence of a blocking operator. On the other hand, non-blocking operators are able to produce results as tuples enter the system. An important concept of stream query languages is the notion of window criterion that denotes a ﬁnite subset of tuples over which other operators can be evaluated. Otherwise, the entire data stream would have to be considered, but this is impossible in practice [39, 65].

There are several examples of stream query languages including: CQL [9], SQuAl [1], ESL [13], StreamSQL 10, EQL 11, and StreaQuel [134]. The main difference between the existing languages is the approach followed about the stream processing requirements, namely: language closure, windowing, correlation, and pattern matching. Language closure is related with the capabilities of the query operators, namely if they are able to receive relations as input additionally to data streams. From the previous examples of languages, in the EQL and SQuAl languages each operator accepts streams as input and produces streams as output. The remaining languages support both data streams and relations.

The windowing requirement focuses on the treatment of time windows as a ﬁrst-class feature of the language, i.e. windows that can be named, deﬁned as the result of a query, and that can be accessed by subsequent windows. Correlation has to do with the ability of the language to correlate data stream tuples with tuples appearing on historical data or on another data stream.

Finally, the pattern matching requirement addresses the capacity of a language to identify patterns. It can take two forms, namely single-stream and multi-stream pattern matching. The first one identifies patterns on a single stream using, typically, a matching language based on regular expressions to express the desired patterns. The second one finds patterns that appear on separate streams, instead of a single data stream. An overview of how stream query languages implement these requirements is presented in Table 3.4[39].

10http://www.streambase.com/products/streambasecep/streamsql 11http://esper.codehaus.org/

26 Language

Requirement CQL SQuAl ESL EQL StreamSQL StreaQuel

Operators receives streams • ◦ • ◦ • • and relations as input First-class Windows • ◦ ◦ • ◦ • Correlation •••••• Pattern matching ◦ ◦ ◦ • • •

Table 3.4: Examples of stream query languages and their support to the stream processing requirements (adapted from [39]), where stands for supported feature and stands for unsupported feature. • ◦ 3.4.4 Stream Query Languages Operators

The operators that a stream query language may provide to transform and retrieve meaningful information from the gathered data streams are presented below [47]. Some of the queries operators are inspired on SQL operators and relational algebra [59].

Single-item operators are a class of operators that process data stream tuples one by one, being each tuple evaluated independently.

Selection Filters tuples of a stream according to their content, keeping only those that respect a given constraint.

Projection Extracts parts of the information contained in the tuple.

Extended Applies a transformation, also known as user-deﬁned function, to the contents of a tuple. Projection An example is the conversion from Celsius to Fahrenheit of a room’s temperature reading.

Window operators enable the production of the query results using only a sub-finite part of the stream, instead of the entire stream [39, 65]. The window boundaries can be defined as a function of time (e.g. all collected tuples during the last 5 minutes) or as a function of the tuples inside the window (e.g. the last ten tuples collected). Windows can be classified considering the movement of their boundaries into the following classes:

Fixed A window with ﬁxed boundaries. For instance, it could be used to process stream tuples Window received between [18h, 20h].

Landmark A dynamic window with a ﬁxed lower bound, while the upper bound advances when new Window stream tuples are received. An example of use is to process stream tuples between [18h, now].

Sliding A dynamic window with a ﬁxed size, where the lower and upper bounds advance when Window new stream tuples are received. Could be used to process the stream tuples of the past 2 hours [now-2h, now].

27 Pane and Are variants of sliding windows, where the lower and upper bound moves k tuples, when k Tumble tuples are received. Pane windows have a size greater than k, on the other hand, tumble Windows windows have a size smaller or equal to k. A tumble window ensures that whenever the window moves all the elements inside them change, this is not veriﬁed by pane windows.

Logic operators enable the deﬁnition of detection rules in order to assess the existence of patterns on the data stream tuples. Unlike sequence operator (see below), these rules are order independent, i.e. they do not rely on the order in which the tuples are detected, instead they only consider the detection (or non detection) of tuples.

Conjunction A conjunction of tuples T1, T2, ..., Tn is satisﬁed when all the tuples T1, T2, ..., Tn have been detected in the data stream.

Disjunction A disjunction of tuples T1, T2, ..., Tn is satisﬁed when at least one of the tuples T1, T2, ..., Tn has been detected in the data stream.

Repetition Repetition of tuple T is satisﬁed when it is detected at least m times and less than n times in the entire data stream. Where m and n are customizable parameters.

Negation A negation of a tuple T is satisﬁed when T was never detected in entire stream.

Repetition and Negation are blocking operators and due to this they need to consume the entire stream to produce results. This means that in the presence of an unbounded data stream they may block for- ever. Considering this fact they must be combined with a window operator.

Sequence operators are similar to the logic operators in that they allow the definition of sequence pattern rules to detect tuples in a given stream. However, sequence operators take the tuple order of arrival in consideration, i.e. a sequence rule that defines an ordered set of tuples T1, T2, ..., Tn is satisfied when all the tuples belong to the data stream in the specified order T1, T2, ..., Tn.

Iteration operators are a generalization of the sequence operators [81]. Iterations detect possibly unbounded sequences that respect a certain iterating condition. As sequences, iterations consider the tuples order of arrival, however the set of tuples to be captured are not deﬁned explicitly, but instead implicitly, using an iterating condition that deﬁnes the constraints that tuples should respect. Iteration operators are blocking and should be used with window operators.

Flow management operators are operators used to merge, split, organize and process data streams. Examples of these operators include: join, union, except, intersect, duplicate, remove-duplicate, group- by, and order-by.

Aggregate operators apply a transformation to a group of tuples to produce new aggregate information. In addition to the common built-in aggregates like AVG, MIN, MAX, and SUM, some languages allow the

28 Characteristic DBMS DSMS

Query Type One-time Continuous Result Type Accurate Approximate Memory Use Unlimited Restricted Data Access Multiple Unique Time to Process Data Unlimited Restricted Update Frequency Rate Low Continuously Blocking Operators Use Allowed With modiﬁcations

Table 3.5: Some differences between DBMS and DSMS [33, 67, 70]. user to create new ones (user-deﬁned aggregates). These operators are blocking operators and their usage must be combined with a window operator.

3.4.5 DSMS vs DBMS

The computational model of data streams presents some differences to the persistent relational model that have implications in the computational requirements and, thus, in the scalability of EMSs. Database Management Systems (DBMSs) only processes data after they have been stored and indexed, introducing an unacceptable penalty on the data processing latency [47, 140]. In contrast, DSMSs produce results in real-time, therefore they are time restricted. Due to the fact that data streams arrive continuously, one distinctive aspect of DSMSs is the fact that they process continuous queries, while DBMSs process one-time queries. As we seen before, since it is unfeasible to store an entire data stream in memory, to deal with unbounded data streams is necessary to use bounding techniques, like windows, to consider only a sub-ﬁnite part of the stream. These techniques enable, for instance, the use of blocking operators, but they have as drawbacks the production of approximate results. Because data streams are transient, fundamental differences between DBMSs and DSMSs have emerged as showed in Table 3.5[12, 47]. DSMS appear more adequate to be used in monitoring applications, because they are able to run the same query continuously over streaming data and produce results in due time [33, 67, 140]. Ap- plications to monitor data from health sensors [89, 161], network trafﬁc [4, 46, 141], and stock market transactions [35] are examples of monitoring applications that use a DSMS and because of this they are able to achieve better results.

3.5 A Survey of existing EMS

A large number of EMSs are currently available in the market. However, many of the existing solutions are proprietary being unfeasible to acquire a paid license to evaluate each of them. Due to this, this survey is limited to the available documentation and overviews. In addition, the documentation provided by product manufacturers is scarce and rarely discloses any technical information. For example, the

29 Features

Systems Real-time Monitoring FDD Alarms Alarm Personalisation Alarm Creation EEMSuite † –– –– EnergyWitness •† ––•• –– –– –– EnerwiseEM • OpenEIS ◦ •–– • –– ◦ ––◦ ESightEnergy ––◦ •–– ∗ Cylon Active Energy Manager ••∗ ◦∗ Noveda EnergyFlow Monitor ••••∗ • Wisemetering ––• ◦ • • ◦ Gridpoint EMS ◦ • ◦ ◦ • ◦ • ◦ ◦ Table 3.6: Survey of Energy Management Systems, where stands for supported, stands for not supported, and - stands for unknown information. systems that• respond in near real-time.◦ unknown how it is implemented. † ∗

systems are classified as real-time, but the time scale of their timeliness is not specified. Other example is related with alarm personalisation and creation. Generally, manufacturers do not provide sufficient information about how users personalise and create alarms, instead they just state that these features are available without specifying to what extent.

This survey presents what we believe to be a representative sample of existing EMSs solutions on the market. The systems are evaluated by their ability to present results in real-time, provide FDD and alarms. In this last feature, it is also analysed if the systems enable users to personalise or create alarms.

The results of this survey are illustrated in Table 3.6, where the general features are identiﬁed to each of the analysed solutions, namely: EEMSuite [108] 12, EnergyWitness 13, EnerwiseEM 14, OpenEIS 15, Esight 16, Cylon VoyaXplor 17, Noveda EnergyFlow Monitor 18, Wisemetering 19, and Gridpoint EMS 20.

In conclusion, to the best of our knowledge, most solutions do not allow users to create or personalise alarms. Another important aspect is related with the use of a DBMS or DSMS as a solution base. At least four of the surveyed solutions (EEMSuite, EnergyWitness, EnerwiseEM, and OpenEIS) have a DBMS as their main data processing infrastructure instead of a DSMS. This observation is in line with the results of this survey where most systems do not provide results in real-time.

12http://www.mckinstryeem.com/eemsuite/overview.html 13http://www.intdatsys.com/EnergyWitness.htm 14http://www.enerwise.com/energymanager.php 15http://eis.lbl.gov/openeis.html 16http://esightenergy.com 17http://www.cylon.com/products/energy-management/voya-xplor.html 18http://www.noveda.com/solutions/energy-management/energyflow-monitor 19http://about.wisemetering.com/ 20https://www.gridpoint.com/enterprise-software/

30 3.6 Systematization of Alarm Conditions

To develop a DSL to enable building energy managers to specify alarms it is necessary to comprehend the domain. Thus, we performed a literature review and interviews with experienced building energy managers. The literature review aims to identify a set of relevant alarms in the building energy management domain, and was conducted according to the following planning:

Literature Review Question aims at identifying a set of alarm conditions that can be used to do real- time anomaly detection through alarms, helping the building energy manager activity. It must be possible to convert these alarm conditions into continuous real-time queries that will be executed in a DSMS using time series records produced by energy meters and other sensors (e.g. temperature, occupation, and equipment status) installed in buildings.

Search Strategy is based on two fundamental sources, namely the available online literature related with the review objectives, and consultations with experts in the ﬁeld. The sources used in the literature review are the following: (i) Science direct, (ii) IEEE Xplore digital library, (iii) ACM digital library, (iv) Springer link, and (v) Google scholar.

The search terms used include “alarm” or “alert” as main terms since the objective is to identify a set of alarm conditions. Considering the domain where we want to apply these alarms we used also the following terms: “energy”, “management”, “energy management system”, “EMS”, “BAS”, “monitoring”, “building”, “performance indicator”, “condition monitoring”, “pattern”, “query”, “fault detection and diagnosis”, and “anomaly”. This set of terms aim to represent the domain (i.e. the building energy management) and the systems used like EMS or Building Automation System (BAS). This last system is used as a term because, according to Granderson et al. [71], the terms EMS and BAS refers to similar systems. So, the complete search term used is: (“alarm” OR “alert”) AND (“energy” OR “management” OR “energy management system” OR “EMS” OR “BAS” OR “monitoring” OR “building” OR “performance indicator” OR “condition monitoring” OR “pattern” OR “query” OR “fault detection and diagnosis” OR “anomaly”).

Selection Criteria takes into account the recommendations of Kitchenham [94], in order to reduce the probability of bias. Therefore, this review applies a selection criteria where all literature containing queries related with anomaly detection or examples of alarm conditions in the building energy management context are included. On a second phase all queries should respect a number of requirements such as: (i) being executed in real-time and (ii) can be translated into an alarm that matter to building energy managers.

After reviewing literature we concluded that, to the best of our knowledge, there is no alarm systematization in the building energy management domain. However, during the literature review, we identiﬁed several examples of alarm conditions, which are presented in Table 3.7. There are, for instance, alarms related with temperature or energy consumption measurements, associated with an equipment or a spe- ciﬁc building zone. In addition, there are alarms represented as thresholds or variations. Also, some

31 Id Description of the alarm condition found Adapted from

1 The energy consumption of a zone is above a certain threshold [23, 63, 69, 99, 107] 2 A building zone has an unexpected energy consumption considering its occupation [40] 3 The energy consumption of the last X minutes has seen an increase of N percentage [36] 4 There are repeatedly large variations in the energy consumption [36] 5 The actual energy consumption is higher than the consumption of the last day or month [49] 6 The energy consumption is reaching zero in a faster way [132] 7 The average, minimum, or maximum of the power input is below or higher than a certain [49, 99] threshold 8 Voltage is below or higher than a certain threshold during a certain time period [107] 9 There is no N percentage buffer between available power capacity and current demand [132] 10 The minimum or average of the energy produced in the building is below a certain [49] threshold 11 The energy consumed is N times higher than the energy produced in the building [49] 12 The quantity or sale value of the energy sold to external entities is below a certain [49] threshold 13 Energy cost per square foot per year is higher than a certain threshold [49, 63] 14 Considering the actual energy consumption within ﬁve days the cost per square foot is [63] above a certain threshold 15 Energy tariff is above a certain threshold [30, 99] 16 Energy tariff has an increase or decrease of N percentage during a certain period of [63, 99] time 17 Two sensors with a distance of N meters between them have an unexpected energy [24] consumption 18 Temperature of a zone is below or above certain threshold [63, 77, 78, 84, 101] 19 Temperature of an empty zone of the building is below or above certain threshold [69, 142] 20 Besides the HVAC equipment is turned on, a zone of the building registers during a [84, 133] period of time a temperature below or above certain threshold 21 An equipment is consuming more than N Watts [69, 84] 22 An equipment needs to be repaired [25, 63, 78] 23 An equipment is turned on and it is not being used [40, 41, 49, 113, 129] 24 An equipment is turned on more than a certain period of time [30] 25 Multiple equipment are turned on simultaneously [69] 26 The minimum, maximum, or average of the occupant Comfort index is below or above [63] certain threshold

27 Tuple arrival frequency does not respect an interval n1 sec.

29 A zone registers a CO2 increase after a decrease of the energy consumption [6]

Table 3.7: Alarm conditions gathered from the literature review.

32 Alarm Type Alarm conditions

Absolute 1, 2, 4, 5, 7, 8-15, 17-19, 21, 24, 26, 27 Deviation 3, 4, 11, 16 Change rate 3, 4, 6, 16 Discrepancy 23, 25, 28, 29 Calculated 1-29 Statistical 1-29 System diagnostic 20, 22

Table 3.8: A possible classiﬁcation of the alarm conditions gathered from the literature review, where the id of the alarm conditions correspond to the ﬁrst column of Table 3.7.

alarms are activated according to the outcomes of certain conditions or taking into account the period during which the condition holds.

Despite the simplicity of the alarm condition with id 1, it contributes, for instance, to prevent exceeding the energy consumption maximum peak demand, after which the energy tariff rate increases. Alarm condition 6 is used to ensure the timely detection of when to turn on auxiliary energy generators. To prevent energy waste in empty building spaces we can use alarm conditions 2, 19 and 23. The detection of these conditions depends on the availability of energy consumption, temperature, and occupation data. Finally, alarm conditions 24 and 25 are related, for instance, with the use of equipment with high consumption. They prevent the use of several equipment simultaneously, or restrain equipment working hours. These are examples of goals that motivate the existence of some of the identiﬁed alarms.

In addition to the previous literature review, we have performed interviews with experienced building energy managers. This enabled the identification of other related data, namely water and gas consumption, interior humidity, and CO2 emissions. We also identified that building activities may vary on a daily basis, and due to this, it may be necessary to specify alarms to each day of the week. Finally, we also identified that it may be required to have alarms to detect repetitions (e.g. a sensor may report an unexpected energy consumption 3 times within the last 60 minutes). Using this kind of alarms it is possible, for example, to detect equipment malfunctioning or to reduce the number of alarms, because the alarm is only activated when its trigger condition is true a given number of times during a certain period of time.

Considering the examples of alarm types presented in Table 2.2, all the gathered alarms may be classified as calculated and statistical since they are generated based on statistical processing of one or more variables (i.e. the direct measures). To this classification we consider that even the alarm condition with id 1 — “The energy consumption of a zone is above a certain threshold” — needs to be aggregated in a specific way to obtain, for instance, the hourly average of energy consumption. A possible classification using these alarm types is detailed in Table 3.8.

33 3.7 Discussion

From this study of related work, it is possible to draw several conclusions. First, we can conclude that detecting alarm conditions in the energy domain include the following requirements:

1. The integration of several different data sources, in order to gather relevant data necessary to produce useful information.

2. Input data assumes the form of potentially unbounded data streams.

3. The detection of alarm conditions must occur in a timely way, preferably in real-time or near real- time.

4. It is necessary to run multiple alarms simultaneously.

5. Considering the huge number of possible alarm conditions it is necessary to consider several different mechanisms to detect them. An example of a possible mechanism is the detection of a value above a certain threshold.

6. The detection of an alarm condition, in addition to the data streams currently entering the system, may require some reasoning about historical data. An example occurs when an alarm has a condition like “a sensor reports 3 times an unexpected consumption within the last 60 minutes” where it is necessary to count the number of occurrences of a speciﬁc event.

As explained in Section 2.3.2, due to the challenges of dealing with a large volume of continuously incoming data in a data stream scenario, most of the traditional anomaly detection techniques cannot be directly applied. Thus, it is possible to conclude that it is difficult to apply automatic techniques to define and detect complex alarm conditions. However, existing stream query languages (provided by SPEs such as DSMSs), and the operators supported by them (described in Section 3.4.4), have enough power to express such complex conditions through continuous queries. In addition to this, DSMSs are able to process multiple data streams as input, to produce results in a timely way, and to run multiple queries simultaneously. The different alarm processing approaches (presented in Section 3.2.2) are important to design and implement alarm systems, especially regarding user interfaces where alarms are presented. Despite they are not directly related with the specification of alarm conditions, these approaches (e.g. on-delay techniques) are useful in alarm specifications in order to reduce the number of alarms. During the alarm management life-cycle (described in Section 2.2.1) it is necessary to modify or to create new alarms preferably without the need to shut down the system. Thus, considering the capability of DSMSs in deploying queries on the fly this requirement is satisfied. Finally, we note that a DSMS is able to satisfy all the enumerated requirements about the specification and detection of alarm conditions. Considering this observation it appears to be a good approach to use a DSMS as underlying technology of a system that aims to support building energy managers to specify domain specific alarms involving complex conditions. However, to the best of our knowledge, this kind of solutions are not currently available.

34 Chapter 4

Solution

Stream query languages (provided by SPEs such as DSMSs), and the operators supported by them (described in Section 3.4.4), have enough power to express complex conditions regarding alarms through continuous queries. Additionally, DSMSs are able to process multiple data streams as input, to produce results in a timely way, and to run multiple queries simultaneously. Finally, using domain notions a DSL becomes more expressive, resulting in a language that is easier for users to learn, understand, and apply for a specific problem category [96, 112, 164]. Considering these facts, this work aims to create a visual DSL and an alarm system to support building energy managers on the specification of domain specific alarms involving complex conditions. The alarm system has a DSMS as underlying technology, and on the system interface users use the visual DSL to specify the alarm conditions. First, this section presents an architecture overview of the proposed solution. Then, the visual DSL is developed according to an iterative process based on the literature.

4.1 Architecture Overview

Our solution is organized into three stages: information presentation, data processing, and data acquisition (see Figure 4.1). The information presentation stage is a sophisticated user interface comprising a Visual Alarm Editor and an Alarm Dashboard. This interface was developed considering the standardized characteristics for good alarms described in the EEMUA 191 guideline [56], and the alarm life-cycle described by the ANSI/ISA 18.2 alarm standard [7]. Using the Visual Alarm Editor users can create alarms by dragging and dropping blocks, where each block corresponds to a language primitive. This language, which we refer as Alarm Speciﬁcation Language (ASL), comprises a number of fundamental operators that enable users to specify alarms using complex conditions. In the data processing stage, the alarm system translates the user speciﬁcation into a continuous query representing the alarm trigger condition. This query is installed on a DSMS in order to be continuously evaluated, being the results of its evaluation forwarded to the alarm manager. This last module will process the query results generating an alarm and related information, including the alarm timestamp,

35 Figure 4.1: Solution Proposal Architecture. From left to right: the Data Acquisition Stage composed of data streaming sources; the Data Processing Stage responsible for the creation and evaluation of the continuous queries that represent the alarm conditions; the Information Presentation Stage presents the alarm dashboard and enables expert users to create new alarms. priority, and corrective action. The generated alarm and its information will be displayed in the alarm dashboard, enabling users to act and correct abnormal situations in due time. Finally, a DBMS is used in the data processing stage to provide persistent data management. The data acquisition stage acquires data streams from several sources like energy meters, equipment sensors, and environment sensors. This data is forwarded on to the data processing stage where it will be integrated and cleaned. The main purpose of this phase is to combine several data streams, in order to formulate a new set of data streams, with a well deﬁned and agreed upon schema, underlying the semantics of the energy data problem domain.

4.2 Alarm Speciﬁcation Language

According to Voelter et al. [148], the development of a DSL is an iterative process composed of four stages, namely: domain analysis, design, implementation, and validation. In the case of a DSL to enable building energy managers to specify alarms involving complex conditions the ﬁrst stage, i.e. the domain analysis, consists in identifying the essential set of alarms in this domain and understand the terms that are necessary to construct them. Using these concepts the language can then be designed and implemented. Finally, in the last stage the language is validated with building energy managers, i.e. real users, to understand, for example, the level of usability and expressability of the language. With the feedback gathered in this stage we performed some improvements in the language. Indeed, although this stage is sometimes neglected, validation with real users is essential since it enables improvements that can be achieved in the next iteration of the development process [16, 64].

36 4.2.1 Literature-based Domain Analysis

To develop the ASL the ﬁrst step is to comprehend the domain. Thus, we used the results of the systematization of alarm conditions presented in Section 3.6. Through a literature review and interviews with experienced building energy managers, the systematization identiﬁes a set of relevant alarms in the building energy management domain. Therefore, from the results of the domain analysis we can conclude that the alarm conditions:

1. May require data from several sources, such as: energy consumption, energy cost, energy tariff,

voltage, power input, produced energy, energy sold, CO2 emissions, interior temperature, exterior temperature, water consumption, gas consumption, interior humidity, and data arrival frequency.

2. May need to access historical data.

3. May require data aggregation, using for instance the average operator (see Section 3.4.4).

4. Detect that a threshold is reached or that a variation occurs over a certain period of time.

5. Can be considered true only when some requirements are respected. Examples of these requirements include for instance: that a condition is true continuously during a certain period of time; a condition is true multiple times over a certain time period; and a condition is true only in certain days or time periods. Some of these requirements may be related with techniques used to reduce the number of alarms. For instance, the ﬁrst requirement is the on-delay technique used to reduce nuisance alarms (see Section 3.2.2).

6. Can include sub-conditions, using for example logical and sequence operators (see Section 3.4.4).

4.2.2 Language Design

Using the results of the domain analysis it is then possible to define the language elements necessary to construct an alarm specification (i.e., an alarm trigger condition). These elements, depicted in Figure 4.2, are divided in seven groups, namely: Source, History, Aggregation, Forecast, Threshold, Variation, and Optional Detectors. The last three groups are detectors — enable the detection of a condition — being the use of a Threshold or a Variation mandatory, in contrast the use of Optional Detectors is optional. The language elements have input and/or output ports in order to share data between different elements; additionally they have fields where users introduce more data related with the alarm specification. The language is the following:

Sources enable users to specify the data source to be used in the alarm. Since this kind of language element only speciﬁes the source of data, it is possible to create new source elements without having to modify the remaining elements of the language. The sources available include: Energy Consumption, Energy Cost, Energy Tariff, Voltage, Power Input, Produced Energy, Energy Sold,

CO2 Emissions, Interior Temperature, Exterior Temperature, Water Consumption, Gas Consump- tion, Interior Humidity, and Data Arrival Frequency. These elements, except the Energy Tariff and

37 Figure 4.2: Elements of the Alarm Speciﬁcation Language.

the Data Arrival Frequency, having an option ﬁeld to select the id of an equipment or of a building zone enable users to be more selective about the data sources. In addition to these options the Energy Sold element has another to select if the energy sold data is about the sale value or the quantity of energy sold. The Energy Tariff and the Data Arrival Frequency elements allow only to

38 select the id of a building zone and of equipment, respectively. Other possible option ﬁeld that could be added to the Sources is one to select the unit, for instance Watt or Kilowatt for energy data.

History enables obtaining historical data and there are two possible elements, namely Simple History and Period History. The Simple History element enables the creation of a sliding window (see Section 3.4.4) having two option fields. In the first one, the user introduces an integer number that specifies the window size. In the second option is specified the granularity of the window size, i.e. one of the following: minutes, hours, days, week, month, and year. The Period History, in addition to the Simple History options, enables the specification of a time period, enabling for instance to specify that we want the historical data relative to the 10:00 to 17:30 period of the last month. However, the granularity of the window does not include the minutes and hours options.

Aggregation is used to specify how to aggregate data provided by the Source or History. One can aggregate data per minute, hour, day, week, month, and year using minimum, maximum, or average operators (see Section 3.4.4). An example of a possible utilization is to specify that we want the hourly average of the data provided by the Source element.

Forecast consists in estimating the future of the value received from the Aggregation element. This element has two option ﬁelds relative to the deﬁnition of the period for which there is a forecast. A possible use of this language element is to enable the earlier detection that an alarm condition will become true within a given time period considering the data provided by the Aggregation element. This way, it is possible for instance to predict that a threshold is reached or a variation is going to occur within a given period, enabling a corrective action before the situation actually occurs.

Thresholds detect that a certain limit is reached. There are three types of thresholds, namely: Lower Limit Threshold, Upper Limit Threshold, and Within Threshold. The ﬁrst one detects that a lower limit is reached, i.e. a value decreases and reaches the limit. The Upper Limit Threshold detects that a upper limit is reached, i.e. a value increases and reaches the limit. Using the Within Threshold it is possible to detect when a value is inside a [lower limit, upper limit] range. These three types of thresholds can have different arity of input ports, namely unary and binary (ternary in the Within Threshold case). In case of unary Thresholds the user has to specify manually the limit’s value. On the other hand, when they are binary the second input port receives the limit’s value from the element connected to that port. The ternary Within Threshold is similar, however it receives the data to analyse on the ﬁrst input port, receives the lower limit’s value on the second port, and on the last input port receives the upper limit’s value. When using binary or ternary thresholds the user can specify that the limit’s value will be a percentage of the value received as input.

Variation detects fluctuations of a value received from the first input port. There are two types of Vari- ation elements depending of its arity, namely unary variation and binary variation. Unary variation detects the variation of a value during a specified period of time. It has four option fields. The first

39 two fields specify the variation percentage and if the user wants to detect an increase or decrease. The other two fields determine the size and granularity of the sliding window where it is expected to detect a variation. Using the unary variation it is possible to detect, for instance, that a value had an increase of 25% over the last 5 minutes. The binary variation detects a variation comparing the value obtained from the first input port with the value obtained from the second input port. This way, one can detect, for example, that the value obtained from the first input port is 25% higher relatively to the value provided by the second input port.

Optional Detectors are a group of elements that enable the speciﬁcation of alarm conditions with a higher level of abstraction. There are two special elements, namely Occupation and Working Equipment, that work both as data sources and detectors.

Repeat detects that a given situation occurred a given number of times in a sliding window. This element has 3 ﬁelds. The ﬁrst one receives the number of repetitions and the other two specify the size and granularity of the sliding window.

During detects that a condition is true during a given period of time (speciﬁed using the two available ﬁelds).

Within narrows the alarm condition to specific days or time periods. There are two types of Within, namely Simple Within and Period Within. The Simple Within has a field where the user selects the day (i.e. Sunday to Saturday) or day type (e.g. weekday, week- end, holiday, spring, summer, autumn, and winter) during which the alarm condition becomes true. In addition to this field, the Period Within element has a field to specify a time period, for instance the 10:00 to 17:30 period.

Followed provides a way to specify a high level alarm condition that deﬁnes an order between By the occurrence of sub-conditions. It has an input port where the inputs order speciﬁes the order in which the sub-conditions must occur. Using this element it is possible to specify for instance that an alarm condition becomes true when a variation occurs followed by the excess of a threshold.

And speciﬁes that a high level alarm condition becomes true when multiple sub-conditions are true simultaneously. The sub-conditions are provided by the elements connected to the input port.

Or speciﬁes that a high level alarm condition becomes true when one of multiple sub- conditions (provided by the elements connected to the input port) becomes true.

Occupation detects if a zone is empty or not. This element has two fields. In the first one the user specifies the id of the building zone. The second one specifies if the user wants to detect an empty zone or not.

Working detects when an equipment (selected by the user using the available ﬁeld) is working. Equipment A possible way to detect that an equipment is working consists in detect that its energy consumption is bigger than zero Watts. Using this language, a possible way

40 to specify this condition consists in the use of three elements namely: an Energy Consumption source, an Aggregation — in order to get the maximum consumption, and an Upper Limit Threshold — to detect consumptions higher than zero. In order to make this language easier to use we developed the Working Equipment element as syntactic sugar to the previously mentioned condition. Using this element users are able to specify that an equipment is working in an easier and faster way. In addition to these reasons, this element prevents the speciﬁcation of erroneous conditions.

The language elements presented aim to detect different patterns, and therefore, its behaviour can be classified according to the types of patterns described in Section 2.4. A Source, History, Aggregation, Occupation, and Working Equipment aim to select a subset of events using various criteria, thus they expose subset selection patterns. Threshold elements detect threshold patterns, aiming to detect that a certain limit is reached. The Forecast and Variation elements detect trend patterns because they trace the value of an attribute over time. Having to check that an assertion is satisfied the During and Within elements detect modal patterns. The Followed By and the Repeat elements detect temporal order patterns, namely the sequence pattern where time plays a fundamental role. Finally, being based on logical operators the And and Or elements detect logical operator patterns. These classifications are summarized in Table 4.1.

4.2.3 Language Syntax

After the identification of the language elements, the next phase is the definition of the language characteristics and the relation between the language elements, namely the language syntax. Despite being visual, the language syntax define the rules to form syntactically correct sentences to specify meaningful alarms (i.e. which can be assigned semantics) [22, 126]. The language elements have in its visual representation input ports (ports represented by an empty circle) and/or output ports (ports represented by a full circle). Each port has a colour associated and it is possible to connect output ports with input ports. Each group of elements presented in the previous section has a different port configuration. The Sources have one blue output port; History elements have one input and one output port both with

Type of Pattern Detected Language Elements

Subset selection pattern Source, History, Aggregation, Occupation, Working Equipment Threshold pattern Threshold Trend pattern Forecast, Variation Modal pattern During, Within Temporal order pattern Followed By, Repeat Logical operator pattern And, Or

Table 4.1: A possible classiﬁcation of the pattern detected by each language element, considering the types of patterns described in Section 2.4.

41 blue colour; Aggregation has one blue input port and one yellow output port; Forecast has one input port and one output port both yellow; Thresholds and Variations have multiple yellow input ports and one green output port. Finally, the Optional Detectors have one green input port and one green output port. However, the Occupation and Working Equipment elements, in contrast with the other Optional Detectors, do not have input ports. To specify an alarm it is necessary to connect language elements, however it is only possible to connect ports of the same colour. Additionally, when using the History, Repeat, During, or Within types it is not possible to connect two elements of the same type. These restrictions exist in order to preserve the following constraints:

1. The output port of a Source element can be connected to the input port of a History or Aggregation element.

2. The History output port can be connected to an Aggregation input port.

3. The Aggregation output port can be connect to the input port of a Forecast, Threshold, or Variation element.

4. The output port of a Forecast can be connected to an input port of a Threshold or Variation.

5. The output port of a Threshold or Variation can be connect to the input port of an Optional Detector except the special cases, namely to the Working Equipment and the Occupation elements.

6. Optional Detectors can connect between them.

7. It is possible to connect an output port to multiple input ports, in order to reduce the language complexity enabling the re-utilization of language elements by the user.

These restrictions also preserve the language correctness during the user utilization, reducing this way possible errors. In addition to these restrictions, the And, Or, and Followed By elements must have at least two elements connected to them in order to respect their goals. To summarize the language characteristics we created a grammar, presented in AppendixA, and two models, namely the domain model and the feature model. A domain model consists of objects and propositions about them, describing for instance how the objects relate to others [138]. The complete domain model of this language is presented in AppendixB. A feature model defines the features — increments in a program functionality — and their usage constraints [19]. Representing each language element as a feature we constructed a feature model to express the mandatory and optional elements of the language. This model is presented in AppendixC. From the groups of elements presented in the previous section three are mandatory elements to specify an alarm. The first mandatory element is a Source to describe the data source to be used in the alarm. An Aggregation element is the second mandatory element. Finally, a Threshold or a Variation element is the last mandatory element. The other groups of elements are optional and can be used to specify more complex alarm specifications.

42 Chapter 5

Implementation

Our solution is organized into three modules, namely: information presentation, data processing, and data acquisition (see Figure 4.1). A web-based front-end was developed to represent the information presentation stage, i.e. the alarm system interface. The data processing stage is represented by the implementation of the alarm system, using a DSMS as underlying technology, and by the ASL implementation, which is based on the Interpreter design pattern. Finally, a simulator is used to simulate the acquisition of data.

5.1 Information Presentation Stage

The information presentation stage consists in the alarm system interface. This interface has an alarm dashboard and a visual alarm editor, which are implemented using a web-based front-end developed in HTML, CSS, and JavaScript. The alarm dashboard is divided in two modules. The ﬁrst module, depicted in Figure 5.1, presents information regarding active alarms, i.e., the alarms whose trigger condition is true. This information is presented on a table where each line corresponds to an active alarm. As previously described in Section 2.2, good alarms must respect standardized characteristics described by the EEMUA 191 guideline [56]. Accordingly, to each active alarm is provided the following information: its id, priority, title, message to user, the id of the meter that provides data to this alarm, the value that triggered the alarm, and the activation time (i.e. the date and time when the alarm is activated). Considering the alarm life-cycle described by the ANSI/ISA 18.2 alarm standard [7], each line of the table also has an option to enable users to acknowledge an alarm preventing re-announcements until the alarm condition becomes false (see Section 2.2). Using this information users are able to identify urgent alarms through its priority. Knowing where the problem occurs and what is the value that activates an alarm (through the meter id and the value, respectively) users are able to diagnose the alarm. Finally, the message conveys information that helps users to know how to react. Each alarm corresponds to a unique line in the table. Therefore, there is alarm compression (see Section 3.2.2) since multiple occurrences of the same alarm are represented in an unique line.

43 Figure 5.1: Interface to manage active alarms, containing a table with information regarding active alarms, designed considering the good alarms characteristics recommended by the EEMUA 191 guideline [56] (1). Each column of the table has an option that enables users to sort the lines of the table according to the column content, enabling, for instance, to sort the table lines according to the alarm priority (2). In accordance with the alarm life- cycle described by the ANSI/ISA 18.2 alarm standard [7], an acknowledge option enables users to acknowledge an alarm (3). Finally, the interface presents information to help users understanding how to use the interface (4).

The second module of the alarm dashboard, depicted in Figure 5.2, presents on a table information regarding existing alarms, i.e. all the alarms created except the removed ones. Additionally to the alarm basic information (namely its id, priority, title, and message to user), each line of the table enables users to pause/restart or remove the alarm. The pause/restart option corresponds to shelving an alarm (see Section 3.2.2), enabling users to temporally suppress an alarm.

Figure 5.2: Interface to manage existing alarms. The information regarding existing alarms is presented on a table designed considering the good alarms characteristics recommended by the EEMUA 191 guideline [56] (1). Each column of the table has an option to enable users to sort the lines of the table according to the column content (2). To each alarm there are options that enable users to remove or pause/restart an alarm, corresponding the pause/restart option to shelving an alarm (see Section 3.2.2) (3). Finally, the interface presents information to help users understanding how to use the interface (4).

44 Figure 5.3: Interface to create a new alarm. A text box enables users to introduce the alarm title (1). An option field enables users to select the alarm priority, as prescribed by the ANSI/ISA 18.2 alarm standard [7] (2). Considering the good alarms characteristics recommended by the EEMUA 191 guideline [56], a text box enables users to introduce the message that helps users to know how to react when the alarm becomes active (3). A toolbox contains the ASL elements that users can use to specify an alarm trigger condition (4). Users specify on a specification area the alarm trigger condition, using the elements present in the toolbox (5). The specification area has a button to clean the specification present in the specification area (6). Finally, this interface has a button to create the alarm (7), and presents information to help users understanding what are the necessary steps to create a new alarm (8).

Finally, the visual alarm editor, depicted in Figure 5.3, enables users to create new alarms. Using this interface users have to perform two steps. First, users have to provide the title and priority of the

45 new alarm, and the message to show to user when the alarm becomes active. The alarm priority is selected according to the categories prescribed by the ANSI/ISA 18.2 alarm standard (see Table 2.3). Second, users have to specify the alarm condition using the ASL. Accordingly, users have to drag and drop language elements from a toolbox to a specification area. Next, on the specification area users have to connect the language elements and when necessary to fill in language elements option fields. To develop the alarm system interface we used a Bootstrap template, namely SB Admin 21. To the active and existing alarms modules we used the dataTables2 framework to construct the tables holding the alarms information. Finally, to the module related with the alarm creation we used jQuery3 and others JavaScript frameworks. To develop the toolbox containing the elements of the ASL we used the liteAccordion4 framework. To enable connections between the language elements we used the JsPlumb5 framework. The Within element has two fields that require the introduction of time periods. This feature was developed using the jQueryTimepicker6 framework.

5.2 Data Processing Stage

The data processing stage, summarized in AppendixD, provides a REST API used by the alarm system interface, enabling the exchange of data and information between them. To convert an alarm speciﬁca- tion in continuous queries the ASL is implemented using an algorithm based on the Interpreter design pattern that, according literature, is a possible approach to implement a DSL [100, 112]. Finally, to timely process continuous queries over unbounded data streams we use Esper 7 which is a DSMS presenting language capabilities for data and event stream processing as well as for pattern matching.

5.2.1 Data Processing Stage API

The alarm system interface needs to communicate with the data processing stage to send data and receive information. Therefore, the data processing stage provides a REST API that is used by the alarm system interface. Thus, in a client-server interaction the data processing stage is the server and the interface has the client role. The REST API is represented by a single URI (/Application) and has GET and POST methods with several parameters as summarized in Table 5.1. When the interface wants to get information regarding active alarms, it sends a GET request to the server. After receiving this, the server returns a JSON message containing the information that is used to construct the table in the active alarms module of the interface. The server considers an alarm as active when the corresponding continuous query produces a result, being associated to the alarm a lease time that is renovated each time the continuous query produces a result. When the lease time expires the alarm is deactivated, being this detected by an instance of a class called Cleaner that runs a

1http://startbootstrap.com/template-overviews/sb-admin-2/ 2https://www.datatables.net 3http://jquery.com/ 4http://stitchui.com/liteaccordion/ 5https://jsplumbtoolkit.com/ 6http://trentrichardson.com/examples/timepicker/ 7http://www.espertech.com/products/esper.php

46 Method Parameter Description

GET activeAlarms Gets a list containing information about active alarms. GET existingAlarms Gets a list with information regarding existing alarms. POST pause Receives an alarm identifier and pauses the corresponding alarm. POST restart Has as input an alarm identifier and restarts the corresponding alarm. POST remove Removes the alarm identified by the alarm identifier received as input. POST ack Acknowledges the alarm identified by the input, i.e. an alarm identifier. POST newAlarm Creates a new alarm using the title, priority, message to user, and the alarm specification received as input.

Table 5.1: REST API provided by the data processing stage. thread to check periodically the leases associated to the active alarms and deactivates the alarms with expired leases. A GET request is also sent to the server when the interface wants information regarding existing alarms. In response to this request the server returns the required information through a JSON message. The options to enable users to pause/restart, remove, or acknowledge an alarm send to the server a POST request, identifying the alarm and the chosen option. When the server receives a pause request, it pauses the queries corresponding to the alarm, restarting them when a restart request is received. On receiving an acknowledge request the server marks the alarm as acknowledged. Then exists a behaviour similar to the active alarms behaviour, i.e. when the corresponding continuous query produces a result is associated to the acknowledged alarm a lease time that is renovated each time the continuous query produces a result. When the lease time expires the alarm is deactivated, being this detected by an instance of a Cleaner class. To create a new alarm, the interface sends a POST request containing the data related with the alarm, namely: title, priority, message to user, and the alarm specification. The alarm specification is a JSON array of language elements and the connections between them, where each language element is an object described by the fields of the language element. When the server receives the request it converts a JSON string to equivalent Java objects (using the GSON8 library), being this way created instances of the classes representing the language elements and the connections among them. Then, it is created a new instance of a class representing the alarm, containing the alarm basic information (i.e. id, title, priority, and message to user) and the continuous queries corresponding to this alarm. These queries are generated from the alarm specification.

5.2.2 Applying the Interpreter Design Pattern

During the conversion of the alarm specification in continuous queries we treat the language elements used in the specification as nodes of a tree, from now on referred to as specification tree. The root node of a specification tree is the last element of the alarm specification, in other words is the element that is connected to at least one element and does not has connections from it (i.e. does not exist a connection

8https://sites.google.com/site/gson/gson-user-guide

47 Figure 5.4: Example of an alarm specification. In the corresponding specification tree the And element corresponds to the root node and the Energy Consumption elements are the leafs. starting in the output port). Usually, according to Section 4.2.3, the root node of a specification tree is one of the following: a Threshold, a Variation, or an Optional Detector excepting the special cases (i.e. the Working Equipment and Occupation). Figure 5.4 presents an example of an alarm specification, where the root node of the specification tree is the And element and the Energy Consumption elements are the leafs. Therefore, considering the alarm specification as a specification tree, to convert the alarm specification in continuous queries the query creation module uses an algorithm based on the Interpreter design pattern (depicted in Figure 5.5). According to Mernik et al. and Kosar et al., this design pattern is a possible approach to implement a DSL [100, 112]. The Interpreter design pattern follows the Composite design pattern being possible to deal equally with the language elements, treating individual elements (the leafs) and element compositions uniformly [68]. Additionally, the use of the Interpreter design pattern increases the language maintainability, i.e. the degree to which a language promotes ease of program maintenance [90]. Our solution needs to convert an alarm specification in continuous queries, and depends on the ability to timely generate alarms. To achieve this we use Esper 9 which is a DSMS able to process continuous queries over unbounded data streams. It also presents language capabilities for data and event stream processing as well as for pattern matching, which is necessary since it must be possible to translate an alarm defined by users in continuous queries using stream query language operators (see Section 3.4.4). As mentioned in Section 3.4.4, the use of windows is a possible solution to enable blocking operators to produce results in a data stream scenario. However, some blocking operators, such as average, minimum, and maximum, can also be evaluated incrementally without having to maintain the complete data stream in memory. For instance, the average operator may be evaluated keeping only two variables, one for cumulative sum and another for the quantity of events examined so far. Esper engine optimizes its aggregation functions to be evaluated incrementally, thus for example a query that selects an average from a sliding window retains the minimal data necessary to compute the aggregated result. Thus, since the ASL aggregates data using these operators, even if it is necessary to maintain, for instance, the hourly average of the energy consumption of the last year it is sufficient to keep only two variables. In our solution when is necessary to create an auxiliary query its results are inserted in an event stream. This way its is possible to make the results of an auxiliary query available for use in the FROM clause of other query.

9http://www.espertech.com/products/esper.php

48 Figure 5.5: Interpreter design pattern, where terminal and compound expressions implement the interpret method, and therefore, it is possible to treat the expressions uniformly.

5.2.3 Semantics of the Language Elements

In accordance with the Interpreter design pattern, each language element implements a method called interpret that receives an instance of a Context class as parameter and returns a string. In our algorithm the Context class has a reference to the root node of the specification tree and a query container, containing the continuous queries that represent the alarm specification. In a specification tree the root node is the first node where the interpret method is invoked, leading this to the invocation of the method on the other nodes of the specification tree. Depending of the goal associated to each language element in the ASL the method behaviour varies as follows:

Source is a leaf in a speciﬁcation tree. It returns the name of a query created to select the meter’s id (provided by the user on the interface) and the measure from the data stream where the input data is being placed. However, there are Source types that have a different behaviour. The Energy Cost element is a particular case that creates a continuous query to calculate the energy cost of the zone or equipment identiﬁed by the id provided by the user. The Data Arrival Frequency uses the rate operator provided by Esper to create a query that returns the arrival frequency of the input data. The Energy Sold element assumes that the system receives data related both with the quantity of energy sold and the unitary price. When the user wants to select the quantity of energy sold, this element returns the name of the data stream where the input data is being placed. If the user wants to select the value sold, it is created a query to calculate this value multiplying the unitary price by the quantity.

History creates a query and returns its name. However, depending of the type of the History element (i.e. Simple and Period History) the interpret method has different behaviour. The Simple History stores in a sliding window (created according to the fields of the element) the events of the event stream indicated by the Source element. The query created by a Period History additionally to the previous behaviour has a WHERE clause to enable the selection of data relative to the time period specified by the user in the fields of the History element. This way it is possible, for example, to maintain data relative to the 10:00 to 17:30 period of the last month.

Aggregation when connected with a Source element the interpret method returns the name of a query that selects and aggregates data (according to the ﬁelds of the Aggregation element) from the event stream indicated by the Source element. The behaviour is similar when a History is con-

49 nected with the Aggregation element, however data is aggregated considering the time granularity of both the History and Aggregation elements. So, for instance when the History stores the events of the last day and one wants to obtain the hourly average, the query divides the sum of the measures of the last day by the number of hours of a day, i.e. 24 hours.

Forecast was not implemented, however a possible simple implementation consists in having a continuous query that produces results according to a linear regression equation. In this equation one can use the aggregated value received from the Aggregation element, the current day of the week (such as Monday and Tuesday), and time as independent variables to calculate a forecast (a dependent variable) of the value received from the Aggregation element.

Threshold uses the results of the continuous query provided by the element connected to the first input port, from now on referred to as inputValue. The interpret method returns the name of a continuous query created whose behaviour depends both on the threshold type and arity. First regarding the threshold type: (i) if the threshold type is a Lower Limit Threshold the query provides results when the inputValue reaches the lower limit; (ii) in the presence of an Upper Limit Threshold the query produces results when the inputValue exceeds the upper limit; and (iii) with a Within Threshold the continuous query produces results when the inputValue is inside the range specified in the threshold fields. Second, with respect to the arity when the thresholds are unary the limits are provided by the user through the threshold fields. On the other hand, when the thresholds are not unary the only difference to the previous behaviour is that the limits are obtained from the results of continuous queries, provided by the elements connected to the remaining input ports of the Threshold.

Variation interpret method has different behaviour depending of the arity of the Variation element. In relation to the unary variation, since its goal is to detect that an aggregated value — result of the aggregation or forecast query — registers a variation over a certain period of time, it is necessary to obtain two values to calculate the variation. First, we need the current aggregated value that is provided by the aggregation or forecast query. Second, we need to obtain the aggregated value corresponding to a speciﬁed time period in the past. For instance, if we want to detect that a hourly aggregated value had an increase of 25% over the last 5 minutes we need the following values: (i) the current hourly aggregated value extracted from the sliding window [now-1hour, now], and (ii) the hourly aggregated value extracted from the sliding window [now-1 hour-5 minutes, now-5 minutes]. Using these two values the variation can be determined using a continuous query that calculates the ratio between the second and the ﬁrst value.

To the best of our knowledge, Esper does not provide a direct way to create the second sliding window. To overcome this issue and extract the second aggregated value a possible solution consists in using two sliding windows, for instance [now-1 hour-5 minutes, now] (from now on referred to as auxiliarySlidingWindow1) and [now-5 minutes, now] (from now on referred to as auxiliarySlidingWindow2) for the previous example. Using these sliding windows it is possible to extract the second aggregated value (average aggregation) using a continuous query that does

50 the following calculation:

sum(auxiliarySlidingW indow1) sum(auxiliarySlidingW indow2) − count(auxiliarySlidingW indow1) count(auxiliarySlidingW indow2) −

This solution works only when the aggregation is done using an average operator and does not work with minimum and maximum operators, that are also a possible choice in the Variation element ﬁelds. This occurs because, for example, when the minimum or maximum value is in the last 5 minutes of the auxiliary sliding window these operators always returns the minimum or maximum corresponding to the last 5 minutes, however the goal is to obtain the minimum or maximum from the sliding window [now-1 hour-5 minutes, now-5 minutes] and not from the last ﬁve minutes.

With regard to the binary variation its goal is to detect a variation comparing the value obtained from the ﬁrst input port with the value obtained from the second input port. So, the interpret method invokes the interpret method of the elements connected to the binary variation, and creates a continuous query to calculate the ratio between these two values, producing results when the ratio is above the variation percentage deﬁned by the user.

Optional Detectors use four types of pattern operators (provided by Esper) to detect pattern expressions, namely: operators to control the repetition of sub-expressions, logical operators, temporal operators that operate on event order, and guards that are special where conditions used to control the life-cycle of sub-expressions. Using these operators each optional detector element creates a pattern expression. Usually, the interpret method returns a string containing a pattern expression. However, when the element is the root node of the specification tree it creates a continuous query to detect pattern expressions, being the name of this query the return of the interpret method. This behaviour enables the creation of a single query containing the combination of the pattern expressions provided by the optional detector elements present in an alarm specification. Otherwise, if each optional detector creates a query the number of queries created is directly proportional to the number of optional detector elements present in an alarm specification. The Repeat element is an exception to this behaviour because its goal is to detect repetitions within a sliding window. Therefore, it is necessary to create a query that specifies both the pattern and the window in order to detect repetitions occurring only inside the window.

Repeat uses the repeat operator of Esper that matches when a pattern sub-expression evaluates to true a given number of times. To generate the pattern the interpret method returns a string “[n] queryName”. Where (i) [n] corresponds to the Esper repeat operator notation, (ii) n is the number of times that a situation must repeat, and (iii) query- Name corresponds to the continuous query name provided by the interpret method of the element connected to the Repeat element.

During creates a pattern expression to detect that a condition is true during a given period of time. To the best of our knowledge Esper does not provide a direct way to detect this situation. Therefore, it is created a pattern to match when: occurs an event indicating

51 that the condition is true, followed by a period during which the condition never becomes false, followed by a new occurrence of an event indicating that the condition is true. To detect that a condition never becomes false during a period we have to detect that its negation does not occur during that period. To create the negation of a condition we have to: (i) switch the signals used in queries representing thresholds (e.g. with an Upper Limit Threshold we detect that the limit is never exceeded), (ii) in variations the increase becomes a decrease and vice-versa, and (iii) when an AND element is used we switch it with an Or because, for instance, the negation of “D and E” corresponds to “not D or not E”, being the negation of D and E provided, for example, by the negation of thresholds or variations. So, for instance, if one wants to detect that a condition A (e.g. a threshold being exceed) is true during a 5 minutes it

is created the following pattern: “A1 ->(timer:interval(5 minutes) AND not B) ->A2”.

Where “->” corresponds to the Esper followed-by operator, events A1 and A2 represent that the condition A is true, B represents the negation of A, and “(timer:interval(5 minutes) AND not B)” represents that during a period of 5 minutes B does not occur.

Within adds a clause to the where conditions of the queries created by the elements that are descendant nodes of the Within element in the specification tree. This clause creates a fixed window (see Section 3.4.4) enabling that an alarm condition becomes true only inside a given period of time or in specific days according to the fields and type of the Within element.

Followed uses the followed-by operator of Esper, requiring that, for instance, in the pattern “A- By >B” A must occur before B. Since this element has two elements connected to its input port, to generate the pattern the interpret method invokes the interpret method on each of the connected elements and links the results with the string “->” corresponding to the Esper followed-by operator.

And uses the and operator of Esper, requiring that the nested pattern expressions become true before the whole expression turns true. Since this element has two elements connected to its input port, to generate the pattern the interpret method invokes the interpret method on each of the connected elements and links the results with the string “AND”.

Or is based on the or operator of Esper, requiring that at least one of the expressions must be true before the whole expression turns true. Since this element has two elements connected to its input port, to generate the pattern the interpret method invokes the interpret method on each of the connected elements and links the results with the string “OR”.

Occupation creates a continuous query to select both the identifier and occupation status of the location, when the occupation respects the options specified in the fields of the Oc- cupation element. The interpret method returns the name of the continuous query

52 created. In a speciﬁcation tree this element is a leaf.

Working is a leaf in a speciﬁcation tree that creates a continuous query to select the identiﬁer Equipment and energy consumption of the equipment when it is working (i.e. its energy consumption is bigger than zero Watts). The interpret method returns the name of the continuous query created.

5.2.4 Language Conversion Examples

An example of an alarm specification used to detect that the energy consumption of the zone identified by Alameda has a hourly average exceeding a 10000 Watts limit is depicted in Figure 5.6. This figure presents also the queries created using the previous algorithm. First, the Energy Consumption element creates a query which results are inserted into an event stream named “source1”. Then, the Aggregation element creates the second query to obtain the average of the energy consumption, using the results of the previous query. Finally, the last query uses the results of the second one and detects when the threshold is exceeded, selecting in this situation the meter identifier and the value that exceeds the limit, being this information presented to the user on the interface. Figure 5.7 depicts an alarm specification whose purpose is to detect when the energy consumption of the zone with identifier Civil has an hourly average registering an increase of 25% over the last 5 minutes. The queries representing this alarm specification are presented bellow the alarm specification, where the first one is created by the Source element, the second by the Aggregation, and the remaining

Figure 5.6: Example of an alarm specification and the corresponding queries used to detect that the energy consumption of the zone identified by Alameda has a hourly average exceeding a 10000 Watts limit. The first query is created by the Energy Consumption source (1). The Aggregation element creates the second query (2). Finally, the third query is created by the Threshold element (3).

53 Figure 5.7: Example of an alarm specification and the corresponding queries aiming to detect that the energy consumption of the zone with identifier Civil has an hourly average registering an increase of 25% over the last 5 minutes. The first query is created by the Energy Consumption source (1). The Aggregation element creates the second query (2). Finally, the remaining queries are created by the Unary Variation element (3). ones are created by the unary Variation element. Combining the alarm specifications depicted in Figure 5.6 and in Figure 5.7 using an And element results in the alarm specification depicted in Figure 5.4. This specification additionally to the previous queries is represented by the following query that uses the pattern operators provided by Esper:

SELECT eventName.meterId AS meterId, eventName.value AS value

54 FROM PATTERN [EVERY eventName=variation AND threshold]

5.3 Data Acquisition Stage

The data acquisition stage, depicted in Figure 4.1, is composed of data streaming sources. We use a simulator to simulate readings from several meters using the Modbus protocol, being possible to choose the readings frequency and the number of activated meters. The data provided by the simulator is forwarded to Esper being inserted into data streams.

55 56 Chapter 6

Validation

Our work comprises the development of a DSL and an alarm system, aiming to enable building energy managers to specify alarms involving complex conditions. To validate the developed DSL we performed interviews with experienced building energy managers, following a DSL validation methodology based on the literature that assesses the DSL effectiveness, efﬁciency, satisfaction, accessibility, reliability, and productivity. The alarm system was assessed considering its performance and usability characteristics, taking in consideration the ISO 9241-11 standard [85]. Nielsen and Molich proposed four ways to evaluate usability, namely: formally, automatically, empirically, and heuristically [117]. These approaches are summarized in Table 6.1. To access the usability of a DSL have been used empiric and heuristic approaches, and due to this we followed these approaches [14, 117].

6.1 ASL Validation

Most of the requirements regarding the evaluation of user interfaces are associated with usability [15]. According to the ISO 9241-11 standard, usability is defined as the“extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use” [85]. The ISO/IEC 25010 standard, expands this definition introducing the notion of quality in use that refers to the quality perceived by users during the product utilization in a real context of use [86].

Evaluation approach Description

Formally Using analysis techniques, using for instance models and simulations to predict measures like the difﬁculty to learn how to use a system Automatically Using a computerized procedure Empirically Developing experiments with test users Heuristically By simply looking at the system and passing judgement according to an own opinion

Table 6.1: Usability evaluation approaches (adapted from [14, 117]).

57 The quality assessment of a DSL is a concept in development [90, 154]. However, since the main goal of a DSL is to close the gap between domain experts and a computational solution, a DSL can be used as a structured and comprehensive means to achieve human computer interaction [15]. Therefore, Barisiˇ c´ et al. taking in consideration the ISO/IEC 25010 standard propose that the most relevant attributes to evaluate the achieved quality in use of a DSL in a real context are the following ones [17, 86]:

Effectiveness determines the accuracy and completeness of the sentences implemented by users.

Efﬁciency states the effectiveness level that is achieved at the expense of resources, such as mental and physical effort.

Satisfaction expresses the satisfaction of the user needs when a system is used in a speciﬁed context of use.

Accessibility specifies the degree to which a system can be used by users with the widest range of characteristics and capabilities to achieve a specified goal in a specified context of use. Barisiˇ c´ et al. give emphasis to learnability and memorability of the language elements.

These attributes are also supported by other authors [79, 90, 97, 147]. For instance, according to Kahraman and Bilgen (based on ISO/IEC 25010) and Visser, it is important that concepts and scenarios of the domain can be expressed using the DSL. This can be expressed as the completeness or domain coverage of the DSL, being evaluated in the effectiveness attribute presented before [90, 147]. Taking these attributes in consideration, we developed a set of questions to validate the developed DSL, i.e. the ASL. These questions are presented in Table 6.2. Reliability is another attribute proposed in literature as contributing to the success of a DSL [79, 90]. It refers to a language property regarding the production of reliable programs, preventing errors through, for instance, the prevention of unexpected relations. Having ports with colours, where it is only possible to connect ports of the same colour and of different language elements (when connecting History, Repeat, During, or Within), the ASL prevents error occurrences. Additionally, since our implementation veriﬁes the language syntax we consider that the ASL ensures reliability.

Question ID Description

Effectiveness Question 1 Is it possible to specify all the alarms you need using this language?

Efﬁciency Question 2 Are you able to specify alarms in a timely way?

Satisfaction Question 3 Would you use this language in your EMS?

Accessibility Question 4 Is it easy to specify alarms using this language? Question 5 Is it easy to understand the goal/meaning of the language elements?

Table 6.2: ASL validation questions (based on [17, 79, 90, 97, 147]).

58 6.2 Alarm System Validation

Since we also developed an alarm system, we elaborated a group of questions to validate both the interface and the performance of the system. The questions regarding the alarm system interface are based on the ISO 9241-11 standard [85], which is the standard for ergonomics of human-computer interaction. These questions were prepared taking in consideration ﬁve fundamental aspects for a good interface construction, namely: design, functionality, easiness of use, learnability, and satisfaction. Fi- nally, there are two questions to measure if the system performance is acceptable according to users needs. These questions pretend to validate that the time required to convert an alarm speciﬁcation in continuous queries, and the system performance during the production of information (e.g. regarding existing and active alarms) respects the users requirements, providing information in due-time that enables users to act and solve the problems. The complete set of questions used during the alarm system validation is depicted in Table 6.3.

In addition to the questions regarding the system performance perceived by users, the alarm system could be evaluated by performing comparisons with other systems. During these comparisons, the systems could be evaluated taking in consideration performance objectives, measuring associated metrics. According literature examples of these metrics include [18, 59]: (i) the number of input events processed by a system within a given time period (i.e., the input throughput), (ii) the number of results produced by a system within a given time period (i.e., the output throughput), and (iii) the average time taken to process an event (i.e. the average latency). However, considering that, to the best of our knowledge, most systems do not allow users to specify alarms, the systems comparisons will be limited to the pre-deﬁned

Question ID Description

Design Question 1 Is the system interface pleasant to use?

Functionality Question 2 Is the information provided by the system effective at helping to perform tasks?

Easiness of Use Question 3 Is the system interface easy to use? Question 4 Is it easy to ﬁnd the information you need?

Learnability Question 5 Is it easy to learn how to use the system interface? Question 6 Is the information provided by the system easy to learn?

Satisfaction Question 7 Can you fulﬁl your tasks effectively? Question 8 Are you satisﬁed with the outcome of the performed tasks?

Performance Question 9 How do you classify the system performance in the alarm creation (i.e. conversion of the alarm speciﬁcation into continuous queries)? Question 10 How do you classify the system performance in the production of information?

Table 6.3: Alarm system validation questions, organized according to ergonomic dimensions of ISO 9241-11 standard [85].

59 alarms supported by the other systems. Additionally, since most EMS solutions are proprietary it is unfeasible to acquire a paid license to evaluate each of them, being the systems comparisons unfeasible to perform.

6.3 Methodology and Participants

To validate both the ASL and the alarm system developed, we performed several user interviews each one structured in two stages. The first one to validate the ASL and the second to validate the alarm system. The interviews were performed on the building energy manager’s office, taking an average of 60 minutes each allowing participants to interrupt any time. In each interview we performed the following steps: (i) a questionnaire to establish the user profile; (ii) a brief language explanation to users through a set of examples of alarm specifications using the ASL; (iii) a questionnaire with the questions presented in Table 6.2; (iv) a briefing about the alarm system interface where users freely explored the interface; and (v) a questionnaire with the questions presented in Table 6.3. The complete questionnaire is presented in AppendixE. Involving real users is a major aspect of this validation. Considering this, we preferred to have a small number of participants that are real users, i.e. are building energy managers, instead of involving ad-hoc users in the tests, which could produce biased results. In addition to this, due to the relatively high costs associated it is difficult to arrange meetings with real users (for instance each building energy manager has an hourly cost and assigned work to do during its work period). Due to this fact and because users do not want to perform usability tests where they have to do use case scenarios, we cannot gather metrics such as the time spent on each task, number of mistakes, and the number of accomplished tasks. However, to minimize this problem we question users if they are able to specify alarms in a timely way. Table 6.4 details the profiles of the participants, namely: age, gender, education level, years of experience in the domain, and the type of building managed. Most participants are graduated males and have more than ten years of experience in the building energy management domain. The type of buildings managed include educational buildings (e.g. universities), commercial buildings (i.e. compa-

Age Gender Education Years of Experience Type of Building

50 Female Master 5 Commercial 39 Male Bachelor 10 Commercial 58 Male Master 25 Commercial 57 Male Bachelor 28 Commercial 34 Male Bachelor 3 Educational 27 Male Master 5 Educational 47 Male Master 15 Educational 58 Male Bachelor 18 Educational 39 Male Master 11 Museum 59 Male Bachelor 37 Museum

Table 6.4: Proﬁles of the participants involved in the validation.

60 nies/governmental ofﬁces, stores, or both in the same building), and museums (i.e. buildings serving both as museums and spaces for conferences/presentations). Some participants manage all the buildings of its institution (like banks and foundations), existing for instance one that manages 700.000 m2 spread across 850 buildings, other managing 500 buildings, two managing 110.000 m2 each, and other managing 75.000 m2.

6.4 Results

The results of the validation are presented in this section. First, we describe and analyse the results of the ASL validation. Then, the results of the alarm system validation are presented and analysed.

6.4.1 Results of the ASL Validation

The language validation results are presented in Table 6.5. From these results we can conclude that the ASL covers the building energy management domain, allowing the specification of the necessary alarms. However, some building energy managers did not give the highest score. According them, they need more sources of data, such as water and gas consumption, interior humidity, and CO2 emissions. Additionally, they also identified that building activities may vary on a daily basis, and therefore it may be necessary to specify alarms to each day of the week. Finally, it was also related that it may be required to have alarms detecting repetitions (e.g. a sensor reports an unexpected energy consumption 3 times within the last 60 minutes). Using this kind of alarms it is possible, for example, to detect equipment malfunctioning or to reduce the number of alarms because the alarm is only activated when its trigger condition is true a given number of times during a certain period. This feedback, added to the ASL, was important inducing some adjustments or the addition of small features, therefore helping in the improvement of the final language and prototype. Still, according to the language validation results, we can deduce that the language enables the specification of alarms in a timely way, satisfying the participants needs. Since, to the best of our knowledge, there is any language used to specify alarms in the building energy management domain we cannot perform comparison studies with other languages. However, all participants related an increased productivity, i.e. the specification of alarms using the ASL consumes less time than the usual way [79,

Question Id Minimum Maximum Average

Question 1 4 5 4.8 Question 2 5 5 5 Question 3 5 5 5 Question 4 4 5 4.9 Question 5 4 5 4.9

Table 6.5: Results of the language validation questionnaire. The question id corresponds to the ﬁrst column of Table 6.2. Each answer follows a Likert scale where 1 corresponds to strongly disagree and 5 corresponds to strongly agree.

61 90]. This fact is important because productivity is another attribute supported in literature as being important to the DSL success [79, 90]. Regarding accessibility, participants feedback indicates that it is easy to specify alarms using this language, being the language elements easy to learn and understand. According some participants, the use of ports with colours in the language elements is a major help to understand and remember the language syntax, reducing the probability of errors and contributing to the language reliability. Finally, taking in consideration that one can quickly and easily use the ASL to specify alarms, all the participants would like to use this language in their EMS.

6.4.2 Results of the Alarm System Validation

The validation results regarding the alarm system are detailed in Table 6.6. Regarding design most participants gave the highest score. This means that the pleasantness of interaction and likeability of the system interface are extremely good. With respect to functionality, i.e. if the information provided by the system helps users during their work, most participants gave the highest score. However, there are three participants that did not give the highest score. According them, alarms are not the unique way to obtain information. They also use, for example, graphics about energy consumption and associated costs, giving this a graphical visibility to the information that complements the information given by alarms. Additionally, one participant revealed interest in exploring historical data regarding alarms. Accordingly, information like how many alarms occurred in the last day and what are their priorities could be used, for instance, to detect that an alarm trigger condition must be updated. All participants gave the highest score to the remaining questions. Thus, we can conclude that the system is easy to use, learn, and produces information in a timely way. Indeed, most participants highlighted both the easiness of using the system and its performance, both during the production of information (e.g. regarding existing and active alarms) and during the conversion of the alarm speciﬁ- cation into continuous queries. In addition to these aspects, participants were able to fulﬁl their tasks

Question Id Minimum Maximum Average

Question 1 4 5 4.9 Question 2 4 5 4.7 Question 3 5 5 5 Question 4 5 5 5 Question 5 5 5 5 Question 6 5 5 5 Question 7 5 5 5 Question 8 5 5 5 Question 9 5 5 5 Question 10 5 5 5

Table 6.6: Results of the alarm system validation questionnaire. The question id corresponds to the ﬁrst column of Table 6.3. Each answer follows a Likert scale where 1 corresponds to strongly disagree and 5 corresponds to strongly agree.

62 effectively, being satisﬁed with the outcomes provided.

6.5 Lessons Learned

There are some difficulties associated with performing validation tests with building energy managers (i.e. real users). First, it is difficult to arrange meetings with building energy managers. Second, most of the building energy managers do not want to perform usability tests where they have to do use case scenarios. Therefore, it is difficult to gather metrics such as the time spent on each task, number of mistakes, and the number of accomplished tasks. These difficulties are motivated by the relatively high costs associated (e.g. each building energy manager has an hourly cost and assigned work to do during its work period), and because users feel fear of being evaluated, even if we explain that the evaluation regards the system and not the user. Finally, when a solution has some kind of innovation it is difficult to perform validations through comparisons with similar solutions. This fact is justified by the absence of solutions, or because the existing ones do not provide similar features. In addition, if most solutions are proprietary it is unfeasible to acquire a paid license to evaluate each of them. These difficulties were noticed in this work during the validation of both the ASL and the alarm system.

6.6 Discussion

During the interviews most participants showed great interest and receptivity both in the ASL and in the alarm system. They said that our solution is very innovative and that does not compare with what they have, because they cannot specify alarms or can only specify alarms involving thresholds. Thus, this feedback and the validation results demonstrate that both the ASL and the alarm system are necessary and useful. Considering the ASL validation, we can conclude that the ASL is easy to use and covers the building energy management domain, allowing the speciﬁcation of the necessary alarms. Additionally, all participants related an increased productivity, i.e., the alarm speciﬁcation using the ASL consumes less time that the usual way [79, 90]. Finally, according to the participants feedback, using colours in the ports is a major help to understand and remember the language syntax, reducing the probability of errors and contributing to the language reliability. As previously described in Section 2.2, good alarms must respect standardized characteristics described by the EEMUA 191 guideline [56]. The importance of providing information based on those characteristics was also demonstrated during the alarm system validation. Indeed, most of the validation participants highlighted this conclusion, since according them the system provides the right information, enabling them to act and solve problems. In addition, it was also demonstrated that the alarm quality requirements presented in Section 3.2.2 are important to the development of both the ASL and the alarm system. These requirements were a motivation to develop language elements (like the Repeat and During elements), and were taken in

63 consideration during the development of the alarm system interface. Indeed, considering these facts most participants consider that our solution contributes to solve some problems regarding the number of active alarms. Finally, considering that the ASL has a good domain coverage and enables the speciﬁcation of the necessary alarms, we can conclude that the existing stream query languages (provided by SPEs such as DSMSs) have enough power to express complex conditions regarding alarms. In addition to this, using a DSMS the alarm system is able to provide information in a timely way to users. Indeed, this performance was highlighted by the validation participants. Therefore, we consider that alarm systems can have a new architecture based on a DSMS.

64 Chapter 7

Conclusions

Timeliness is an increasingly important requirement for decision makers since agility in business is critical to success [118]. This is specially true for energy management because faster decisions enable building energy managers to diagnose problems and react quickly to anomalous situations [44]. Energy management systems (EMSs) are used to support the decision making process of building energy managers [72, 114]. Considering the timeliness requirement one important feature of EMSs are alarms because they enable the timely recognition of anomalies [7, 98, 135, 149].

After reviewing the state of the art we concluded that existing EMSs in buildings with alarm functionalities, as well as monitoring systems in general, generate many alarms, overloading users with redundant information hindering their capacity to correctly handle their tasks. Moreover, to the best of our knowledge, most systems do not allow users to create new alarms based on complex conditions without modifying the application code. Finally, that monitoring applications capable of processing real- time data are already taking advantage of DSMSs as an alternative to DBMSs, because the processing rate required is higher than the supported by a traditional DBMS.

A systematization of alarm conditions regarding the building energy management domain was performed through a literature review and interviews with experienced building energy managers. After reviewing the literature we concluded that, to the best of our knowledge, there is no alarm systematization in the building energy management domain.

Building upon a DSMS-based architecture, this work creates both a visual DSL and an alarm system to support building energy managers to specify domain speciﬁc alarms involving complex conditions. This solution enable users to create new alarms just using the DSL on the system interface without the need to modify the application code. Using this solution, building energy managers are able to get enhanced control regarding existing alarms and conditions triggering them.

To validate the proposed solution we validated both the DSL and the alarm system developed. First, the ASL was validated with experienced building energy managers using a DSL validation methodology based on the literature, assessing the language effectiveness, efﬁciency, satisfaction, accessibility, reliability, and productivity. Second, the alarm system was assessed through its usability and performance characteristics. The results show that the DSL is easy to use and has a good domain coverage, being

65 the system easy to use and efﬁcient in the production of information.

7.1 Impact

Our systematization of alarm conditions used in the building energy management domain is of the utmost importance due to several factors. First, to the best of our knowledge, there is no alarm systematization in the building energy management domain. Second, considering the gathered conditions we identified the main requirements regarding alarm conditions in the building energy management domain (e.g. the required data sources, the need of historical data, and the need to detect that a threshold is reached). Finally, the conditions gathered and the requirements identified enable the development of adequate solutions that consider the users needs. The DSL and the alarm system developed enable building energy managers to specify domain specific alarms involving complex conditions. Therefore, building energy managers are able to get more control regarding existing alarms and the conditions triggering them. Additionally, since the alarm system provides information in a timely way, building energy managers are enabled to decide and act faster. Considering that the ASL has a good domain coverage and enables the specification of the necessary alarms, we can conclude that the existing stream query languages (provided by SPEs such as DSMSs) have enough power to express complex conditions regarding alarms. In addition to this, using a DSMS as underlying technology the alarm system developed is able to provide information in a timely way to users. Therefore, we consider that a new architecture based on a DSMS is a good approach to alarm systems.

7.2 Future Work

The development of a DSL and an alarm system has the possibility of ongoing enhancements. The proposed language and system are not an exception existing possible enhancements. First, it is necessary to develop a model to be used in the Forecast element. This model could be based, for example, on a linear regression, enabling a simple implementation consisting in having a continuous query producing results according to a linear regression equation. In this equation one can use the aggregated value received from the Aggregation element, the current day of the week (such as Monday and Tuesday), current season (e.g. summer or winter), and time as independent variables to calculate a forecast (dependent variable) of the value received from the Aggregation element. Second, there are other alarm quality techniques that can be implemented in the alarm system. These include, for instance, the creation of an interface where users can specify conditions that the alarm system uses to prevent alarm indications, implementing this a suppression method, namely the suppressed by design technique. Third, there is also potential to explore historical data regarding alarms. This way, it is possible to extract information like how many alarms occurred in the last day and what are their priorities. This

66 information could be used, for instance, to detect that an alarm trigger condition must be updated, because, for example, a building has been experiencing an increase of energy consumption. Fourth, it is possible to implement a re-utilization of the queries used by the alarms. Each query has a well defined behaviour that identifies itself as a unique query. Therefore, it is possible that multiple alarms re-utilize queries. This way, when a query is created it is stored on a data structure and when an alarm is being created each language element before the creation of the corresponding query searches on that data structure to find a similar query and if it exists it is re-utilized. Finally, during the alarm management life-cycle it is necessary to modify existing alarms. Therefore, there is a feature regarding this requirement to be implemented. To do this, it is necessary to develop an interface similar to the one used to create a new alarm. This interface enables users to modify the alarm, and sends a request to the alarm system. To modify the existing alarm specification the alarm system can re-use the algorithm developed to convert an alarm trigger condition into continuous queries.

67 68 Bibliography

[1] Daniel J. Abadi, Don Carney, Ugur Cetintemel, Mitch Cherniack, Christian Convey, Sangdon Lee, Michael Stonebraker, Nesime Tatbul, and Stan Zdonik. Aurora: a new model and architecture for data stream management. The VLDB Journal The International Journal on Very Large Data Bases, 12(2):120–139, aug 2003. ISSN 1066-8888. doi: 10.1007/s00778-003-0095-z.

[2] ABB. Alarm Management for power generation. ABB, pages 1–8, 2012.

[3] Charu C. Aggarwal. Classiﬁcation in Streams. In M. TAMER LIU, LING OZSU,¨ editor, Encyclope- dia of Database Systems, pages 340–341. Springer US, 2009.

[4] Nadeem Akhtar and FH Siddiqui. UDP Packet Monitoring with Stanford Data Stream Manager. In International Conference on Recent Trends in Information Technology, pages 533–537. IEEE, jun 2011. ISBN 978-1-4577-0588-5. doi: 10.1109/ICRTIT.2011.5972403.

[5] Leman Akoglu, Hanghang Tong, and Danai Koutra. Graph based anomaly detection and description: a survey. Data Mining and Knowledge Discovery, pages 1–63, jul 2014. ISSN 1384-5810. doi: 10.1007/s10618-014-0365-y.

[6] Diogo Anjos, Paulo Carreira, and Alexandre P Francisco. Real-Time Integration of Building En- ergy Data. In IEEE International Congress on Big Data (BigData Congress), pages 250 – 257, Anchorage, AK, 2014. IEEE.

[7] ANSI/ISA 18.2. ANSI/ISA - 18.2 - 2009 Management of Alarm Systems for the Process Industries, 2009.

[8] Arvind Arasu, Brian Babcock, Shivnath Babu, John Cieslewicz, Mayur Datar, Keith Ito, Rajeev Motwani, Utkarsh Srivastana, and Jennifer Widom. Stream: The Stanford Data Stream Manage- ment System. Technical report, Stanford InfoLab, 2004.

[9] Arvind Arasu, Shivnath Babu, and Jennifer Widom. The CQL continuous query language: se- mantic foundations and query execution. The VLDB Journal, 15(2):121–142, jul 2005. ISSN 1066-8888. doi: 10.1007/s00778-004-0147-z.

[10] Jordan Ash, Monica Babes, Gal Cohen, Sameen Jalal, Sam Lichtenberg, Michael Littman, Phillip Quiza, Blase Ur, and Emily Zhang. Scratchable Devices : User-Friendly Programming for House-

69 hold Appliances. In Human-Computer Interaction. Towards Mobile and Intelligent Interaction En- vironments, pages 137–146. Springer Berlin Heidelberg, 2011.

[11] Adiel Ashrov, Assaf Marron, Gera Weiss, and Guy Wiener. A use-case for behavioral programming: An architecture in JavaScript and Blockly for interactive applications with cross- cutting scenarios. Science of Computer Programming, 1:1–25, feb 2014. ISSN 01676423. doi: 10.1016/j.scico.2014.01.017.

[12] Brian Babcock, Babu Shivnath, Mayur Datar, Rajeev Motwani, and Jennifer Widom. Models and Issues in Data Stream Systems. In Twenty-First ACM SIGMOD-SIGACT-SIGART Symposium on Principles of database systems, pages 1–16, New York, New York, USA, 2002. ACM Press. ISBN 1581135076. doi: 10.1145/543614.543615.

[13] Yijian Bai, Hetal Thakkar, Haixun Wang, Chang Luo, and Carlo Zaniolo. A data stream language and system designed for power and extensibility. In 15th ACM international conference on In- formation and knowledge management, pages 337–346, New York, New York, USA, 2006. ACM Press. ISBN 1595934332. doi: 10.1145/1183614.1183664.

[14] Ankica Barisiˇ c,´ Vasco Amaral, Miguel Goulao,˜ and Bruno Barroca. How to reach a usable DSL? Moving toward a Systematic Evaluation. Electronic Communications of the EASST, 50, 2011.

[15] Ankica Barisiˇ c,´ Vasco Amaral, Miguel Goulao,˜ Bruno Barroca, and M Goulao. Quality in use of domain-speciﬁc languages: a case study. In 3rd ACM SIGPLAN Workshop on Evaluation and usability of programming languages and tools, pages 65–72. ACM New York, NY, USA, 2011. ISBN 9781450310246. doi: 10.1145/2089155.2089170.

[16] Ankica Barisiˇ c,´ Vasco Amaral, and Miguel Goulao. Usability Evaluation of Domain-Speciﬁc Lan- guages. In Eighth International Conference on the Quality of Information and Communications Technology, pages 342–347. IEEE, 2012. ISBN 978-1-4673-2345-1. doi: 10.1109/QUATIC.2012. 63.

[17] Ankica Barisiˇ c,´ Vasco Amaral, Miguel Goulao,˜ and Bruno Barroca. Evaluating the Usability of Domain-Speciﬁc Languages. In Marjan Mernik, editor, Formal and Practical Aspects of Domain- Speciﬁc Languages: Recent Developments. Information Science Reference, 2012.

[18] Len Bass, Paul Clements, and Rick Kazman. Performance. In Software Architecture in Practice, chapter 8. Addison-Wesley, third edition, 2013.

[19] Don Batory. Feature Models, Grammars, and Propositional Formulas. In Henk Obbink and Klaus Pohl, editors, Software Product Lines, pages 7–20. Springer Berlin Heidelberg, 2005.

[20] Emanuela Bauleo, Serena Carnevale, Tiziana Catarci, Stephen Kimani, Mariano Leva, and Mas- simo Mecella. Design, realization and user evaluation of the SmartVortex Visual Query System for accessing data streams in industrial engineering applications. Journal of Visual Languages & Computing, 25(5):577–601, oct 2014. ISSN 1045926X. doi: 10.1016/j.jvlc.2014.08.002.

70 [21] Kalyani Bhaskar, V. V S Sarma, D. Thukaram, and K. Ramakrishna. Decision support requirements for intelligent operation of southern grid in India. In IEEE Power India Conference, pages 635–641, New Delhi, 2006. IEEE. ISBN 0780395255. doi: 10.1109/POWERI.2006.1632582.

[22] Dines Bjorner. Syntax. In Software Engineering 2 - Speciﬁcation of Systems and Languages, pages 173–212. Springer Berlin Heidelberg, 2006.

[23] Zhong Bocheng. Design of Building Energy Monitoring and Management System. In Second International Conference on Business Computing and Global Informatization, pages 645–648. IEEE, 2012. ISBN 978-1-4673-4469-2. doi: 10.1109/BCGIN.2012.173.

[24] Philippe Bonnet, Johannes Gehrke, and Praveen Seshadri. Towards Sensor Database Systems. In Second International Conference on Mobile Data Management, pages 3–14. Springer-Verlag London, UK, 2001.

[25] M L Bransby and J Jenkinson. The management of alarm systems. Technical report, Bransby Automation Ltd & Tekton Engineering, 1998.

[26] Jean Bresson and Jean-Louis Giavitto. A reactive extension of the OpenMusic visual programming language. Journal of Visual Languages & Computing, 25(4):363–375, aug 2014. ISSN 1045926X. doi: 10.1016/j.jvlc.2014.03.003.

[27] E.H. Bristol. Improved process control alarm operation. ISA Transactions, 40(2):191–205, apr 2001. ISSN 00190578. doi: 10.1016/S0019-0578(00)00004-5.

[28] Peter Bullemer and Doug Metzger. Process Safety Metrics Review : Considerations from an ASM Perspective. pages 1–9. Abnormal Situation Management (ASM) Consortium, 2008.

[29] Peter T Bullemer, Dal Vernon C Reising, Mischa Tolsma, and Jason C Laberge. Towards Im- proving Operator Alarm Flood Responses: Alternative Alarm Presentation Techniques. Technical report, Abnormal Situation Management (ASM) Consortium, 2011.

[30] BL Capehart. Information technology for energy managers. Fairmont Press, 2004. ISBN 0881734497.

[31] Don Carney and U C¸etintemel. Monitoring streams: a new class of data management applications. In 28th VLDB Conference, pages 1–12. ACM, 2002.

[32] Ugur Cetintemel, Daniel Abadi, Yanif Ahmad, Hari Balakrishnan, Magdalena Balaxinska, Mitch Cherniack, Jeong-Hyon Hwang, Wolfgang Lindner, Samuel Madden, Anurag Maskey, Alexander Rasin, Esther Ryvkina, Mike Stonebraker, Nesime Tatbul, Ying Xing, and Stan Zdonik. The Aurora and Borealis Stream Processing Engines. Technical report, Brown University, M.I.T., and Brandeis University, 2006.

[33] Sharma Chakravarthy and Qingchun Jiang. Stream Data Processing: A Quality of Service Per- spective. Springer, 2009. ISBN 978-0-387-71003-7. doi: 10.1007/978-0-387-71003-7.

71 [34] Varun Chandola, Arindam Banerjee, and Vipin Kumar. Anomaly Detection: A Survey. ACM Computing Surveys, 41(3):1–58, jul 2009. ISSN 03600300. doi: 10.1145/1541880.1541882.

[35] Badrish Chandramouli, Mohamed Ali, Jonathan Goldstein, Beysim Sezgin, and Balan Sethu Ra- man. Data stream management systems for computational ﬁnance. Computer, 43:45–52, 2010. ISSN 00189162. doi: 10.1109/MC.2010.346.

[36] Bei Chen, Mathieu Sinn, Joern Ploennigs, and Anika Schumann. Statistical Anomaly Detection in Mean and Variation of Energy Consumption. In 22nd International Conference on Pattern Recognition. IEEE, 2014. doi: 10.1109/ICPR.2014.614.

[37] Chao Chen and Diane Cook. Energy Outlier Detection in Smart Environments. Artiﬁcial Intelli- gence and Smarter Living, 11(07):9–14, 2011.

[38] Jianjun Chen, David J. DeWitt, Feng Tian, and Yuan Wang. NiagaraCQ: A Scalable Continuous Query System for Internet Databases. In ACM SIGMOD International Conference on Management of Data, pages 379–390. ACM, 2000. ISBN 1581132182.

[39] Mitch Cherniack and Stan Zdonik. Stream-Oriented Query Languages and Operators. In LING LIU and M. TAMER OZSU,¨ editors, Encyclopedia of Database Systems, pages 2848–2854. Springer US, 2009.

[40] William Chung and Y. V. Hui. A study of energy efﬁciency of private ofﬁce buildings in Hong Kong. Energy and Buildings, 41:696–701, 2009. ISSN 03787788. doi: 10.1016/j.enbuild.2009.02.001.

[41] William Chung, Y. V. Hui, and Y. Miu Lam. Benchmarking the energy efﬁciency of commercial buildings. Applied Energy, 83(1):1–14, 2006. ISSN 03062619. doi: 10.1016/j.apenergy.2004.11. 003.

[42] P.J. Clemente, J. M. Conejero, J. Hernandez,´ and L. Sanchez.´ HAAIS-DSL: DSL to Develop Home Automation and Ambient Intelligence Systems. In Second Workshop on Isolation and Integration in Embedded Systems, pages 13–18. ACM, 2009.

[43] Jonathan Cook and Alan Meier. Coordinating Fault Detection , Alarm Management , and Energy Efﬁciency in a Large Corporate Campus. Technical report, ACEEE Summer Study on Energy Efﬁciency in Buildings, 2012.

[44] Lucie Copin, Herve Rey, Xavier Vasques, Anne Laurent, and Maguelonne Teisseire. Intelligent Energy Data Warehouse: What Challenges? In 2010 22nd IEEE International Conference on Tools with Artiﬁcial Intelligence, pages 337–342. IEEE, oct 2010. ISBN 978-1-4244-8817-9. doi: 10.1109/ICTAI.2010.120.

[45] Andrea Costa, Marcus M. Keane, J. Ignacio Torrens, and Edward Corry. Building operation and energy performance: Monitoring, analysis and optimisation toolkit. Applied Energy, 101:310–316, 2013. ISSN 03062619. doi: 10.1016/j.apenergy.2011.10.037.

72 [46] Chuck Cranor, Johnson Theodore, Oliver Spataschek, and Vladislav Shkapenyuk. Gigascope: A Stream Database for Network Applications. In ACM SIGMOD International Conference on Management of data, pages 647–651. ACM, 2003. ISBN 158113634X.

[47] Gianpaolo Cugola and Alessandro Margara. Processing Flows of Information: From Data Stream to Complex Event Processing. ACM Computing Surveys (CSUR), 44(3):1–69, 2012.

[48] Fredrik Dahlstrand. Consequence analysis theory for alarm analysis. Knowledge-Based Systems, 15(1-2):27–36, jan 2002. ISSN 09507051. doi: 10.1016/S0950-7051(01)00118-6.

[49] Sarah Darby. Energy feedback in buildings: improving the infrastructure for demand reduction. Building Research & Information, 36(February):499–508, 2008. ISSN 0961-3218. doi: 10.1080/ 09613210802028428.

[50] Judith R. Davis. Right-Time Business Intelligence: Optimizing the Business Decision Cycle. Tech- nical report, Business Intelligence Network, 2006.

[51] Alan Demers, Johannes Gehrke, Biswanath Panda, Mirek Riedewald, Varun Sharma, and Walker White. Cayuga: A General Purpose Event Monitoring System. In Conference on Innovative Data Systems Research, pages 412–422, 2007.

[52] Arthur Dexter and Jouko Pakanen. Demonstrating Automated Fault Detection and Diagnosis Methods in Real Buildings. Technical report, International Energy Agency - Energy Conservation in Buildings and Community Systems ANNEX 34, 2001.

[53] Patrick Marcel Dherte, Mariana Pires Gentil Negrao,˜ Silvio Mori Neto, Rafael Holzhacker, Vanessa Shimada, Paula Taberner, and Maria Jose´ Carvalho Carmona. Smart Alerts: Development of Software to Optimize Data Monitoring. Brazilian Journal of Anesthesiology, 61(1):72–80, 2011. ISSN 1806-907X. doi: 10.1016/S0034-7094(11)70008-3.

[54] John D. N. Dionisio and Alfonso F. Cardenas.´ MQuery : A Visual Query Language for Multimedia, Timeline and Simulation Data. Journal of Visual Languages and Computing, 7:377–401, 1996.

[55] Lian Duan and Li Da Xu. Business Intelligence for Enterprise Systems : A Survey. IEEE Transac- tions on Industrial Informatics, 8(3):679–687, 2012.

[56] EEMUA 191. EEMUA Publication 191 Alarm Systems - A Guide to Design, Management and Procurement. Engineering Equipment and Materials Users Association (EEMUA), third edition, 2013.

[57] Frank Eichinger, Daniel Pathmaperuma, Harald Vogt, and M Emmanuel. Data Analysis Chal- lenges in the Future Energy Domain. In Computational Intelligent Data Analysis for Sustainable Development, pages 1–55. CRC Press, 2013.

[58] Opher Etzion. Event Pattern Detection. In LING LIU and M. TAMER OZSU,¨ editors, Encyclopedia of Database Systems, pages 1046–1048. Springer US, 2009.

73 [59] Opher Etzion and Peter Niblett. Event Processing in Action. Manning, 2010. ISBN 9781935182214.

[60] Ted Faison. Event-Based Programming: Taking Events to the Limit. Apress, 2006. ISBN 9781590596432.

[61] Simon Fong and Yang Hang. Enabling Real-Time Business Intelligence by Stream Mining. In New Fundamental Technologies in Data Mining. 2010.

[62] Luigi Fortuna, Salvatore Graziani, Alessandro Rizzo, and Maria G. Xibilia. Fault Detection, Sensor Validation and Diagnosis. In Soft Sensors for Monitoring and Control of Industrial Processes, pages 183–226. Springer London, 2007.

[63] H Friedman, E Crowe, E Sibley, and M Efﬁnger. The Building Performance Tracking Handbook - Continuous Improvement For Every Building. Technical report, Portland Energy Conservation, Inc., 2011.

[64] Pedro Gabriel, Miguel Goulao,˜ and Vasco Amaral. Do Software Languages Engineers Evaluate their Languages? In XIII Congreso Iberoamericano en ”Software Engineering”, pages 149–162, 2010. ISBN 9789978325100.

[65] J Gama and M Gaber. Learning from Data Streams Processing Techniques in Sensor Networks. Springer, 2007. ISBN 9783540736783.

[66] Joao˜ Gama. A survey on learning from data streams: current and future trends. Progress in Artiﬁcial Intelligence, 1(1):45–55, jan 2012. ISSN 2192-6352. doi: 10.1007/s13748-011-0002-6.

[67] Joao˜ Gama and Pedro Pereira Rodrigues. Data Stream Processing. In Joao˜ Gama and Mo- hamed Medhat Gaber, editors, Learning from Data Streams, pages 25–38. Springer, 2007.

[68] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional, 1994.

[69] Zach Gima, Qunzhi Zhou, Yogesh Simmhan, and Viktor Prasanna. Complex Event Processing for Intelligent Energy Management in Microgrids. In 3rd Annual Ming Hsieh Department of Electrical Engineering Research Festival, page 1. University of Southern California, 2013.

[70] Lukasz Golab and M Tamer Ozsu. Issues in Data Stream Management. ACM SIGMOD Record, 32(2):5–14, 2003.

[71] J. Granderson, M.A. Piette, B. Rosenblum, and L. Hu. Energy Information Handbook: Applications for Energy-Efﬁcient Building Operations. Lawrence Berkeley National Laboratory, LBNL-5272E. 2011.

[72] Jessica Granderson, M. A. Piette, G. Ghatikar, and P. Price. Building Energy Information Sys- tems: State of Technology and User Case Studies. Lawrence Berkeley National Laboratory. LBNL- 2899E. In Barney L. Capehart and Timothy Middelkoop, editors, Handbook of Web Based Energy Information and Control Systems, chapter 10, pages 133–182. Fairmont Press, ﬁrst edition, 2011.

74 [73] Vincenzo Massimiliano Gulisano. StreamCloud : An Elastic Parallel-Distributed Stream Process- ing Engine. Phd thesis, Universidad Politecnica´ de Madrid, 2012.

[74] Jiawei Han. Data Mining. In M. TAMER LIU, LING OZSU,¨ editor, Encyclopedia of Database Systems, pages 595–598. Springer US, 2009.

[75] Jiawei Han and Bolin Ding. Stream Mining. In LING LIU and M. TAMER OZSU,¨ editors, Encyclo- pedia of Database Systems, pages 2831–2834. Springer US, 2009.

[76] Yang Hang and Simon Fong. Real-time Business Intelligence System Architecture with Stream Mining. In 2010 Fifth International Conference on Digital Information Management (ICDIM), pages 29–34. IEEE, jul 2010. ISBN 978-1-4244-7572-8. doi: 10.1109/ICDIM.2010.5664637.

[77] D. D. Hatley, R.J. Meador, S. Katipamula, and M. R. Brambley. Energy Management and Control System: Desired Capabilities and Functionality. Technical Report April, US Department of Energy, 2005.

[78] Philip Henderson and Meg Waltner. Real-Time Energy Management A Case Study of Three Large Commercial. Technical Report october, Natural Resources Defense Council, 2013.

[79] Felienne Hermans, Martin Pinzger, and Arie van Deursen. Domain-speciﬁc languages in practice: A user study on the success factors, volume 5795. Springer Berlin Heidelberg, 2009. ISBN 3642044247. doi: 10.1007/978-3-642-04425-0 33. {\ } [80] V.J. Hodge and Jim Austin. A Survey of Outlier Detection Methodologies. Artiﬁcial Intelligence Review, 22(2):85–126, 2004.

[81] Mingsheng Hong, Alan Demers, Johannes Gehrke, and Mirek Riedewald. Event and Pat- tern Detection over Streams. In LING LIU and M. TAMER OZSU,¨ editors, Encyclopedia of Database Systems, pages 1029–1033. Springer US, 2009. ISBN 9783540693185. doi: 10.1007/978-3-540-69319-2 1. {\ } [82] JH Hooke, D Hart, and BJ Landry. Energy Management Information Systems: Achieving Improved Energy Efficiency: a Handbook for Managers, Engineers and Operational Staff. Technical report, Office of Energy Efficiency of Natural Resources Canada, 2004.

[83] M. Anwar Hossain, Pradeep K. Atrey, and Abdulmotaleb El Saddik. Modeling and Assessing Quality of Information in Multisensor Multimedia Monitoring Systems. ACM Transactions on Multi- media Computing, Communications, and Applications, 7(1):1–30, jan 2011. ISSN 15516857. doi: 10.1145/1870121.1870124.

[84] J Hyvarinen and S Karki. Building Optimization and Fault Diagnosis Source Book. Technical report, International Energy Agency, 1996.

[85] ISO 9241-11. ISO 9241-11:1998 Ergonomic requirements for ofﬁce work with visual display ter- minals – Part 11: Guidance on usability, 1998.

75 [86] ISO/IEC 25010. ISO/IEC 25010:2011 Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models, 2011.

[87] Iman Izadi, Sirish L. Shah, and Tongwen Chen. Effective resource utilization for Alarm Manage- ment. In 49th IEEE Conference on Decision and Control (CDC), pages 6803–6808. IEEE, dec 2010. ISBN 978-1-4244-7745-6. doi: 10.1109/CDC.2010.5717328.

[88] Halldor´ Janetzko, Florian Stoffel, Sebastian Mittelstadt,¨ and Daniel A. Keim. Anomaly detection for visual analytics of power consumption data. Computers & Graphics, 38:27–37, 2014.

[89] Xiaorui Jiang, S Yoo, and J Choi. DSMS in Ubiquitous-Healthcare: A Borealis-based Heart Rate Variability Monitor. In 4th International Conference on Biomedical Engineering and Informatics (BMEI), pages 2144–2147. IEEE, 2011. ISBN 9781424493524.

[90]G okhan¨ Kahraman and Semih Bilgen. A framework for qualitative assessment of domain-speciﬁc languages. Software & Systems Modeling, 14(4):1505–1526, 2015.

[91] Srinivas Katipamula and Michael Brambley. Review Article: Methods for Fault Detection, Diag- nostics, and Prognostics for Building Systems - A Review, Part I. HVAC&R Research, 11(1):3–25, jan 2005. ISSN 1078-9669. doi: 10.1080/10789669.2005.10391123.

[92] M Kezunovic and Yufan Guan. Intelligent alarm processing: from data intensive to information rich. In 42nd Hawaii International Conference on System Sciences, pages 1–8. IEEE, 2009. ISBN 9780769534503.

[93] Andrew King, Alex Roederer, David Arney, Sanjian Chen, Margaret Fortino-mullen, C William Han- son Iii, Vanessa Kern, Nicholas Stevens, Jonathan Tannen, Adrian Viesca Trevino, Soojin Park, Oleg Sokolsky, and Insup Lee. GSA : A Framework for Rapid Prototyping of Smart Alarm Sys- tems. In 1st ACM International Health Informatics Symposium, pages 487–491. ACM, 2010. ISBN 9781450300308.

[94] Barbara Kitchenham. Procedures for performing systematic reviews. Technical report, Keele University, 2004.

[95] Anneke Kleppe. Software Language Engineering: Creating Domain-Speciﬁc Languages Using Metamodels. Addison-Wesley Professional, 2008.

[96] Paul Klint, Arie Van Deursen, Paul Klint, and Joost Visser. Domain-Speciﬁc Languages : An Annotated Bibliography. SIGPLAN Not., 35(6):26–36, 2000.

[97] Ds Kolovos and Rf Paige. Requirements for domain-speciﬁc languages. In First ECOOP Work- shop on Domain-Speciﬁc Program Development, pages 1–4, 2006.

[98] Sandeep R. Kondaveeti, Iman Izadi, Sirish L. Shah, Tim Black, and Tongwen Chen. Graphical tools for routine assessment of industrial alarm systems. Computers & Chemical Engineering, 46 (15):39–47, nov 2012. ISSN 00981354. doi: 10.1016/j.compchemeng.2012.06.042.

76 [99] Vikhorev Konstantin, Richard Greenough, and Neil Brown. An advanced energy management framework to promote energy awareness. Journal of Cleaner Production, 43:103–112, mar 2013. ISSN 09596526. doi: 10.1016/j.jclepro.2012.12.012.

[100] Tomazˇ Kosar, Pablo E. Mart´ınez Lopez,´ Pablo a. Barrientos, and Marjan Mernik. A preliminary study on various implementation approaches of domain-speciﬁc language. Information and Soft- ware Technology, 50(5):390–405, 2008. ISSN 09505849. doi: 10.1016/j.infsof.2007.04.002.

[101] Rajeev Kumar. Recent advances in SCADA alarm system. International Journal of Smart Home, 4(4):1–10, 2010. ISSN 19754094.

[102] Sanjay Kumar, S Sinha, T Kojima, and H Yoshida. Development of parameter based fault detection and diagnosis technique for energy efﬁcient building management system. Energy Conversion and Mangement, 42:833–854, 2001.

[103] V. Kumar. Parallel and Distributed Computing for Cybersecurity. IEEE Distributed Systems Online, 6(10):1–1, oct 2005. ISSN 1541-4922. doi: 10.1109/MDSO.2005.53.

[104] G. Lambert-Torres, E.F. Fonseca, M.P. Coutinho, and R. Rossi. Intelligent Alarm Processing. In 2006 International Conference on Power System Technology, pages 1–6. IEEE, oct 2006. ISBN 1-4244-0110-0. doi: 10.1109/ICPST.2006.321758.

[105] Jessica Lin, Eamonn Keogh, Stefano Lonardi, and Bill Chiu. A symbolic Representation of Time Series, with Implications for Streaming Algorithms. In 8th ACM SIGMOD workshop on Research issues in data mining and knowledge discovery, pages 2–11, New York, New York, USA, 2003. ACM Press. doi: 10.1145/882085.882086.

[106] Bela G. Liptak, editor. Instrument Engineers’ Handbook Vol. 2: Process Control and Optimization. CRC Press, 4th edition, 2005.

[107] Ning Lu, Pengwei Du, Patrick Paulson, Frank Greitzer, Xinxin Guo, and Mark Hadley. A multi- layer, hierarchical information management system for the smart grid. In IEEE Power and Energy Society General Meeting, pages 1–8. IEEE, 2011. ISBN 978-1-4577-1001-8. doi: 10.1109/PES. 2011.6039214.

[108] McKinstry. Enterprise Energy Management Suite (EEM SuiteTM), 2015.

[109] Paul Medlock-Walton, Kyle J. Harms, Eileen T. Kraemer, Karen Brennan, and Daniel Wendel. Blocks-based Programming Languages: Simplifying Programming for Different Audiences with Different Goals. In 45th ACM technical symposium on Computer science education, volume 46, pages 545–546. ACM New York,NY, USA, sep 2014. ISBN 9781450326056. doi: 10.1109/MC. 2013.229.

[110] 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 UbiComp ’14

77 Proceedings of the 2014 ACM International Joint Conference on Pervasive and Ubiquitous Com- puting, pages 105–115. ACM, 2014. ISBN 9781450329682.

[111] Nirvana Meratnia and Paul Havinga. Outlier Detection Techniques for Wireless Sensor Networks: A Survey. IEEE Communications Surveys & Tutorials, 12(2):159–170, 2010. ISSN 1553-877X. doi: 10.1109/SURV.2010.021510.00088.

[112] Marjan Mernik, J Heering, and A.M. Sloane. When and how to develop domain-speciﬁc languages. ACM computing surveys (CSUR), 37(4):316–344, 2005.

[113] Evan Mills. Building Commissioning: A Golden Opportunity for Reducing Energy Costs and Greenhouse Gas Emissions. Technical report, Lawrence Berkeley National Laboratory, 2009.

[114] N Motegi and MA Piette. Case Studies of Energy Information Systems and Related Technol- ogy: Operational Practices, Costs, and Beneﬁts. In Third International Conference for Enhanced Building Operations, pages 1–10, Berkeley, California, 2003.

[115] Aniruddha Mukherjee, Punit Diwan, Prasun Bhattacharjee, Debnath Mukherjee, and Prateep Misra. Capital Market Surveillance using Stream Processing. In 2010 2nd International Con- ference on Computer Technology and Development, number Icctd, pages 577–582. IEEE, nov 2010. ISBN 978-1-4244-8844-5. doi: 10.1109/ICCTD.2010.5645965.

[116] Tho Manh Nguyen and A Min Tjoa. Zero-latency Data Warehousing (ZLDWH): the State-of-the- art and experimental implementation approaches. In 2006 International Conference onResearch, Innovation and Vision for the Future, pages 167–176. IEEE, 2006. ISBN 1-4244-0316-2. doi: 10.1109/RIVF.2006.1696434.

[117] Jakob Nielsen and Rolf Molich. Heuristic Evaluation of user interfaces. In SIGCHI Conference on Human Factors in Computing Systems, number April, pages 249–256. ACM New York, NY, USA, 1990. ISBN 0201509326. doi: 10.1145/97243.97281.

[118] Zeljko Panian. Just-in-Time Business Intelligence and Real-Time Decisioning. International Jour- nal of Applied Mathematics and Informatics, 1(1):28–35, 2007.

[119] Spiros Papadimitriou. Anomaly Detection on Streams. In LING LIU and M. TAMER OZSU,¨ editors, Encyclopedia of Database Systems, pages 88–90. Springer US, 2009.

[120] M.S.B. PhridviRaj and C.V. GuruRao. Data Mining – Past, Present and Future – A Typical Survey on Data Streams. Procedia Technology, 12:255–263, 2014. ISSN 22120173. doi: 10.1016/j. protcy.2013.12.483.

[121] Clifton Phua, Damminda Alahakoon, and Vincent Lee. Minority Report in Fraud Detection : Clas- siﬁcation of Skewed Data. ACM SIGKDD Explorations Newsletter - Special issue on learning from imbalanced datasets, 6(1):50–59, 2004.

78 [122] Shaileen Crawford Pokress and Jose´ Juan Dominguez Veiga. MIT App Inventor Enabling personal mobile computing. In Programming for Mobile and Touch, pages 1–3, Indianapolis, IN, USA, 2013. MIT Media Lab, ACM.

[123] Yemula Pradeep and S. A. Khaparde. Complex Event Processing of High Level Events in Multi- area Power Grid : An Indian Perspective. In 2010 IEEE Power and Energy Society General Meeting, pages 1–6, Minneapolis, MN, 2010. IEEE. ISBN 9781424465514.

[124] Jon T.S. Quah and M. Sriganesh. Real-time credit card fraud detection using computational intelligence. Expert Systems with Applications, 35(4):1721–1732, nov 2008. ISSN 09574174. doi: 10.1016/j.eswa.2007.08.093.

[125] MA Rassam, Anazida Zainal, and MA Maarof. Advancements of Data Anomaly Detection Re- search in Wireless Sensor Networks: A Survey and Open Issues. Sensors, 13(8):10087–122, jan 2013. ISSN 1424-8220. doi: 10.3390/s130810087.

[126] George P. Redei.´ Syntax. In Encyclopedia of Genetics, Genomics, Proteomics and Informatics, page 1912. Springer Netherlands, 2008.

[127] Mitchel Resnick and John Maloney. Scratch: programming for all. Magazine Communications of the ACM - Scratch Programming for All, 52(11):60–67, 2009. doi: 10.1145/1592761.1592779.

[128] Douglas Rothenberg. Alarm Management for Process Control. Momentum Press, 2009.

[129] George Runger. Leveraging Smart Meter Data through Advanced Analytics: Applications to Build- ing Energy Efﬁciency. Master thesis, Arizona State University, 2013.

[130] David Savage, Xiuzhen Zhang, Xinghuo Yu, Pauline Chou, and Qingmai Wang. Anomaly detection in online social networks. Social Networks, 39:62–70, oct 2014. ISSN 03788733. doi: 10.1016/j. socnet.2014.05.002.

[131] Markus Schleburg, Lars Christiansen, Nina F. Thornhill, and Alexander Fay. A combined analysis of plant connectivity and alarm logs to reduce the number of alerts in an automation system. Journal of Process Control, 23(6):839–851, jul 2013. ISSN 09591524. doi: 10.1016/j.jprocont. 2013.03.010.

[132] Yogesh Simmhan, Saima Aman, Baohua Cao, Mike Giakkoupis, Alok Kumbhare, Qunzhi Zhou, Donald Paul, Carol Fern, Aditya Sharma, and Viktor Prasanna. An Informatics Approach to De- mand Response Optimization in Smart Grids. NATURAL GAS, 31:1–14, 2011.

[133] Yogesh Simmhan, Viktor Prasanna, Saima Aman, Sreedhar Natarajan, Wei Yin, and Qunzhi Zhou. Demo Abstract: Toward Data-driven Demand-Response Optimization in a Campus Microgrid. In ACM Workshop On Embedded Sensing Systems For Energy-Efﬁciency In Buildings, Seatle, Wa, USA, 2011. ACM. ISBN 9781450307499.

79 [134] Chandrasekaran Sirish, Cooper Owen, Deshpande Amol, Michael J. Franklin, Joseph M. Heller- stein, Hong Wei, Krishnamurthy Sailesh, Sam Madden, Vijayshankar Raman, Fred Reiss, and Mehul Shah. TelegraphCQ: Continuous Dataﬂow Processing for an Uncertain World. In CIDR Conference, 2003.

[135] Hou Sizu and Zhang Xianfei. Alarms Association Rules Based on Sequential Pattern Mining Algorithm. In Fifth International Conference on Fuzzy Systems and Knowledge Discovery, pages 556–560. IEEE, oct 2008. ISBN 978-0-7695-3305-6. doi: 10.1109/FSKD.2008.11.

[136] Ian Sommerville. Software Engineering. Pearson-Wesley, ninth edition, 2011. ISBN 9780137035151.

[137] Todd Stauffer. Preventing Unplanned Downtime through Alarm Management: The Five Most Important Alarm Management Techniques for Preventing Unplanned Downtime. Technical report, Siemens Energy & Automation, Inc., 2006.

[138] Friedrich Steimann. Proving Aspect-Freeness of Domain Models. In Krzysztof Czarnecki, Ileana Ober, Jean-Michel Bruel, Axel Uhl, and Markus Volter,¨ editors, Model Driven Engineering Lan- guages and Systems. Springer Berlin Heidelberg, 2008.

[139] Nicholas Stevens, Ana Rosa Giannareas, Vanessa Kern, Adrian Viesca Trevino, Margaret Fortino- Mullen, Andrew King, and Insup Lee. Smart Alarms : Multivariate Medical Alarm Integration for Post CABG Surgery Patients. In 2nd ACM SIGHIT International Health Informatics Symposium, pages 533–542. ACM, 2012. ISBN 9781450307819. doi: 10.1145/2110363.2110423.

[140] Michael Stonebraker, Ugurˇ C¸etintemel, and Stan Zdonik. The 8 requirements of real-time stream processing. ACM SIGMOD Record, 34(4):42–47, dec 2005. ISSN 01635808. doi: 10.1145/ 1107499.1107504.

[141] Mark Sullivan and Andrew Heybey. Tribeca : A System for Managing Large Databases of Network Trafﬁc. In USENIX Annual Technical Conference, number 98, 1998.

[142] Aaron Tarjan. Development of a Decision Support Tool to Test Energy Management Alarming Thresholds. Master thesis, University of Miami, 2011.

[143] Gilbert Tekli, Richard Chbeir, and Jacques Fayolle. A visual programming language for XML ma- nipulation. Journal of Visual Languages & Computing, 24(2):110–135, apr 2013. ISSN 1045926X. doi: 10.1016/j.jvlc.2012.11.001.

[144] Franklyn Turbak, David Wolber, Mark Sherman, Fred Martin, and Shaileen Crawford Pokress. Events-First Programming in App Inventor. Journal of Computing Sciences in Colleges, 29(6): 81–89, 2014.

[145] Blase Ur, Elyse McManus, Melwyn Pak Yong Ho, and Michael L. Littman. Practical Trigger- Action Programming in the Smart Home. In 32nd ACM conference on Human factors in com-

80 puting systems - CHI ’14, pages 803–812, New York, New York, USA, 2014. ACM Press. ISBN 9781450324731. doi: 10.1145/2556288.2557420.

[146] Arie van Deursen and Paul Klint. Domain-Speciﬁc Language Design Requires Feature Descrip- tions. Journal of Computing and Information Technology, 10(1):1–17, 2002. ISSN 1330-1136. doi: 10.2498/cit.2002.01.01.

[147] Eelco Visser. WebDSL: A Case Study in Domain-Speciﬁc Language Engineering. In Ralf Lammel,¨ Joost Visser, and Joao˜ Saraiva, editors, Generative and Transformational Techniques in Software Engineering II, pages 291–373. Springer Berlin Heidelberg, 2008.

[148] Markus Voelter, Sebastian Benz, Christian Dietrich, Birgit Engelmann, Mats Helander, Lennart Kats, Eelco Visser, and Guido Wachsmuth. DSL Engineering Designing, Implementing and Using Domain-Speciﬁc Languages. CreateSpace Independent Publishing Platform, 2013. ISBN 978- 1481218580.

[149] Stefan Wallin. Chasing a Deﬁnition of “Alarm”. Journal of Network and Systems Management, 17 (4):457–481, may 2009. ISSN 1064-7570. doi: 10.1007/s10922-009-9127-3.

[150] Dumidu Wijayasekara, Ondrej Linda, Milos Manic, and Craig Rieger. Mining Building Energy Management System Data Using Fuzzy Anomaly Detection and Linguistic Descriptions. IEEE Transactions on Industrial Informatics, 10(3):1829–1840, 2014.

[151] Luc De Wilde and Dal Vernon Reising. Where Technology Shapes Solutions - Alarm management: Wasn’t that problem already solved years ago? Technical report, Honeywel and Abnormal Situation Management (ASM) Consortium, 2011.

[152] Cassandra L Hawkins Wilson, Mississippi Ofﬁce, The Alliance, and Certiﬁed Hazardous. Using MIT App Inventor in an Emergency Management Course to Promote Computational Thinking. In 121st American Society for Engineering Education, number 2007. American Society for Engineer- ing Education, American Society for Engineering Education, 2014.

[153] Anthony D. Wood, John a. Stankovic, Gilles Virone, Leo Selavo, Zhimin He, Qiuhua Cao, Thao Doan, Yafeng Wu, Lei Fang, and Radu Stoleru. Context-aware wireless sensor networks for as- sisted living and residential monitoring. IEEE Network, 22(August):26–33, 2008. ISSN 08908044. doi: 10.1109/MNET.2008.4579768.

[154] Yali Wu, Frank Hernandez, Francisco Ortega, Peter J. Clarke, and Robert France. Measuring the effort for creating and using domain-speciﬁc models. In 10th Workshop on Domain-Speciﬁc Modeling, number 14. ACM, 2010. ISBN 9781450305495. doi: 10.1145/2060329.2060360.

[155] Zongda Wu, Guandong Xu, Yanchun Zhang, Zhongsheng Cao, Guiling Li, and Zhiwen Hu. GMQL: A graphical multimedia query language. Knowledge-Based Systems, 26:135–143, feb 2012. ISSN 09507051. doi: 10.1016/j.knosys.2011.07.013.

81 [156] F Yang, S L Shah, D Xiao, and T Chen. Improved correlation analysis and visualization of industrial alarm data. ISA transactions, 51(4):499–506, jul 2012. ISSN 1879-2022. doi: 10.1016/j.isatra. 2012.03.005.

[157] Hang Yang and Simon Fong. The Impacts of Data Stream Mining on Real-Time Business Intel- ligence. In 2nd international Conference on IT & Business Intelligence (ITBI-10), pages p. 9–19, 2010.

[158] Yong Yao and Johannes Gehrke. The cougar approach to in-network query processing in sensor networks. ACM SIGMOD Record, 31(3):9, sep 2002. ISSN 01635808. doi: 10.1145/601858. 601861.

[159] David J. Young and James R. McDonald. Alarm Processing. In Intelligent knowledge based systems in electrical power engineering, chapter 7, pages 119–154. Springer US, 1997. ISBN 9781461563877.

[160] Chulhee Yun, Jaegon Ahn, and Yeon-ho Kim. A Fusion of Computer Vision Technique and a Visual Programming Language for Edutainment Robots. In 44th International Symposium on Robotics (ISR), 2013, pages 1–5, Seoul, 2013. IEEE. ISBN 8232329548.

[161] Qing Zhang, Chaoyi Pang, Simon Mcbride, David Hansen, Charles Cheung, and Michael Steyn. Towards Health Data Stream Analytics. In The 2010 IEEE/ICME International Conference on Complex Medical Engineering, pages 282–287. IEEE, 2010. ISBN 9781424468430.

[162] Yang Zhang, Nirvana Meratnia, and Paul Havinga. A Taxonomy Framework for Unsupervised Outlier Detection Techniques for Multi-Type Data Sets. Technical report, University of Twente, 2007.

[163] Hu Zhengbing, Li Zhitang, and Wu Junqi. A Novel Network Intrusion Detection System (NIDS) Based on Signatures Search of Data Mining. In First International Workshop on Knowledge Dis- covery and Data Mining (WKDD 2008), pages 10–16. IEEE, jan 2008. ISBN 0-7695-3090-7. doi: 10.1109/WKDD.2008.48.

[164] Steffen Zschaler, Dimitrios S. Kolovos, Nikolaos Drivalos, Richard F. Paige, and Awais Rashid. Domain-Speciﬁc Metamodelling Languages for Software Language Engineering, volume 5969. Springer Berlin Heidelberg, 2010.

82 Appendix A

Grammar of the Alarm Speciﬁcation Language

Figure A.1 illustrates a possible grammar of the Alarm Speciﬁcation Language.

83 1. ::= | | 2. ::= | 3. ::= | 4. ::= | 5. ::= | | 6. ::= | 7. ::= | |

8. ::= | | | | 9. ::= | 10. ::= | 11. ::= | | 12. ::= 13. ::= | 14. ::= | 15. ::= Energy Consumption Energy Cost Energy Tariff Voltage Power Input | | | | Produced Energy Energy Sold CO2 Emissions Interior Temperature Exterior Tempera- ture| Water Consumption| Gas Consumption| Interior| Humidity Data Arrival| Frequency | | | | 16. ::= | | 17. ::= | | | 18. ::= | | 19. ::= |

Figure A.1: Grammar of the Alarm Speciﬁcation Language.

84 Appendix B

Domain Model of the Alarm Speciﬁcation Language

Figure B.1 illustrates the domain model of the Alarm Speciﬁcation Language.

85 Figure B.1: Domain model of the Alarm Speciﬁcation Language. 86 Appendix C

Feature Model of the Alarm Speciﬁcation Language

Figure C.1 illustrates the feature model of the Alarm Speciﬁcation Language.

87 Figure C.1: Feature model of the Alarm Speciﬁcation Language.

88 Appendix D

Alarm System Representation

Figure D.1 illustrates a summarized representation of the alarm system.

89 Figure D.1: Summarized representation of the alarm system.

90 Appendix E

Validation Questionnaire

Figures E.1, E.2, and E.3 illustrate the questionnaire used in the validation of the proposed solution.

91 ASL: A Domain Specific Language to Specify Complex Alarm Conditions in the Energy Domain Alberto Carvalho albertofi[email protected] Instituto Superior Técnico

Validation Questionnaire Thank you for your participation. Your answers are anonymous and will be used solely in the scope of this project.

General Information 1. Age:

2. Gender: Female Male 3. Education: 2 2 4. Job: 5. Years of experience on the energy domain: 6. What is the type of building owned by your organization? Commercial (e.g. bank) Museum 2 Residential (e.g. apartments) 2 Educational (e.g. college) 2 Industrial (e.g. factory) 2 Other 2 ASL2 Validation This section aims to evaluate the alarm speciﬁcation language. Answer the following questions with a value from 1 to 5, where 1 corresponds to strongly disagree and 5 corresponds to strongly agree.

1. Is it possible to specify all the alarms you need using this language?

1 2 3 4 5

2. Are2 you2 able to2 specify2 alarms2 in a timely way?

1 2 3 4 5 2 2 2 2 2

Figure E.1: Questionnaire used in the validation1 of the proposed solution (page 1/3).

92 3. Would you use this language in your EMS?

1 2 3 4 5

4. Is2 it easy2 to specify2 alarms2 2 using this language?

1 2 3 4 5

5. Is2 it easy2 to understand2 2 the2 goal/meaning of the language elements?

1 2 3 4 5

Alarm2 System2 2 Validation2 2 During this section we ask you to freely explore the system interface. We suggest you to specify the following alarm conditions:

Alarm 1: The energy consumption of the zone identified by “Alameda” • has a hourly average exceeding a 10000 Watts threshold. Alarm 2: The energy consumption of a zone with identifier “Civil” has an • hourly average registering an increase of 25% over the last 5 minutes. Alarm 3: The energy consumption of the zone identified by “Alameda” • has a hourly average above 15000 Watts three times during the last one hour.

The following questions are based on ISO 9241, which is the standard for ergonomics of human-computer interaction. These questions were prepared taking in consideration ﬁve fundamental aspects for a good interface construction, namely: design, functionality, easiness of use, learnability, and satisfaction. Ad- ditionally, there are two questions to measure if the system performance is acceptable according to users needs. Taking in consideration your use of the system interface answer the following questions with a value from 1 to 5, where 1 corresponds to strongly disagree and 5 corresponds to strongly agree.

1. Is the system interface pleasant to use?

1 2 3 4 5

2. Is2 the information2 2 provided2 2 by the system eﬀective at helping to perform tasks?

1 2 3 4 5 2 2 2 2 2 Figure E.2: Questionnaire used in the validation2 of the proposed solution (page 2/3).

93 3. Is the system interface easy to use?

1 2 3 4 5

4. Is2 it easy2 to ﬁnd2 the2 information2 you need?

1 2 3 4 5

5. Is2 it easy2 to learn2 how2 to use2 the system interface?

1 2 3 4 5

6. Is2 the information2 2 provided2 2 by the system easy to learn?

1 2 3 4 5

7. Can2 you2 fulﬁl2 your tasks2 eﬀectively?2

1 2 3 4 5

8. Are2 you2 satisﬁed2 with2 the outcome2 of the performed tasks?

1 2 3 4 5

9. How2 do2 you classify2 2 the system2 performance in the alarm creation (i.e. conversion of the alarm speciﬁcation into continuous queries)?

1 2 3 4 5

10. How2 do2 you classify2 2 the system2 performance in the production of information?

1 2 3 4 5 Additional2 2 comments2 2 or2 suggestions

You reached the end of the questionnaire. We are grateful for your collaboration.

Figure E.3: Questionnaire used in the validation3 of the proposed solution (page 3/3).