Framework Blueprint forBuilding Energy Management Systems

João Pedro Rocha Pinho

Thesis to obtain the Master of Science Degree in

Information Systems and Computer Engineering

Supervisor: Prof. Paulo Jorge Fernandes Carreira

Examination Committee

Chairperson: Prof. Ernesto José Marques MorgadoSupervisor: Prof. Paulo Jorge Fernandes Carreira

Members of the Committee: Prof. Rui António dos Santos Cruz

May 2016

“Do not go where the path may lead,

Go instead where there is no path

And leave a trail.”

— Ralph Waldo Emerson

ii

Acknowledgments

Em primeiro lugar, gostaria de expressar a minha eterna gratidão ao Professor Rui Cruz, pelo apoio

sem precedentes, pela dedicação, pelo empenho e a exigência, pelas críticas cheias de força, pelos

elogios e, acima de tudo, por ter acreditado em mim e no meu trabalho.

Uma palavra de gratidão ao Professor Paulo Carreira, pela boa vontade com que despendeu de

horas para me introduzir à temática dos Sistemas de Gestão de Energia, e pela ajuda na iniciação aos

Sistemas de Automação para Edifícios.

Agradeço também à minha família, a quem dedico este trabalho, em particular à minha esposa Carla

Reis, ao meu sogro António Reis e à minha sogra Alice Reis, pela forma com que, na sua união,

serviram de primeira linha de apoio nos momentos mais trabalhosos, naqueles em que a motivação

faltava. A eles devo a pessoa que sou.

Aos meus amigos, que nos últimos meses me apoiaram nas minhas frustrações e alegrias, que me

ouviram a falar sempre no mesmo assunto, horas a fio, que me encheram de força e que me ajudaram

no meu trabalho: Diogo Rosa, Pedro Domingues, Gonçalo Almeida e Renato Vieira, entre muitos

outros.

Obrigado.

iii

Abstract

Buildings are major energy consumers of today. A solution for optimization of building energy consump-

tion implies coordinating devices in order to maximize energy efficiency. However, the control logic

underlying such techniques is currently implemented on hardware controllers commissioned by propri-

etary solutions, thus limited and difficult to integrate with other systems. Therefore, integrating multiple

energy efficient control techniques is usually more complex and expensive. Moreover, while it is tech-

nically possible to connect devices directly to TCP/IP networks, most Home and Building Automation

Systems (HBASs) still use non-IP field level communication protocols. In this context, no proper frame-

work for centralized energy control systems has been documented in literature. In this work we present

a platform over which applications featuring energy-efficiency techniques can be built on. The proposed

solution has been validated on a real-world automated scenario to attest its practical applicability.

Keywords

Smart Buildings, Building Energy Management Systems, Energy-Efficiency, Building Automation, Real-

time data processing, Internet of Things

v

Resumo

Nos dias de hoje, os edifícios representam um fator significativo no consumo de energia. A optimização

do consumo de energia em edifícios, envolve a coordenação de múltiplos dispositivos para a automação

de técnicas que permitam um consumo mais eficiente de recursos. Contudo, a lógica de controlo subja-

cente à implementação destas técnicas, é normalmente alcançada recorrendo a soluções baseadas em

controladores de hardware, possuindo protocolos proprietários. Dada a sua natureza, estas soluções

são naturalmente mais complexas de gerir e integrar com outros sistemas, sendo por isso mais lim-

itadas. Neste seguimento, a integração de técnicas de eficiência energética, recorrendo ao uso de

controladores de hardware, é tipicamente uma tarefa complexa. De igual modo, embora seja tecni-

camente possível conectar estes controladores diretamente a redes TCP/IP, a grande maioria dos sis-

temas de automação para edifícios ainda usa mecanismos de comunicação específicos ao seu domínio,

não compatíveis com redes TCP/IP. Neste contexto, não existe documentação apropriada, em termos

literários, da arquitetura para uma plataforma que vise permitir a monitorização e controlo centralizado

do consumo de energia em edifícios. Este trabalho documenta uma plataforma e um conjunto de apli-

cações desenvolvidas para a optimização do consumo de energia em edifícios, criando uma base para

um marketplace de aplicações para edifícios. A solução desenvolvida foi validada num cenário real,

recorrendo a múltiplos sistemas de automação, procurando assim atestar a sua aplicabilidade prática.

Palavras Chave

Edifícios Inteligentes, Sistemas de Gestão de Energia para Edifícios, Eficiência Energética, Automação

em Edifícios, Processamento de Dados em Tempo Real, Internet das Coisas

vii

Contents

1 Introduction 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Methodology and Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Concepts 9

2.1 Building Automation Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Energy Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1 Data Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.2 Utilities and BAS data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.3 Metering Systems & Weather Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.4 Space Planning & Tariffs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3 BEMS Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Middleware for BAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.1 Cisco EnergyWise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4.2 aWESoME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4.3 Medusa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.4 PoliSave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.5 LinkSmart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.6 HomeSOA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4.7 DomoNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Related Work 21

3.1 Commercial Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 EEM Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.2 Energy Witness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.3 EnerWise EM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.4 Jonhson Planoramix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

ix

3.2 Real-time Data Interfacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1 Metrics Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2.2 Data Transformation Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2.3 Data Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2.4 Data Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 Solution 29

4.1 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Data Integration Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.1 Device Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.2.2 Device Gateway Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2.3 Telegraf Data Input Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3 Data Access Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.1 Data History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.2 Data Querying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.4 Core Services Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.4.1 Energy Manager Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4.2 Data Processing Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.5 Security Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.6 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Validation 43

5.1 Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1.1 Case Study: IST TagusPark - KNX Energy Meters . . . . . . . . . . . . . . . . . . 45

5.1.2 Case Study: IST TagusPark - HTTP Energy Meters . . . . . . . . . . . . . . . . . 48

5.1.3 Case Study: Energy Insight - Sensors and Actuators . . . . . . . . . . . . . . . . . 49

5.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6 Conclusions 57

6.1 Retrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

A Energy Meters Dashboard 69

B Weather Station Dashboard 71

x

List of Figures

1.1 Illustration around the concept of a centralized energy monitoring framework. On the

bottom heterogeneous data from different BAS are integrated by the framework. On top

a common object model, provides a set of general services for applications to act upon

such data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Illustration of an monolithic Building Energy Management System (BEMS) architecture.

On top we have the application layer were energy-efficiency applications are deployed.

From the management layer down to the field layer we have Building Automation System

(BAS) interaction software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1 Overview of building automation systems and their subsystems - On the top, the protocol

specific layer presents heterogeneous BAS protocols. Bellow we have BAS subsystems,

programmed for a specific field level protocol. At the bottom, trend logs record data pro-

duced by these subsystems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 An example of monitoring and control points being collected from a BAS (left figure).

Those points represent instant or accumulated readings processed and stored into a data

warehouse (right figure). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.1 Overview of BEMS Architecture - Presenting (i) application layer, featured by possible ap-

plications, (ii) security layer, with user management, (iii) core services, provide context

awareness about spaces, devices and other services, (iv) data access layer, with ser-

vices for managing data, and (v) data integration layer, provides means for data exchange

between clients and the framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 Data Integration Overview, presenting two components/plugins of the data collection ser-

vice and a third service called device gateway to interface with BAS devices. The com-

ponents integrate with various sources of data and pass it as input to the data collection

service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

xi

4.3 Data Access Layer Overview, presenting three components, a data collection service, a

persistence service for storing metrics called InfluxDB and a Mongo database to store

system wide data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4 Core Services Layer Overview, presenting two components, Energy Manager Service and

a Data Processing Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.5 Illustration of the Channel mapping of an HVAC equipment consisting of multiple devices

