asl: a domain specific language to specify complex alarm … · asl: a domain specific language...
TRANSCRIPT
ASL: A Domain Specific Language to SpecifyComplex 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 MarquesSupervisor: 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 agradeco 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.
Agradeco 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, agradeco 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 deteccao de problemas permite tomar decisoes rapidamente, permitindo assim resolver
os problemas. A combinacao 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 esforco
de programacao, especialmente quando estao envolvidas condicoes complexas. De facto, a definicao
de alarmes nos EMS requer a especificacao de condicoes sobre dados recolhidos continuamente de
medidores e sensores, nao existindo ainda uma solucao sistematica. Este trabalho tem como objectivo
criar uma solucao para suportar os gestores de energia dos edifıcios na especificacao de alarmes
especıficos a este domınio, que envolvem condicoes complexas sobre dados de medidores e sensores.
Esta solucao vai permitir que os utilizadores criem novos alarmes usando apenas uma interface sem
a necessidade de modificar o codigo da aplicacao. Usando esta solucao os gestores de energia dos
edifıcios tem maior controlo sobre os alarmes existentes e as condicoes que os activam. Para validar
esta solucao realizamos testes de usabilidade.
Palavras-chave: Gestao de Energia, Alarmes, Processamento de Dados, Linguagem Es-
pecıfica de Domınio
vii
viii
Abstract
In energy management timeliness is a fundamental aspect, mainly because faster problem detection en-
ables 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 ad-
equate 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 me-
ters 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 Specific 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 Specific 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 classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Specification 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 Specification Language 83
B Domain Model of the Alarm Specification Language 85
C Feature Model of the Alarm Specification 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 require-
ments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Classification of the alarm conditions gathered from the literature review . . . . . . . . . . 33
4.1 Classification 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 Profiles 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 workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Alarm management life-cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1 Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Elements of the Alarm Specification 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 Specification Language . . . . . . . . . . . . . . . . . . . . . . . . 84
B.1 Domain model of the Alarm Specification Language . . . . . . . . . . . . . . . . . . . . . 86
C.1 Feature model of the Alarm Specification 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 Specification 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 Identifier
xix
xx
Chapter 1
Introduction
Up-to-date information improves the decision making process, mostly because building energy man-
agers 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 conse-
quently 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
fired when an anomaly is detected, thus enabling building energy managers to decide and act faster.
An alarm is a notification 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 com-
plex 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 appli-
cations, 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 experi-
enced 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, effi-
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 efficient 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 find 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 inefficient 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 definitions 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 flooding [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 flood 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 find out effective ways to specify
alarm conditions visually.
• Characterize the essential operators of stream query languages to find 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 specification of
domain specific alarms involving complex conditions.
• Develop an alarm system prototype and validate it through its usability and performance charac-
teristics.
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 deliverablesand 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 require-
ments 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 implementa-
tion 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 finally, 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 specific languages.
2.1 Energy Management Systems
Energy management systems (EMSs) are a collection of performance monitoring software, data acquisi-
tion 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 de-
tection) 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 ac-
tual 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 efficiency measures such as [71, 82]:
• Benchmarking building energy performance against other similar buildings (cross-sectional bench-
marking), 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 predefined 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 identified 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 abnor-
mal 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 acorrective action
Prioritizable Should have a clear priority to be followed by the user in the problem resolution
Understandable The alarm message is understandable
Diagnosable Identifies 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 defined 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 notification 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 notifications 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 im-
provements [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 defining 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 defined 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 first 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 pre-scribed by ANSI/ISA 18.2 alarm standard [7].
9
Inactive,Acked
start
Active,Unacked
Inactive,Unacked
Active,Acked
conditionactivated condition
deactivated
useracknowledge
user acknowledge
condition deactivated
Figure 2.2: Alarming workflow (adapted from [2, 7]), where Acked means that the alarm indication was acknowl-edged 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 con-
sumption), 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 man-
agement 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 in-
stance, 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 tothe rest of the data
Contextual Anomalies An observation that is classified as anomalous in a particular context and normalin 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 beanomalies by themselves, however their occurrence collectively as a collection isanomalous
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 definition of anomaly, a straightforward anomaly detection approach consists in defining 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 defini-
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 definition of normal and anomalous behaviour may evolve with time due to changes of equip-
ment 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
finite 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 sup-
port a timely decision making process. This kind of applications can be found in financial 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 fire 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 pro-
cessing 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 find 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 define 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
operator
patterns
are based on logical operators, namely conjunction, disjunction, and negation. Examples
of these patterns include the all (conjunction) pattern, any (disjunction) pattern, and the
absence (negation) pattern. For instance, the all pattern is satisfied when all the events that
form the pattern have occurred until now.
Threshold
patterns
compare the result of an aggregation operation against a threshold value. The aggregation
operations used include, for instance, the count, maximum, minimum, and average opera-
tors.
Subset
selection
patterns
select a subset of events from an event collection using various criteria. These patterns can
be used, for instance, to select from an event collection the events that have the n highest
or lowest values of a given attribute.
Modal
patterns
have an assertion and check if it is satisfied by all the events in the participant event set
or just by some ones. The always and sometimes patterns are examples of modal pat-
terns. 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
order
patterns
are patterns where time plays a fundamental role. An example of this category of patterns
is the sequence pattern where a given pattern is satisfied when: (i) the participant event
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
patterns
trace the value of an attribute over time. The order of arrival of the events is also con-
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
patterns
are satisfied considering the distance between the values of the location attributes (when
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
temporal
patterns
use the location attribute (when it exists) of events to determine spatial trends over time.
These patterns can be used, for instance, to detect the movement of an object.
2.5 Domain Specific 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 ap-
plication 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 com-
putational 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 cate-
gory [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 define 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 capabil-
ities 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 define 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 significantly 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 anoma-
lous. 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-classified as normal and anomalous. New
data instances are classified 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 contin-
uously. 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 intelli-
gence (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 first 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 col-
lection 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 un-
derstand how commercial solutions operate we identified 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 prop-
erty [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 mini-
mize 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 iso-
lation, 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 knowl-
edge 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 Identification 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-
sified as first-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 specific to a system or a process.
2. It is difficult to guarantee always the applicability of all rules, and to find 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 accom-
modate special circumstances.
3.2.2 Alarm Quality Requirements
An alarm system may not have a good alarm management when it shows symptoms related, for in-
stance, 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 floods Occurs when a large number of alarms are generated during abnormal situations, over-loading the system user
Cascadingalarms
Group of alarms that always occur together
Nuisance alarms Alarms that are annunciated excessively and unnecessarily
Standing alarms Users are continuously overloaded with alarms even in normal situations
Usefulness alarmmessages
Alarm messages do not provide useful information to the system user
Overload of highpriority alarms
Excessive high priority alarms are presented to the user and due to this some of themare 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 intoaccount a condition different of the one used to define 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 exist-
ing 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 com-
pression [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 con-
dition 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 floods,
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 floods,
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 soft-
ware 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 first
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 ap-
plications 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
definition 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 program-
ming, 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.edu7mindstorms.lego.com8http://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 difficult 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, pro-
cesses, 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 fly 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 notifications, which need to
be filtered 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 classification
Taking into account the users requirements a query can be classified 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 reflect 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 aggre-
gated 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 defined condition is satisfied, 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 in9http://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 specification 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 finite
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 opera-
tors, 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 first-class feature of the
language, i.e. windows that can be named, defined 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 ex-
press 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/streamsql11http://esper.codehaus.org/
26
Language
Requirement CQ
L
SQ
uAl
ES
L
EQ
L
Stre
amS
QL
Stre
aQue
l
Operators receives streamsand 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 infor-
mation 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
Projection
Applies a transformation, also known as user-defined function, to the contents of a tuple.
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
Window
A window with fixed boundaries. For instance, it could be used to process stream tuples
received between [18h, 20h].
Landmark
Window
A dynamic window with a fixed lower bound, while the upper bound advances when new
stream tuples are received. An example of use is to process stream tuples between [18h,
now ].
Sliding
Window
A dynamic window with a fixed size, where the lower and upper bounds advance when
new stream tuples are received. Could be used to process the stream tuples of the past
2 hours [now-2h, now ].
27
Pane and
Tumble
Windows
Are variants of sliding windows, where the lower and upper bound moves k tuples, when k
tuples are received. Pane windows have a size greater than k, on the other hand, tumble
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 verified by pane windows.
Logic operators enable the definition 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 satisfied when all the tuples T1, T2, ..., Tn have
been detected in the data stream.
Disjunction A disjunction of tuples T1, T2, ..., Tn is satisfied when at least one of the tuples T1, T2, ...,
Tn has been detected in the data stream.
Repetition Repetition of tuple T is satisfied 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 satisfied 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 ar-
rival 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 defined explicitly, but instead
implicitly, using an iterating condition that defines 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 modifications
Table 3.5: Some differences between DBMS and DSMS [33, 67, 70].
user to create new ones (user-defined 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, intro-
ducing 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 continu-
ously, 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-finite 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 traffic [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 Rea
l-tim
eM
onito
ring
FDD
Ala
rms
Ala
rmPe
rson
alis
atio
n
Ala
rmC
reat
ion
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 notsupported, and - stands for unknown information. † systems that respond in near real-time. ∗ unknownhow 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 identified 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.html13http://www.intdatsys.com/EnergyWitness.htm14http://www.enerwise.com/energymanager.php15http://eis.lbl.gov/openeis.html16http://esightenergy.com17http://www.cylon.com/products/energy-management/voya-xplor.html18http://www.noveda.com/solutions/energy-management/energyflow-monitor19http://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 manage-
ment 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. temper-
ature, 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 field. 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 system-
atization in the building energy management domain. However, during the literature review, we identified
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-
cific building zone. In addition, there are alarms represented as thresholds or variations. Also, some
31
Id Description of the alarm condition found Adaptedfrom
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 certainthreshold
[49, 99]
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 certainthreshold
[49]
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 certainthreshold
[49]
13 Energy cost per square foot per year is higher than a certain threshold [49, 63]
14 Considering the actual energy consumption within five days the cost per square foot isabove a certain threshold
[63]
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 oftime
[63, 99]
17 Two sensors with a distance of N meters between them have an unexpected energyconsumption
[24]
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 aperiod of time a temperature below or above certain threshold
[84, 133]
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 abovecertain threshold
[63]
27 Tuple arrival frequency does not respect an interval n1 sec.<dt<n2 sec [6, 153]
28 A zone temperature is low and the chiller has high temperature [150]
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 classification of the alarm conditions gathered from the literature review, where theid of the alarm conditions correspond to the first 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 identified 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 consump-
tion, 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 unex-
pected 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 specific 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 (de-
scribed 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 acqui-
sition (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 standard-
ized 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 Specification 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 specification into a continuous
query representing the alarm trigger condition. This query is installed on a DSMS in order to be continu-
ously 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 datastreaming sources; the Data Processing Stage responsible for the creation and evaluation of the continuous queriesthat represent the alarm conditions; the Information Presentation Stage presents the alarm dashboard and enablesexpert 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, equip-
ment 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 defined and agreed upon schema, underlying
the semantics of the energy data problem domain.
4.2 Alarm Specification 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 first 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 first 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 system-
atization identifies 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 require-
ments 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 first 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 specifies 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 Specification Language.
the Data Arrival Frequency, having an option field 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 field 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 ag-
gregate 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 fields relative to the definition 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 first 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 first 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 specification 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 fields. The first 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 (specified using the two
available fields).
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
By
provides a way to specify a high level alarm condition that defines an order between
the occurrence of sub-conditions. It has an input port where the inputs order specifies
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 specifies 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 specifies 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
Equipment
detects when an equipment (selected by the user using the available field) is working.
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 specification 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 char-
acteristics 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 classification of the pattern detected by each language element, considering thetypes 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 Appendix A, 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 Appendix B.
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 Appendix C.
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 imple-
mentation, 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 first 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 de-
scribed 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 ac-
tivated). 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, de-signed considering the good alarms characteristics recommended by the EEMUA 191 guideline [56] (1). Eachcolumn 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 analarm (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 tabledesigned considering the good alarms characteristics recommended by the EEMUA 191 guideline [56] (1). Eachcolumn 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 thepause/restart option to shelving an alarm (see Section 3.2.2) (3). Finally, the interface presents information to helpusers 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 fieldenables users to select the alarm priority, as prescribed by the ANSI/ISA 18.2 alarm standard [7] (2). Considering thegood alarms characteristics recommended by the EEMUA 191 guideline [56], a text box enables users to introducethe message that helps users to know how to react when the alarm becomes active (3). A toolbox contains theASL elements that users can use to specify an alarm trigger condition (4). Users specify on a specification area thealarm trigger condition, using the elements present in the toolbox (5). The specification area has a button to cleanthe specification present in the specification area (6). Finally, this interface has a button to create the alarm (7), andpresents 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 Appendix D, provides a REST API used by the alarm system
interface, enabling the exchange of data and information between them. To convert an alarm specifica-
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.net3http://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 alarmspecification 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 connection8https://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 corre-sponds 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 speci-
fication 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 pat-
tern 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 specification 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 identified 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 fields 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 con-
tinuous 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 specified 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 first 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(auxiliarySlidingWindow1)− sum(auxiliarySlidingWindow2)
count(auxiliarySlidingWindow1)− count(auxiliarySlidingWindow2)
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 ele-
ment fields. 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 five minutes.
With regard to the binary variation its goal is to detect a variation comparing the value obtained from
the first 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 defined by the user.
Optional Detectors use four types of pattern operators (provided by Esper) to detect pattern expres-
sions, 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 expres-
sions 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 eval-
uates 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 oper-
ator 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 be-
comes 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 repre-
sent 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
By
uses the followed-by operator of Esper, requiring that, for instance, in the pattern “A-
>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 “->” corre-
sponding 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 specification tree this element is a leaf.
Working
Equipment
is a leaf in a specification tree that creates a continuous query to select the identifier
and energy consumption of the equipment when it is working (i.e. its energy con-
sumption 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 energyconsumption of the zone identified by Alameda has a hourly average exceeding a 10000 Watts limit. The first queryis 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 energyconsumption of the zone with identifier Civil has an hourly average registering an increase of 25% over the last 5minutes. The first query is created by the Energy Consumption source (1). The Aggregation element creates thesecond 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 method-
ology based on the literature that assesses the DSL effectiveness, efficiency, 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, empir-
ically, 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 ap-
proaches [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 predictmeasures like the difficulty to learn how to use a system
Automatically Using a computerized procedureEmpirically Developing experiments with test usersHeuristically 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, Barisic
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.
Efficiency 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 specified 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. Barisic
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 sce-
narios 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 possi-
ble 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
verifies the language syntax we consider that the ASL ensures reliability.
Question ID Description
EffectivenessQuestion 1 Is it possible to specify all the alarms you need using this language?
EfficiencyQuestion 2 Are you able to specify alarms in a timely way?
SatisfactionQuestion 3 Would you use this language in your EMS?
AccessibilityQuestion 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 in-
teraction. These questions were prepared taking in consideration five 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 specification 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 en-
ables 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 sys-
tems 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 pro-
cess 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-defined
Question ID Description
DesignQuestion 1 Is the system interface pleasant to use?
FunctionalityQuestion 2 Is the information provided by the system effective at helping to perform tasks?
Easiness of UseQuestion 3 Is the system interface easy to use?Question 4 Is it easy to find the information you need?
LearnabilityQuestion 5 Is it easy to learn how to use the system interface?Question 6 Is the information provided by the system easy to learn?
SatisfactionQuestion 7 Can you fulfil your tasks effectively?Question 8 Are you satisfied with the outcome of the performed tasks?
PerformanceQuestion 9 How do you classify the system performance in the alarm creation (i.e. conversion of
the alarm specification 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 ISO9241-11 standard [85].
59
alarms supported by the other systems. Additionally, since most EMS solutions are proprietary it is un-
feasible 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 Appendix E.
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 ex-
perience 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 Commercial39 Male Bachelor 10 Commercial58 Male Master 25 Commercial57 Male Bachelor 28 Commercial34 Male Bachelor 3 Educational27 Male Master 5 Educational47 Male Master 15 Educational58 Male Bachelor 18 Educational39 Male Master 11 Museum59 Male Bachelor 37 Museum
Table 6.4: Profiles of the participants involved in the validation.
60
nies/governmental offices, 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 build-
ings 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.8Question 2 5 5 5Question 3 5 5 5Question 4 4 5 4.9Question 5 4 5 4.9
Table 6.5: Results of the language validation questionnaire. The question id corresponds to the firstcolumn of Table 6.2. Each answer follows a Likert scale where 1 corresponds to strongly disagree and5 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 specifi-
cation into continuous queries. In addition to these aspects, participants were able to fulfil their tasks
Question Id Minimum Maximum Average
Question 1 4 5 4.9Question 2 4 5 4.7Question 3 5 5 5Question 4 5 5 5Question 5 5 5 5Question 6 5 5 5Question 7 5 5 5Question 8 5 5 5Question 9 5 5 5Question 10 5 5 5
Table 6.6: Results of the alarm system validation questionnaire. The question id corresponds to the firstcolumn of Table 6.3. Each answer follows a Likert scale where 1 corresponds to strongly disagree and5 corresponds to strongly agree.
62
effectively, being satisfied 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 specification of the necessary alarms. Additionally, all partic-
ipants related an increased productivity, i.e., the alarm specification 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 de-
scribed 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 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 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 func-
tionalities, 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 per-
formed 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 systematiza-
tion 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 specific 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, efficiency, satisfaction, accessibility, reli-
ability, 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 efficient 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 spe-
cific 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 sys-
tem 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 nec-
essary 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. Classification 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 descrip-
tion: 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 pro-
gramming: 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 Barisic, 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 Barisic, Vasco Amaral, Miguel Goulao, Bruno Barroca, and M Goulao. Quality in use of
domain-specific 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 Barisic, Vasco Amaral, and Miguel Goulao. Usability Evaluation of Domain-Specific 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 Barisic, Vasco Amaral, Miguel Goulao, and Bruno Barroca. Evaluating the Usability of
Domain-Specific Languages. In Marjan Mernik, editor, Formal and Practical Aspects of Domain-
Specific 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 require-
ments 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 - Specification 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 Cetintemel. 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 finance. 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. Artificial 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 efficiency of private office 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 efficiency 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
Efficiency in a Large Corporate Campus. Technical report, ACEEE Summer Study on Energy
Efficiency 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 Artificial 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 Effinger. 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
Artificial 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-Efficient 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, first 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-specific 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. Artificial 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 office 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] Gokhan Kahraman and Semih Bilgen. A framework for qualitative assessment of domain-specific
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-Specific Languages Using
Metamodels. Addison-Wesley Professional, 2008.
[96] Paul Klint, Arie Van Deursen, Paul Klint, and Joost Visser. Domain-Specific Languages : An
Annotated Bibliography. SIGPLAN Not., 35(6):26–36, 2000.
[97] Ds Kolovos and Rf Paige. Requirements for domain-specific languages. In First ECOOP Work-
shop on Domain-Specific 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-specific 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 efficient 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-specific 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 Benefits. 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-
sification 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 in-
telligence. 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 Efficiency. 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-Efficiency 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 Dataflow 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 Cetintemel, 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
Traffic. 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-Specific 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-Specific 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-Specific Languages. CreateSpace Independent Publishing Platform, 2013. ISBN 978-
1481218580.
[149] Stefan Wallin. Chasing a Definition 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 manage-
ment: Wasn’t that problem already solved years ago? Technical report, Honeywel and Abnormal
Situation Management (ASM) Consortium, 2011.
[152] Cassandra L Hawkins Wilson, Mississippi Office, The Alliance, and Certified 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-specific models. In 10th Workshop on Domain-Specific
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-Specific Metamodelling Languages for Software Language Engineering, volume 5969.
Springer Berlin Heidelberg, 2010.
82
Appendix A
Grammar of the Alarm Specification
Language
Figure A.1 illustrates a possible grammar of the Alarm Specification Language.
83
1. <Alarm Specification>::= <Threshold>|<Variation>|<Optional Detector>
2. <Optional Detector>::= <Unary Optional Detector>|<Binary Optional Detector>
3. <Unary Optional Detector>::= <Alarm Specification><Unary Optional Detector Type>|<Special Detector><Unary Optional Detector Type>
4. <Binary Optional Detector>::= <Alarm Specification><Alarm Specification><Binary OptionalDetector Type>|<Alarm Specification><Special Detector><Binary Optional Detector Type>|<Special Detector><Binary Optional Detector Type><Alarm Specification>
5. <Threshold>::= <Unary Threshold>|<Binary Threshold>|<Ternary Threshold>
6. <Unary Threshold>::= <Forecast><Threshold Type>|<Aggregation><Threshold Type>
7. <Binary Threshold>::= <Forecast><Forecast><Threshold Type>|<Forecast><Aggregation><Threshold Type>|<Aggregation><Aggregation><Threshold Type>|<Aggregation><Forecast><Threshold Type>
8. <Ternary Threshold>::= <Forecast><Forecast><Forecast><Within Threshold>|<Forecast><Forecast><Aggregation><Within Threshold>|<Forecast><Aggregation><Forecast><Within Threshold>|<Aggregation><Aggregation><Aggregation><Within Threshold>|<Aggregation><Forecast><Aggregation><Within Threshold>|<Aggregation><Aggregation><Forecast><Within Threshold>
9. <Variation>::= <Unary Variation>|<Binary Variation>
10. <Unary Variation>::= <Forecast><Variation>|<Aggregation><Variation>
11. <Binary Variation>::= <Forecast><Forecast><Variation>|<Forecast><Aggregation><Variation>|<Aggregation><Aggregation><Variation>|<Aggregation><Forecast><Variation>
12. <Forecast>::= <Aggregation><Forecast>
13. <Aggregation>::= <History><Aggregation>|<Source><Aggregation>
14. <History>::= <Source><Simple History>|<Source><Period History>
15. <Source>::= 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. <Threshold Type>::= <Upper Limit Threshold>|<Lower Limit Threshold>|<Within LimitThreshold>
17. <Unary Optional Detector Type>::= <During>|<Simple Within>|<Period Within>|<Repeat>
18. <Binary Optional Detector Type>::= <And>|<Or>|<Followed By>
19. <Special Detector>::= <Occupation>|<Working Equipment>
Figure A.1: Grammar of the Alarm Specification Language.
84
Appendix B
Domain Model of the Alarm
Specification Language
Figure B.1 illustrates the domain model of the Alarm Specification Language.
85
Figure B.1: Domain model of the Alarm Specification Language.
86
Appendix C
Feature Model of the Alarm
Specification Language
Figure C.1 illustrates the feature model of the Alarm Specification Language.
87
Figure C.1: Feature model of the Alarm Specification 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 SpecifyComplex Alarm Conditions in the Energy Domain
Alberto [email protected]
Instituto Superior Tecnico
Validation Questionnaire
Thank you for your participation. Your answers are anonymous and will beused solely in the scope of this project.
General Information
1. Age:
2. Gender: Female 2 Male 23. Education:
4. Job:
5. Years of experience on the energy domain:
6. What is the type of building owned by your organization?2 Commercial (e.g. bank)2 Museum2 Residential (e.g. apartments)2 Educational (e.g. college)2 Industrial (e.g. factory)2 Other
ASL Validation
This section aims to evaluate the alarm specification 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 2 2 3 2 4 2 5 22. Are you able to specify alarms in a timely way?
1 2 2 2 3 2 4 2 5 2
1Figure E.1: Questionnaire used in the validation of the proposed solution (page 1/3).
92
3. Would you use this language in your EMS?
1 2 2 2 3 2 4 2 5 24. Is it easy to specify alarms using this language?
1 2 2 2 3 2 4 2 5 25. Is it easy to understand the goal/meaning of the language elements?
1 2 2 2 3 2 4 2 5 2Alarm System Validation
During this section we ask you to freely explore the system interface. We suggestyou 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 anhourly 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 onehour.
The following questions are based on ISO 9241, which is the standard forergonomics of human-computer interaction. These questions were prepared ta-king in consideration five 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 isacceptable according to users needs.
Taking in consideration your use of the system interface answer the followingquestions with a value from 1 to 5, where 1 corresponds to strongly disagreeand 5 corresponds to strongly agree.
1. Is the system interface pleasant to use?
1 2 2 2 3 2 4 2 5 22. Is the information provided by the system effective at helping to perform
tasks?
1 2 2 2 3 2 4 2 5 22Figure E.2: Questionnaire used in the validation of the proposed solution (page 2/3).
93
3. Is the system interface easy to use?
1 2 2 2 3 2 4 2 5 24. Is it easy to find the information you need?
1 2 2 2 3 2 4 2 5 25. Is it easy to learn how to use the system interface?
1 2 2 2 3 2 4 2 5 26. Is the information provided by the system easy to learn?
1 2 2 2 3 2 4 2 5 27. Can you fulfil your tasks effectively?
1 2 2 2 3 2 4 2 5 28. Are you satisfied with the outcome of the performed tasks?
1 2 2 2 3 2 4 2 5 29. How do you classify the system performance in the alarm creation (i.e.
conversion of the alarm specification into continuous queries)?
1 2 2 2 3 2 4 2 5 210. How do you classify the system performance in the production of infor-
mation?
1 2 2 2 3 2 4 2 5 2Additional comments or suggestions
You reached the end of the questionnaire. We are grateful for your collaboration.
3Figure E.3: Questionnaire used in the validation of the proposed solution (page 3/3).
94