(left) that are mapped into four channels (right). . . . . . . . . . . . . . . . . . . . . . . . . 39

4.6 Security Layer Overview, presenting StormPath Identity component for user authentica-

tion and authorisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1 MIT Department - Nucleus 14, featuring four KNX energy meters, being queried by En-

sight Platform. Energy Dashboard application sits on top of our platform to render col-

lected data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.2 KNX Energy Meters Dashboard displaying a data window of 2 days. . . . . . . . . . . . . 47

5.3 NodeMCU ESP8266 Module attached to an Amica R2 development board. . . . . . . . . 50

5.4 Relay Module actuator connected to a power plug electric cable. . . . . . . . . . . . . . . 50

A.1 Energy Meters dashboard, with consumptions per meter and the aggregated total. . . . . 70

B.1 Dashboard showing data collected from Taguspark Weather Station. . . . . . . . . . . . . 72

xii

List of Tables

2.1 BEMS functionalities according to ISO and EN standards [1–3]. . . . . . . . . . . . . . . . 16

2.2 Comparison of Middleware Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Features overview of current EMS solutions . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Analysis of Metrics Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1 Channel Manager API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.2 Channel Categories Manager API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.3 Channel Notifications API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

xiii

xiv

Listings

4.1 Gateway Driver Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Kapacitor TICKscript for Auto Dimming Luminaries . . . . . . . . . . . . . . . . . . . . . . 40

5.1 Continuous Query to aggregate KNX Energy Meters data . . . . . . . . . . . . . . . . . . 46

5.2 Continuous Query that aggregates KNX Weather Station sensors data . . . . . . . . . . . 47

5.3 Continuous Query that aggregates Energy Meters data . . . . . . . . . . . . . . . . . . . 49

5.4 Data processing script to trigger alerts based on light conditions in our room . . . . . . . . 52

5.5 Micro controller programming sketch to control the Relay Module . . . . . . . . . . . . . . 53

5.6 Micro controller programming sketch to read from the light sensor . . . . . . . . . . . . . . 54

xv

xvi

Acronyms

HBAS Home and Building Automation System

HVAC Heating, Ventilation and Air Conditioning

EMS Energy Management System

BEMS Building Energy Management System

BAS Building Automation System

API Application Programming Interface

BMS Building Management System

IoT Internet of Things

DSL Domain Specific Language

SB Smart Building

IT Information Technologies

TTL Time To Live

UI User Interface

ISO International Organization for Standardization

EU European Standard

HMI Human Machine Interface

JSON JavaScript Object Notation

REST Representational State Transfer

URI Universal Resource Identifier

xvii

CRUD Create, Retrieve, Update and Delete

UDF User Defined Function

ETL Extract, Transform and Load

LAN Local Area Network

MCU Microcontroller Unit

GUI Graphical User Interface

xviii

1Introduction

Contents

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Methodology and Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1

2

Rising energy costs and concerns about environmental effects of increased energy consumption,

are leading organizations into more sustainable and “green” business operations [4]. Moreover, global

environmental laws are being approved forcing organizations to comply with strict energy efficiency

policies [5]. However, using energy more efficiently requires reducing the amount of energy consumed

without affecting the comfort of their occupants.

Building Energy Management is the process of monitoring and controlling the systems operating in a

building. Though specific components may differ, these systems might be heating and air conditioning,

ventilation, lighting, power, security, and alarm systems [6].

BASs aim at improving user comfort while using resources more efficiently, in particular the con-

sumption of energy. A BAS consists of a distributed control system working over a digital network of

devices designed to monitor, control and enable a more adequate building automation according to user

requirements. Buildings that use BAS are commonly known as Smart Buildings (SBs).

BEMSs combine both intelligent and “green” buildings technology. To achieve being intelligent,

energy-saving, “green” and other environmental objectives, an unified management of energy consump-

tion is designed to improve equipment operation and reduce energy consumption [6,7].

One of the greatest challenges faced by software developers when creating energy-efficient and

control software is to create an appropriate abstraction on software [8,9]. In the particular case of energy

control software, different devices might be working on different protocols within the same building.

Therefore, installing an energy control software in a building can be hard and sometimes expensive,

since it has to be compatible with multiple communication protocols [10]. Moreover, energy-efficient

and control techniques are mainly implemented in hardware controllers, therefore, an abstraction of the

energy-efficient and control firmware is not an easy task.

Techniques such as like daylighting—achieved by dimming luminaries that are not needed during

daylight [11]—reduce up to 40% of buildings energy consumption [12]. Coarsely speaking Heating, Ven-

tilation and Air Conditioning (HVAC) systems are responsible for around 70% of the energy requirements

of a building, while the remaining are mostly spent on lighting systems [13–15].

A centralized monitoring software (Figure 1.1) can simplify the monitoring and control of a very com-

plex maintenance system reducing costs and allowing the deployment of energy-efficient control tech-

niques to more than one building space [10].

1.1 Motivation

Most recent developments in BAS have followed the advances made in computer technology, telecom-

munications and information technology [16]. Furthermore a number of studies have been presented for

modern intelligent buildings and control systems, revealing the ongoing interest of the scientific commu-

3

Diverse BAS and Data

OPC BACnet LON KNXModbus

Centralized Energy Control Framework

Common Object Model (Data Points)

Applications for Energy-Efficiency

Figure 1.1: Illustration around the concept of a centralized energy monitoring framework. On the bottom hetero-geneous data from different BAS are integrated by the framework. On top a common object model,provides a set of general services for applications to act upon such data.

nity on this topic [17–20].

Nowadays building automation vendors provide out of the box and turn-key solutions for BASs.

Therefore, it is common to have buildings with more than one BASs solution installed to control different

types of devices [16].

Developing energy control software for buildings is challenging for programmers, mostly due to the

complexity of creating an abstraction of the bottom technologies for devices and energy-efficient control

techniques [10,21]. Some of the problems that can hinder the development of such systems are:

heterogeneity of existing building automation solutions, as each technology implements their

own field level protocol without considering third-party compatibility [8,9,21].

absence of concrete requirements are difficult to specify as there is much to say about building

systems such as chiller systems [22], HVAC systems, steam systems and so forth. Unfortunately

current literature does not specify all the types of data that needs to be collected from each building

system [23].

software testability requires equipped facilities for validation purposes. Moreover, data must be

retrieved for a period of time and must be large enough to be measurable. Only then software unit

tests can be carried on, thus making it hard to test this type of systems [23].

4

data retention policies define for how long data should be retained on a given system, before be-

ing discarded. Any kind of monitoring, specially, when dealing with large buildings involve querying

and interfacing with thousands of sensors and smart meters. Even at a small scale if we think about

the data flow of one hundred devices sending data every 15 minutes to a central server, in simple

math, that would account for almost 10K data points per day. Therefore, thinking about what is the

best policy to retain data, without storing it all, is a complex topic.

An illustrative scenario for some of this complexity can be an university campus with different build-

ings equipped with various automation and monitoring technologies. If we assume that devices installed

on one building work over the BACNet1 field level protocol. And several other rooms of the same build-

ing work over the KNX2 field level protocol. Different protocols on the same building would increase the

software complexity in terms of programming/commissioning. An example of such monolithic solution is

depicted in Figure 1.2.

That increase in terms of complexity rises due to the need of controlling each back-end system

individually. Both BACnet and KNX [24] have their own commissioning protocols and the programming

of energy efficiency techniques over such systems requires certified technicians for each technology.

To apply energy-efficiency control techniques such as daylight harvesting in all university spaces, the

common solution involves installing a decentralized control software per building— commonly known

as BAS,— eventually made of specific modules to interact with each field level protocol. This strategy

presents some challenges in terms of: where will data be persisted, what data model should be adopted,

how to act upon real-time data that arrives each second from various sensing devices.

1.2 Problem Definition

A centralized energy control and monitoring software will give us the ability to apply energy-efficient

and control techniques even if the back-end building automation systems do not support it. This way

it becomes possible to seamlessly develop and deploy applications committed to maximize energy effi-

ciency across different buildings, despite their technology heterogeneity.

This framework will consist of a software layer residing above the individual systems and their specific

protocols. Its role is to provide an uniform method for accessing data from, and issuing commands to,

the various building devices. Therefore, the framework must be protocol agnostic and vendor neutral,

supporting all devices equally. Web services which are emerging Information Technologies (IT) give us

an elegant way to solve some of the above problems [25].

An example of a technique that such software can implement even if the hardware does not allow it,

1BACnet is a communications protocol for building automation and control networks.2KNX is a standardized, OSI-based network communications protocol for building automation.

5

ManagementLayer

Automation Layer

ApplicationLayer

CommunicationLayer

KNX BAS STACK

BACnet BAS STACK

LonWorks BAS STACK

BACnet

EIB / KNX

LonWorks BACnetEIB / KNX

KNXGateway

BACnetRS232

LonWorksOPC Server

Sensing Services

Actuation Services

Management Services

Management Services

Management Services

Building Energy Management System

Field Level BUS

Data Acquisition Reporting

Energy Forecast Baselining …

LonWorksSensing Services

Actuation Services

Sensing Services

Actuation Services

Figure 1.2: Illustration of an monolithic BEMS architecture. On top we have the application layer were energy-efficiency applications are deployed. From the management layer down to the field layer we have BASinteraction software.

is “intelligent duty cycling” where the software can control the on/off functionality to implement energy-

efficient rules based on external sensors and without using the control hardware. For example, an old

HVAC could be enhanced with auto shut-off functionality, allowing it to turn off when a specific room

reaches a certain temperature. Such temperature would be measured by means of external sensors,

installed on a building room.

This work approaches the problem from the pragmatic perspective that, monitoring our buildings

through the usage of sensing and actuation devices should be as natural and easy as humanly possible.

If we think of a building where each room is equipped with energy metering, sensing and actuator

devices, such framework should be able to collect all metering data, provide a simple way to query this

data and give actionable and straightforward methods to process it.

Such capabilities would enable us to draw conclusions in real-time for later analysis, and also would

give us the ability to deploy energy efficiency techniques that could actually be measurable, since the

6

operational baselines of our buildings would be stored outside the deployed BAS solutions.

According to our knowledge no framework that abstracts energy-efficient control techniques through

software applications has been proposed so far.

1.3 Methodology and Contributions

The objective of this work was to gain insight about, what software architecture is more adequate for a

framework capable-of supporting modular energy-efficiency techniques. Therefore, we have developed

an hardware-independent framework for centralized control and energy management. This framework

blueprint was be developed through a composition of services capable-of providing an abstraction of

the underlining BASs. This framework supports integration with external data sources through a set of

Application Programming Interfaces (APIs). The user interface of this system is available through a web

browser application, that enables the management of building sensing and actuator devices through

an abstraction called channel. These channels are configurable on our web interface and a set of

dashboards are readily available for data visualization with a minimum effort.

To address our research, this work was conducted as follows:

• A set of building automation systems have been identified.

• Functional and non-functional requirements for building automation systems have been analyzed.

• Existing solutions on energy management in terms of functionalities have also been analyzed.

• A survey of the literature regarding energy management and available frameworks have been

performed.

• A prototype have been implemented and validated in a real world environment by deploying it on

the facilities of the University of Lisbon (Taguspark campus).

1.4 Organization

This manuscript is structured as follows: Section 2 describes concepts necessary to understand our

solution proposal; Section 3 explores existing solutions for energy management and their functionalities;

Section 4 introduces our solution and the proposal for possible applications that such framework could

promote; Section 5 details our solution evaluation methodology; and Section 6 presents conclusions

about both problem and final solution.

7

8

2Concepts

Contents

2.1 Building Automation Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Energy Management System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 BEMS Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 Middleware for BAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

9

10

The key concepts of this work will be introduced by first approaching BASs. Secondly Energy Man-

agement Systems (EMSs) section explores the definition of what is an EMS, their advantages in com-

parison to BASs and what minimum feature set is expected from such system. Lastly we present a set

of middlewares for BASs and a brief analysis of their characteristics.

2.1 Building Automation Systems

A BAS provides means to control and monitor indoor environment conditions, either manually or

automatically, through a grid of smart devices ranging from sensors, actuators and controllers. The his-

torical root of BAS was the automation of HVACs, providing means to control and adjust their parameters

in order to maximize user comfort. Although, the reach of BAS has been further extended to include all

kinds of BASs such as lighting, security, chiller and steam systems, among other [26].

BUILDING SYSTEMS

Protocol Specific

BAS [ KNX | LonWorks | BACnet | … ]

LIGHTNING HVAC SECURITYALARMS

ACCESSCONTROL

INTRUSION ALARMS

WEATHER DATA

Trend Logs

Figure 2.1: Overview of building automation systems and their subsystems - On the top, the protocol specific layerpresents heterogeneous BAS protocols. Bellow we have BAS subsystems, programmed for a specificfield level protocol. At the bottom, trend logs record data produced by these subsystems.

Besides enabling automation of electric components, BAS can provide data such as electric con-

sumption, temperature and heat radiation through monitoring on precise readings from available equip-

ment, generating trend logs (Figure 2.1) and information charts.

A common issue regarding BAS consists on the difficulty of deploying several distinct solutions inside

the same facility [27]. For instance, in the University of Lisbon (Taguspark campus), there are at least

three commissioned BASs running in parallel for different purposes. This type of scenario poses a

11

problem related with BASs interoperability, since BASs are by nature heterogeneous.

The heterogeneity between different BAS technologies can be troublesome, because they hinder

facility managers work, by forcing them to collect data from different systems into a consolidated data

warehouse [27].

Also, collecting data only from monitoring points, typically is not enough to determine what to improve

or the sources of a problem, such as over consumption of some electric equipment [28]. Furthermore,

facility managers are left with inaccurate and small amounts of relevant data, when metering systems

are installed instead of a BEMS. [28].

According to Interval Data Systems—a well known software house of BEMS solutions—it is not un-

usual for large facilities to have 30,000 points or more (a large college campus can easily have well over

100,000 points) [29]. With such a large number of data collection points (Figure 2.2), each generating

one record every 15 minutes, the total data set comprises over a billion records per year [28, p. 70].

Such amount of data can be unfeasible to manage by facility managers, thus leading to huge amount of

data being discarded.

BAS

MONITORING

- TEMPERATURE- DEW POINT- WIND SPEED- STEAM FLOW

CONTROL

- ON/OFF SWITCHs- CONTROL EVENTS- DIM (VALUE %)- BLINDS (UP / DOWN)

FACILITY DATA

WAREHOUSE

instant readings

accumulated readings

other relevant values

Figure 2.2: An example of monitoring and control points being collected from a BAS (left figure). Those pointsrepresent instant or accumulated readings processed and stored into a data warehouse (right figure).

Another topic of concern is trending data, for every monitoring and control point collected there is as-

sociated data related with it, data such as weather, maintenance tasks and other facility operations [28].

Consider a typical scenario where HVAC systems report a consumption peek. The usage of BAS

trend logs, can result on many interpretations of such event, for instance, the over consumption could

be related to a very cold day, a maintenance task for fixing a malfunctioning equipment or eventually it

could be related with a misconfiguration of the equipment.

Therefore, trending data is an important issue regarding diagnostics, monitoring, measurement and

verification. Moreover, it represents a historical record of facility operations [28]. With such historical

12

record a facility manager could easily notice that such consumption peak is related with seasonal activity

on the building, or due to some kind of special event, such as a conference occasion [20, Chapter 2].

2.2 Energy Management System

An EMS is a “set of interrelated or interacting elements, to establish an energy policy and objectives,

together with processes and procedures to achieve those objectives” (ISO 50001:2011) [19]. Energy

Management Systems provide a set of tools that enables the monitoring of facility operations through

the gathering of all building data related to environment and equipment operations. Moreover, they help

increase user awareness on how building is performing [30]. As stated before, at the most simplified

level, an energy management system consolidates all operational and energy-related data into a data

warehouse and provides a framework for tools to access and interact with that data.

The BEMS makes data available so that end users are able to perform in-depth diagnostics, analysis,

and monitoring in a fraction of the time they would took with earlier methods. The resulting information

enables building owners to make radical improvements in their systems operations, staff deployment,

and information dissemination inside and outside of their buildings [28].

Being made of a consistent set of monitoring and analytical tools, an EMS covers the following main

aspects of a building [6,28]:

Used utilities data: All operational-related (electricity, natural gas, chilled water and other appli-

cable) data must be gathered and consolidated into a data warehouse [31].

Data normalization: The acquired data must be normalized and restructured in a consistent data

model in order to be usable.

Interactive and actionable data: All the collected data must be presented in an intelligible and

actionable format to the user. By actionable we mean that, the facility manager, must be able to

act based on the data gathered from the BASs.

Measurement and verification: Performance measurement and verification provides the ability

to compare energy use, before and after, some steps have been taken to address potential energy

savings. An EMS should allow the facility management team to distinguish between real savings

versus stipulated savings and energy saving versus monetary savings [31].

2.2.1 Data Acquisition

Being data a core component of any analytical and monitoring tool, an EMS needs to know how to

collect information from all the sources of data available in a facility [32]. Data can come from metering

13

systems, BAS, utility reports (requiring manual data insertion) or from space management systems [28,

33]. Another aspect that these systems must take into account are billing rates, besides collecting

energy related operational-data an EMS must be able to translate such data into meaningful monetary

values.

It is very common for a medium-large facility to have more than one billing-rate for different buildings.

Also in order for an EMS be able to correlate consumptions with such billings rates, a data acquisition

process must be studied first [20,28]. Most utility vendors have their reports available through electronic

formats, for instance EDP—a Portuguese electrical company—makes those billings available on-line

through a web-based system, other like gas or water companies make those reports available through

paper-based support, sent monthly or bi-monthly.

Thus the best way to gather consumptions is to install smart meters for the various utilities directly on

buildings [20,28]. Enabling a more effective validation of those billings, including metrics and techniques

to be deployed, allowing consume optimization without disregarding user comfort.

2.2.2 Utilities and BAS data

In large corporations, featuring more than one building, is very common to have buildings generating

utilities, such as, chilled water for air conditioning and steam. Those utilities either purchased or gener-

ated, produce data that must be acquired, processed and normalized into a data warehouse. An EMS

must be able to relate this data with billing rates and other factors, such as, weather data and calculated

data. For instance, for steam, is very common to compute flow and condensation return values [28].

Utilities derived data is crucial for an EMS, enabling it to present data in an intelligent and actionable

format, forming the basis of any EMS analytical and monitoring tool [20,28,33].

Nowadays, it is common for a facility to feature one or more BAS to control HVACs, lighting, weather

stations, along with other building automated systems. It is important to notice the distinction between

BAS and EMS systems BAS are responsible for controlling HVACs not EMSs, as EMS are not control

systems. EMSs provide intelligent and actionable data to their facility managers while BAS provide them

ways to control and monitor them.

From a BAS it is possible to extract control and monitoring points, control points regarding information

about equipment status, allowing us to know if it is turned on or off. Monitoring points provide readings

from sensors and continuous values from equipment devices [28].

2.2.3 Metering Systems & Weather Data

Metering Systems are used to measure utilities consumption. Usually they store the collected data

on their own dedicated database systems [20, 28]. An EMS should be able to read data from those

14

database systems or from meters directly when appropriated. When an EMS is installed those metering

systems—if not already—should be configured to provide not only instantaneous readings, but also

totalized values, enabling the EMS to fill the gaps, between failed readings, with the totalized values [34].

Another consideration when dealing with metering systems is sub-metering, a technique where an

EMS must be able to deduct meters, by collecting interval data directly from sub-meters and then deduct-

ing their consumption from a main meter, before apportioning energy usage to other spaces [20, p. 40].

Weather data is also an important variable to take into account, as it improves the accuracy of energy

forecasting models. Weather data also enables an EMS to understand the context around a period of

consumption. For instance, during cold or hot days HVAC systems are expected to consume more or

lesser energy [35]. But this variable is not enough to predict for sure if the energy consumptions will in

fact increase, since they could also decrease depending on the space allocation variable.

2.2.4 Space Planning & Tariffs

Space Planning helps EMS identifying energy costs and consumptions in function of space/location.

Space planning systems map the entire building structure such as floors, their compositions in terms of

spaces, sub-spaces and their rooms [36]. These systems can also take into consideration organizational

information, i.e, by mapping those spaces and sub-spaces to cost centers, departments an their office

rooms or work teams—for example, in the University of Lisbon Campus located in Taguspark some

departments have work teams in offices borrowed from other departments.

Space Planning Systems allow an EMS to accurately track back costs and energy consumption back

to a corporate department [34]. Regarding general spaces, these systems enable facility managers to

understand the spaces that are requiring more energy, allowing them to focus on the reasons for higher

consumptions on those areas.

Many energy suppliers allow their consumers to contract different tariffs according to their energy

needs. When choosing this tariff plans, customers rarely have in consideration their consumptions

because they simple do not have systems to enable them to overview their consumption patterns from

a macro point of view [37,38]. Because of this, most customers end up contracting the plan that is most

appealing for their needsthis is far from being an informed decision [34].

With an EMS, corporations are able to estimate billing rates of their buildings, by letting the system

translate consumptions into energy costs. This information, produces a baseline, from where we can

extract consumption reports with actionable information, regarding prices and comparisons with other

tariffs.

15

2.3 BEMS Standards

With the aim to understand the specific features that a BEMS should provide, it is necessary to call

upon the International Organization for Standardization (ISO) and European Standards (EUs) documen-

tation, as detailed in Table ??.

Table 2.1: BEMS functionalities according to ISO and EN standards [1–3].

BEMS StandardsISO 16484-3 EN 15232

Grouping/Zoning Individual zone control is listed asa required functionality. (Section5.1.1.4)

The concept of zones is used to de-fine room or zone specific controlactivities and set-point preferences.(p. 27, 32, 46)

Event Notification Event handling and notification isdescribed as an operator functionprovided by the HMI. (Section5.1.1.2, 5.3.5.17)

Refers to the notification of changesin the system status for several pur-poses such as controlling indoor oc-cupation [2].

Alarm Notification Alarm notification is described as anHMI. (Section 5.1.1.2, 5.3.5.17)

Alarm notification are essential tooperators function provided by mal-function situations detection.

Historical Data Access This standard presents data archiv-ing and the means for retrieving thatdata as management functionalitiesof a BAS. (Section 5.3.2.9)

States that data collection and log-ging are features offered by buildingmanagement systems. (p. 10).

Scheduling Provides a section describing timescheduling features. (Section5.3.5.15)

Specifies the use of schedules tocontrol some attributes such as theair flow in a room (Section 7.5.1)

Scenarios There is no direct reference to the“scenario” terminology, although,energy management services areseen as a requirement that accord-ing to EN 15232 benefits from thisconcept. (Section 5.1.1.3)

This standard defines several sys-tem operating modes that are usedto adapt the operation of the build-ing to occupant needs. Each opera-tion mode can be modeled as a sce-nario [2].

2.4 Middleware for BAS

Middleware has been defined as a distributed system service that includes standard programming

interfaces and protocols [39]. These services are called middleware because they act as a layer above

the device-specific and networking software and below business applications. Umar [40] presents an

extensive treatment of the subject.

Architecture research regarding middleware focuses on the problems and effects of integrating com-

16

ponents with off-the-shelf middleware. Di Nitto and Rosenblum [41] describe how the usage of mid-

dleware and predefined components can influence the architecture of a system being developed and,

conversely, how specific architectural choices can constrain the selection of middleware [42].

Table 2.2: Comparison of Middleware Systems

System Domain Middleware Web Services Composition

EnergyWise Management/Automation aWESoME Automation MEDUSA - PoliSave Automation # #LinkSmart Automation #Home SOA Multimedia/Automation # DomoNet Automation #

Table 2.2 presents a comparison between the different middleware systems. According to the mid-

dleware/application domain—multimedia and/or automation, —all of the presented systems have a web

services based architecture and a predefined model corresponding to their semantics.

2.4.1 Cisco EnergyWise

Cisco EnergyWise is a proprietary technology that provides the ability to monitor and control power

across IT infrastructures by utilizing the network itself [43]. Their architecture consists of three tiers—

management applications, domain members, and endpoints. EnergyWise aims at enabling an overall

energy management strategy and subsequently enable the control of power within the network infras-

tructure of facilities. Cisco EnergyWise provides a framework where the network itself can be used to

make power management available to all device types. This framework is already performing arrange-

ments to support future integration with Building Management Systems (BMSs).

2.4.2 aWESoME

aWESoME is a Web Service Middleware for Ambient Intelligence environments, developed by a

group of Greek Researchers, at IHU University, Thessaloniki, Greece [44]. aWESoME is one of the

components of the Smart IHU project, which aims to implement a large-scale Smart University system,

regarding energy consumption savings.

The main goal of the proposed middleware is to fulfill functional and non-functional requirements

of the system and to ensure universal, homogeneous access to the systems services. This solution

employs a wide range of web open standards for hardware discovery and description, such as ZigBee

Smart Plugs and Sensor Boards, Smart Clampers, Z-Wave Devices, as well as software functions, in

17

order to assure interoperability between them.

This middleware integrates different layers: hardware, services, integration between services and

devices layer—in order to achieve their interoperability, —and application layer to provide the users of

the system a form to manage the devices and energy consumption across university campus.

2.4.3 Medusa

MEDUSA consists of a middleware based on Activity-Oriented Computing (AOC) paradigm [45]. This

paradigm promotes run-time applications by composing ubiquitous systems based on abstract specifi-

cations of user activities. For example, given a smart phone equipped with RFID reading capabilities, it

can be used to scan cards that represent services and form service compositions, resulting in a practical

physical interface for users.

This way it is possible to develop a system which is aware of user needs and activities in real-time

situations. This enables users to create their own services and expand the role of the service developer,

by doing it iteratively, accordingly to users activities.

2.4.4 PoliSave

PoliSave is a software designed to reduce power consumption in computer networks [46]. It manages

the scheduling of power on and off, of computers in order to save energy. The process is carried out

via a graphical web application interface. This software also aims to customize the monitor capability so

that individual users can be able to track the power consumption of their personal computers. Moreover,

it introduces active learning techniques in order to compute the best power scheme applicable for each

user, regarding their activity.

2.4.5 LinkSmart

LinkSmart1 middleware, formerly named Hydra middleware, is part of a European project for the

development of service-oriented software to expose heterogeneous device functions in a universal way

and target domains such as home automation, among other. This middleware supports a wide variety

of devices that can be controlled by external interfaces such as RFID, RF, Bluetooth, ZigBee and USB.

This solution is based on semantic models (ontologies). The main idea is to generate the software

components and web services in order to integrate within the supported device instances, based on

the semantic model meta-data. However, having devices with capability to support embedded services

themselves is very hard. Therefore, there are few devices able to support this middleware.

1http://www.hydramiddleware.eu/news.php

18

2.4.6 HomeSOA

HomeSOA is an open architecture for home service deployment [47]. It is based on a service platform

concept, where distribution and protocol heterogeneity are managed by service-oriented drivers.

HomeSOA allows developers to model networked applications as a local composition of uniform ser-

vice interfaces that become bound at runtime. This solution deals with important Pervasive Computing

challenges, such as dynamic distribution and heterogeneity. It also couples service-oriented design

patterns, such as a service interface, a service provider, a service client and a service registry.

Each service description is specific to a device protocol set, and represented in object-oriented

programming interfaces adapted to the protocol set. The service-oriented mediators are refined drivers

responsible for masking protocol heterogeneity, connecting the services of a specific device type into

the existing services of an application domain semantic.

To summarize, it proposes a modular architecture that can be opportunistically adapted on various

topologies, protocol sets and platform technologies, as it integrates various home protocol drivers in an

architecture where functions are registered in a uniform programming language API. This model was

applied in multimedia, home automation and device management domains.

2.4.7 DomoNet

DomoNet is a service-oriented solution framework designed for home environments [48, 49]. This

prototype implements an architecture which makes the connection between lighting devices of two dif-

ferent middlewares: UPnP and Konnex [50]. This solution is based on a SOA and uses web services

to reach the interoperability between different home computer middleware. The aim of this solution is

to prove how an approach based on XML, Web Services and Internet protocols can provide an uniform

architecture for home automation.

19

20

3Related Work

Contents

3.1 Commercial Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 Real-time Data Interfacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

21

22

3.1 Commercial Tools

In commercial buildings the set of energy-efficient control techniques that can be implemented is vast,

in order to avoid wastes and reduce energy consumption [51]. Based on the on-line documentation some

of the most used energy control systems were analyzed, in order to better understand how scalability

affects the number of energy-efficient control techniques a software can actually implement.

While conducting this survey we were able to observe that, there is not a standard feature set to

define an EMS. The reason underneath this lack of cohesion is that, most solutions were designed

towards a particular end goal [28].

3.1.1 EEM Suite

EEM Suite consists of a web based solution from McKinstry 1. This solution aims to analyze data

collected from several meters to achieve better efficiency in business operations and billing practices.

It is able to forecast energy consumption as well as increase user awareness through customizable

reports and alarms [52].

Only energy data is collected on this system, therefore making it hard to correlate energy consump-

tion with environmental factors. The environment factor has a huge impact on energy consumption, and

is required to perform profiling and forecasting.

3.1.2 Energy Witness

The Energy Witness2 solution from Interval Data Systems, Inc. follows a different approach. Their

concept is that, an EMS must gather all available data. According to this solution, in order to diagnose

a problem, all data must be readily accessible. Although all energy related data is gathered, this system

does not provide a solution for analysis through some form of data visualization or other method. This

task is left to the end-user, who might become overwhelmed with such large dataset of information to

process.

3.1.3 EnerWise EM

The EnerWise3 EMS solution gathers energy data consumption and builds a consumption profile

used to detect unusual consumption. Unlike EEMSuite this solution produces a daily forecast based

on gathered data, enabling it to produce more accurate forecasts than solutions using only raw energy

data, without considering daily variables.

1http://www.mckinstry.com/2http://www.intdatsys.com/EnergyWitness.htm3http://www.enerwise.com/energymanager.php

23

http://www.intdatsys.com/EnergyWitness.htmhttp://www.enerwise.com/energymanager.php

3.1.4 Jonhson Planoramix

The Planoramix4 platform consists of a suite of cloud-based applications, services and support to

help facility managers harness data and manage their facilities. It pulls data from a variety of existing

building systems such as a BASs, utility meters, and transmits it to a cloud system, where it can be

used by a range of applications aiming at greater control over energy usage, equipment operation, and

occupants comfort.

A detailed analysis regarding EMSs features, and the similarities between the different solutions has

been summarized in Table 3.1.

Table 3.1: Features overview of current EMS solutions

Features EEMSuite

EnergyWitness

EnerWiseEM

JohnsonPlanoramix

Data Acquisition and IntegrationEnergy meter data gathering Equipment status data gathering # - Environmental data gathering # - Web data gathering # # Dynamic data sources - Data Analysis and Data MiningData mining and normalization - - # Unusual consumption detection - - Energy consumption forecast - - #Data quality analysis - # #Data Reporting and VisualizationEquipment maintenance # # - #Real time monitoring Cost estimation Tariff comparison - - #Data extraction - Web access Alarms - - Reports

3.2 Real-time Data Interfacing

When dealing with sensing and actuator devices continuously we face the problem of real-time

data [53]. Due to the various interpretations one may have about what is in fact real-time data, it is

important to give the definition of what we mean by real-time data.

4http://www.johnsoncontrols.com/content/us/en/products/building_efficiency/products-and-systems/building_management/panoptix.html

24

http://www.johnsoncontrols.com/content/us/en/products/building_efficiency/products-and-systems/building_management/panoptix.htmlhttp://www.johnsoncontrols.com/content/us/en/products/building_efficiency/products-and-systems/building_management/panoptix.html

Real-time data, comprises the flow of information typically segregated and transmitted into small units

of data representing some sort of state, instantaneous reading or aggregated computation of some kind,

all associated with a given time-stamp and providing from multiple specific sources, either, by means

of a polling or publish/subscription strategy. The set of sources being queried, not necessarily in a

synchronous way, generates a flow of near real-time data whose state is a function of the variable time.

During the analysis of our solution, interfacing with real-time data became a problem worth studying.

According to our definition above, the continuous data flow generated at a given time, must be stored

to avoid data loss. During this phase of persisting data, an adequate way to process it and extract

actionable information must be possible.

It is important to be aware also that, there could be cases where the instantaneous real-time data

that arrives at our database does not let us draw conclusions about anything specific. Case where we

would need to work over aggregations of that data — by 15 minute periods, by day, week or month, —

which is continuously arriving at our database. Thus, an adequate solution to continuously evaluate data

arriving in real-time that would let us work over the evaluated and aggregated data would be desirable.

3.2.1 Metrics Database

The main goal of a Metrics Database is to store metrics associated with a time-stamp. A metric

represents something that is measurable and such measure must always be associated with a time-

stamp. In a metrics database, data is stored in measurement tables, similar to a table in an SQL

database. The smallest unit of data that can be persisted to this kind of database is called metric.

Since a metrics database belongs to the category of NoSQL databases, the structure of the data

being stored is flexible, enabling different formats to be stored on the same measurements table, which

is ideal when working in the context of Internet of Things (IoT).

In our solution we need to address the problem of dealing with various sensors, smart meters and

BAS devices to extract data continuously and store it on a database. Such database should be highly

optimized to deal with metrics and should have a way do deal with data retention policies— that would

enable us to specify for how long data should be persisted.

During our analysis of metric databases we also took in consideration the support for the creation of

continuous queries. Continuous queries, consist of queries that continuously evaluate as data arrives

and output their results to a measurements table. This type of queries are good to aggregate data into

bigger sets of data, making it possible to convert various readings per minute into 15 minute aggregates

of information. Such feature would enable us to favor the persistence of aggregate data, while letting us

discard data with too much granularity, which is difficult to manage in the long term.

Bellow, some solutions in the category of NoSQL and Metrics Databases have been analyzed in the

context of this thesis:

25

Graphite, stores numeric time-series data into measurement tables. It enables us to specify data

retention policies, specifying for how long should data be persisted. And, also has support for

producing charts over data.

InfluxDB, besides storing numeric time-series data, it also supports strings values. Has built-in

support for indexes over specific fields to enhance queries performance. Supports the concept of

Continuous Queries, mentioned previously, outputting the results of those queries to new measure-

ments tables. It also supports data retention policies and comes with different types of protocols

to make writing data to InfluxDB simple and straightforward.

Apache Cassandra, is a logging database that can be used to store time-series data. It has vast

support for all kinds of data types and supports the concept of data retention policies through the

usage of Time To Lives (TTLs). A TTL can be associated with a row key or with a table, letting us

control how much time each specific record or table will be persisted.

The features listed in Table 3.2 consolidate our analysis regarding metric databases and their support

for each of these features.

Table 3.2: Analysis of Metrics Databases

Metrics Databases Graphite InfluxDB ApacheCassan-

dra

String data type support - Data retention policies Continuous queries - -Indexes -

3.2.2 Data Transformation Scheduler

Another part of our problem, is an adequate method to gather real-time data from various sources

of information and send it to a metrics database. Such method, should be able to receive as input a

source of data to read from, with a specific interval and should be able to output its readings to a metrics

database, into a given measurements table.

Such service must be able to have multiple inputs of data, to support various sensors, actuators

and BAS devices. During our analysis, and after exploring InfluxDB Metrics Database capabilities, we

focused our attention on Telegraf.

Telegraf, is an open source agent developed with the main purpose of collecting metrics and data

from multiples sources of information. Telegraf collects data and writes it to InfluxDB in the desired

26

format. This data collection service, has a vast set of input and output plugins, meaning it can collect

and write from and into almost everything.

For our requirements, Telegraf can be good fit to help us collect data from various sensing and

actuator devices and write all of that data into the correct format to a Metrics Database such as InfluxDB.

3.2.3 Data Visualization

When dealing with sensing and actuator devices, either directly or by means of a BAS, the most basic

task that must be easy to accomplish is—, assuming data is being stored—aggregate and graphing data.

To accomplish this we must be able to—, using a relatively simple Domain Specific Language (DSL)—

specify queries over our data and immediately see results as they arrive at our metrics database.

Studying and analyzing the available solutions on the open source market, we have found a set of

solutions, presented bellow:

Grafana, is a front-end for metrics, it enables data visualization through various types of charts,

and lets you organize them into dashboards. When creating these charts it consumes our data

and displays it. Filtering capabilities are available using date ranges and field values. There is

no support for more complex groupings or data transformations, such as grouping by week and

display the average of energy consumption.

Chronograf, is another front-end for metrics, which enables data visualization though line charts.

Using Chronograf its possible to create visualizations that aggregate data from different metrics

using an intuitive DSL called influxQL. This query language is the same used for InfluxDB and

enables complex aggregations over the data to be displayed. After creating a set of visualizations

they can be grouped into a dashboard that will auto refresh itself automatically.

freeboard, is a dashboard builder tool, far more generic than Grafana or Chronograf, that comes

with a set of widgets capable of fetching data from any data source reached via HTTP, and that can

output data in a JavaScript Object Notation (JSON) format. It supports multiple types of charts and

can be extended with more graph types if needed, since it is an open source project. Although,

it does not provide any method for storing the dashboards created, so after a page refresh, all

dashboards and configurations are lost.

3.2.4 Data Processing

Data processing over real-time data allows us to infer conclusions out of raw data [54]. For instance,

consider an energy efficiency technique where a user is notified to turn the room lights on or off, depend-

ing whether or not there is enough natural light in the room to work comfortably. If a sensor indicates it

27

is dark, it is not reliable to take just one data point into consideration. A better approach, could be to at

least consider the last 60 seconds of readings and compute their average. If above a certain threshold

we could decide whether to raise an alert to trigger the process of sending a notification.

We could also use this type of data processing to compute events [55], such as reporting that a door

has not been closed when heating is on [54]. Such events would enable facility manager to gain more

insight about possible problems in their buildings.

In this context, we have analyzed Kapacitor a time-series data processing, alerting and anomaly

detection service, that is able to process streams of data from InfluxDB and trigger alerts when a set of

pre-conditions are met.

Kapacitor uses a DSL called TICKscript to define tasks. A task in Kapacitor represents a unit of work

over a given data set. There are two types of task, those over stream data and those over batch data.

Each TICKscript defines a pipeline used by the Kapacitor service to know which data to process

and how it should be processed. Using a solution like Kapacitor, would enable us to compute events

from the real-time data fetched directly from sensing devices on our buildings. Such events, would have

at least two possible applications, sending notifications about some specific occurrence, or providing

factual data to help further analyses over energy consumption, equipment malfunctions, and other that

may apply.

3.3 Discussion

We have explored fundamental variables to the solution proposed on this document. These variables

were (i) BEMS standards, where we try to determine what are the features involved on these systems,

(ii) middleware solutions for BAS and their requirements are also carefully analyzed, and finally (iii) a

survey of commercial tools regarding BEMS is performed, where we try to determine what are their

features and how they address BASs heterogeneity issues.

During this research, mostly due to the amount of information involved, we also found convenient to

detail BEMS standards, BASs middlewares, and BEMS commercial solutions along with their features

on tables 2.1, 2.2 and 3.1.

Being the context our work sensitive around the concept of real-time data, we have also studied tools

and applications that could help us address issues related with data collection, storage, processing, and

visualization of data providing from various sensing and actuator devices.

As discussed during our analysis, BEMSs provide a common set of features important to monitor

and analyze utility data, such as consumptions. But as a trade-off such solutions are built into monolithic

architectures, promoting vendor lock-in and are hard to configure.

28

4Solution

Contents

4.1 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Data Integration Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3 Data Access Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.4 Core Services Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.5 Security Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.6 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

29

30

An energy management system can be seen as a composition of different services, each aiming

at exploring or exposing data under a certain way. These services are combined to create a platform,

upon which new applications can be built on [56]. In this thesis, we present a platform to enable the

deployment of energy efficiency techniques, by means of software modules, using sensing and actuator

devices.

This platform is able to interface with BAS devices and other sensing or actuator devices. By control-

ling devices through software, it is possible to program logic, regarding energy efficiency techniques, di-

rectly from software modules and without requiring reprogramming micro-controllers with new firmware.

After our extensive analysis on BEMS Standards, Middlewares for BASs (Section 2.4), BEMS Com-

mercial Tools (Section 3.1) and Real-time data interfacing techniques (Section 3.2), we believe to have

come up with an elegant and simple solution.

4.1 Architecture Overview

In this section we present an overview of our solution architecture (Figure 4.1). The adopted solution

enhances the typical BEMS architecture with the following benefits:

• Modular Add-on Applications: New applications deployed over the centralized energy control

framework can use data coming from different sources and use all core services available on

the platform. This means that, add-on application developers can be ignorant about BAS solu-

tions, such as KNX, LonWorks or BACnet [57]. Making them free to focus on levering the collected

data utility to facility managers, solving real world problems, while optimizing time consuming and

monotonous tasks [58].

• Loose coupling: By making all components independent though APIs and a common data model,

this architecture allows the parts to evolve without compromising the whole system architecture.

• Hardware abstraction: When interacting with devices using HTTP protocol and simple data formats

such as JSON, all the information is normalized when writing to a metrics database. BAS devices

and controllers are abstracted by software drivers to hide the complexity of interfacing with the

back-end BAS.

• Scalability and Performance: Because clients are narrowed down to simple data suppliers (Sec-

tion 4.2.1), their implementation is relatively simple. Therefore, meaning they are ideal candidates

to be installed on cheap embedded devices, with limited resources for computing [59].

Bellow, a brief description of the functional and non-functional requirements that this project archi-

tecture aims to accomplish are presented.

31

SecurityLayer

Core Services Layer

Data Access Layer

Channel Management

User Management

Notification Services

Data CollectionData Querying Data History

ApplicationLayer

Central Administration

Building Energy Management System

Data Integration Layer

Field Level / Technology Dependent Layer

Energy Dashboard

Auto DimmingLumaries App

n

1

Data Collection API

Device Gateway Service

Driver KNX Driver ModBus Other Driver

Gateway Driver Gateway DriverGateway Driver

Figure 4.1: Overview of BEMS Architecture - Presenting (i) application layer, featured by possible applications, (ii)security layer, with user management, (iii) core services, provide context awareness about spaces, de-vices and other services, (iv) data access layer, with services for managing data, and (v) data integrationlayer, provides means for data exchange between clients and the framework.

Functional Requirements:

Web services based on direct access to devices, allowing back-end services to discover and

directly communicate with devices, and consume the services they offer. For example, the ca-

32

pability to receive event notifications from the device side, to which other services can subscribe

to [25].

Device integration, is achieved through the implementation of gateways and service mediators to

allow integration of the non-web service enabled devices.

Devices history, is required to keep device behaviors up-to-date: logging of data, events and

devices history.

Device management, through web service enabled devices that will contain both static and dy-

namic data. This information needs to be managed in order to maintain reliability between data

retrieved from devices and their exploitation above the field level layer.

Non-Functional Requirements:

Service composition: Service Oriented Architecture (SOA) infrastructure will allow building more

sophisticated services on top of generic ones, therefore allowing add-ons for enhanced function-

ality [47, 60]. This implies an environment where there are composed services: i) at device level,

ii) back end level, iii) bidirectional cross-level.

Modular: The system should be designed regarding this property in order to be decomposed into

a set of cohesive and loosely coupled modules.

Coupling: Refers to the number of dependencies between a module and other modules of the

system. A loosely coupled module operates independently and offers the flexibility to be composed

and reused quickly to create or adapt an application to changing requirements.

We will now describe in detail each component involved in our solution. Illustrative pictures will

partially describe each section to give more context and by the end of this section a diagram of the

complete system is presented.

4.2 Data Integration Layer

The data integration layer provides integration capabilities between the platform and the devices,

such as sensing, actuator, or BAS devices. Its goal is to provide seamless integration between hardware

devices, ranging from BAS devices to simple HTTP IP-based sensors.

4.2.1 Device Drivers

Device drivers are responsible for the communication with field level systems such as BASs. A device

driver is a software module specific for a BASs protocol.

33

KNX-based BAS (Network Protocol: KNX)

Data Collection Service

HTTP JSONPlugin

HTTP MeterPlugin

IP-basedSensors

KNXSensors

IP-basedKNX Gateway

Device Gateway Service

KNX Driver

>

>

Figure 4.2: Data Integration Overview, presenting two components/plugins of the data collection service and a thirdservice called device gateway to interface with BAS devices. The components integrate with varioussources of data and pass it as input to the data collection service.

A BAS based on the KNX protocol is installed on the Taguspark campus of the University of Lisbon,

the access to its network of devices is made through an IP-based gateway that converts IP frames

into KNX frames. In this thesis a KNX driver has been developed to enable reading from sensors and

writing to actuators. Device drivers implement an interface called GatewayDriver, its contract is defined

in Listing 4.1.

Listing 4.1: Gateway Driver Interface

1 DataPointValue read(DataPoint datapointMetadata);

2 void write(DataPointValue value);

3 void setAddress(String gatewayAddress);

4 String getAddress();

Parameters of the type DataPoint hold meta-data about a data point and enables a driver to interact—

read or write —with its underlying device by means of a BAS gateway. A DataPointValue wraps a value

to be written or a value read from a device— sensor or actuator. Finally this interface also specifies

the contract of the assessor methods for address, specifying the gateway address, normally an IPv4

Address.

The way how the gateway address is used and how the read and write operations use data points

meta-data, is a concern that should be addressed by the implementation of each gateway driver.

4.2.2 Device Gateway Service

This service provides a way to inter-communicate with BASs by means of gateway drivers. Being a

stateless service, it provides a simple interface through an API containing two endpoints, one for reading

34

and other for writing to and from a device. The exposed Representational State Transfer (REST) API is

described bellow:

GET /device-gateway/{device-identifier}/read - this endpoint queries a service for meta-data

about the received device identifier. That meta-data is used to select the appropriate driver, set its

gateway address and query the physical device. The response outputs a JSON payload with the

value read.

POST /device-gateway/{device-identifier}/write/{value} - is used to write to a device. The re-

sponse outputs HTTP status code 200 in case of success or HTTP status code 500 in case of a

failure.

4.2.3 Telegraf Data Input Plugins

The service responsible for data collection, uses Telegraf to fetch data within regular intervals. To be

able to fetch data, our data collection service requires a plugin that has knowledge about how to query

a data source.

In our solution, we have written a plugin, named HTTP Meter Plugin, to interface with IP-based me-

ters using the HTTP protocol. Telegraf already comes with an HTTP plugin that is able to fetch data and

parse JSON, but it does not support Basic Auth protocol or forwarding of requests via an authenticated

proxy. These two features are essential for interfacing with IP-based meters on the University of Lisbon

- Taguspark facilities.

Internally, our plugin supports BasicAuth authentication protocol and RequestForwarding using the

Linux command wget, a non-interactive network downloader.

4.3 Data Access Layer

The Data Access Layer consists of three components (i) Data Querying, this component ensures

real-time data is being continuously aggregated before being stored into a persistent storage, (ii) Data

Collection, this component is a service that knows how to fetch data from various sources of information

and then dispatches it to a persistence service, and (iii) Data History, a set of persistence services that

store real-time data into a metrics database and system-wide data on a NoSQL database. Figure 4.3

presents an overview of the relations between these components.

4.3.1 Data History

The Data History component consists of two persistence services (i) a Metrics Database, to store

real-time data, and (ii) a NoSQL Database, to store more or less structured sets of information regarding

35

Sources of DataData Collection Service

Input PluginsSensors>

Actuators

BASDevices

InfluxDB Output Plugin

InfluxDB MongoDBEnergy Manager Service

>

Figure 4.3: Data Access Layer Overview, presenting three components, a data collection service, a persistenceservice for storing metrics called InfluxDB and a Mongo database to store system wide data.

devices, configurations and notification subscriptions.

To store real-time data we use a metrics database called InfluxDB. This database is ideal for dealing

with data originated from sensors. It is able to organize readings into measurement tables and is pre-

pared to deal with flexible data structures, enabling device readings data to mutate without compromising

the database schema.

Our model, for storing sensors data, assumes that all data is always sent first to a measurement

table that will retain its data for a certain amount of time, typically one month. With this we assume that

if no other configuration in done, our platform will store a sliding window of data with the size of 30 days

(considering one month) for each sensor, actuator status readings or BAS device data.

To support a more persistent data strategy we introduce the concept of continuous queries to our

users, letting them specify a continuous query to aggregate their sensors data. A continuous query

that aggregates data, can be a query that grabs the readings of the last 15 minutes of data and down-

samples it to 1 point whose value could be the average of all the points in that last 15 minute period.

Continuous queries aggregate data of a measurements table and output their results to a second

measurements table. In our case, the measurements table that receives the output of a continuous

query can persist its data for a time span of 1 year.

36

4.3.2 Data Querying

Continuously collecting data from various devices across entire building infrastructures can be seen

as the process of taking a snapshot of the current state of our facilities at a given time T .

This flow of snapshot data is captured multiple times per hour and can result in enormous quantities

of data [61]. Most of the time the exact measure of a given meter at a given time T is not the most

relevant information to work with.

Therefore, a way to continuously evaluate and aggregate data as it arrives is a requirement, in order

to enable fast queries over real-time data. If every graphical visualization, report or API that needs to

access our data has to aggregate it in memory every single time it is needed, that solution can turn out

to be hard to scale in the long run, as more data continuously arrives at our database.

Data querying component achieves continuous data aggregation using InfluxDB Continuous Queries.

Continuous queries enable down-sampling of raw data to convert high frequency data into low frequency

data.

When a new device is registered on this platform, a channel to access it is created. The concept

of Channel abstracts the back-end device being accessed, since it stores only the required meta-data

to access ita channel could be an Universal Resource Identifier (URI) to a video resource if a proper

driver were available. This registration will cause data to be read from the device into a measurement

table to record its data with a given frequency. This frequency should be high enough to enable a good

precision of data being read. A concrete example would be to fetch energy metering data from a meter

every minute.

By default, data from channels is available within a sliding window of 30 days. After that period data

will be discarded. To enable more persistent storage of the readings the user must supply a continuous

query to aggregate the data. This way the user can graph real-time data by consuming high frequency

data before aggregation, or he can use aggregated data to work over larger sets of data and compare

baselines, such as previous versus current month consumption.

4.4 Core Services Layer

The Core Services Layer consists of two main components (i) the Energy Manager Service, a front-

facing back-end service, that exposes APIs for channel management, channel categories, channel noti-

fications, and real-time data feed, and (ii) the Data Processing Service, a stream processing service that

processes streams of data, raising alerts when certain conditions are met, and reporting alerts to the

Energy Manager Service. Figure 4.4 presents an overview of the relations between these components.

37

Data Collection Service

Sources of Data

Sensors

Actua-tors

BASDevices

InfluxDB

>

Energy Manager Service

Channel Manager

Channel Categories

Channel Notifications

REST

API

Data Processing Service

>

>

>

Figure 4.4: Core Services Layer Overview, presenting two components, Energy Manager Service and a Data Pro-cessing Service.

4.4.1 Energy Manager Service

Energy Manager Service is super set of micro-services that aggregates the micro-services: Real-

time Channel Data Feed, Channel Manager, Channel Categories and Channel Notifications.

The main idea around this micro-service architecture is that new functionalities can be developed and

deployed in the platform by exposing a new micro-service with its own API. Each of these micro-services

exposes a version of their APIs through HTTP Headers, e.g, Content-Type: application/vnd.micro-

service.endpoint.v1+json.

Through this API Versioning Scheme applications can decide whether to support certain functionali-

ties of the platform or to gracefully ignore them.

Channel Manager, exposes a Create, Retrieve, Update and Delete (CRUD) API over the entity

Channel. In the context of our platform, a Channel is an abstract concept, that defines a commu-

nication channel from where we can read and write into. An equipment with various sensors and

actuators would have N channels associated with it (Figure 4.5).

This way, to avoid creating strong bindings with the concept of equipment, device or other less

generic. We introduced the concept of Channel Categories to group one or more channels. The

Channel API can be found in more detail on Table 4.1.

38

CHANNELSDEVICES

HVAC

Switch ON / OFF(read / write)

Air Flow Speed(read