Embed Size (px)
Citation preview
IST SmartOffice
Rodolfo André Henriques dos Santos
Thesis to obtain the Master of Science Degree in
Information Systems and Computer Engineering
Supervisor: Prof. Paulo Jorge Fernandes Carreira
Examination Committee
Chairperson: Prof. Nuno João Neves MamedeSupervisor: Prof. Paulo Jorge Fernandes Carreira
Member of the Committee: Prof. Luís Manuel Antunes Veiga
November 2014
ii
”Everything should be made as simple as possible, but no simpler.” – Albert Einstein
iii
iv
Agradecimentos
Queria deixar aqui o meu profundo agradecimento e imensa gratidao aos meus pais, Armenio Santos
e Ermelinda Henriques, como a minha irma Cristiana Santos, pelo apoio que me deram ao longo
de toda a minha vida, principalmente nesta fase academica, em que foram o suporte para conseguir
alcancar os meus objectivos.
A minha namorada, Vanessa Santos, pelo apoio incondicional desde o primeiro minuto e por me fazer
acreditar nas minhas capacidades e nos meus valores.
Aos meus amigos e companheiros de mestrado Joao Quiterio, David Forte e Rui Silva, pela forte
entre-ajuda demonstrada e pela partilha de varios momentos ao longo desta jornada academica.
Ao meu orientador, Professor Paulo Carreira, porque foi uma pessoa essencial a construcao deste
projecto, pelas instrucoes, sugestoes e por toda a disponibilidade demonstrada.
Ao MIT Portugal pela disponibilizacao de todo o material, bem como o Laboratorio de Energia e os
gabinetes do nucleo N14, fundamentais para que este trabalho fosse possıvel de realizar.
Ao Eng. Mario Trigueiros da Garret pelo suporte e apoio na instalacao e configuracao do material
tecnico de automacao.
Aos colegas de trabalho da Coriant, pelo apoio demonstrado nesta fase final da dissertacao.
A todos o meu muito obrigado,
Rodolfo Santos.
v
vi
Resumo
Os sistemas de automacao e gestao de energia acrescentam valor aos edifıcios, tornando-os mais con-
fortaveis, mais produtivos para os ocupantes e mais eficientes em termos energeticos. No entanto, as
tecnologias de hardware e o software dos sistemas subjacentes sao amplamente monolıticas e incom-
patıveis entre si, o que dificulta a sua extensibilidade, acabando por condicionar o consumidor final. Para
superar este problema, este trabalho propoe a criacao de uma camada de software intermedia (mid-
dleware) que abstrai a diversidade dos sistemas de automacao existentes, e simultaneamente fornece
funcionalidade sofisticada as aplicacoes de controlo inteligente e de gestao de energia. A solucao ap-
resentada tambem expoe servicos que permitem abstrair as aplicacoes finais, os diversos protocolos
e detalhes tecnicos associados a cada fabricante de hardware, permitindo que os programadores se
concentrem apenas no desenho de algoritmos e tecnicas inovadoras que maximizem a eficiencia en-
ergetica e o conforto do ocupante, sem se preocuparem com os detalhes de hardware de cada sistema.
Este conceito e validado a partir da implementacao do prototipo de uma arquitetura orientada a servicos
que suporta a gestao de energia e o controlo inteligente das varias salas e gabinetes das instalacoes
do IST.
Palavras-chave: Arquitectura Orientada a Servicos, Automacao de Edificios, Gestao de
Energia, Programacao Modular
vii
viii
Abstract
Building automation and energy management systems increase the value of buildings by making them
more comfortable, productive, and energy efficient. However, the hardware and software technologies
underlying actual systems are largely monolithic and incompatible with each other, hampering extensibil-
ity and favoring consumer lock-in. In order to overcome this problem, we propose to create a middleware
that abstract the heterogeneity of automation systems and provide sophisticated functionality to applica-
tions for intelligent control and energy management. Our solution also exposes services that allows to
abstract the numerous protocols and technical requirements associated with each manufacturer to appli-
cations, allowing developers to apply all their effort designing algorithms and innovative techniques that
maximize the energy efficiency and user comfort, without worrying about the technical details of each
existing system. The concept is validated with the implementation of a service-oriented architecture
prototype that enables energy management and intelligent control of IST office rooms.
Keywords: Service Oriented Architecture, Building Automation, Energy Management, Modular
Programming
ix
x
Contents
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Document Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Concepts 5
2.1 Building Energy Management Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Building Automation Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Fieldbus Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 Energy Management Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4 BEMS standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Service-Oriented Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 SOA concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Middleware for BEMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Related Work 17
3.1 Fieldbus heterogeneity abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Services exposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Technology-independent integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Energy Management and Automation functionalities . . . . . . . . . . . . . . . . . . . . . 21
3.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.1 Non-Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.2 Functional Requirements (BEMS Features) . . . . . . . . . . . . . . . . . . . . . . 24
xi
4 Solution 25
4.1 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Resources Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Service Collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.1 Direct Actuation and Data Access Services . . . . . . . . . . . . . . . . . . . . . . 28
4.3.2 Autonomous Actuation Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.3 Management Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.4 Intelligent Actuation Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5 Implementation 37
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Middleware implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2.1 OSGI Framework setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.2 Datapoint Connectivity API Java specification . . . . . . . . . . . . . . . . . . . . . 38
5.2.3 Services orchestration, binding and management . . . . . . . . . . . . . . . . . . . 39
5.2.4 Services exposition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3 Services development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.1 Datapoint Connectivity Protocol Integration Service . . . . . . . . . . . . . . . . . 43
5.3.2 Remote Sensing and Actuation Service . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.3 Data Acquisition Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.4 History Data Storage Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.5 Data Querying and Data Fusion Service . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3.6 Alarms Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3.7 Scenarios Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3.8 Scheduling Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.4 IST SmartOffice Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.5 Implementation Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.6 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6 Evaluation 51
6.1 Evaluation Plan and Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2 Scenario-based Software Architecture Evaluation . . . . . . . . . . . . . . . . . . . . . . . 52
6.2.1 Summary of Business Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.2 Summary of the Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.3 Quality Attribute Utility Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.2.4 Scenarios Prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2.5 Analysis of Architectural Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2.6 ATAM evaluation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.3 Case-study 1: IST SmartOffice Prototype Evaluation . . . . . . . . . . . . . . . . . . . . . 57
xii
6.3.1 Automated Building Areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3.2 Building Fieldbus Technologies Integration . . . . . . . . . . . . . . . . . . . . . . 58
6.3.3 Summary and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.4 Case-study 2: Energy Consumption Prediction Service . . . . . . . . . . . . . . . . . . . 69
6.4.1 Energy Prediction Modeling Methods . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4.2 Data used in Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4.3 Prediction Services Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.4.4 Experiments and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7 Conclusions 75
7.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Bibliography 82
A Application Programming Interfaces 83
A.1 Datapoint Connectivity API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
A.2 IServiceRegistry Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
A.3 Datapoint Connectivity API JavaScript Wrapper . . . . . . . . . . . . . . . . . . . . . . . . 90
A.4 Calimero Process Communicator Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 92
A.5 JLifx IBulb Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
B Software Diagrams 94
B.1 Service Exposition Wrappers Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
xiii
xiv
List of Tables
2.1 Examples of fieldbus technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 BEMS standard functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Non-functional requirements comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 BEMS features support and services providing . . . . . . . . . . . . . . . . . . . . . . . . 23
5.1 OSGi Service names and Web Services names mapping . . . . . . . . . . . . . . . . . . 40
5.2 Datapoint Connectivity REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3 OSGi Services Architecture Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1 ATAM process steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2 Automated Building Areas Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3 KNX Functionalities Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.4 iLight Functionalities Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.5 INOV Functionalities Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.6 X10 Functionalities Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.7 LIFX Functionalities Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.8 Summary of integrated technologies results . . . . . . . . . . . . . . . . . . . . . . . . . . 68
xv
xvi
List of Figures
1.1 Actual systems versus SOA approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Building Energy Management Systems data sources . . . . . . . . . . . . . . . . . . . . . 6
2.2 OSGi Framework components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1 Pyramid of reviewed BEMS requirements and functionalities . . . . . . . . . . . . . . . . . 17
4.1 Proposed Service Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Resources Connectivity Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.3 Service collections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4 Occupancy-based Control Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5 Daylight-Harvesting Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6 Service Layer – The Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1 Push-Notifications workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Scenario creation workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 IST SmartOffice Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4 OSGi Level SW Components Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.5 OSGi Services Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.1 Fieldbus Infrastructure diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2 KNX technology integration Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.3 iLight technology integration Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.4 INOV meters integration Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.5 X10 technology integration Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.6 LIFX technology integration Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.7 Energy consumption variation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.8 Access Points distribution across floor 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.9 Building occupancy and energy consumption relation . . . . . . . . . . . . . . . . . . . . . 71
6.10 SNMP integration Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.11 Linear Regression test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.12 Fuzzy test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.13 Neural Network test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
xvii
6.14 Results comparison for distinct prediction methods . . . . . . . . . . . . . . . . . . . . . . 73
B.1 Service Exposition Wrappers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
xviii
Glossary
BAS Building Automation System
BA Building Automation
BEMS Building Energy Management System
BIM Building Information Modeling
BMS Building Management System
BPMN Business Process Model and Notation
EMS Energy Management System
EM Energy Management
GUI Graphical User Interface
HVAC Heating, Ventilation, and Air Conditioning system
IT Information Technology
OSGi Open Services Gateway initiative
REST Representational State Transfer
SB Service Bus
SOA Service-Oriented Architecture
SOAP Simple Object Access Protocol
WS Web Services
WWW World Wide Web
xix
xx
Chapter 1
Introduction
This document addresses the topic of creating an appropriate architecture for intelligent control and en-
ergy management of building offices. Given the current economic and social situation, it is of utmost
importance to focus on systems and technologies that enable energy efficiency, particularly in large
buildings. In Europe, buildings account for 40% of total energy use and 36% of total CO2 emission [Eu-
ropean Parliament and Council, 2010], and these values are expected to grow in the coming years. This
aspect results in a major concern for more energy conservation. Large buildings require technologies
with sophisticated applications and functionality, such as automatic control of lighting and temperature
set-points, as well the need for the system to learn with the activity of users inside the building. In ad-
dition, these environments must be energy efficient and must simultaneously ensure the comfort and
well being of the occupants in order to enable them to become more productive. The main hindrance in
developing this vision are the lack of interoperability that automation systems offer. Each manufacturer
keeps developing their proprietary specifications and has little motivation to evolve their systems to the
emerging trends of communication standards [Litvinov and Vuorimaa, 2011].
1.1 Motivation
To illustrate the addressed issue, take into account the following scenarios:
Scenario 1 consider a daylight-harvesting system, which aims to use daylight to control
the amount of electric illuminance needed to properly light a space, in order to reduce en-
ergy consumption. These systems uses a set of sensors and actuators inside the room to
measure luminance and adjust the lighting of the lamps, respectively. In this scenario it is
necessary to deal with interoperability of diverse devices, their functionality and technical
features, since many are from different manufacturers and communication protocols.
Scenario 2 consider a scheduling system, which execute some tasks periodically. This tasks
are triggered after an event or set of events have occurred. Events can be a time value or a
specific event from the user’s activity. In this scenario it is necessary to understand how the
1
scheduling system of each device technology works and map the logic of scheduling with the
operation logic of each device.
Existing solutions to address the requirements of scenarios 1 and 2 consist of monolithic applications
that do not provide modular services, and also do not allow interoperability with other automation tech-
nologies used. In addition, most existing solutions are proprietary and not expose their insights, which
do not allow the reusing and extension of its functionality. This situation is illustrated in Figure 1.1, which
compares a monolithic system with a layered architecture [Bastide et al., 2006].
Service-Oriented Architecture (SOA) is a paradigm that defines services as key elements of software
design. The main goal of SOA approach is to reduce the dependencies of software parts, where each
part is typically a remote piece of functionality accessed by clients. By reducing such dependencies,
each element can envolve separately and the application becomes more flexible than monolithic appli-
cations. The advantages of SOA also apply to automation applications: loose coupling, run time service
binding, and location transparency. Indeed, services abstract implementation to provide the desired
functionality; they provide faster prototyping based on creation of new services from existing (service
composition); they enable handling the diversity of devices and applications, because they are easier
to integrate and evolve; they enable integrate Building Automation Systems (BAS) functionality with the
Information Technology (IT) systems underlying the occupant business. Technically, SOA provides ab-
straction: upon a call to the specific service, the implementation is invoked regardless of whether it
is deployed in a device, or in another software module. This latter paradigm motivates the need of a
SOA-based reference architecture for Smart Buildings systems.
Layered'System'(SOA'approach)System'3
AutomaticControl
History
Devices
System'2
Scheduling
Devices
Building/UsersDataUsers:Data
System'1
Daylightharvesting
Devices
AutomaticControl
History
Scheduling
Building/UsersData
Building/UsersData
Daylightharvesting
Devices
Service:Layer:MiddlewareBuilding/Users
DataBuildingData
(a) (b)
Figure 1.1: Actual systems versus SOA approach. (a) Monolithic architecture where high level applica-tions are highly dependent on the original software design. (b) Layered horizontal solution that enablestechnology abstraction, interoperability, and extensibility.
2
1.2 Problem Definition
Nowadays, there is a lack of a solution that integrates office control systems in a extensible way, which
ensures the interoperability of BAS functionalities, such as intelligent control of lighting, Heating, Ven-
tilation, and Air Conditioning (HVAC), and other electric equipment. There is still no solution for the
development of applications for intelligent control and energy management in a modular way, based on
SOA, where it is possible to reuse and compose services in order to implement new functionality. The
current solutions of Building Automation (BA) and Energy Management (EM) are vertically integrated
and do not allow communication with devices in a standard way, and poorly support their heterogeneity.
Re-designing and re-programming BA and EM systems, in order to change and extend features to sup-
port new devices and functionalities are still too expensive and too slow to achieve. Web Services (WS)
and SOA has allowed it, more precisely in IT systems [Lee et al., 2010], due to the different business
needs, but not embarked on the automation and energy management domain yet. What really hap-
pens is that both services and the programmer has to know the details and characteristics of the BAS,
which causes a massive consumer lock in. Increasingly it is necessary that the IT system and BAS are
integrated in the architecture that supports the business, since the optimization of the energy and the
business processes is something that has to be done in an integrated way.
Herein, we propose a way to build BA applications atop of a modular service layer middleware that
also abstracts the heterogeneity of BAS. The middleware abstract all systems and low level devices to
BA applications, making less complex to develop these software. This novel approach enables taking
advantage of systems that already exist, orchestrating and reusing the services they offer to implement
new features that take into account the needs of the business. Conceivably in the near future, BAS will
enable adding new features without having to redesign the original architecture of the system.
Solutions to this problem are quite complex as is necessary to realize the systems architecture and
services that the middleware service layer has to offer. Typically, architectures for these systems include
services for energy consumption and for commanding devices. Indeed, these service components are
needed. It is necessary to integrate all context information (e.g. retrieve the state of electrical devices,
the energy consumption data, and the user presence data), to derive control decisions that meet the
user preferences and needs while ensuring the best values of energy consumption in the building.
Other solutions, as detailed in Chapter 3, are trying to solve this issue using service oriented archi-
tectures to provide some interoperability between different systems. However, they only expose devices
as service calls along with the idiosyncrasies associated with each device. There is no semantics on top
of these services, such as logical services to reuse and extend. The characteristics of different devices,
the different protocols and different drivers continue to exist, but now at the service level, maintaining the
lack of interoperability. The issue that these solutions solve, is that previously the devices communicate
in specific protocols and now they communicate on web services languages like REST and XML.
This work will analyze the various existing functionalities in Building Energy Management Systems
(BEMS) and propose a reference architecture with a set of services collections required in order to create
modular intelligent energy management and automation control applications on top of these services.
3
1.3 Contributions
The contributions of this document are as follows:
(i) An extensive review of the existing literature concerning service-oriented architectures of BEMS
(ii) A architecture blueprint for a BEMS, that will enable the easy extension and fast development of
new BA and EM applications
(iii) Evaluation of the proposed architecture implementation prototype in a real-world setting. Our
solution prototype are applied in IST facility 1 , particularly in offices rooms, in order to validate the
proposed solution to this scientific problem
1.4 Document Organization
This document is organized as follows: Introduction chapter attempted to introduce the research problem
of this study and present a brief overlook of the scientific problem in hands. In the Concepts chapter it is
introduced some of the concepts used in this document such as BEMS and SOA, aiming to familiarize
the reader and providing him a better understanding to the work presented in this document. Related
Work chapter collects and review the researched work of various fields that aim to achieve some of the
goals of this study. Solution chapter presents a service layer middleware that implements a novel SOA-
based architecture related to BEMS and BAS software. In order to prof the concept, the Implementation
chapter describes all the implementation details regarding the components of our prototype, as well
the technologies involved and programming language tools used. The Evaluation chapter presents the
overall evaluation process of this project and analyses the solution architecture. Finally, the Conclusions
chapter, summarizes the work, presents the conclusions and points for future directions.
1For this reason, this work was designated as IST SmartOffice.
4
Chapter 2
Concepts
In this chapter, it is given a brief description of some of the key terms and systems used, in order
to provide a better reader understanding. We will make a literature review of the concepts regarding
Building Energy Management Systems, their functionalities and standards. Then we also explore sev-
eral aspects of Service Oriented Architectures. This is important to determine the benefits concerning
these systems. Then, we will review the requirements needed with the view to design and develop a
middleware for BEMS, based on a Service Oriented Architecture.
2.1 Building Energy Management Systems
A BEMS is part of a Building Management System (BMS) and a computer-controlled system, which
when installed in a building, controls its power systems, including lighting, heating, ventilating and air-
conditioning. The basic functions of a BEMS are – monitoring, controlling, and optimizing [Levermore,
2002]. The system is designed to reduce the energy consumption, improve the utilization, increase the
reliability, and predict the performance of the technical building systems, as well as optimize energy
usage and reducing its cost [International Standard, 2013].
The functional aim of BEMS is to manage the environment within a building, so that energy consump-
tion perfectly balances with the way of building utilization and its normal activities. By achieving this, the
amount of wasted energy is minimized. This saves money and reduces carbon emissions. Managing
the energy used in a building means controlling a wide variety of parameters, such as distributing and
managing the level of lighting, heating and ventilating to suit changing levels of activity within different
areas of the same building throughout the day. The level of control can be refined to a very specific
degree: such as managing the energy used in different zones of a single area if required. BEMS are
dependent on the other two system that underpins all the BEMS functionalities – BAS and EMS [Bloom
and Gohn, 2013], as shown in Figure 2.1.
One important system in a BEMS is a BAS, which is a digital network of electronic devices and
appliances that may respond more adequately to the requirements of an user in a given instant, while
reducing energy consumption by switching loads based on occupancy information. BAS can be inte-
5
Energy'Management'System'
Building'Automation'System
Building'Energy'Management'System(BEMS)
IT'System
FacilitiesOperation
Figure 2.1: Building Energy Management Systems data sources. BEMS is aware of environment vari-ables of the building. From the energy information derived from the EMS, the IT System and the facilitiesactivity is possible to achieve the real time control of the building energy systems.
grated with an Energy Management System (EMS), enabling for example, to trace the status of certain
devices in certain energy peak loads [Chen et al., 2009]. A BAS can also be connected to a infor-
mation management system, which integrates real-time data concerning the devices with maintenance
management data and with space management. BEMS are a critical component to manage energy
consumption, since BEMS linked systems represents almost 70% of the energy consumption on a build-
ing [Agarwal et al., 2011].
2.1.1 Building Automation Systems
A BAS, also referred as BACS, is a distributed system directed to the computerized control, measure-
ment, and management of building services. This distributed system can be seen as a pyramid divided
into three levels [Fernbach et al., 2010]. The lowest level is the Field Level where the interaction with
field devices happens. In the middle of the pyramid we have the Automation Level, where measure-
ments are processed, control loops are executed and alarms are activated. The level at the top of the
pyramid is the Management Level, where happens activities like system configuration and commission-
ing (submission of system’s configurations), presentation and archiving of system data. Modern BAS
take advantage of service-oriented architectures, having loosely coupled modules and the capability for
providing secure and cheap access to the BAS from any location inside the infrastructure or, if needed,
in the whole world, through the Internet [Lahti et al., 2011].
According to ISO 16484-7 standard [International Standard, 2013], a BAS must provide the following
control features to enable energy performance in buildings:
• Heating and cooling control
• Ventilation and air conditioning control
• Lighting control
• Blind control
6
Technology Field of use
Controller Area Network (CAN) Automobile engineering, Building Automation
Process field bus (Profibus) Process and Factory Automation
Interbus Factory Automation
Konnex (KNX) Building Automation
Local Operating Network (LON) Building Automation
Local Control Network (LCN) Building Automation
Modbus MODBUS Building Automation
BACnet Building Automation
Table 2.1: Examples of fieldbus technologies and the applications they are used in taken from [Merzet al., 2009b]
2.1.2 Fieldbus Networks
A fieldbus is a digital serial data bus that enables communication between devices at the field level such
as controllers, transducers, actuators and sensors [Merz et al., 2009a, Thomesse, 2005].
The fieldbus technology promises to improve quality, reduce costs and boost efficiency by commu-
nicating with devices digitally, by reducing the required wiring and installation effort, since analog signal
standards require devices to have their individual set of wires. Also, in a fielbus network, is expected that
all devices connected to it have some computational power, and because of that they are considered
smart devices, that can replace several analog devices at once, reducing the costs of the system [Field-
bus, 2006].
There are many fieldbus systems on the market and their specifications vary according to require-
ments of the applications they are used in. There have been created several industrial standards such
as BACnet [Bushby, 1997], KNX [KNXAssociation, 2009], LON [Corporation, 1999] and CAN [Gmbh,
1991]. Figure 2.1 describe some of the most relevant technologies.
2.1.3 Energy Management Systems
An EMS is a set of systems that uses operators of an electronic grid to monitor, control and optimize
buildings energy use. It also allows the implementation of energy-efficient control techniques or action
plans in order to increase energy performance.
They help increase user awareness on how building is performing. EMS aims at guaranteeing maxi-
mum operation efficiency without adversely affecting the building occupants comfort. Through monitor-
ing, EMS can:
• Improve the level of building management allowing the facility to be monitored from a single loca-
tion. The facility management team can check more effectively if the building is operating according
to their expectations, acting immediately if it is not.
• Obtain a pattern of energy consumption allowing unexpected consumptions to be identified when
the pattern is not met, thus enable the system to warn users about the need to take further actions.
7
• Identify peak electrical demand that might be responsible for additional costs. After identified,
those peaks might be lowered or smoothed, allowing associated cost to be saved.
In order to achieve its purpose, an EMS performs three fundamental operations, (i) gathering all
energy related data, (ii) interpretation of collected data, (iii) data presentation to the users in the form
of reports [Ma et al., 2010]. EMS software model typically follows a three layer representation: (i) data
acquisition layer, containing the modules responsible for retrieving device information according to its
type; (ii) integration layer, containing the module responsible for mapping retrieved data into EMS data
repository; (iii) application layer, containing the application modules responsible for implementing the
features over the stored data, we detail these aspects in turn over the following sub-sections.
2.1.4 BEMS standards
With the aim to understand the specific features that a BEMS system should provide, it is necessary
to call upon the International Organization for Standardization (ISO) and European Standards (EN)
documentation, as shown in Table 2.2 of the following page.
2.2 Service-Oriented Architectures
The idea of a service-oriented architecture (SOA) [Open Group Standard, 2011] refers to a paradigm
for the construction and integration of software systems where the primary structuring element is the
service as opposed to subsystems or components, and strives to link resources on demand. In SOA,
any subsystem is described by the services it offers.
Despite being a paradigm, SOA can have distinct meanings based on different perspectives: busi-
ness, architecture and implementation perspectives. From a business perspective, SOA is a set of
important services that a business wants to expose to their customers and partners, or other portions of
the organization. From an architecture perspective, it is an architectural style which requires a service
provider, requester and a service description, a set of architectural principles and patterns. From an
implementation point of view, a SOA is a programming model complete with standards, tools and tech-
nologies such as Web Services (WS). But ultimately, SOA is a way of thinking aiming to enhancing at
the maintainability and availability of systems.
Web Services (WS) are the most common implementation of SOAs. WS consist of modular and
independent software applications that can be executed over the web. These applications usually use
XML and SOAP over standard network protocols, to implement the communication channels.
Organizations that focus their development effort around the creation of services, will realize many
benefits, such as, code mobility and reusability, scalability and availability, and better testing.
SOA is a good choice when applied in special circumstances: they are best suited to large hetero-
geneous distributed systems with different owners, different purposes, implemented at different points
in times, with different programming languages. Most enterprise landscapes can employ this paradigm.
8
ISO 16484-3 EN 15232
Grouping/ZoningIndividual zone control is listed as a required functionality. (Section 5.1.1.4)
The concept of zones is used to define room or zone specific control activities and setpoint preferences. (p. 27, 32, 46)
Event Notification
Event handling and notification is described as an operator function provided by the HMI. (Section 5.1.1.2, 5.3.5.17)
Refers to the notification of changes in the system's status for several purposes such as controlling indoor occupation.*
Alarm NotificationAlarm notification is described as an operator function provided by the HMI. (Section 5.1.1.2, 5.3.5.17)
Alarm notificiation are essential to detect malfunction situations.
Historical Data Access
This standard presents data archiving and the means for retrieving that data as management functionalities of a BAS. (Section 5.3.2.9)
States that data collection and logging are features offered by building management systems. (p. 10)
Scheduling Provides a section describing time scheduling features. (Section 5.3.5.15)
Specifies the use of schedules to control some attributes such as the air flow in a room (Section 7.5.1)
Scenarios
There's no direct reference to the "scenario'' terminology, although, energy management services are seen as a requirement that according to EN 15232 benefits from this concept. (Section 5.1.1.3)
This standard defines several system operating modes that are used to adapt the operation of the building to occupants' needs. Each operation mode can be modelled as a scenario.*
BEMS Standards
Table 2.2: BEMS functionalities addressed in ISO 16484-3 [International Standard, 2007] and EN15232 [European Standard, 2006] *This statement is confirmed along the entire EN 15232 document.
Consider a BEMS based on a SOA, where an automation software is responsible for encapsulat-
ing the logic of building automation and simultaneously for offering its services to enable any external
application to interact with the system. These external applications may be user interfaces capable of
consuming that automation software’s services, thus enabling the development of multiple interfaces
such as one interface for a desktop computer, other for smartphones, etc. This eases the task of main-
taining the system, because changes in the automation software’s internal logic won’t affect any of its
interfaces, and interfaces can be created or modified without affecting the automation software.
Therefore, SOA is the best solution to support layered architectures and implements a BEMS that
coordinates the heterogeneous environment of electrical devices present in a building.
2.2.1 SOA concepts
Technically a SOA is based on three major concepts: services, interoperability (through a service bus),
and loose coupling [Josuttis, 2007]. A service is defined as a discoverable software resource. It en-
9
capsulates a business function (a function that has meaning for a non-developer person). Services use
a mechanism to register and locate other services at run-time. This mechanism introduces three roles
identified as providers that offers other services, consumers that need services, and brokers that bring
them together by advertising and locating services. Services have descriptions (usually referred as in-
terfaces) that represent a service’s capabilities and the necessary information for their usage, such as,
name, how the services can be accessed and the their location. Services are understood to be available
for searching, binding and invocation by a service consumer. A service is made available through a
service provider who publishes the its capabilities on the service broker. Service consumers interested
in a specific service or it capability, querying the service broker for that service. The broker in turn
replies with the service description. Service consumers must adhere to the contract published by the
service provider in order to use the service. A consumer adheres to the contract by reading its contents
and determine what operations the provider has, what parameters it expects and what data structures it
returns. Once the adhesion is done they can bind to the service provider and use its services.
Services may be reused by other services and applications. This means that each service is created
(build) once but can be instantiated (deployed) to all systems that require it. Through reuse, services
can also be composed to provide the functionality needed and fulfill multiple business requirements and
they can be orchestrated in business processes.
The Service Bus (SB) is the infrastructure that enables interoperability and facilitates communication
between services acting as a message broker. It provides an abstraction for endpoints (entry points to
services). This interaction allows loose coupling and promotes flexibility in communications because it
frees the service consumer from having explicit knowledge about the connection details of the service
provider. Services communicate with each other by placing messages in the SB and specifying a desti-
nation. The SB processes the request by applying transformations (in case the sender business service
request does not conform to the same structure and format expected by the service provider or in case
the protocols are different or in the worst case both) and routes the request to the appropriate service
provider. Routing can be based on deterministic or variable criteria, such as policy-based routing or
complex rules-based routing. Complex routing can be based on any criteria that the user defines, like
type of user or type of application. A SB performs service mapping. It translates a business service into
the corresponding service implementation and provide binding and location information.
Loose coupling is important because adapting a system by incorporating changes in one of its com-
ponents, in this case implying changing the location of a service, becomes much easier.
2.2.2 Web Services
A Web service, in very broad terms, is a method of communication between two applications or electronic
devices over the World Wide Web (WWW). Web services are of two kinds: Simple Object Access
Protocol (SOAP) and Representational State Transfer (REST).
10
REST
Representational State Transfer (REST) implements the standard HTTP as an interface allowing clients
to obtain access to resources based on requested URIs. URI takes the form
http://domain.com/service/method?param1=var1¶m2=var2
and is a string of characters used to identify a name of a web resource. It is important to note that REST
based services are stateless because http is natively stateless, as it doesn’t have built in support for
states, for example, it isn’t possible to store if the user has made logged in on the system.
One of the many benefits for implementing HTTP service interfaces is the possibility of caching.
Caching reduces web server processing and increase response times because content is already pro-
cessed and stored for immediate access. Caching can be done on a web service much like caching
is done on requested web pages. Typical actions performed by REST based services include generic
CRUD (Create, Read, Update, and Delete) operations and operations that do not require state.
REST is particularly fit for a number of situations where:
• Limited bandwidth and resources: Any browser can be used because the REST approach uses
the standard GET, PUT, POST, and DELETE verbs. REST can also use the XMLHttpRequest
object that most modern browsers support today.
• Totally stateless operations: if an operation needs to be continued, then REST is not the best
approach and SOAP may fit it better. However, if the main objective is to use stateless CRUD
(Create, Read, Update, and Delete) operations, then REST is it.
• Caching situations: if the information can be cached because of the totally stateless operation of
the REST approach, this is perfect.
SOAP
Simple Object Access Protocol (SOAP) on the other hand uses a generic interface in order to transport
messages. Unlike REST, SOAP can use HTTP, HTTPS, SMTP, JMS, or any other standard communica-
tion protocols. Furthermore, SOAP utilizes XML in the following ways: i) define the message; ii) defines
how the message is to be processed; iii) defines the encoding of the message; iv) lays out procedure
calls and responses.
SOAP is fairly mature and well-defined and does come with a complete specification. Areas that
SOAP works really well are:
• Asynchronous processing and invocation: if the application needs a guaranteed level of reliability
and security then SOAP offers additional standards to ensure this type of operation.
• Formal contracts: if both sides (provider and consumer) have to agree on the exchange format
then SOAP 1.2 1 gives the rigid specifications for this type of interaction.
1SOAP Specification - http://www.w3.org/TR/soap/
11
• Stateful operations: if the application needs contextual information and conversational state man-
agement then SOAP has the additional specification in the WS structure to support those things
(Security, Transactions, Coordination). Comparatively, the REST approach would make the devel-
opers build this custom plumbing.
REST vs. SOAP
As REST aligns more with a Resource View, SOAP aligns more with a Method View in that, business
logic is exposed as methods typically through SOAP web service because they can retain state. In
addition, SOAP requests are not cached therefore every request will be processed by the server. As
stated before SOAP does retain state and this gives it a special advantage over REST for services
that need to preform transactions where multiple calls to a service are need in order to complete a
task. Additionally, SOAP is more interoperable for enterprise level services that implement standard
enterprise exchange formats in the form of contracts. REST does not currently support this. [Francia,
2010, Rozlog, 2010, Merritt, 2012]
OSGi
Open Services Gateway initiative (OSGi) is a component framework specification that aims at bring-
ing modularity to the Java platform. It enables the creation of highly modular and dynamic systems.
These systems are highly modular in the sense that OSGi-based applications are composed by multiple
independent modules or components, and also dynamic because development, testing, deployment, up-
dating, and management on each module have minimal or no impact on the overall system. This means
that bundles can be safely added and removed from the framework without restarting the application
process.
Its mission is to “create a market for universal middleware” to assure interoperability of applications
and services delivered and managed via networks. Since its inception OSGi has undergone several
releases of its specification along with the development of several framework implementations, both
commercial and open-source, e.g., Knopflerfish [Knopflerfish], and Equinox [Eclipse]. The latter is the
most widely used since it is the base runtime of Eclipse, open-source integrated development environ-
ment and also of mainstream application servers such as JBoss and IBM’s Websphere.
OSGi is built upon the Java platform with a five layered architecture: a module definition layer, module
life-cycle layer, service registry layer, services layer, and security layer, in ascending order. At its lowest
level, the OSGi specification defines a deployment model for Java-based modules, defining the unit of
deployment known as bundle. A bundle consists of a set of Java packages deployed along with their
corresponding metadata. Rather than creating a completely new deployment mechanism. OSGi bundles
are much like common JAR files, except that their META-INF/MANIFEST.MF file contains OSGi-specific
metadata, including a definitive name, version, dependencies, and other deployment details.
A bundle can be installed, started, stopped, and uninstalled from the frame- work. Once a bundle is
installed into an OSGi framework, the OSGi life-cycle layer governs the status of the bundle.
12
OSGi specification provides a service registry layer, where bundles may publish and/or subscribe
services. OSGi enables bundles to publish services and to subscribe services of other bundles. The
interface of an OSGi service is realized by specifying a corresponding Java interface. A bundle contains
a public and a private section. Service interfaces should appear in the public section, whilst implementa-
tions should be kept in the private section. Therefore, services are known by their published interfaces,
not by the implementation. This separation ensures that bundles only depends on the interface of other
bundles. The service registry enables bundles to detect the addition or removal of services, and adapt
accordingly. The OSGi service provider, service consumer and service broker together form a service-
oriented architecture. However, unlike many interpretations of SOA, which rely on web services for
communication and operating across a networked environment, OSGi services are published and con-
sumed within the same Java virtual machine. Thus, OSGi can be described as “SOA in a JVM” [Walls,
2009, Hall et al., 2010]
On an OSGi-based application operations on bundles, such as installation, uninstallation and update,
does not disrupt execution of the application. Therefore, bundles are said to be hot-pluggable. This is
possible because each bundle is loaded into its own class space and has its own class loader. Another
important aspect of independent class space is that the contents of a bundle are private unless explicitly
exported. This makes it possible for a bundles internal implementation to evolve without impacting
other bundles that depend on its public API. This differentiates a bundle from normal JAR files, whose
contents are fully published into the applications classpath and consequently, seen by every other class
in the classpath at run-time. Another consequence of isolating bundles in their own class space is the
possibility for multiple versions of a given bundle to coexist in an OSGi framework. Bundles can depend
on a particular version of other bundles that meet their requirements.
Many applications start as monoliths with little modularity (strongly coupled and with low cohesion).
OSGi provides a set of mechanisms for decomposing monolithic systems into independent modules,
thus attaining flexibility and ease of extension. An OSGi application is a collection of bundles executing
in the OSGi framework. In an OSGi-based system there are no layers, as far as the standard notion of
layers go in software engineering, there is only a community of bundles, providing functionality to each
other and working collaboratively to achieve a given end.
As outlined before, bundles are independent from each other, however they collaborate in a well-
defined way. They describe themselves by declaring their public API and defining their dependencies on
other bundles. These dependencies are references to types (classes) in other bundles.
Bundles are more powerful than standard JAR files, because one can explicitly declare which con-
tained packages are externally visible. It is possible to declare on which external packages a bundles de-
pends. These dependencies are called exported and imported packages, respectively, and are declared
in the bundles manifest file. The main benefit of explicitly declaring bundles’ exported and imported pack-
ages is that the OSGi framework can manage and verify their consistency automatically. This process
is called bundle resolution and involves matching exported packages to imported packages.
It should be noted that just adopting OSGi into an application architecture will not necessarily make
an application more modular. It’s necessary to ensure that the modules created follow good modular
13
OSGi%Framework
Java%Virtual%Machine
Dev
ice&Ac
cess
Http&Se
rvice
Log&Se
rvice&
Preferen
ces&Se
rvice
Confi
guratio
n&Ad
min
Service&Trac
ker
Use
r&Adm
in
Pack
age&Ad
min
Prem
ission
&Adm
in
Wire
&Adm
in
XML&Pa
rser&Service
Mea
suremen
t
Positio
n
Conn
ecto
r&Service
Jini&Service
UPn
P&Se
rvice
Start&L
evel
URL
&Han
dler
Figure 2.2: OSGi Framework components [Open Services Gateway Initiative, 2002]
design. OSGi does, however, encourage modular programming practices by making it easy to create
well-defined modules.
Jini
Jini technology is a service-oriented architecture technology developed by Sun that defines a program-
ming model which extends Java technology for building Java applications that rely on widely distributed
components. Jini is very similar to OSGi for the reason that it enables a flexible and dynamic envi-
ronment of groups of services, employing concepts such as service consumers, providers and service
lookup registry. Where Jini differs is its focus on distributed systems. Consumers access clients through
some form of proxy using a remote procedure call mechanism, such as Remote Method Invocation
(RMI). The service-lookup registry is also a remotely accessible service. The Jini model assumes re-
mote access across multiple VM processes, where OSGi assumes everything occurs in a single VM
process. But in contrast to OSGi, Jini doesn’t define any modularity mechanisms and relies on the
execution-time code-loading features of RMI.
UPnP
Universal Plug and Play (UPnP) [UPnP] is a protocol architecture for peer-to-peer networks, connecting
intelligent appliances, wireless devices, and computers of different ways. It is designed to bring easy-to-
use, flexible, standards-based connectivity to ad-hoc or unmanaged networks whether in the home, in a
small business, public spaces, or attached to the Internet. UPnP technology provides a distributed, open
networking architecture that leverages TCP/IP and Web technologies to enable seamless proximity net-
working in addition to control and data transfer among networked devices. UPnP is intended for smart
homes, small offices and other types of local area networks. It was originally created by Microsoft Cor-
poration in 1999 [Reynolds, 2002]. The technical inspiration behind UPnP was to provide a distributed
14
computing framework based on web technologies for small networks, especially home networks. OSGi
framework also support UPnP protocol [The OSGi Alliance, 2009], as shown in Figure 2.2.
2.3 Middleware for BEMS
Middleware has been defined as a distributed system service that includes standard programming inter-
faces and protocols [Bernstein, 1996, Umar, 1997]. These services are called middleware because they
act as a layer above the device-specific and networking software and below business applications.
Architecture research regarding middleware focuses on the problems and effects of integrating com-
ponents with off-the-shelf middleware. Di Nitto and Rosenblum [Di Nitto and Rosenblum, 1999] describe
how the usage of middleware and predefined components can influence the architecture of a system
being developed and, conversely, how specific architectural choices can constrain the selection of mid-
dleware [Fielding, 2000].
Functional and Non-functional Requirements
A functional requirement defines a function of a system or its component. A function is described as a
set of inputs, the behaviour, and outputs. Functional requirements may be calculations, technical details,
data manipulation and processing and other specific functionality that define what a system is supposed
to accomplish. Behavioural requirements describing all the cases where the system uses the functional
requirements are captured in use cases.
Functional requirements are supported by non-functional requirements (also known as quality at-
tributes), which impose constraints on the design or implementation (such as performance requirements,
security, or reliability). Next, a brief description of the functional and non-functional requirements that
this project architecture aims to accomplish are presented.
Functional Requirements
• Web services based on direct access to devices: Back end services must be able to discover
and directly communicate with devices, and consume the services they offer. For example, have
the capability to receive event notifications from the device side, to which other services can sub-
scribe to.
• Web services based on direct access to application-level services: Business logic must be
able to execute on applicational services and take decisions not only based on its local information
but also on information provided by the devices. For example, devices must be able to subscribe
events and use the business logic services.
• Service Discovery: Automatic service discovery to dynamically access device services without
having explicit task knowledge and the need of a priori binding.
15
• Service life-cycle management: Provide a basic support infrastructure to mediate issues related
to future services implementation, which will be installed, updated, deleted, started and stopped.
• Device integration: Implement gateways and service mediators to allow integration of the non-
web services enabled devices.
• Devices history: It is needed in order to keep devices behaviour up-to-date: logging of data,
events and devices history.
• Device management: Web services enabled devices will contain both static and dynamic data.
This information needs to be managed in order to maintain reliability between data retrieved from
devices and their exploitation above the device-layer.
Non-functional Requirements
• Service composition: SOA infrastructure will allow building more sophisticated services on top
of generic ones, therefore allowing add-ons for enhanced functionality.
• Modularity: 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 without placing in
unnecessary dependencies.
• Cohesion: Is a relevant measure of the elements that modules comprise to the module goal. A
highly cohesive module states that all parts of the module are focused on addressing a particular
aspect and thus, are much easier to test and reuse since they deliver just the function needed.
• Development time: The amount of time and effort required to build a system or functionality.
• Interoperability: The system components cooperation with different languages running on differ-
ent operating systems.
• Modifiability: Changes in components do not require other components to be changed. System
can be changed at runtime and continues to operate when components are temporarily removed
or replaced.
• Testability: An error message with the component causing the error have to be communicated,
bringing the ease of constructing and test software. Also component interactions of the whole
system can be visualized and logged.
• Performance: Some optimization techniques must be used in order to decrease the response
time of reading data from sensors or obtain the status of the appliances.
16
Chapter 3
Related Work
Smart buildings require integration of various building automation systems that are usually made by
different manufacturers [International Standard, 2013]. Most of the manufacturers tend to focus on a
specific domain, while others try to comprise all domains in one application. The need to integrate
several network technologies and communication protocols into applications has forced developers and
researchers to create service oriented frameworks or use existing to accomplish that objective.
There are several service oriented solutions to support intelligent automation and energy manage-
ment features in an ambient intelligent environment. Some solutions claim to provide an abstraction
layer to overcome the heterogeneity. Other solutions intended to provide services for sophisticated ap-
plications.
EM#and#BAfunctionalities
Technology#independent#integration
Services#exposition#(devices)
Fieldbus#heterogeneity#abstraction
Figure 3.1: Pyramid of reviewed BEMS requirements and functionalities. This pyramid shows differentrequirements and functionalities groups that BEMS concerning solutions should provide, starting fromthe abstraction of devices from different technologies and protocols, the need to expose them as aservices, the integration of the different technology functionalities and provide the general EM and BAfunctionalities to end-user.
17
A bottom-up analysis is presented below, starting from the need of heterogeneity abstraction and
interoperability of several field devices technologies, where it is required that this systems provides ser-
vices exposition and composition in order to compose all various systems in a technology-independent
integration way. After being achieved the integration of various technologies, it is possible to provide
several energy management and automation functionalities that will deliver application-level services to
the end-user applications. These different requirements are grouped into different classes, as shown in
Figure 3.1.
3.1 Fieldbus heterogeneity abstraction
Given that there are several automation devices from different manufacturers, they are incompatible and
can not communicate with each other. A popular method to achieve integration is defining a common
protocol between centralized front-end and individual gateways to proprietary systems.
Building Automation and Control Network (BACnet) [Bushby, 1997] protocol has been widely
accepted and used in BAS industry. BACnet is a communication protocol, developed by the American
Society of Heating, Refrigerating and Air-conditioning Engineers (ASHRAE) and its concept is to replace
the communication portion of each device with a common, standard set of communication rules, so that
all devices can exchange information using only one language.
LonWorks [Corporation, 1999] is another completely different solution and a great competitor. Lon-
Works is actually a family of products and at the core of this technology lies a communication protocol
called LonTalk.
Despite the fact they seem good solutions as it is, both require Web Services interfaces to accom-
modate functionalities integration [Szucsich, 2010], as you will see in the next sections. They have been
conceived to cover all domains of building automation, including Heating, Ventilating and Air Conditioning
(HVAC), lighting, and alarming. Hence, proprietary communication protocols have become unnecessary
and interoperability of components from different vendors could have been achieved. However, standard
communication protocols have not been able to completely solve the integration problem due to still ex-
isting proprietary products. So new approaches have had to be developed for the integration of building
automation subsystems.
3.2 Services exposition
The primary technologies used in SOA domains are Web Services since they have broad industry ac-
ceptance. In the BA, there is an increasing need and opportunity to create interfaces between the
physical devices and software applications. BAS developers, inspired by Web Services technologies,
began researching for a way to extend the SOA paradigm into the device space, that is, implementing a
high-level communications infrastructure based on Web Services protocols at the device level [Jammes
and Smit, 2005].
18
Devices Profile for Web Services (DPWS) [Mensch, 2009] is the extension of the Web Services
protocol that surfaced. With DPWS, all messaging, whether related to discovery, control or event noti-
fication, is based on the use of SOAP. In that context, a target service is a device. Once discovered, a
device exposes the services. This protocol is a service enabler for devices, i.e. converts binary commu-
nication to XML via SOAP, and the technical features of the devices still exist and it is necessary to deal
with them at the higher level.
Service-Oriented Device Architecture (SODA) [Deugd et al., 2006] is an adaptation of SOA which
aims to integrate a wide range of devices into an enterprise system. Once again, devices like sensors
and actuators are dealt as services. A SODA implementation adds a new layer to the SOA model,
wherein device interfaces and protocol adapters are provided, enabling communication between propri-
etary and standard device interfaces, and other SOA services over the enterprise network. This protocol
is also a service enabler, but offers some integration of devices and provides services extension and
composition to the software layers above.
3.3 Technology-independent integration
System high level protocols are used to connect these automation systems with each other and also to
integrate them with management software components. Integration of software components within an
enterprise environment can be achieved through the implementation of a service layer middleware.
BACnet/WS [Szucsich, 2010] is a standard designed to be a Web-Service based communication
protocol in the industrial and home automation which can be applied to any fieldbus system. BACnet/WS
is independent from the underlying BAS and allows heterogeneity abstraction and exposes their data
model and attributes through a web service interface. The BACnet/WS web services are used to access
and manipulate data in a server, which therefore will communicate with the fieldbus technology. Although
this technology allows to expose services, these are fairly primitive and generic, as only provides basic
operations of read, write, and collect historic data of nodes. In order to implement functionality over
field devices is necessary to develop other services to allow a higher level of abstraction to support
sophisticated applications. The BACnet/WS data model is quite simple and not extensible.
OPC Unified Architecture (OPC UA) [Leitner and Mahnke, 2006], is an architecture designed by the
OPC Foundation for connect industrial devices to control and supervision applications [Hadlich, 2006].
The focus of OPC is on getting access to large amounts of real-time data while ensuring performance
constraints without disrupting the normal operation of the devices. The original OPC specifications,
based on Microsoft COM/DCOM, are becoming obsolete and are gradually being replaced by new in-
teroperability standards, including Web Services. OPC UA has the most complex data model of all
standards mentioned before. The data model of OPC UA is almost arbitrarily extensible by services
composition.
Open Building Information Exchange group (oBIX) [OASIS Open, 2013] is a specification and
aims to integrate enterprise functions in several building control systems. This specification is designed
to provide access to the embedded software which sense and control the environment around us. With
19
rapid increase of low cost microprocessors for embedded devices is easy to implement Machine-to-
Machine (M2M) communication. oBIX provide standard mechanisms to transfer information over net-
works for publication and consumption, breaking networking into two pieces: an abstract request/re-
sponse model and a series of protocol bindings which implement that model. Current version of oBIX
defines two protocol bindings designed to leverage existing Web Service infrastructure: an HTTP REST
binding and a SOAP binding. It is concise, but very flexible. Multiple inheritance is explicitly allowed and
rules for single and multiple inheritance are specified.
Home SOA [Bottaro and France, 2008], is an open architecture for home service deployment. It
is based on a service platform concept, where distribution and protocol heterogeneity are managed
by service-oriented drivers. Home SOA allows developers to model networked applications as a local
composition of uniform service interfaces, which become bounded at runtime. This solution manages
with important Pervasive Computing challenges, such as 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 an device protocol, and represented in object-
oriented programming interfaces adapted to the protocol. 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. This architecture is implemented regarding
the OSGi standard [Dobrev et al., 2002], where its specification defines how to deal with device’s access:
how to share and isolate resources between modules. 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 an uniform program-
ming language API. This model was applied in multimedia, home automation and device management
domains.
DomoNet [Miori et al., 2006] is a service-oriented solution framework designed for home environ-
ments. This prototype implements an architecture which makes the connection between lightning de-
vices of two different middlewares: UPnP and KNX. This solution is based on a SOA and uses web
services to reach the interoperability between different home computer middlewares. The aim of this so-
lution is to prove how an approach that relies on XML, Web Services and Internet protocols, can provide
an uniform architecture to home automation.
LinkSmart middleware, formerly named Hydra middleware [HYDRA, Eisenhauer et al., 2011], is
part of an European project for the development of service-oriented software to expose heterogeneous
device functions in an universal way and target domains such as home automation, among others. 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 with the aim to integrate within the supported
device instances, based on the semantic model meta-data. Decoupling the application development
from the device programming brings advantages with regard to modularity, reusability and extensibility.
LinkSmart offers a set of extended features such as security, context awareness, quality of service, and
distributed storage. These features help application developers build high quality applications within a
20
short time. However, not all system’s devices can be supported by this middleware, as it is very difficult
to find in the market devices that can embed the services themselves.
Service-Oriented Cross-layer Infrastructure for Distributed Embedded devices (SOCRADES)
[Cannata et al., 2008] is a Framework for developing intelligent systems in manufacturing and relies
on European research project addressing SOA-based manufacturing paradigm [Information Society
Technologies]. The primary objective is to develop a design, execution and management platform for
next-generation industrial automation systems, exploiting the SOA paradigm both at the device and
at the application level. SOCRADES Framework uses an improved DPWS specification in order to
perform a Web Service-based network architecture. This defines a set of built-in services that allow
service orchestation, service management, semantic web services, and service gateway. At application
level, SOCRADES allow an unified enterprise integration via a cross-layered web service infrastruc-
ture [Karnouskos et al., 2007].
3.4 Energy Management and Automation functionalities
Some solutions focuses on energy management and building automation functionalities to provide best
comfort while ensuring efficient energy consumption. This aspect is the most important functional re-
quirement in a BEMS.
PoliSave [Chiaraviglio and Mellia, 2010] is a software designed to reduce power consumption in
computer networks. It manages the scheduling of power on and off of building 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 PC’s, and also, introduce active learning techniques for the purpose of compute the best power
scheme to apply for each user regarding their activity. A similar solution is what we aim to develop in this
project regarding the computers, displays and data-shows present in the building. This solution is not
within the scope of the BEMS, but it is a good solution for buildings with much computerized equipment,
and it can be turned off and turned on depending on the needs of business.
MEDUSA [Davidyuk et al., 2009] is a middleware based on Activity-oriented computing paradigm.
This paradigm promotes run-time applications by composing ubiquitous systems based on abstract
specifications of user activities. For example, given a smartphone equipped with RFID reading capabil-
ities, it can be used to scan cards that represent services and form service compositions, resulting in a
practical physical interface for users. In 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. It is an interesting
approach if we think about the IST SmartOffice context when we define different possible scenarios to
be achieved in terms of a lecturer wishes to give a class, an exam or do a presentation.
aWESoME is a Web Service Middleware for Ambient Intelligence environments [Stavropoulos et al.,
2013]. aWESoME aims to implement a large-scale building system, regarding energy consumption sav-
ings. This middleware relies on the following paradigms – Ubiquitous Computing (UbiComp), Pervasive
21
Computing (PerComp), and SOA. Ubiquitous systems are able to perceive user needs and interface
with them in an intuitive way. Service oriented services are in practice a manner of exposing a systems
methods for users or applications to consume in an universal way. The proposed middleware is the
middle layer that establishes the connection between the hardware layer and the various applications
layer. The main goal of this solution is to fulfill functional and non-functional requirements of the system
and to ensure universal, homogeneous access to the system’s 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 order to assure
interoperability between them. Also, two client applications, a desktop application and a smartphone ap-
plication prove its usability and effectiveness in the scenario of energy monitoring and savings, allowing
managing the building environment in an user-friendly way.
Smart Energy Efficient Middleware for Public Spaces (SEEMPubS) [SEEMPubS] is an European
project that aims exploiting ICT monitoring and control services to reduce energy consumption and CO2
footprint in existing buildings. This approach focuses on easily integration of existing BMS with new
sensors and actuator networks. The main goals of this project are: a integrated BAS; a middleware for
energy-efficient buildings domain; and a multi-dimensional building information modelling-based visual-
ization. To reach its goals the project implement an interoperable Web-based software solution for real-
time energy performance monitoring and control of lighting and heating, ventilation, and air conditioning
(HVAC) services through Wireless Sensor and Actuator Networks (WSAN). This is achieved through
an integrated approach based on the LinkSmart energy-aware middleware platform mentioned above.
SEEMPubS layered architecture are composed by three layers: LinkSmart Proxy Layer, SEEMPubS
Middleware Layer, and SEEMPubS Application Layer [Osello, 2013]. This solution lacks in providing
application-level services to BEMS. End-user applications do not have to worry about the implementa-
tion of BA and EM functionality.
3.5 Discussion
The previous Section 3.4 was addressed several technologies that focus on trying to solve different
domain issues, such as automation fieldbus heterogeneity abstraction, BA services exposition, BAS
technology-independent integration, and energy management and automation functionalities providing.
Table 3.1 and Table 3.2 summarize those technologies features that we find most interesting to our
project, regarding the researched concepts and standards. This tables take into account the functional
and non-functional requirements associated to BEMS.
3.5.1 Non-Functional Requirements
Most solutions are supported by SOA, thus providing greater extensibility and interoperability with other
technologies in an easier way. Systems that stand out for a higher extensibility and interoperability
22
SOA Relative Model Complexity Extensibility Interoperability
BACnet ✗ simple low lowLonWorks ✗ simple low low
DPWS ✓ simple medium lowSODA ✓ simple medium medium
BACnetWS ✓ simple low lowOPC UA ✓ complex high high
oBIX ✓ concise high mediumHomeSOA ✓ concise high highDomoNet ✓ concise low highLinkSmart ✓ concise high high
SOCRADES ✓ concise high highPoliSave ✓ simple low high
MEDUSA ✓ concise medium highaWESoMe ✓ concise high high
SEEMPubS ✓ concise high high
Energy Management and Automation functionalities
SystemNon-Functional Requirements
Field-bus heterogeneity abstraction
Services exposition
Technology independent integration
Table 3.1: Different available systems non-functional requirements comparison.Legend: 3 feature supported; 7 feature not supported
Automation Energy Management
BACnet ✓ ✗ ✗LonWorks ✓ ✗ ✗
DPWS ✓ ✗ ✗SODA ✓ ✗ ✗
BACnetWS ✓ ✗ ✗OPC UA ✓ ✗ ✗
oBIX ✓ ✗ ✗HomeSOA ✓ ✗ ✓DomoNet ✓ ✗ ✓LinkSmart ✓ ✗ ✗
SOCRADES ✓ ✗ ✓PoliSave ✓ ✓ ✗
MEDUSA ✓ ✗ ✗aWESoMe ✓ ✓ ✗
SEEMPubS ✓ ✓ ✗
SystemBEMS Functional Requirements
Functional Services Providing
Table 3.2: BEMS features support and application-level services providing to BA and EM applications.Legend: 3 feature supported; 7 feature not supported
23
are: OPC UA, HomeSOA, LinkSmart, SOCRADES, aWESoMe and SEEMPubS. These solutions solve
some issues of the problem, because they can help development of BEMS supporting BA technology
integration and abstraction. As they are based on SOA it is possible to implement EM and BA functional
application-level services over this systems, using a modular service composition, being that the focus of
my solution. The aWESoME and SEEMPubS middleware are the most similar approaches regarding the
IST SmartOffice architecture objectives, as it 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 the energy consumption of the
campus offices within an user-friendly interface.
3.5.2 Functional Requirements (BEMS Features)
Despite all solutions supports some BA and EM functionality, majority have a lack support of BEMS func-
tionality, which causes a need to implement a new system with all the standard features. Application-level
services providing is an important feature, that enables extension and development of BAS applications
easily. As we can see, no solution fulfills all the characteristics surveyed. However, they all complement
each other, increasingly motivating the creation of a new reference architecture.
One aspect that lacks enough, are the system ability to provide BA and EM application-level services
in order to help the developers to build easily and quickly BEMS sophisticated applications.
24
Chapter 4
Solution
The solution aims at developing a new middleware architecture with the purpose of overcome the iden-
tified issues, such as interoperability and extensibility lacks of BEMS. The solution present a vision of
a middleware architecture and its software layers (Section 4.1), and propose a collection of different
services that the middleware must provide (Section 4.3) and also present and describes what is the
purpose of each collection and their services.
To achieve the middleware goals, an existing building automation and energy management software
will be refactored into a modular architecture. OSGi framework will be used to implement such archi-
tecture, since it has mechanisms that promote modularity and also can afford all requirements of BEMS
shown in Section 2.3. The first step to modularize the application, is to identify its essential structure.
This will help to understand the dependencies and identify interactions. From there its possible to define
the building blocks that constitute the middleware. Finally, with a fully modular and functional middleware
it is possible to implement a sophisticated BEMS fully based on SOA, being also highly functional and
extensible system.
4.1 Architecture Overview
This section proposes an architecture for the service layer middleware (Figure 4.1), aiming at flexibility
and scalability, enabling easy development of new applications in a modular way. This novel architecture
will be very useful, to the extent that at the end we will take advantage of several benefits:
• Abstraction - modular service components will allow multiple levels of abstraction
• Fast prototyping - creation and utilization of existing services
• Heterogeneity handling - services will enable integration of devices diversity
• IT integration - will be possible to create services that integrate automation systems with the IT
systems present in the building
• Lower operational and maintenance costs - there is no more maintenance dependence with sup-
pliers and manufacturers of equipment and systems.
25
Service Middleware
Applications
Serv
ice
BusManagement Services
Autonomous Actuation Services
Intelligent Actuation Services
Direct Actuation and Data Access Services
Resources Connectivity
Devices
History DataBuilding/Users
DataBuilding/UsersData
ServiceEnabledSystems
Figure 4.1: Proposed Service Architecture. The Middleware consists of several service modules whichdeal and abstract the specifications of each different BAS technology and provide functional services forhigh-level applications, starting from the field level, then building automation, energy management, andintelligent control.
As opposed to other solutions, this architecture is based on the BA and EM standards (Sections 2.1.1
and 2.1.4), regarding also to the latter paradigms of software architectures. This platform will centralize
all the building’s control functions, in order to reduce the installation, commissioning, maintenance and
hardware costs. The proposed layered architecture is composed by several extensible blocks with well-
defined interfaces that abstract its implementations. The implementation of each block can be a software
module or even can be in other proprietary software solution module.
As depicted in Figure 4.1, this architecture is able to manage and interoperate with several fieldbus
technologies and their devices, thus solving the problem of heterogeneity. The system also implements
energy management and intelligent control functionalities on service layer middleware instead on ex-
pensive hardware controllers. High-level services, will provide all the necessary functionality to the fast
development of BEMS applications. The various services presented are divided into four layers, cor-
responding to different types of features. Each layer is a different level of abstraction, where the lower
layer offers services to upper layer, which simultaneously uses the services of layer below. Service Bus,
will enable interoperability between service layers, promoting communication between service providers
and service consumers.
The system functionalities and services are described in detail through the next sections.
26
4.2 Resources Connectivity
Resources connectivity is the service layer responsible for manage and communicate with the various
BAS protocols. It also allows the access multiple data models manipulation, such as history databases,
building models and users data preferences. In order to internal model interact with different protocols
and BAS technologies, it is necessary to define a common API (Application User Interface) and cre-
ate adapters that cope with various and heterogeneous protocol implementations and adapt them to a
specific common protocol - the Datapoint Connectivity API, as depicted in Figure 4.2.
The Resources Connectivity Layer is essential to decouple the internal service API from specific BAS
protocols and specifications (like KNX, X10, iLight, Modbus, etc.). The BEMS services contact to a spe-
cific BAS technology within the Resources Connectivity layer. The clearly defined interface between our
internal services and the device driver services allows control of different devices via different adapters.
Adapters will take care for translation and presentation of specific protocol details to Connectivity API
service. Protocol Integration can access the different adapters implementations via OSGi services that
guarantees a clear datapoint abstraction. Then, the decoupling and generic access to various devices
via OSGi service interfaces is provided.
It is a general design rule to minimize implementation effort in Resources Connectivity Layer to be
able to flexibly provide and support new adapters on customer/vendor request without (or with minimal)
changes in internal services.
Resources Connectivity
Protocol 1
Protocol Integration
Protocol 2 Protocol 3 Protocol 4 Protocol N
Adapter 1 Adapter 2 Adapter 3 Adapter 4 Adapter N
Devices Devices History Data
Building/UsersData
External Resources
Datapoint Connectivity API
Figure 4.2: Resources Connectivity Layer. Figures above show the basic separation of different protocolimplementations and the common and unified protocol – the Datapoint Connectivity API. The differentAdapters provide a clear interface of devices from different protocols, while Protocol Integration layer isintended to join the various adapters in a common communication protocol.
27
4.3 Service Collections
In Figure 4.3 are shown the set of services that will provide sophisticated functionality to Applications
layer. The services were divided into multiple logical levels, the service collections, taking into account
the type of BA and EM functionality and the energy-efficient control techniques according to standards
(Sections 2.1.1 and 2.1.4).
Service Middlew
are
Applications
Management
Autonomous Actuation
Intelligent Actuation
Direct Actuation and Data Access
OccupancyBasedControl
DaylightHarvesting
AutomaticBlind Control
HVACControl Learning
User ModelManagement
OccupancyFeedback
Management
Building Model
Management
Energy Model
Management
Alarms and Events
Scenarios Management Scheduling
Remote Sensing & Actuation
Meter & Sensor Data Acquisition
History Data Storage
Data Querying
Data Fusion & Analytics
Figure 4.3: Service collections. The services were divided into multiple logical levels, according to thelevel of abstraction and also taking into account the type of BA and EM functionality
Next sections intends to describe in detail all the system functionalities and services shown in Fig-
ure 4.3.
4.3.1 Direct Actuation and Data Access Services
The Direct Actuation and Data Access Services Collection intends to deal with BAS devices commu-
nication and its abstraction. It is also responsible for the devices history data storage, data querying
functions, and data fusion and analytics techniques.
Remote Sensing and Actuation
A physical device denotes some type of sensor, that converts a physical reality into an electric signal
that can be measured, or an actuator, which is any electrically actionable device, piece of equipment or
appliance, such as a window blind or a lamp.
Since automation hardware is highly heterogeneous, they should be abstracted in a way that enables
software applications to be as independent as possible from the hardware specificities. From a software
perspective, reading from a sensor is equated as reading from a variable that represents a hardware
28
input port and commanding an actuator is compared with writing a value on a variable representing an
output port. So when a device is created we have to specify the input ports and the output ports where
the device will be connected. Later, the service abstract all these details and a sensor reading or device
actuation is done from a service call to the service that is responsible for affecting these variables.
Meter, Sensor and Equipment Data Acquisition
This service allows the addition of new sources of data through the using existent drivers or using the
implementation of a new devices data gathering drivers. They are connected to the real-time sensor or
device data through its exposed interface. Drivers might be used to connect with other sources besides
physical devices. For example, they might gather data from online weather stations for instance without
any impact on the existing solution.
History Data Storage
History services are divided into short history and long term history. Short term history keeps a detailed
trace of the changes to variables for a smaller period (a few minutes or hours), while long term history
may keep less detailed history information but for long periods (days, months or years). The history
service should allow performing certain types of queries to history data. It should also offer history read
and update services.
History Data Storage Service should abstract the schemas and types of databases. Given that
buildings are constantly producing data the service should concerns about Big Data challenges. A
new trend in smart buildings are data storage through cloud-based solutions that store and maintain
big data [Bloom and Gohn, 2012]. Automation applications that use the data does not have to worry
about how data are structured in the databases. Even if the data schema needs to be changed, it is not
necessary to change the application logic, since the service interface is maintained.
Data Querying, Data Fusion and Analytics
This solution will offer the possibility to provide data to other services and present the gathered data to
the user through queries. Data querying will be implemented as an EMS application accessing stored
data through the service layer. The end-user will be able to extract data using a set of well defined
queries.
Data Fusion is the process where gathered data from multiple sources is combined into a single data
source [Jiawei and Kamber, 2006]. In this process collected information will be mapped into the system
model. There are two types of data that need integration [Capehart and Middelkoop, 2011]:
• Static data consists in data that is loaded once into the system. This data are usually related to
building properties such as location, room areas, organizational data or energy tariffs. Static data
are commonly gathered or read from configuration files. Although these data might change, and
the frequency on which it does change is low.
29
• Stream data are data that often vary, so it must be continuously retrieved from devices or online
sources in order to keep it updated. New data are periodically arriving into the BEMS and it needs
to be stored and kept by History Data Storage Service. Due to the high frequency updates and
number of sources that need to be mapped in the data store, integration process is much more
complex when dealing with dynamic data.
To ensure that inaccurate data are not added to the repository, data quality measures must be de-
termined and insured by services implementation. Data quality measures usually relate to accuracy,
completeness, time and consistency [Batini and Scannapieco, 2006]. On BEMS the mostly common is-
sues are related to network failure, duplicate data, misread information and human error while inserting
data manually. For instance, a system using event driven data gathering might not be able to distinguish
between a network failure and a device failing to transmit information because there is no environment
updates. After extraction, cleaning and transformation, data are ready to be loaded into the system
data base where it should fit its data model, this entire process is also known as the process of Extract
Transform and Load (ETL) [Nagesh et al., 2010].
4.3.2 Autonomous Actuation Services
The Autonomous Actuation Services Collection aims to provide some basic functionality actualy present
in BAS, such as alarms, events, scheduling and scenarios.
Alarms and Events
An event consists of any occurrence that modifies the building state. The building manager may choose
to be notified of certain events, usually conditions that have been verified, such as a room’s tempera-
ture that changed 2 degrees Celsius since last measurement, a specific door that was just opened, a
new person that entered in a room, and so on. Exceptional events or running conditions of a system
are identified as alarms. Typically exceptional conditions are originate in a specific device or group of
devices. Alarm events capture malfunction in some device, lack of a essential resource for the exe-
cution of a process or other unexpected behavior in the system. An alarm service should indicate the
devices or systems it is related to and the closest known source of the problem. In contrast with reg-
ular events, alarms either require manual acknowledgment or may be transient, meaning that they are
cleared whenever the condition that initiated them disappear.
Scenarios Management
Scenarios can be as static or dynamic. A static scenario is described in terms of status. In other
words, it describes the desired status of a group of devices. It is said by static that it does not prescribe
actuation whenever environment conditions change. A static “studying scenario” can be defined as
having the lights on over the table. A dynamic scenario describes how the system reacts to changes in
the environment. A dynamic “studying scenario” specifies that lamps have to be turned on if there is not
enough light.
30
Another important aspect of scenarios is the time dimension. When a scenario is activated, the
effect on the status of devices may not be immediate. Consider a “give a class” scenario, where minutes
before the time the user specified, factors such as room temperature and lighting, which were previously
in standby mode to save energy, are automatically switched on accordingly to user’s pre-definitions to
the system.
Scheduling
BAS sometimes need to execute certain automation tasks at predefined schedules. BAS software usu-
ally provides a scheduling service. A scheduling service is used to relate tasks execution with some
moment in time. Schedules are uniquely identified by the combination of date, time and the actions they
perform. They can be defined according to fine-grained units of time such as hours, minutes or even
seconds. As time passes scheduling events are triggered and tasks are executed.
Scheduled events can be one-time events or repeatable events. A scheduling service should also
enable different calendars for specific purposes. For example, a calendar that manages actions related
to illumination control, in order to reduce energy consumption at night. This service must also allow
registering user defined schedules and delegated schedules. A delegated scheduled is defined by an
algorithm or by an external source that captures local holiday information or other events. Schedules
are often embedded in hardware controllers, but in larger facilities they are often configured in the main
server that runs the BAS software. Many fieldbus specifications cover scheduling functionalities natively.
4.3.3 Management Services
The Management Services Collection aims to achieve a better way to manage the building and the BEMS
functions, based on available data models of information.
User Model Management
This service is intended to define the types of users that use the resources inside the building. For this
reason there are two types of control techniques:
• Centralized control BAS may include a central point of control for lighting and HVAC systems, this
is called centralized control. Centralized control in a building provides commodity and also helps
controlling energy usage, since it helps applying standard energy-efficient control techniques in all
building rooms. It also simplifies changes in a buildings energy policies, because it only needs to
be change once instead of doing manually to all rooms as it happens in a decentralized control
system.
• Personalized control often uses energy-efficient control techniques which are applied in buildings,
peoples comfort may be compromised and eventually consumers will stop using energy-efficient
control techniques in favor to their personal comfort. But frequently people use more light intensity
31
than what they actually need, a way to overcome this is to enable the consumer to personal-
ize their own ambient, selecting their ideal light level for working. This way the consumer can
achieve his desired light level keeping his comfort while reducing energy consumption. It has been
demonstrated by a number of studies that personal dimming also results in higher productivity. So
allowing personal light control on buildings may induce people to reduce light intensity or even to
switch lights off thus saving energy.
Occupant Feedback Management
Real-time reporting or feedback helps people to understand how much energy they are actually using to
perform a task, understanding where they are spending energy. With proper education and incentives
the introduction of reporting can result in cost reduction. People can change their consumption behavior
in order to achieve an increase of energy efficiency in buildings. A study performed in a dormitory
in Oberlin College in Ohio, USA, shows that dormitories where an automated data monitoring system
provides to the students a real-time feedback of their energy and water consumption given through a
web-based system resulted in a 32% reduction in electricity consumption [Petersen et al., 2007].
Building Model Management
Building automation is intrinsically related to the idea of controlling spaces, which are areas that are
monitored or controlled by the BAS.
Spaces are divided into several zones. A zone can be a floor, a room (or just part of it) or an
area within another zone. Zones may be related according to containment and adjacency, providing
information about the building (for example using zones to identify and distinguish halls from rooms in
a building). Furthermore, zones are characterized by meta-data such as the zone name, space usage
profile and location within the parent zone as well as its boundary polygon that defines the zone’s shape
and borders.
Zone information is also useful for querying about the spatial context of devices, this is important for
determining where devices are installed and their influence zones. Physical and functional characteris-
tics of spaces can be retrieved from Building Information Models (BIMs).
Energy Model Management
Collected energy data must be transformed into costs. Although, due to the complexity that might be
associated with this operation, BEMSs need billing models to allow that transformation. Having a billing
model implemented on an BEMS might seem a feature that every EMS should have. However, this is
still one of the major lacks in today’s systems. The lack of these models is mostly due to the complexity
associated to them.
Energy tariff model is the commonly adopted solution. Despite the large number of variables that
can be used to model energy tariffs, usually a simple cost estimation solution can bring good results.
A common solution is to calculate the average energy costs during a time period relating them to the
32
measured consumption. This value can be used to estimate current energy costs according to the
current consumption. Actually, this approach yield so good cost estimations that implementing more
complex energy tariffs wouldn’t bring significant insight. [Capehart and Middelkoop, 2011]
A pricing model provides a way to obtain a rough estimate of the costs associated with energy
consumption serving as advisor. An interesting approach is offered by few systems that provide the
capability to compare several modeled tariffs at the same time. This feature allows comparing which
tariff would bring better savings according to expected energy consumption. Adopting the optimal tariff
might bring significant gains even before changing the energy consumption pattern though the adoption
of new energy policies.
4.3.4 Intelligent Actuation Services
At this level in this architecture, is possible to provide energy-efficiency control techniques more eas-
ily, given the higher service abstraction. These techniques are occupancy-based control, daylight-
harvesting, automated blinds control, HVAC control, and some learning techniques in order to take
in consideration the user’s activities and behavior.
Occupancy-based Control
Occupancy control sensors are commonly used in indoor spaces using infrared sensors to detect mo-
tion. When no motion is detected in a certain room, it is assumed that the space is empty, and thus
does not need to be illuminated. There are two major types of actuation are based on occupation de-
tection, the movement detection switching and the movement detection dimming. On the first one the
occupancy sensor switch on/off lights according to the motion detected in a room, on the second one
the sensor dims the light to a defined level in the absence of motion. Both types of actuation are based
on occupancy control to turn on/off or to dim the lights can result in substantial energy savings [Roisin
et al., 2008].
Despite the service abstraction of sensors occupancy detection, there are some major issues when
using occupancy control sensors. After a certain period of time since the last motion is detected by
the sensor, the lights will be switched off. This interval is commonly referred as time-delay. This may
happens simply because the user stopped moving during a period of time, this situation is known as a
false switch off and causes a major discomfort to users. One way to overcome the false switch off is to
use smart occupancy sensors. These sensors changes the time-delay according to a certain time of the
day. This is done by measuring the activity and inactivity periods of the day. According to experiments
using this type of smart sensors, the energy savings can increase to 5% and the false switch off are
actually reduced significantly, thus increasing the user comfort [Garg and Bansal, 2000]. Automatic
lighting control systems are a good solution for reducing energy consumption in buildings.
This high-level service can be easily implemented from the orchestration of services from layers
below using Business Process Model and Notation (BPMN) processes, as shown in Figure 4.4
33
Presencedetection
Light ON (100%)
OccupancySensor value
changed
Light OFF (0%)
no
yes
Figure 4.4: Occupancy-based Control Process.
Daylight-Harvesting
An adequate control of the output intensity of electric lights is the base of lighting energy savings. The
idea of daylight harvesting service is to drive the light output taking into account the current ambient
luminance level obtained from a photo sensors devices. However photo sensors are not precise enough
— their performance depends mostly on their placement [Ehrlich et al., 2001]. The service layers be-
low, such as data fusion and analytics service, can deal with those device specific features, killing and
abstracting the lack of some equipment precision.
Also using BMPN processes, it is possible to implement this technique of intelligent actuation, as
depicted in Figure 4.5.
Presence detection
Daylight availability
Light ON (100%)
no
Light OFF (0%)
yes
If daylight > Theshold
yes
If light > Theshold
If light < Theshold
Dim Lights(+%)
Bright Lights(-%)
yes
yes
no
no
Figure 4.5: Daylight-Harvesting Process.
34
Automated Blinds Control
Automated blind controls will help control light intensity in the room. With more natural light the system
will turn off or dim the luminaries, reducing energy consumption. To prevent from excessive glare, a
system can also automatically close the blinds. So the only possible way to have a proper dimming
response is with the installation of shields that prevent the saturation of the sensor from daylight and
reflections. So the major issues during an installation of a system like this, are the blinds control and the
calibration of photo sensors. The installation of a dimming system using Auto open blinds proofed to be
very efficient, creating a 27% reduction in lighting energy use [Floyd and Parker, 1995].
HVAC Control
An HVAC control systems enable to control the environment climate conditions of the building, like
temperature, humidity, and ventilation. Several works have shown that approximately 25%-40% energy
saving can be achieved by regulating HVAC systems based on occupancy data derived from the sensors.
[Erickson et al., 2011].
Generally, a HVAC consists of three subsystems [Wang, 2010]: chillers, heat-rejection system and
chilled water distribution system.
The HVAC control is achieved from a set of devices, such as sensors, thermostats, controllers, ac-
tuators, communications systems, control panels, and user interfaces associated with building climate
control. Good HVAC control strategies can optimize the consumption of energy by capitalizing on in-
formation about thermal comfort conditions as well as properties of the building structure and systems.
The existing problem is if there is a need to expand or upgrade the HVAC control system, a building
owner has been forced to either return to the same vendor who installed the existing system, replace it
in its entirety, or install a separate independent system because the communication protocols for other
products were incompatible. This service aims to solve this problem, enabling interoperability in the
control of several different HVAC systems.
Learning
The BEMS will support specific interaction capacities with the offices users that will enable the devel-
opment of a bi-directional learning system such that both the user and the building may learn how to
interact with each other in a more energy efficient way. Examples of such interaction are for instance the
BEMS continuously acquiring a given user (or groups of users) comfort preferences (in terms of lighting
and HVAC) and optimizing the energy usage of a given space so to be able to comply with the users
needs, and provide an automatic conflict detection and resolution solving. For the above mentioned
objective it is necessary to characterize the consumption profiles through recorded data and simulate
the expected consumption profiles, which will lead to the identification of inefficient energy consumption
habits and respectively to saving strategies.
Evolutionary algorithms should be a proper solution for optimizing stochastic (non-deterministic) ex-
perimental conditions: optimization of energy consumption and comfort conditions in order to increase
35
the general welfare of a room with one or several tenants with different comfort profiles. These algo-
rithms are expected to work continuously and in real time when a space is occupied and work as an
interactive bridge with the users, namely by incorporating the user’s comfort conditions whenever they
may want [Shrestha, 2009].
4.4 Summary
Fieldbus
HardwareAbstraction Layer
Automation&
Control Logic
Service Layer
Applications
User InterfacesManagement
Level
Automation Level
Field Level
Applications
Service Middleware
Intelligent Actuation
Management
Autonomous Actuation
Direct actuation and data access Prop
osed
sol
utio
n
Resources Connectivity
Figure 4.6: Service Layer – The Middleware. The Service Layer is responsible for the abstraction of lowlevel details, such as the automation and logic control of each fieldbus technology, and also for providinga service collection which allows the easy development of new BEMS applications and Graphical UserInterfaces (GUI).
This chapter described the proposed solution for a service middleware. The solution entailed the
development of a new SOA for intelligent environments, such as Building Automation and Energy Man-
agement. Based on this middleware architecture, we outlined a novel architecture for the development of
BEMS solution in a easy way, that provides a high level abstraction of low level details of fieldbus tech-
nologies, and also provides a solution for development of new BEMS features. We further described
these features in a Service Collections blueprint.
As shown in Figure 4.6, our Service Layer on top of the Automation Level will handle with the hetero-
geneous environment of fieldbus technologies, and also provide a set of service collections to end-users
applications through their GUI.
36
Chapter 5
Implementation
The knowledge acquired from researching the current literature allowed us to implement a BEMS service
oriented architecture which could replace majority of the current software solutions. The developed soft-
ware intends to contribute as middleware between physical devices of BAS and end-user applications,
providing all the BEMS systems functionality through services. This middleware supports interactions
with several heterogeneous BAS technologies, by providing mechanisms that allows new devices to be
added, while contributing with a service layer which promotes data access through services exposure.
The presented middleware allows easily extend the BEMS features through services composition.
In this chapter will be described how the middleware was designed and implemented, focusing on
the main challenges encountered and the solutions to overcome them.
5.1 Overview
During the development environment phase was necessary to study which are the best technologies
that would meet our needs: the development of an service-oriented architecture.
On the one hand we have to develop an infrastructure that settled on the Service Oriented pattern
and enables the services, bundles and dependencies management. On the other hand, it is necessary
to develop some lower level and primitive services that can be reused and composed in order to create
new services with more sophisticated functionality.
5.2 Middleware implementation
This service middleware has been implemented in Java, using an OSGi Framework, which can be
executed on Java virtual machine (JVM) regardless of computer architecture, allowing it to reach a wider
range of developers. The OSGi framework can be used in the implementation of BEMS solutions, easing
the task of integrating new BAS technologies, reducing the associated implementation effort. Moreover
existing solutions can benefit from this middleware as it allows the addition of new drivers and functional
services which might offer users new insights on their building performance.
37
5.2.1 OSGI Framework setup
Under the Eclipse IDE, the chosen OSGi framework for the architecture development was the Apache
Felix1. Apache Felix implements the OSGi R4 Service Platform under the Apache license. This frame-
work is the best suited for projects interested in the principles of modularity, component-orientation, and
service-orientation. With the purpose of automate the building process and the dependencies man-
agement of the bundles, the Maven2 building tool was also used. Thought Maven it is possible to use
the BND Maven Plug-in, where it can generate bundles and calculate package imports directly from a
Maven build, decreasing development time of software.
5.2.2 Datapoint Connectivity API Java specification
In this section is specified the Datapoint Connectivity API that provides a well-defined interface to service
implementations. A data point is a discrete unit of information, then ”datapoint connectivity” naming
refers to the main objective of this API – deliver an uniform way of exposing devices and connect services
as a discrete unit of information. The main purpose is that all services implements this API in order to
turns it in an unified data points protocol.
This API offers the following resources and operations:
DatapointAddress[] getAllDatapoints();
This method gets the addresses of all datapoint controlled by the service implementation. The Dat-
apointAddress define the virtual or internal address of a device, that are mapped into a real device
address.
DatapointMetadata getDatapointMetadata(DatapointAddress address);
Gets the meta-data of a given datapoint address. The data point meta-data consists of all meta infor-
mation about the datapoint, such as the access type operation, the data point description, the read/write
addresses, the type, etc.
int requestDatapointRead(DatapointAddress address, ReadCallback readCallback)
Gets the latest available value or status of a datapoint given their address. The response is obtained
through a readCallback that stores a DatapointValue with the reading value and the reading timestamp.
int requestDatapointWindowRead(DatapointAddress address, long startTimestamp,
long finishTimestamp, ReadCallback readCallback);
Request the readings a datapoint within a given time window. The response is obtained through a
readCallback that stores a set of all DatapointValues available in the time window.
int requestDatapointWrite(DatapointAddress address, DatapointValue[] values,
WriteCallback writeCallback);
1OSGi Apache Felix - http://felix.apache.org2Apache Maven - http://maven.apache.org
38
Request a datapoint write operation given the DatapointAddress and the values to write are passed
through a set of DatapointValues.
The complete API specification is available in Appendix A.1.
5.2.3 Services orchestration, binding and management
Apache Felix OSGi framework provides a ServiceTracker API that abstract the framework service reg-
istry into services bus. Through the ServiceTracker is possible to add new services, remove services
from service bus and also gets the references for services already registered on the bus. One limi-
tation found is that is not possible to register listeners to receive service changes notifications in the
registry. So we defined a new interface called IServiceRegistry that provides ServiceRegistryListener
and methods for doing additional service operations through ServiceTracker. The interface definition is
available in Appendix A.2. This new interface established another level of abstraction and really helped
the service orchestration process.
Another challenge in the services management, is to set the dependencies between service bind-
ings. Services needs to know this information in order to create their concrete instances in the Service
Registry and also change their behavior according to other services status. Thus, the management of
services and their dependencies had to be defined in a dependency tree. The dependency tree allows
also the addition of dynamic dependencies through wild-cards. An example of a service dependency
tree is presented below in JSON format:
1 {
2 "dependencyTree": [
3 {
4 "serviceName": "ist.smartoffice.dataaccess.dataaquisition.
DataAquisitionService",
5 "dependencies": [
6 "ist.smartoffice.dataaccess.remotesensingactuation.
RemoteSensingActuationService",
7 "ist.smartoffice.dataaccess.historydata.HistoryDataStorageService"
8 ]
9 },
10 {
11 "serviceName": "ist.smartoffice.deviceconnectivity.protocolintegration.
DatapointProtocolIntegrationService",
12 "dependencies": [
13 "ist.smartoffice.deviceconnectivity.*"
14 ]
15 }
16 ]
17 }
39
According to DatapointProtocolIntegrationService dependencies presented in the JSON example
above, the service behavior is changed upon other services registrations whose name starts with the
previous expression, such as the following service examples:
• ist.smartoffice.deviceconnectivity.knxip.DatapointConnectivityKNXIPService
• ist.smartoffice.deviceconnectivity.modbus.DatapointConnectivityMeterIPService
• ist.smartoffice.deviceconnectivity.x10.DatapointConnectivityX10CM11Service
5.2.4 Services exposition
Since the services are all enclosed in the OSGi framework, we can not access them from the outside,
unless we can communicate within the framework service-bus. A way to decouple the OSGI dependency
and allow the communication with services using the Datapoint Connectivity API was to use some Web
Services technologies in order to expose them to the world over WWW. Thus we developed some Web
Service Wrappers for OSGi, as detailed in the following sections. The global diagram of developed
service Wrappers is available in Appendix B.1.
REST Wrapper
The REST technology are chosen to expose OSGi services as Web Services. We defined a RESTful API
because it is supported by all browsers and the Web API do not require XML-based protocols, such as
SOAP or WSDL to support their interfaces. The REST Wrapper OSGi Bundle was developed using the
Restlet3 Framework. Restlet is a RESTful web API framework for Java. During the wrapper development
phase, it was necessary to adapt the Datapoint Connectivity Java API to REST Web Service Resources.
So we had to define a new adapted API in form of REST resources, as shown is Table 5.2. We used
JSON responses format because it is simpler to parse the data using Javascript. Another aspect the
wrapper has to know is the URI paths that correspond to OSGi services, in order do track the service
registry and expose them as REST. So we have to define the mapping between OSGi Service names
and Web Service names. Table 5.1 shows some mapped names. Another aspect for improving the
REST API ease of use, we developed one extra wrapper: a Javascript module that abstracts the REST
communication with the Restlet Server. The Javascript module is available in Appendix A.3.
OSGi Service Name Web Service Name
ist.smartoffice.dataaccess.remotesensingactuation.RemoteSensingActuationService /remoteactuation
ist.smartoffice.dataaccess.historydata.HistoryDataStorageService /historydatastorage
ist.smartoffice.dataaccess.dataquerying.DataQueryingService /dataquerying
ist.smartoffice.autonmactuation.scenarios.ScenariosService /scenarios
ist.smartoffice.autonmactuation.scheduling.SchedulingService /scheduling
ist.smartoffice.autonmactuation.alarmseventsAlarmsEventsService /alarmsevents
Table 5.1: Mapping between OSGi Service names and Web Services names.
3Restlet - REST Framework for Java - http://restlet.com
40
Method Endpoint Inputs JSON Output Description
GET /datapoints N/A
{ "addresses" : [ "address", "address", ... "address" ]}
Gets the addresses of all datapoints of devices
controlled by this service.
GET /datapoints/{address}/metadata address: The desired datapoint address
{ "units" : units "datatype" : datatype "accesstype" : accesstype "precision" : precision "scale" : scale ...}
Returns the metadata of a given datapoint.
GET /datapoints/{address}/{startTimestamp}/{endTimestamp}
address: The desired datapoint addressstartTimestamp: The timestamp that defines the initial windowfinishTimestamp: The timestamp that defines the final window
{ "readings" : [ { "timestamp" : timestamp, "value" : value }, ... } ]}
Gets the readings of a datapoint within a given
time window.
GET /datapoints/{address} address: The desired datapoint address
{ "timestamp" : timestamp, "value" : value}
Gets the latest available reading of a datapoint.
PUT /datapoints/{address}address: The desired datapoint addressContent-Type: application/jsonRequest Body: {"values" : [value1, ..., valueN]}
{ "operationstatus" : operationstatus}
Request a datapoint write.
Table 5.2: Datapoint Connectivity REST API.
PubSub Wrapper
Another technology to complement the Web Service and REST functionality is the Push-Notifications.
Push notification, also called server push notification, is the delivery of information from the server to
the client application without a specific request from the client. In our case, this is implemented by the
Publish-Subscribe paradigm, where the server are considered as publisher and client applications are
subscribers.
The PubSub Wrapper OSGi Bundle was developed using the Faye4 system. Faye is a publish-
subscribe messaging system based on the Bayeux protocol. It provides message servers for Node.js
and Ruby and support libraries for all major web browsers. In our case, we chose to use the Node.js
server. This server is not required to be on the same platform as the OSGi server. Therefore the
number of Faye connected clients does not affect the performance of the OSGi server, increasing system
scalability. In order integrate the OSGi with the Faye server, the Faye Client Java Library 5 was used.
Faye provides message channel concept. Message channels are the channels that carry messages
inside a message queue. In one side, we have message producers (publishers) and on another side
we have message consumers (subscribers). The PubSub wrapper basically expose all collected data-
point into message channels, and the client just have to subscribe the datapoint channels according to
their needs. The Figure 5.1 illustrate the PubSub workflow between clients and the server. Bellow is
presented an example of Faye usage in Javascript:4Faye - Simple pub/sub messaging for the web - http://faye.jcoglan.com5Faye Client for Java - https://github.com/MaRoe/faye-java-sample-client
41
1 var faye = new Faye.Client(’http://sb-dev.tagus.ist.utl.pt:8000/faye’);
2
3 faye.subscribe(’/remoteactuation/lamp1’, function(data) {
4 //this is called for each new event on the subscribed channel
5 var json_data = $.parseJSON(data)
6 //ex: update lamp GUI status.
7 });
:Server :Lamp:Client B
PUT ‘/datapoints/lamp1’ ON
publish ‘/datapoints/lamp1’ ON
requestDatapointWrite(lamp1, ON)
{responseOK}
:Client A
subscribe ‘datapoints/lamp1’
subscribe ‘datapoints/lamp1’
publish ‘/datapoints/lamp1’ ON
Notifications Subscribe
Status changeby Client B
Push Notification of
changes
Figure 5.1: Push-Notifications workflow. As depicted in the sequence diagram, after the clients subscrip-tion to the channel, when the status of the subscribed datapoint is changed, all the subscribers receivesa new notification. Thus we ensure that the datapoint state is always propagated to client applications.
5.3 Services development
After all the middleware infrastructure implementation, some of the services proposed in Solution chap-
ter are developed at this stage. Not all services have been implemented due to time constraints of
dissertation development, however we implemented the most relevant services in order to evaluate this
novel architecture in a real-world scenario. The implemented services are: Datapoint Connectivity Pro-
tocol Integration Service, Remote Sensing and Actuation Service, Data Acquisition Service, History
Data Storage Service, Data Querying and Data Fusion Service, Alarms Service, Scenarios Services
and Scheduling Service.
It is also possible that the remaining services are implemented in the future by the manufacturers,
extending and composing the existing services. Each manufacturer is free to develop only the services
they want according to their business needs. However they are always advised to follow the proposed
architecture design to ensure all system requirements.
42
5.3.1 Datapoint Connectivity Protocol Integration Service
This service is responsible for consuming all the services that abstract the protocols BAS technologies
and implements the Datapoint Connectivity API. Then the service implementation composes the different
data points of each consumed service and expose all data points from different protocols as a single
service. Using the dependency tree wild-cards in Section 5.2.3, this service will know what services
have to be consumed and then, expose them.
5.3.2 Remote Sensing and Actuation Service
This service aims to maintain the status of each sensor or actuator stored into a variable. This variable
corresponds to a data point. This state is obtained and synchronized from the Protocol Integration
Service, that offers a communication abstraction layer with the real devices.
A feature made during the implementation, was the possibility of gets the historical data of each dat-
apoint, even when the concrete technology does not support. When is performed a reading of historical
data in a datapoint and the concrete service does not support it, the history is obtained from the History
Data Storage Service.
Beyond that, an optimization was also added. In order to decrease the response time of reading data
from sensors or actuators status, instead of performing a reading in the concrete device, it is returned
last record of the device history. This is only possible to do when the Data Acquisition Service is working,
because it is responsible for storing all update events from devices, ensuring always the synchronization
between real and virtual datapoint status.
5.3.3 Data Acquisition Service
This service only has the responsibility to acquire data from different information sources and store it
in history databases. On one hand we have a information source that is the Remote Sensing Service,
and on the other and we have the History Data Storage Service to store the data into databases. So
basically this service implementation acquires data from devices status and store it in history database.
5.3.4 History Data Storage Service
The Historic Data Storage Service aims to expose the historical data each devices in the form of virtual
datapoints. They are virtual because they can represent the real state of a device at a certain moment
in the past. Thus, it becomes possible to navigate over the time.
From functional point of view, this service responsible for providing the abstraction layer for handling
with the storing of devices history in the database. This service handles with the following tasks:
• Establishing and maintaining the database connection
• Supplying instruments that ease database creation and updates
• Providing the mechanisms that enable data exchange through service consumers of the database
• Abstracting the database implementation schema
43
5.3.5 Data Querying and Data Fusion Service
This service abstracts the data querying to History Data Storage in a form of datapoints. When the
user requests the query correspondent datapoint, he receives the result without having to deal with the
technical details of the history database.
This service provides the following query examples:
• Q1: State the average energy consumption measured in the Library space in the last hour
• Q2: State the peak of wind speed occurred today
• Q3: State the minimum temperature observed during the night
Some of queries are constantly changing, so we have process the all the queries results continu-
ously. To improve the querying performance, we integrated the Esper6 Java Library in order to process
continuous queries. The Esper equivalent Q1 is:
select avg(value) from DatapointValue.win:time(60 min) where datapoint=’libraryenergymeter’
5.3.6 Alarms Service
The Alarms Service is implemented with the aim of detect and notify the user of exceptional events or
conditions of the system. Thus, this service uses the Remote Sensing Service to monitor all of events
and status change of datapoints. With the aim to detect malfunction behavior or some exceptional
conditions we developed a way to define alarms using boolean expressions. These expressions called
Alarm conditions, can be defined by the end user and are mapped into alarm datapoints. These alarms
can assume two states: TRUE or FALSE. If a condition verified, the alarm state is set to TRUE, otherwise
it is FALSE. Whenever one of these conditions is verified, a new event is generated in the corresponding
datapoint alarm.
Alarms expressions can be set with the following BNF grammar:
1 <expression> ::= <condition> ?
2 <condition> ::= <datapoint> <comparator> <value> [and|or contition]
3 <comparator> ::= "=" | "<" | ">" | "<=" | ">=" | "<>"
4 <datapoint> ::= A Datapoint Address available.
5 <value> ::= A Datapoint Value.
6 <and> ::= "AND"
7 <or> ::= "OR"
Expression examples:
• "weatherstationwindspeed > 50 ?" - This alarm is triggered when the wind-speed datapoint
from weather station is above to 50 m/s.
• "knx158sensorlux < 0 ?" This alarm is triggered when the lux sensor is below to 0 lux. This is
a situation of malfunction.6Esper - Event Processing for Java - http://esper.codehaus.org
44
• "knx158hvac = true AND knx158windowstatus = true ?" This alarm detects a situation of an
open window when the HVAC is turned on.
The user are also notified when an alarm change do FALSE to avoid transient alarms situations.
5.3.7 Scenarios Service
A scenario describes the desired status of a group of devices. With this services is possible to create
and select new scenarios, or using the existent ones from the hardware defined scenarios. The definition
of a new scenario is done using the ”macro recorder” concept. A macro recorder is a piece of software
that records user actions and playback them later. The main advantage of using a macro recorder
is that it allows an user to easily perform complex operations much faster and with less effort without
requiring custom programming or scripting skills. Imagine a leaving office scenario that the light and the
HVAC must be turned off. This scenario can be defined using a macro: The macro starts recording user
actions, user turns off the light and HVAC and then stops the macro recording. Then, if the user active
this scenario, the recorded operation are executed automatically. This scenario creation workflow are
depicted in Figure 5.2. The scenario service can also incorporate hardware defined scenarios. It was
done by mapping a hardware scenario into a scenarios service datapoint.
5.3.8 Scheduling Service
The scheduling service aims to provide a way to o execute certain automation tasks at predefined
schedules. The schedule service implementation also used the ”macro recorder” concept. The user
records the desired tasks and then assign them two values: an timestamp and a interval value. The
timestamp defines the date and time of the first execution of the task. The interval value is the period
between the task executions after the first execution is done.
:Server:Client
POST ‘/remoteactuation/lamp1’ FALSE
POST /scenarios/newscenario TRUEMacro starts recording
User executes operations
Macro stops recording
POST ‘/remoteactuation/hvac’ FALSE
POST /scenarios/newscenario FALSE
Figure 5.2: Scenario creation workflow. The scenario is defined using a macro recorder that stores alldevices status changes done by user operations.
45
5.4 IST SmartOffice Dashboard
Additionally, we also developed a functional dashboard that take usage of implemented services. This
dashboard allows a common user to interact with the system, such as visualize the energy consumption
curves and perform some control operations on BAS devices. The dashboard main screen is shown in
Figure 5.3.
Figure 5.3: IST SmartOffice Dashboard. The current screen shows a set of energy consumption andsome sensors history data. To access all other implemented services, there is available a left bar withthe corresponding icon buttons.
The chosen technologies for the GUI development was HTML5 and Javascript using the Bootstrap7
Framework. Bootstrap easily and efficiently scales the applications with a single code base allowing the
high compatibility with smartphones, tablets and desktops screens sizes.
Since the dashboard was developed using web oriented technologies, it become quite easy to deal
with the communication between the dashboard application and the OSGi web service technologies, the
RESTlet and the Faye wrappers.
The GUI organization consists of several screens according to implemented services. The main
screen, shows some charts with the historical data of some data points, such as the real-time energy
consumption, weather related data and some space environment conditions history. In the left bar,
several buttons are available and allows the access to other screens. These screens corresponds to
the remaining functionalities provided by the developed services: Office Control (Remote Sensing and
Actuation), Scheduling, Scenarios, and Alarms Service.
7Bootstrap Framework - http://getbootstrap.com
46
5.5 Implementation Summary
In this chapter, we started by detailing the middleware implementation phases and the various ap-
proaches to existing technologies. Firstly, we identified the chosen environment for the development
of an ecosystem of building automation and energy management services, the OSGi Framework. Then
we presented the specification of the Datapoint Connectivity API, that enabled an unified way of commu-
nication between different services implementations, and also an abstraction layer to communicate with
the heterogeneous environment of automation technologies. Later we described some implemented
techniques of services orchestration and management inside OSGi, and also how OSGi services are
exposed to the Web. At the end, we described all implemented services and also some of the challenges
and difficulties faced during the development phase.
To give an overview of the developed software components, the Figure 5.4 shows some of the devel-
oped bundles inside the OSGi platform, which corresponds to the different services and functionalities
developed. The software components are grouped into 3 types:
1. Core Bundles corresponds to essential software that allows the proper operation mode of the
global system
2. Adapter Bundles are software components that adds the communication support with new proto-
cols and technologies
3. Service Bundles allow the addition of new functionality over services extensibility and composition
Operating*System
Java*VM
Felix*OSGi
Core%Bundles Adapter%Bundles Service%Bundles
Datap
oint*API
RES
T*Wrapp
er
PubS
ub*W
rapp
er
Logg
ing
Prot
ocol*In
teg.
KNX
X10
iLight
Rem
.*Sen
sing
Data*Aqu
isition
Scen
arios
…
Config.*Files
DB
Figure 5.4: OSGi Level SW Components Overview. SW components follows the concept of modularity,where each piece of software is contained in a OSGi bundle.
The final OSGi services architecture of the implemented system is depicted in Figure 5.5. The
architecture notation is also described in Table 5.3 on the following page. The implemented architecture
was conceived having in mind that all the services are exposed using the same interface, the Datapoint
Connectivity API. Lower level components are service providers and of higher level components that are
service consumers. Finally, applications are only service consumers using the Datapoint Connectivity
REST API.
47
Roles Notation Symbol Description
Service InterfacesThe way a service is exposed to the upper layers of a given architecture, simplifying the interaction with the system’s components.
Service Consumers
Any entity that depends on a given service is called a consumer. To represent this, the arrow that connects the entity (an orange circle) to the service registry (a yellow triangle) is attached to the non-angled side of the triangle.
Service Providers
Any entity implementing a service is a service implementer. Every implementer must register its offered services so that it can be acknowledge by consumers of its presence. To represent this implementers have an arrow connecting to a corner of a service registry’s triangle.
Service Listeners
A listener is an entity that receives notifications concerning a given service registry every time a service implementer registers, updates or removes himself from the registry. A service registry can have an arbitrary number of listeners associated. Listeners are responsible for managing the service consumers behavior concerning service registry updates.
Service
Consumer
get
Provider
register
Listenerlistens
Table 5.3: OSGi Services Architecture Notation used to represent the OSGi services architecture andthe relations that support it.
5.6 Lessons Learned
The lessons learned during the implementation phase comprised in a set of best practices regarding
the modular development of software. Modular programming allows to separate the functionality of soft-
ware into independent modules, improving the maintainability of software. Modularity is an architectural
principle that starts at design time. Modules and relationships between modules have to be carefully
identified as soon as possible in the design of this kind of architectures. Then, you can also use the
right tools that enforce and supports the modularity, such as Java object-oriented programming and the
OSGi Framework. Such tools are very helpful in the task of developing modular solutions because the
enforce module isolation, enforce and clarify module dependencies, and provide a services framework
to consume modules. Enforcing a module isolation is making sure that other modules are not using
internal classes. Module should always only be used by an explicitly defined API. Enforcing module
dependencies is making sure that modules only depend on a well defined set of other modules. Service
is the basic element of modular applications, so you can use and extend the existing OSGi Frameworks
APIs to streamline your application modularity.
48
Datapoint API
KNX Adapter
register
Datapoint API
X10 Adapter
register
Datapoint API
Modbus Adapter
register
Datapoint API
iLight Adapter
register
Protocol Integration
get get get get
AdaptersListener listens
Datapoint API
register
Remote Sensing & Actuation
get
Datapoint API
register
Data Acquisition
get
History Data
StorageData
Querying
get
Datapoint API
register
Datapoint API
registerget get
Alarms & Events
Datapoint API
register
ScenariosMngmt
Datapoint API
register
Scheduling
Datapoint API
register
getgetget
Applications
REST API
REST API
REST API
REST API
REST API
REST API
get
get
get
getget
get
Direct Actuation and Data Access
Resources Connectivity
AutonomousActuation
ServicesExposition
Figure 5.5: OSGi Services Architecture following the OSGi Services Notation presented in Table 5.3.Higher level services are implemented using lower level services according to the desired level of depen-dencies and abstraction. The lower ones corresponds to the services that abstracts the communicationwith real resources such as devices and sensors. Then these services are consumed and composedinto higher-level services that are also exposed and consumed by Web Service applications.
49
50
Chapter 6
Evaluation
The evaluation required to be performed under conditions that enabled the testing of our solution ca-
pabilities, such as flexibility, usability and extensibility mechanisms. The comprehensive evaluation of
Service-Oriented Architectures is a rather challenging and is not easy to achieve. These architectures
specifications are complex and sometime they not accomplish in all possible scenarios. A successful
evaluation depends also on making the right architectural choices.
In this case, we choose a scenario-based software architecture evaluation, which is also comple-
mented by two case-studies. The proposed solution is validated by the evaluation of the Service Oriented
Architecture proposed in Chapter 4 and also by the evaluation of Service Layer Middleware implemen-
tation fully integrated with existing BAS technologies installed in IST Taguspark building. Automation
devices were installed in several office rooms, featuring a number of sensors and actuators, which were
used to implement software modules and services owned by developed middleware platform. This mid-
dleware also sustain intelligent automation and energy management applications that drive the control
of various electrical devices inside building offices, such as heating, HVAC, lighting, and also, the control
of shading system available on IST Taguspark building facade.
6.1 Evaluation Plan and Methods
This work consisted in the design and development of a service-oriented architecture for BEMS. Since
there is no reference model of a SOA for BEMS, it is not possible to compare the results of our solution
with another one. Therefore, our evaluation is based on an early software architecture evaluation that
consists in a Scenario-based Software Architecture Evaluation complemented by two case-studies:
(i) Case-study 1: An empirical evaluation of the implemented prototype: the IST SmartOffice
(ii) Case-study 2: The development and evaluation of energy consumption prediction Services for IST
Taguspark building
The methodology and the results achieved are described in the following sections.
51
6.2 Scenario-based Software Architecture Evaluation
Software architectural evaluation determine properties of software architectures and architectural styles
by analyzing them. The architectural evaluation verifies architectural decisions against problem state-
ments and requirement specifications. It determines the degree to which a software architecture or an
architectural style satisfies its quality requirements.
There are several proven methods for evaluating an software architecture [Roy and Graham, 2008],
such as early and late evaluation methods. Regarding early evaluation, a Scenario-based evaluation
method are being applied in order to make sure that the architecture exactly meets all requirements
before its implementation. Presented solutions in related work were evaluated in similar ways.
Regarding SOA evaluation techniques, there is one that stands out by several software engineering
institutes, the ATAM (Architecture-based Tradeoff Analysis Method) [Kazman et al., 2000, Clements
et al., 2001, Bianco, 2007, Roy and Graham, 2008, Szwed et al., 2013].
ATAM is an early scenario-based method for software architecture evaluation developed at SEI (Soft-
ware Engineering Institute) [Kazman et al., 2000]. Considering many different quality goals ATAM is
capable of capturing the interaction between them, setting goal dependencies and assessing if the pro-
posed system architecture can satisfy those goals.
Summarizing, the greatest benefit from the ATAM methodology is an early identification of risks,
which can consequently result in appropriate mitigation actions introduced before the software is fully
designed and implemented, thus at lower cost. ATAM multi-step system analysis procedure includes
detailed risks filtration, sorting and risk reducing processes. In the first place each risk is classified
into particular risk themes. The impacts, extracted from those risk themes, are afterwards linked with
business drivers or an architectural plans. If one of risk theme impacts requires a new business driver
definition, a set of quality attributions is made. That also leads to a new scenario developed, which
should be considered during the next iteration of the process: a scenario of interaction of one of the
stakeholders with the system. On the other hand, when any risk theme impact requires a new archi-
tectural plan definition, an architecture approach is being created for subsequent software architecture
change.
The ATAM process also includes development team interactions. The whole ATAM process typically
includes the following steps:
Steps Description
1-3 Presentation of the ATAM, Business Drivers and Architecture4 Architectural approaches identification - currently user approaches, without analysis
5Quality attributes collecting. All those attributes should be gathered in an attribute utility tree. It will describe compromises between system utility parameters, such performance, security, usability, availability etc.
6 Architectural approaches analysis - using knowledge established in step 57 Scenarios prioritizing during a voting process8 Architectural approaches analysis - step 6 repetition, but with a scenario priorities knowledge used9 Results
Table 6.1: ATAM process steps [Kazman et al., 2000]
52
6.2.1 Summary of Business Drivers
For the research purpose, the main Business Driver is the development of a novel architecture based
on SOA paradigm, which enhance interoperability and extensibility of Building Automation solutions.
But for the industrial point of view, the Business Drivers are all companies that develop Building
Automation software and hardware, or all customers interested in using this architecture in their buildings
and would like to benefit with the integration of BAS protocols diversity and the easy integration with
existent IT with lower OPEX rates, because they are no longer dependent on manufacturers. CAPEX
rates will also decreased, because they no longer need to purchase proprietary software associated
with the management of automation technology.
On top of this architecture is possible to develop new features from existing ones, and then adapt
them to the global functionalities of the company or client business needs.
In the environment of the development of this architecture there are some technical constraints re-
lated to the need to create adapters and mediators for the various automation protocols existing in mar-
ket. Some of them are proprietary, and we will need to use some techniques to abstract the technical
details of protocols and their operation modes in order to get the most of its functionality.
6.2.2 Summary of the Architecture
The architecture is already explained in the Solution chapter of this document, namely in Section 4.1,
4.2 and 4.3. An architecture summary is also available in Section 4.4.
6.2.3 Quality Attribute Utility Tree
The utility tree provides a vehicle for translating the quality attribute goals articulated in the business
drivers presentation to “testable” quality attribute scenarios.
The scenarios are prioritized along two dimensions: [importance to the system, perceived risk in
achieving this goal]. These nodes are prioritized relative to each other using quantitative rankings such
as High (H), Medium (M), and Low (L).
Quality Attribute: Interoperability
• Scenarios:
1. Internal services must be able to discover and directly communicate with devices, and con-
sume the services they offer (H,M)
2. Business logic must be able to executed on applicational services and take decisions not only
based on its local information but also on information provided by the devices (H,H)
3. Automatic service discovery to dynamically access device services without having explicit
task knowledge and the need of a priori binding (H,M)
4. Implementation of gateways and service mediators to allow support and integration of the
non-web services enabled devices. (H,L)
53
5. When a new field-bus protocol is installed in the building, the devices services must be avail-
able without downtimes. (H,M)
Quality Attribute: Modifiability
• Scenarios:
1. Provides a basic support infrastructure to mediate issues related to future services implemen-
tation, which will be installed, updated, deleted, started and stopped (H,L)
2. Allows the development of more sophisticated services on top of generic ones, therefore
allowing add-ons for enhanced functionality (H,M)
3. The system is designed regarding the modularity property in order to be decomposed into a
set of cohesive and loosely coupled modules (H,H)
Quality Attribute: Performance
• Scenarios:
1. Utilization of optimization techniques in order to decrease the response time of reading data
from sensors or obtain the status of the appliances. E.g. the current state of a device must
be obtained from de history data storage DB instead from the real device (H,M)
2. Should be possible to query the historical data of any device of the system in due time (H,H)
Quality Attribute: Availability
• Scenarios:
1. It may be possible to add redundant components to the system in order to mask failures or
timeouts (M,H)
2. If a failure occurs in a field-bus device, an alarm is generated to the facility manager, and all
other devices still in operation. (H,M)
3. Deployment of new software modules must not stop the application and they must be available
to use immediately (H,H)
Quality Attribute: Testability
• Scenarios:
1. At the development phase the Unit Tests regression must be executed without failures. (H,L)
2. There must be some mechanisms to detect malfunction situations from the analysis of the
historical and logging data. (H,H)
Quality Attribute: Usability
• Scenarios:
1. On a change of device state using a service, the delay between the real state change and the
service notification must be low. (H,M)
2. On a change of device state using a wall switch, the delay between the real state change and
the service notification must be low. (H,H)
54
6.2.4 Scenarios Prioritization
Next, is shown the scenarios that were collected by a brainstorming activity. After the scenarios gener-
ation they were prioritized according to their relevance to the architecture objectives:
1. Back end services must be able to discover and directly communicate with devices, and consume
the services they offer
2. Provide a basic support infrastructure to mediate issues related to future services implementation,
which will be installed, updated, deleted, started and stopped
3. Automatic service discovery to dynamically access device services, without having explicit task
knowledge and the need of a priori binding
4. Implementation of adapters and service mediators to allow support and integration of the non-web
service enabled devices
5. Allow the development of more sophisticated services on top of generic ones, therefore allowing
add-ons for enhanced functionality
6. Utilization of optimization techniques in order to decrease the response time of reading data from
sensors or obtain the status of the appliances
7. On a change of device state using a wall switch, the delay between the real state change and the
service notification must be low.
6.2.5 Analysis of Architectural Approaches
Scenarios from the utility tree and the scenario prioritization process were examined in detail the IST
SmartOffice Architecture. The scenarios that were examined are listed in the previous section.
The use of component framework, such as OSGi, enables the creation of highly modular and dynamic
systems with the support of service oriented architectures trough a service registry layer. The OSGi
has proven functionality to handle with modular services, and also helps with the services of life-cycle
management. A trade-off is that it would take a long time to refactor building automation control software
into a modular architecture.
Another trade-off is the additional effort to generate adapters and mediators to support and integrate
non-web service devices. The utilization of a common protocol, defined by an API will help to reduce
this effort and also allows more interoperability and reutilization of existent components.
In order to expose those services to the world, it is necessary to develop some REST or SOAP
wrappers, with the view to make them easily available to client applications.
55
6.2.6 ATAM evaluation results
The analysis of architectural approaches by applying selected scenarios and the ensuing discussions
surfaced a set of risks, sensitivities, and trade-offs:
Collected Risks
1. We are dependent on a component framework (OSGi). Exists the possibility of the framework stop
being supported and a lot of functionality become legacy, given the new trends and market needs
2. Many manufacturers of BAS may not accept this new architecture, and may difficult the provision
and support of new features
3. Some specific technologies may have some limitations, which can not completely validate the
requirements. E.g. the X10 protocol does not guarantee delivery of messages, which the state of
device may be inconsistent with the state of the system
4. Perform the analysis of historical data in order to detect malfunction situations can generate a high
rate of false positives.
Collected Sensitivities
1. The service performance and scalability depends on BAS hardware performance.
2. We are depending on the quality of sensors data, because eventually there are associated rates
of errors and failures.
Collected Trade-offs
1. Using the same Datapoint Connectivity API to implement all system services can simplify the
usability of the overall system, but also a greater effort is needed to all services meets all the API
specification.
2. Using more than one API for the different services will simplify the implementation of each ser-
vice, but it will reduce drastically the usability of the system. The user has to know all the APIs
specification to interact with the available services.
56
6.3 Case-study 1: IST SmartOffice Prototype Evaluation
With the intention of evaluate the solution and also validate the proposed architecture, the implemented
software is integrated in a real-world setting: the IST Taguspark building. IST Taguspark building is a
higher education and research facility. It hosts classes, teacher and researcher offices, and research
areas. The building is open 24/7 most of the year with exception of some holidays. The building con-
sists of several studding rooms, a library opened 24/7 and laboratories with special equipment (eg. a
Telecommunications lab.). There is low regularity on the activities of this building. Peaks of activity occur
during classes, divided in 2 semesters along the year. Times of lower occupancy occur during vacation,
when both students and researchers are absent. On a weekly view, weekends are the periods of lower
occupancy, but still with some activity, since some students use the premises to study during that time.
Given the building dimensions, there was a need to equip some areas with automation technolo-
gies to allow the efficient control of the environmental conditions within the building. Such lights, HVAC
and shadows, increasing the occupants comfort and the global energy savings. Currently there is no
management platform that controls the different technologies in an unified way. Our solution aims to
address this lack, using service oriented design to incorporate the heterogeneous environment of tech-
nologies available.
6.3.1 Automated Building Areas
Location Equipment
KNX equipment: 1 KNX power source, 1 light control module, 2 control panels, 1 presence sensor, 1 lux sensor, 1 USB-KNX gateway, 1 KNX ballast
X10 equipment: 1 RS232 Gateway, 2 light module, 1 appliance module
LIFX equipment: 1 LIFX Wireless Bulb
EnergyLab KNX solution: 1 HVAC control module, 1 control panels (touchscreen), 8 ballasts, 1 moisture sensor, 1 door lock, 1 presence sensor, 3 blinds motors, 2 KNX-IP Gateways
Nucleus 14 KNX solution: 16 lighting control circuits, 13 HVAC control modules, 13 control panels, 3 movement sensors, 1 KNX-IP Gateway
Library iLight solution: 40 DALI Ballasts (36W), 16 DALI Ballasts (18W), iCAN Module, relays interface, temperature, humidity and CO2 sensors
A4 iLight solution: 18 DALI Ballasts, iCAN Module, Relays Interface, Temperature, humidity and CO2 sensors, scenario selection panel
Weather station KNX solution: 1 precision radiation sensor, 1 rain sensor, 1 outdoor sensor (brightness, wind and temperature)
Rest of building INOV energy meters: 8 INOV Energy Meters IP
Lab 1-42
Table 6.2: Automated Building Areas Equipment.
The building offers various equipment BAS across their floors, areas and spaces. Table 6.2 describes
all installed equipment used in the integration of the prototype. The locations of the equipment are: Lab-
oratory 1-42, EnergyLab (Lab 1-52), Nucleus 14 (all offices), Library, Amphitheater A4, and a weather
station on the roof of the building. There are also some energy smart meters installed along the building
that measure the energy consumption of some areas.
57
6.3.2 Building Fieldbus Technologies Integration
In order to evaluate the solution extensibility and heterogeneity handling, it was required to develop
several fieldbus adapters to promote different technologies integration in a heterogeneity environment.
This protocol integration is supported by the middleware, through the Protocol Integration Adapter. The
BAS equipment installed in Taguspark Building enabled the development of device drivers that interact
with major automation devices of the building. The middleware usability and functionality towards the
device drivers implementation could be assessed through the development of such drivers.
In Figure 6.1, the infrastructure diagram of IST building describes all fieldbus technologies evolved,
such as KNX, iLight, X10, LIFX, and INOV Meters:
KNX Energy Lab
KNXGateway
TCP/IP
Weather Station
VLAN
KNX N14 Offices
KNXGateway
TCP/IP
Modbus Energy Meters
INOVGateway
TCP/IP
iLight Gateway (EG2)
TCP/IP iLight/CAN Amphitheater
Library
RS232X10 Devices
TCP/IP - RS232Interface
TCP/IP
X10Gateway
X10
WLAN
TCP/IP LIFX Lamps802.11
Figure 6.1: Fieldbus Infrastructure diagram.
In the next sections are detailed the technologies discussed, the architecture of each adapter, the
challenges encountered in their development, and some limitations. At the end of each section is pro-
vided a summarized table of the supported and provided features by default technology (Supported),
the integrated features (Integrated), the new features support after integration (After Integration) and
their functionality coverage against the standard functionality. The coverage is obtained by the following
58
expression:
coverage =|Y es|
|No|+ |Y es|∗ 100% (6.1)
KNX Integration
KNX, formerly known as European Installation Bus (EIB), is a building control communication system
that connects sensor, actuator and controller devices. KNX system is an example of a fully decentralized
complex Home and Building Automation System (HBAS).
KNX philosophy bases on the concept of functional block, a structure that abstracts the data points
and behavioral aspects of a device. Each functional block has exactly one device, although a device can
relate to more than one functional block. It consists on a set of data points and the behavioral aspects
concerning the device. Data points can be input/output (representing the devices inputs and outputs)
or parameters concerning the application, like a setpoint or an alarm. Data points can be logically
connected to each other through Group Addresses. This connection is independent from the devices
physical location. If a data point changes its value in a given moment, all the data points sharing the
binding with it will be informed of the new value. For example, consider a light switch bounded to a
rooms luminaries. If the switch changes its state from OFF to ON, the new value will be propagated to
the luminaries, making them turn on.
There are some KNX devices called gateways, that converts the KNX protocol messages to another
protocol type, such as TCP/IP or USB. These gateways have the ability to listen to all messages ex-
changed on the bus, and can also simultaneously inject new messages on the KNX network. Thus, we
can use KNX in a centralized control way.
During the integration phase, it was necessary to study the protocol in detail and also the existing
software libraries in order to support the integration process. One of the most significant libraries for our
environment, was the Calimero API1. Calimero is a Java library for KNX/EIB applications that provides
an API for the network services and data encodings defined in the KNX standard.
The supported Calimero features are:
• KNXnet/IP tunneling (with bus monitor mode), routing, local device management
• FT1.2 serial access
• Easy-to-use process communication (group communication)
• KNX property access
• Datapoint type and property type translation
• Network message buffering for state and command-based datapoint values
• Network configuration storage, with possibility to import ETS 4 project files
The most important feature for our implementation was the process communication with KNX group
addresses. The process communicator interface uses high level interaction based on Java data types
and blocking read/write functionality. The Process Communicator API provided by Calimero are specified
in Appendix A.4.1Calimero Java API - http://calimero.sourceforge.net
59
DatapointConnectivityKNXService2(Adapter)
KNXConfigManagerKNXGatewayDriver
Datapoint Connectivity API
{ "knx158light1": { "description": "EnergyLab Light Blackboard", "datatype": "PERCENTAGE", "accessType": "READ_WRITE", "precision": 0, "scale": 0, "smallestReadInterval": 0, "currentSamplingInterval": 0, "changeOfValue": 0, "hysteresis": 0, "displayMax": 0, "displayMin": 0, "readingMax": 0, "readingMin": 0, "readCacheSize": 0, "readAddress": "0/7/1", "writeAddress": "0/1/0", "gatewayAddress": "172.20.70.147" },
KNXConfig.json
Calimero2API
KNX Gateways
TCP/IP
Figure 6.2: KNX technology integration Adapter. The Calimero API provides an abstraction to KNXGateways protocol communication. The JSON file with KNX configuration allows the adapter to know allgateway addresses and devices group addresses that are mapped automatically into datapoints.
During the development of the adapter presented in Figure 6.2, it was necessary to adapt our Data-
point API to Process Communicator API provided by Calimero, because we have different data types:
• BYTE 1: Not applicable.
• BYTE 2: readFloat(address, false)
• PERCENTAGE: readUnsigned(address, ProcessCommunicationBase.SCALING) | write(address,
value, ProcessCommunicationBase.SCALING)
• SWITCH: readBool(address) | write(address, value)
The notification alarms and events supports is done from a ProcessListener API provided by Cal-
imero, that notifies all new events that occurs in the KNX bus.
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification Yes Yes YesAlarm Notification Yes Yes Yes
Historical Data No No YesScheduling No No YesScenarios No No YesCoverage 50% 50% 100%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No NoAlarm Notification No No No
Historical Data No No YesScheduling No No YesScenarios Yes Yes YesCoverage 33% 33% 67%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No YesAlarm Notification No No Yes
Historical Data No No YesScheduling N/A N/A N/AScenarios N/A N/A N/ACoverage 25% 25% 100%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No NoAlarm Notification No No No
Historical Data No No YesScheduling No No YesScenarios No No YesCoverage 17% 17% 67%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No NoAlarm Notification No No No
Historical Data No No YesScheduling No No YesScenarios No No YesCoverage 17% 17% 67%
KNX Functionalities Integration
iLight Functionalities Integration
INOV Functionalities Integration
X10 Functionalities Integration
LIFX Functionalities Integration
Table 6.3: KNX Functionalities Coverage.
After the integration and adapter development process, observing Table 6.3 we can achieve the
100% of provided functionalities, even when the concrete technology only supports 50% of features.
60
iLight Integration
iLight2 is a control system that can maintain the optimum lighting balance to make the workspace com-
fortable and productive for occupants while deliver easy to use management tools. iLight technology
allows enhance visual environment by taking control of several types of artificial light sources with bet-
ter lighting control. This technology maximize control and energy savings. When trying to improve the
energy efficiency of a project, lighting control is an ideal place to start. Energy savings can be made
through use of intelligent sensors and photocells so that lighting is only used when required. Limited use
of the systems and controlled dimming can extend lamp life, reduce power requirements and minimize
maintenance costs.
iLight manufactures a range of integration tools to assist with the construction and configuration of
the iCAN network and for interfacing with external system components.
The EG2 (Ethernet Gateway) provides a connection between an iCAN network and an Ethernet LAN.
This allows an user to control and configure the iLight system using iCANsoft software. The EG2 is also
the host for the iLight remote software including a REST Server.
DatapointConnectivityiLightService2(Adapter)
iLight2ConfigManager
iLightDriver
Datapoint Connectivity API
{ "knx158light1": { "description": "EnergyLab Light Blackboard", "datatype": "PERCENTAGE", "accessType": "READ_WRITE", "precision": 0, "scale": 0, "smallestReadInterval": 0, "currentSamplingInterval": 0, "changeOfValue": 0, "hysteresis": 0, "displayMax": 0, "displayMin": 0, "readingMax": 0, "readingMin": 0, "readCacheSize": 0, "readAddress": "0/7/1", "writeAddress": "0/1/0", "gatewayAddress": "172.20.70.147" },
iLightConfig.json
EG22REST2Client
TCP/IP
EG22REST2Server
iLight2Driver
iCAN EG2 Gateway
Ethernet
EG22Protocol
Figure 6.3: iLight technology integration Adapter. The iLight EG2 provides an abstraction to CAN proto-col communication. The JSON file with iLight configuration allows the adapter to know the EG2 address,all devices addresses and scenarios that are mapped automatically into datapoints.
2iLight - http://www.ilight.co.uk
61
The EG2 provides the following REST API:
• GET /eg2/requestchannellevel/area/channel - get the lighting intensity of a channel in a certain
area
• GET /eg2/requestcurrentscene/area - get the active scenario for a certain area
• GET /eg2/savescene/area/scene - save a scenario for a certain area
• GET /eg2/selectscene/area/scene/fade - select a scenario for a certain area with a fade interval
• GET /eg2/setchannellevel/area/channel/level/fade - set the lighting intensity level of a channel
in a certain area with a fade interval
The EG2 REST API has the limitation of not notifying the occurrence of new events, so our adapter
has to check the devices state from time to time. One advantage of this technology is scenarios native
support. So our scenarios service can map directly the iLight scenarios service, reducing the adaptation
overhead. As shown in Table 6.4, the after the integration process, the iLight technology came to support
new functionalities, covering them by 67%.
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification Yes Yes YesAlarm Notification Yes Yes Yes
Historical Data No No YesScheduling No No YesScenarios No No YesCoverage 50% 50% 100%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No NoAlarm Notification No No No
Historical Data No No YesScheduling No No YesScenarios Yes Yes YesCoverage 33% 33% 67%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No YesAlarm Notification No No Yes
Historical Data No No YesScheduling N/A N/A N/AScenarios N/A N/A N/ACoverage 25% 25% 100%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No NoAlarm Notification No No No
Historical Data No No YesScheduling No No YesScenarios No No YesCoverage 17% 17% 67%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No NoAlarm Notification No No No
Historical Data No No YesScheduling No No YesScenarios No No YesCoverage 17% 17% 67%
KNX Functionalities Integration
iLight Functionalities Integration
INOV Functionalities Integration
X10 Functionalities Integration
LIFX Functionalities Integration
Table 6.4: iLight Functionalities Coverage.
62
INOV Meters Integration
INOV3 provides an agile and flexible organization, oriented to creating technological skills and establish-
ing cooperation links with various economic entities (universities, industries, companies and Telecommu-
nications Operators). For this purpose, INOV intends to act as an intermediary between the University
and the Industry, basing on the dedicated cooperation with the University in order to provide sustained,
consistent and innovative solutions addressing the problems and challenges faced by our Partners.
Therefore, the INOV developed a three-phase energy REST API, which abstracts the internal protocol:
the Modbus. The Taguspark building was a pilot in this prototype and some of them were installed in
the electric panels of building. They measure the voltage (V), the current (A) and a power factor of each
phase cable, as we can see in the following JSON response example:
1 {
2 ”id”:”C8:A0:30:AC:3F:AA”,
3 ”name”:”Nucleo 14”,
4 ”timestamp”:1412945799,
5 ”phases”:{
6 ”1”:{
7 ”voltage”:236,
8 ”current”:1.3,
9 ”powerfactor”:0.59
10 },
11 ”2”:{
12 ”voltage”:235,
13 ”current”:0.7,
14 ”powerfactor”:1.00
15 },
16 ”3”:{
17 ”voltage”:236,
18 ”current”:0.8,
19 ”powerfactor”:1.00
20 }
21 }
22 }
The JSON response also provides the location name of the meter, the Timestamp of the last measure
and the meter identifier.
The energy consumption is given by the following expression, where consumption is expressed in
KW.h, V is the voltage, A is the current and ψ the power factor of each phase:
Consumption = (V1.A1.ψ1) + (V2.A2.ψ2) + (V3.A3.ψ3) (6.2)
As this technology is not considered a BAS because it only provides sensor data gathering. However,
it adds a great value to the final solution because it turns possible to analyze the energy consumption
and how building energy is used.
3INOV - INESC Inovacao - http://www.inov.pt
63
DatapointConnectivityINOVMeterService4(Adapter)
INOVMeter4ConfigManager
INOVMeterDriver
Datapoint Connectivity API
{ "knx158light1": { "description": "EnergyLab Light Blackboard", "datatype": "PERCENTAGE", "accessType": "READ_WRITE", "precision": 0, "scale": 0, "smallestReadInterval": 0, "currentSamplingInterval": 0, "changeOfValue": 0, "hysteresis": 0, "displayMax": 0, "displayMin": 0, "readingMax": 0, "readingMin": 0, "readCacheSize": 0, "readAddress": "0/7/1", "writeAddress": "0/1/0", "gatewayAddress": "172.20.70.147" },
INOVMeterConfig.json
INOVMeter4REST4Client
TCP/IP
INOVMeter4REST4Server
Modbus4Master4Driver
Modbus Slave Sensors
Modbus
Modbus4Protocol
Figure 6.4: INOV meters integration Adapter. The INOV Meter REST API provides an abstraction toModbus protocol communication. The JSON file with some meters address configuration allows theadapter to know all meter addresses and then map them automatically into datapoints.
This technology only handles with sensors data, so we not be able to integrate some functionalities,
such as scenarios and scheduling services. However, we integrated all other functionalities, reaching a
coverage of 100%, as shown in Table 6.5.
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification Yes Yes YesAlarm Notification Yes Yes Yes
Historical Data No No YesScheduling No No YesScenarios No No YesCoverage 50% 50% 100%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No NoAlarm Notification No No No
Historical Data No No YesScheduling No No YesScenarios Yes Yes YesCoverage 33% 33% 67%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No YesAlarm Notification No No Yes
Historical Data No No YesScheduling N/A N/A N/AScenarios N/A N/A N/ACoverage 25% 25% 100%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No NoAlarm Notification No No No
Historical Data No No YesScheduling No No YesScenarios No No YesCoverage 17% 17% 67%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No NoAlarm Notification No No No
Historical Data No No YesScheduling No No YesScenarios No No YesCoverage 17% 17% 67%
KNX Functionalities Integration
iLight Functionalities Integration
INOV Functionalities Integration
X10 Functionalities Integration
LIFX Functionalities Integration
Table 6.5: INOV Functionalities Coverage.
64
X10 Integration
X10 is a popular protocol for Home Automation System (HAS) that first appeared in 1970’s. This system
primarily uses the power line wiring as communication bus for signaling and control, between the many
devices. It is capable to connecting a maximum number of 256 devices in the same environment.
Usually, X10 devices plug into power outlets where other household appliances are plugged. The system
is mostly used for remote controlling, depending on the users direct inputs, using simple controllers.
Configuration is simple, the user will only have to manually select a letter from A to P, corresponding to
the house address, and a number from 1 to 16, corresponding to the device address, and commands
are pre-defined.
An API for interacting with X10 home automation technology, created by J.Peterson4 was used. He
provided a X10 TCP Server compatible with CM11A and CM15 gateway protocols. X10 commands are
sent to the service via a TCP connection. A X10 TCP Client connects to the host running the service on
the configured port. Commands format takes the following form:
1 commands = +( ”(” command ”)” )
2 command = house−code key−code [ extra−data ]
3 house−code = ”A”
4 | ”B”
5 | ”C”
6 |(...)
7 | ”P”
8 key−code = ”01” ; Unit 1
9 | ”02” ; Unit 2
10 | ”03” ; Unit 3
11 |(...)
12 | ”16” ; Unit 16
13 | ”A0” ; All Units Off
14 | ”L1” ; All Lights On
15 | ”ON” ; On
16 | ”OF” ; Off
17 | ”DI” ; Dim
18 | ”BR” ; Bright
19 | ”L0” ; All Lights Off
20 | ”HR” ; Hail Request
21 | ”HA” ; Hail Acknowledge
22 | ”D1” ; Preset Dim 1
23 | ”D2” ; Preset Dim 2
24 | ”EX” ; Extended Data
25 | ”S1” ; Status On
26 | ”S0” ; Status Off
27 | ”SR” ; Status Request
28 extra−data = Extra data is key code specific. Presently, ’DI’
29 and ’BR’ use extra data. The extra data is a number
30 from 1 − 22 to indicate the number of dims.
4J.Peterson - X10 Java Protocol Library - http://www.jpeterson.com/2007/05/29/x10-api-source-code/
65
Examples of X10 commands:
• Turn on device A3: "(A03)(AON)"
• Turn all the lights with the house code E: "(EL1)"
• Adjusting the light intensity of the device B13 to 50%: "(B13)(BDI11)"
DatapointConnectivityX10Service2(Adapter)
X10ConfigManagerX10Driver
Datapoint Connectivity API
{ "knx158light1": { "description": "EnergyLab Light Blackboard", "datatype": "PERCENTAGE", "accessType": "READ_WRITE", "precision": 0, "scale": 0, "smallestReadInterval": 0, "currentSamplingInterval": 0, "changeOfValue": 0, "hysteresis": 0, "displayMax": 0, "displayMin": 0, "readingMax": 0, "readingMin": 0, "readCacheSize": 0, "readAddress": "0/7/1", "writeAddress": "0/1/0", "gatewayAddress": "172.20.70.147" },
X10Config.json
J.Peterson2X102222TCP2Client
TCP/IP
J.Peterson2X102TCP222Server
RS2322Driver
CM11 Gateway
RS232
X102Protocol
J.Peterson2X102TCP222Server
RS2322Driver
CM15 Gateway
USB
X102Protocol
TCP/IP
Figure 6.5: X10 technology integration Adapter. The J. Peterson Library provides an abstraction to X10Gateways protocol communication, the CM11 and CM15. The JSON file with X10 configuration allowsthe adapter to know all gateway addresses and devices addresses that are mapped automatically intodatapoints.
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification Yes Yes YesAlarm Notification Yes Yes Yes
Historical Data No No YesScheduling No No YesScenarios No No YesCoverage 50% 50% 100%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No NoAlarm Notification No No No
Historical Data No No YesScheduling No No YesScenarios Yes Yes YesCoverage 33% 33% 67%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No YesAlarm Notification No No Yes
Historical Data No No YesScheduling N/A N/A N/AScenarios N/A N/A N/ACoverage 25% 25% 100%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No NoAlarm Notification No No No
Historical Data No No YesScheduling No No YesScenarios No No YesCoverage 17% 17% 67%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No NoAlarm Notification No No No
Historical Data No No YesScheduling No No YesScenarios No No YesCoverage 17% 17% 67%
KNX Functionalities Integration
iLight Functionalities Integration
INOV Functionalities Integration
X10 Functionalities Integration
LIFX Functionalities IntegrationTable 6.6: X10 Functionalities Coverage.
Given the limitations of the technology, we can not read the device status because communication
is unidirectional. This technology also does not guarantee the delivery of all messages in the channel.
In order to reduce the messages loss rate, our adapter duplicates the commands messages on sending
write operations. Table 6.6 shows the functionalities support coverage after integration.
66
LIFX Integration
LIFX is a recently developed innovative system made by a kind of light bulb that can be used for remote
control and automation purposes. LIFX is made of individual wi-fi enabled LED bulbs, that together form
a highly customizable and energy efficient illumination system. Each bulb is made of two communication
interfaces, a WLAN interface and a 802.15.4 wireless mesh interface. The LIFX bulbs can operate in two
modes, the gateway mode and the node mode. The difference between the two modes is that a LIFX bulb
in gateway mode is used to provide communication with many LIFX bulbs in node mode and to provide
an interface between the LIFX system and the local wireless router, allowing devices (e.g. smartphones)
on the network to remotely access the LIFX system. For the wireless router communication, the WLAN
interface is used, and for communicating between LIFX bulbs, the 802.15 interface is used. The purpose
of these two operation modes is mainly to explore the energy efficiency and signal range that mesh
networks provide, as well as to surpass the limitation for the number of devices that can be connected
to the wireless router. Users can perform simple control tasks such as toggle LIFX lamps on and off,
change color and dimming. For more complex tasks, the systems supports zoning and scheduling
functionalities, so groups can be created using the mobile application and schedule one of the mentioned
simple control tasks to a determined time instant or time period.
DatapointConnectivityLIFXService3(Adapter)
LIFXDriver
Datapoint Connectivity API
JLifx3API
LIFX Bulb Gateway
TCP/IP
LIFX Bulb Nodes
Figure 6.6: LIFX technology integration Adapter. The JLifx API provides an abstraction to LIFX bulbsprotocol communication. The JLifx also provides the configuration of available bulbs addresses that aremapped automatically into datapoints.
JLifx5 is a LIFX Java Library that supports the following generic commands:
1 scan − scan and discovery all LIFX gateway bulbs in the network and also all the bulbs nodes found.
5JLifx - http://robvanderleek.github.io/JLifx/
67
2 status <mac−address|all> − retrieve the bulb status information: name, MAC address, hue, saturation, brightness, kelvin,
3 dim and power.
4 switch <mac−address|all> <on|off> − switch the bulb status to ON or OFF.
5 color <mac−address|all> <color−name|rgb−hex−value> − sets a specified color to bulb.
6 blink <mac−address|all> [times] − blink the bulb a number of times.
7 rainbow <mac−address|all> − set the rainbow effect to bulb.
There are also an API to control each bulb individually, called IBulb, that are specified in Appendix A.5.
A good feature of this technology is that it is not necessary to know the configuration in advance,
because the LIFX protocol tracks all installed bulbs and the new ones. So, every time that a new bulb
is inserted, JLifx notifies our adapter, and new light will be automatically available as a new datapoint.
Table 6.7 shows the functionalities support coverage after LIFX integration.
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification Yes Yes YesAlarm Notification Yes Yes Yes
Historical Data No No YesScheduling No No YesScenarios No No YesCoverage 50% 50% 100%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No NoAlarm Notification No No No
Historical Data No No YesScheduling No No YesScenarios Yes Yes YesCoverage 33% 33% 67%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No YesAlarm Notification No No Yes
Historical Data No No YesScheduling N/A N/A N/AScenarios N/A N/A N/ACoverage 25% 25% 100%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No NoAlarm Notification No No No
Historical Data No No YesScheduling No No YesScenarios No No YesCoverage 17% 17% 67%
Supported Integrated After IntegrarionGrouping/Zoning Yes Yes YesEvent Notification No No NoAlarm Notification No No No
Historical Data No No YesScheduling Yes No YesScenarios No No YesCoverage 33% 17% 67%
KNX Functionalities Integration
iLight Functionalities Integration
INOV Functionalities Integration
X10 Functionalities Integration
LIFX Functionalities Integration
Table 6.7: LIFX Functionalities Coverage.
6.3.3 Summary and Discussion
From the analyses of the functionality coverage with the various fieldbus technologies integration with
existing services, we can conclude that our solution successfully addresses the SOA design principles of
modularity, extensibility and interoperability. As depicted in Table 6.8, majority of the functionalities were
supported technologies after the integration process, even when some of them have limitations and do
not support some functionalities by default. The technology complexity and the integration difficulty are
also compared in order to evaluate the technology ability to integrate with others.
Protocol KNX iLight INOV X10 LIFX
Functionality Coverage 100% 67% 100% 67% 67%
Complexity High High Medium Medium Low
Notifications Yes No No No No
Integration Dificulty Higher Medium Lower Lower Lower
Table 6.8: Summary of integrated technologies results. The table shows the functionality coverage inthe final solution after the integration process, the technology complexity over the developed adapter,the support of notifications and the difficulty encountered in the integration process.
Finally, we can prove that existent technologies and standards needs to be improved in order to cope
with SOA requirements by default, easing the integration process with other existing technologies.
68
6.4 Case-study 2: Energy Consumption Prediction Service
This case-study describes the construction and evaluation of energy consumption prediction services
for intelligent buildings based on their heterogeneous occupancy. The IST Taguspark facility is used
where building occupation based on WiFi network connections are compared in order to better predict
energy consumption of the building. We developed three services using these prediction models: linear
regressions, fuzzy systems and neural networks. With these new prediction services, becomes possible
to perform sensor data queries for future periods.
6.4.1 Energy Prediction Modeling Methods
There are several models to predict energy consumption, such as engineering, statistical and artificial in-
telligence methods [Zhao and Magoules, 2012]. Engineering methods generate rather complex models,
where it is necessary to specify the constituent materials of the building’s structure, as well the charac-
terization of all equipment inside. In this case we rejected the utilization of these models in advance due
to its complexity and worst probable outcomes [Neto and Fiorelli, 2008]. Thus we choose three models
based on historical data: one statistical, called linear regressions, and two artificial intelligence methods,
fuzzy systems and artificial neural networks.
6.4.2 Data used in Models
Prediction models are developed from a history dataset acquired from INOV Energy Meters readings,
and also from a occupancy estimation data stored in our History Data Storage Service. The following
sections detail the data used to development of prediction services.
0 500 1000 1500 2000 2500 300020
30
40
50
60
70
80
90
100
110
Samples (15 min)
En
erg
y C
on
su
mp
tio
n (
kW
h)
Figure 6.7: 15-min energy consumption from April 25th to May 31st, 2014, showing the energy con-sumption variation acquired from energy meters, with the highest peaks occurring at night and off-peaksduring the weekends.
69
Energy consumption dataset
Energy consumption data is collected by INOV Energy Meters installed in building. Energy consumption
data is acquired periodically and stored on the History Data Storage Service DB. Each measurement
corresponds to the average active power in kW of last 15 minutes, that is then converted into kWh.
Figure 6.7 shows the 15-min energy consumption of IST-T building, during 35 consecutive days.
Occupancy indicators dataset
Since IST-T building does not have occupancy sensors in the entrances, it is not possible to know
exact number of people inside. Therefore, an indirect indicator had to be found. The number of WiFi
connected users is related to the number of persons in a certain area. Martani Martani et al. [2012]
proposed this approach to track human occupancy and activity inside non-residential buildings. IST-T
building provides an extensive WiFi network accounting with a total of 54 WiFi APs available across the
3 floors, that provide Internet access to the entire building, as shown in Figure 6.8. This infrastructure
enables to estimate human occupancy at different levels of granularity. At the scale of the rooms, floors,
or buildings. Since this services aims at predicting the overall energy consumption of the building, we
will take into account the total WiFi connections of entire building. The Figure 6.9 shows the relation
between Wifi connections (occupancy) and the overall energy consumption of the building.
Figure 6.8: Building blueprint and Access Points distribution across IST-T floor 0.
These Wifi usage information is available from SNMP MIB Agents of the 54 Access Points. For that,
we had to develop an additional adapter to integrate SNMP Protocol, using the SNMP4J Java Library,
which acquires data periodically from all building network equipment via SNMP protocol. The SNMP
adapter are shown in Figure 6.10.
70
0 500 1000 150020
30
40
50
60
70
80
90
100
110
Occupancy (WiFi connections)E
nerg
y C
on
su
mp
tio
n (
kW
h)
(a)
Figure 6.9: Scattered plots between building occupancy indicators and energy consumption, showingthe WiFi connections and energy consumption relation.
DatapointConnectivitySNMPService2(Adapter)
SNMP2ConfigManager
SNMPDriver
Datapoint Connectivity API
{ "knx158light1": { "description": "EnergyLab Light Blackboard", "datatype": "PERCENTAGE", "accessType": "READ_WRITE", "precision": 0, "scale": 0, "smallestReadInterval": 0, "currentSamplingInterval": 0, "changeOfValue": 0, "hysteresis": 0, "displayMax": 0, "displayMin": 0, "readingMax": 0, "readingMin": 0, "readCacheSize": 0, "readAddress": "0/7/1", "writeAddress": "0/1/0", "gatewayAddress": "172.20.70.147" },
SNMPConfig.json
SNMP4J
SNMP
Access2Point
MIB
SNMP2Agent
Router
SNMP
MIB
SNMP2Agent
Figure 6.10: SNMP integration Adapter. The SNMP4J API provides an abstraction to SNMP protocolcommunication, which allows to retrieve data from networking equipment, such as Wireless AccessPoints.
6.4.3 Prediction Services Development
We built three prediction services for each above mentioned prediction methods: linear regressions,
fuzzy systems and neural networks. The models were developed using MATLAB Software from Math-
Works. After the development we integrated Matlab models into Java using the MATLAB Library Com-
piler. For linear regressions we used the Multiple Linear Regression. The fuzzy system was developed
using Sugeno-type Fuzzy Inference System (FIS) with Subtractive Clustering (SC) algorithms. Regard-
ing neural networks, a feedforward backpropagation model was applied. The number of neurons in the
hidden layer were varied in the experiments.
71
6.4.4 Experiments and Results
This section presents the models simulations and respective results, using the following prediction mod-
els: linear regressions, fuzzy systems and neural networks. We used 80% train and 20% test data, the
equivalent to 676 samples of 15-min test data, corresponding to ≈ 7 days (week-long) energy consump-
tion prediction.
The performance of all models is assessed for precision and recall by computing the Variance Ac-
counted For (VAF) and Mean Absolute Error (MAE) indexes over a testing set. The VAF measures the
percentage of variance between the two signals and can be expressed as:
Definition of consumption baseline – Case-study in a Portuguese University campus
Henrique R. M. L. Pombeiro Intelligent Decision and Control 11
automatically generated. With this, FCM clustering is then applied for the development of a fuzzy model with low variations of the predefined number of clusters from the number that was obtained from the previous SC fuzzy models.
Regarding neural networks, a feedforward backpropagation model was applied in this work. Few parameters were varied: the number of hidden layers (1 to 3), the number of neurons in each and the number of epochs. For each parameterization, the output may differ because several parameters like the neurons weight change in the development of the model and so 20 loops cycles were performed for each parameterization and the resulting performance was weighted. After that, the parameterizations with the highest performance are carefully addressed.
Finally, in both fuzzy and neural networks models, the stopping criterion that was defined was the mean squared error (MSE). The performance of all models is assessed with the values of Variance Accounted For (VAF), Mean Squared Error (MSE) and Mean Absolute Error (MAE), evaluating mostly the testing set. They can be expressed as:
𝑉𝐴𝐹 = 1 −𝑣𝑎𝑟(𝑦 − 𝑦 )𝑣𝑎𝑟(𝑦 ) × 100% (Eq. 3)
𝑀𝑆𝐸 =1𝑛 (𝑦 − 𝑦 ) (Eq. 4)
𝑀𝐴𝐸 =1𝑛
|𝑦 − 𝑦 | (Eq. 5)
Results and Discussion This section presents the discussion of the results from the developed models for:
x The amphitheater. x The library, dividing in the warm and in the cold season.
Amphitheater As already mentioned, the selected consumption data for this space is from25-02-2013 to 24-05-2013, totalizing 62 entries. The evolution of the addressed variables and electricity consumption for this space are displayed in Figure 6. This generally complements Figure 4.
(6.3)
The MAE measures the mean of absolute error values, and are expressed as:
Definition of consumption baseline – Case-study in a Portuguese University campus
Henrique R. M. L. Pombeiro Intelligent Decision and Control 11
automatically generated. With this, FCM clustering is then applied for the development of a fuzzy model with low variations of the predefined number of clusters from the number that was obtained from the previous SC fuzzy models.
Regarding neural networks, a feedforward backpropagation model was applied in this work. Few parameters were varied: the number of hidden layers (1 to 3), the number of neurons in each and the number of epochs. For each parameterization, the output may differ because several parameters like the neurons weight change in the development of the model and so 20 loops cycles were performed for each parameterization and the resulting performance was weighted. After that, the parameterizations with the highest performance are carefully addressed.
Finally, in both fuzzy and neural networks models, the stopping criterion that was defined was the mean squared error (MSE). The performance of all models is assessed with the values of Variance Accounted For (VAF), Mean Squared Error (MSE) and Mean Absolute Error (MAE), evaluating mostly the testing set. They can be expressed as:
𝑉𝐴𝐹 = 1 −𝑣𝑎𝑟(𝑦 − 𝑦 )𝑣𝑎𝑟(𝑦 ) × 100% (Eq. 3)
𝑀𝑆𝐸 =1𝑛 (𝑦 − 𝑦 ) (Eq. 4)
𝑀𝐴𝐸 =1𝑛
|𝑦 − 𝑦 | (Eq. 5)
Results and Discussion This section presents the discussion of the results from the developed models for:
x The amphitheater. x The library, dividing in the warm and in the cold season.
Amphitheater As already mentioned, the selected consumption data for this space is from25-02-2013 to 24-05-2013, totalizing 62 entries. The evolution of the addressed variables and electricity consumption for this space are displayed in Figure 6. This generally complements Figure 4.
(6.4)
Our modeling approach uses the indirect indicators that best correlate with energy consumption,
providing a better impact in the prediction performance. We evaluate these impact by training and
testing the generated models for best combinations of variables and comparing their VAF indexes.
The following Figures 6.11, 6.12, and 6.13 present the models performance and the results compar-
ison between real and predicted data.
0 100 200 300 400 500 60020
40
60
80
100
120
140
Samples (15 min)
En
erg
y C
on
su
mp
tio
n (
kW
h)
Real Consumption
Linear Regression Prediction
Figure 6.11: Linear Regression test results: predicted and real values shows a low correlation betweenthe data and consecutively, a weak prediction model quality. VAF=33.64%; MAE=12,28 KWh
Figure 6.14 shows the VAF and MAE values for each type of model, comparing the best performance
and the lowest error. The model that stands out for the best VAF and lower MAE index is the Fuzzy
System. The Neural Network model has identical performance and error values.
In summary, fuzzy systems and neural networks, shows the most suitable models in order to easily
predict a week-long energy consumption of a intelligent building based on occupancy variables, given
their performance indexes.
72
0 100 200 300 400 500 60020
40
60
80
100
120
140
Samples (15 min)
En
erg
y C
on
su
mp
tio
n (
kW
h)
Real Consumption
Fuzzy Prediction
Figure 6.12: Fuzzy test results: predicted and real values. There is a high similarity between the data,which explains the good model performance indexes. Nevertheless, the model is not exact at predictingconsumption during energy peaks over the night. VAF=74.94%; MAE=6,39 KWh
0 100 200 300 400 500 60020
40
60
80
100
120
140
Samples (15 min)
En
erg
y C
on
su
mp
tio
n (
kW
h)
Real Consumption
NN Prediction
Figure 6.13: Neural Network test results: predicted and real values, where there is a correlation betweendata, but the prediction is not very accurate in some ranges of data. VAF=72.30%; MAE=6,97 KWh
VAF (%) MAE (kWh)0
10
20
30
40
50
60
70
80
Linear Regression
Fuzzy System
Neural Network
Figure 6.14: VAF comparison (higher is better) and MAE (lower is better) values for distinct used meth-ods, summarizes the final performance of each energy consumption prediction service.
73
6.5 Discussion
During the evaluation phase, we defined some risks and trade-offs of this architecture, that helped to
redefine some requirements in order to deploy an improved system architecture.
Then, during the Case-Study 1 phase, that consisted in a integration process, the flexibility has
been evaluated through the implementation of several technology adapters through a common protocol
interface, the Datapoint Connectivity API. Our architecture proved to be quite capable to dealing with
heterogeneous environment of automation devices and technologies present in the building. Neverthe-
less, not all features have been integrated, given there are some limitations of the technologies, being a
risk factor that can make all the requirements is not fulfilled, as indicated in ATAM results.
Finally, in Case-Study 2, the energy prediction services development allowed us to prove the exten-
sibility of the global system, where the capacity of integration with different sources of information, can
deliver intelligent behavior functionalities using some data-mining techniques, such as the capacity of
predict future data based on the analysis of indirect factors obtained from different data sources.
At the end, we can conclude that our solution successfully addresses SOA for BEMS requirements
and principles initially defined.
74
Chapter 7
Conclusions
7.1 Summary
Developing software for Building Automation is not an easy task. With the proliferation of BAS, became
almost impossible to integrate several different systems made by different manufacturers. In the docu-
ment, we made a review of existing BEMS technologies and their main functions. We discovered some
lacks in existing systems and we found that the best solution to this problem was to provide a modular
layered architecture middleware, in order to enable the ability to integrate and extend new BA and EM
functionality easily. Thus, we defined a set of services collections that we believe to be common in all
building automation domains, according to existent standards. With this study, we expect to ascertain
the best way to define a software architecture for BEMS, in order to the development of their function-
alities is made easier. The chosen technology for solution development was OSGi since it provides
mechanisms that enforce modular design.
The results achieved in the evaluation of the implemented solution proves that IST SmartOffice pro-
totype can fulfill all the defined requirements of SOA for BEMS. The interoperability goals were achieved
and different protocols and services have been integrated in a software solution.
7.2 Future Work
In the future, we hope that IST SmartOffice system will be extended to more ambient intelligent capa-
bilities, introducing more energy-related benefits to the large buildings and their environment conditions,
such as: comfort, productivity, and energy-efficient.
Comfort, by allowing users to adjust their personal needs. This is achieved by intelligent control of
devices from a set of sophisticated applications built on top of intelligent services.
Productivity, by optimizing the work environment for whatever tasks at hand. The building will deliver
automatic and transparent behavior to the users in order to bring a better user satisfaction since his
comfort will be optimum, which allows workers to concentrate better for a longer periods of time, resulting
in a higher level of productivity.
75
Energy efficient, by reducing the overall energy consumption not only from services with intelligent
control, which keeps some devices off when they are not needed, but also by User Behaviour Trans-
formation (UBT) services that advise the occupants to meets the best practices related to the usage of
electrical devices.
76
Bibliography
Y. Agarwal, T. Weng, and R. K. Gupta. Understanding the role of buildings in a smart microgrid. 2011
Design, Automation & Test in Europe, pages 1–6, Mar. 2011. doi: 10.1109/DATE.2011.5763195. URL
http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5763195.
G. Bastide, A. Seriai, and M. Oussalah. Adaptation of Monolithic Software Components by Their
Transformation into Composite Configurations Based on Refactoring Example of Experimentation :
A Shared-Diary System. pages 368–375, 2006.
C. Batini and M. Scannapieco. Data Quality: Concepts, Methodologies and Techniques (Data-Centric
Systems and Applications). Springer-Verlag New York, Inc., Secaucus, NJ, USA, 2006. ISBN
3540331727.
P. A. Bernstein. Middleware: A Model for Distributed System Services. Commun. ACM, 39(2):86–98,
Feb. 1996. ISSN 0001-0782. doi: 10.1145/230798.230809. URL http://doi.acm.org/10.1145/
230798.230809.
P. Bianco. Evaluating a Service-Oriented Architecture. 2007.
E. Bloom and B. Gohn. Smart Buildings: Ten Trends to Watch in 2012 and Beyond. 2012.
E. Bloom and B. Gohn. Building Energy Management Systems IT-Based Monitoring and Control Sys-
tems for Smart Buildings : Global Market Analysis and Forecasts. 2013.
A. Bottaro and M. France. Home SOA – Facing Protocol Heterogeneity in Pervasive Application General
Terms :. pages 73–80, 2008.
S. T. Bushby. BACnet TM : a standard communication infrastructure for intelligent buildings. 6:529–540,
1997.
a. Cannata, M. Gerosa, and M. Taisch. SOCRADES: A framework for developing intelligent sys-
tems in manufacturing. 2008 IEEE International Conference on Industrial Engineering and En-
gineering Management, pages 1904–1908, Dec. 2008. doi: 10.1109/IEEM.2008.4738203. URL
http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4738203.
B. L. Capehart and T. Middelkoop. Handbook of Web Based Energy Information and Control Systems.
Fairmont Press, Incorporated, 2011. ISBN 9781439876848. URL http://books.google.pt/books?
id=o3P8tgAACAAJ.
77
H. Chen, P. Chou, S. Duri, H. Lei, and J. Reason. The Design and Implementation of a Smart Building
Control System. 2009 IEEE International Conference on e-Business Engineering, pages 255–262,
2009. doi: 10.1109/ICEBE.2009.42. URL http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.
htm?arnumber=5342106.
L. Chiaraviglio and M. Mellia. Polisave: Efficient power management of campus pcs. In Software,
Telecommunications and Computer Networks (SoftCOM), 2010 International Conference on, pages
82–87, Sept 2010.
P. Clements, R. Kazman, and M. Klein. Evaluating Software Architectures: Methods and Case Studies.
Addison-Wesley, 2001. ISBN 978-0-201-70482-2.
E. Corporation. Introduction to the LONWORKS System - Version 1.0. 1999.
O. Davidyuk, N. Georgantas, V. Issarny, and J. Riekki. MEDUSA : Middleware for End-User Composition
of Ubiquitous Applications. 2009.
S. D. Deugd, R. Carroll, K. E. Kelly, B. Millett, and J. Ricker. Standards & Emerging Technologies SODA
: Service-Oriented Device Architecture SERVICES. 2006.
E. Di Nitto and D. Rosenblum. Exploiting ADLs to Specify Architectural Styles Induced by Middleware
Infrastructures. In Proceedings of the 21st International Conference on Software Engineering, ICSE
’99, pages 13–22, New York, NY, USA, 1999. ACM. ISBN 1-58113-074-0. doi: 10.1145/302405.
302406. URL http://doi.acm.org/10.1145/302405.302406.
P. Dobrev, D. Famolari, C. Kurzke, and B. A. Miller. Device and service discovery in home networks with
OSGi. Comm. Mag., 40(8):86–92, Aug. 2002. ISSN 0163-6804. doi: 10.1109/MCOM.2002.1024420.
URL http://dx.doi.org/10.1109/MCOM.2002.1024420.
Eclipse. Equinox OSGi. URL http://www.eclipse.org/equinox/.
C. Ehrlich, K. Papamichael, J. Lai, and K. Revzan. A Method for Simulating the Performance of
Photosensor-Based Lighting Controls. 2001.
M. Eisenhauer, F. Pramudianto, M. S. Researcher, and P. Kostelnik. Towards a generic middleware for
developing ambient intelligence applications. pages 26–28, 2011.
V. L. Erickson, M. A. Carreira-perpi nan, and A. E. Cerpa. OBSERVE : Occupancy-Based System for
Efficient Reduction of HVAC Energy. 2011.
European Parliament and Council. Directive 2010/31/EU of the European Parliament and of the Council
of 19 May 2010 on the energy performance of buildings. Official Journal of the European Union, L153:
13–35, 2010.
European Standard. Energy performance of buildings - Impact of Building Automation Control and
Building Management - EN 15232. 00247046:1–63, 2006.
78
A. Fernbach, W. Granzer, and W. Kastner. Interoperability at the Management Level of Building Automa-
tion Systems : A Case Study for BACnet and OPC UA. 2010.
W. Fieldbus. Introduction to Fieldbus Introduction to Fieldbus. pages 1–8, 2006.
R. T. Fielding. Architectural Styles and the Design of Network-based Software Architectures. PhD thesis,
2000.
D. B. Floyd and D. S. Parker. Field Commissioning of a Daylight-Dimming Lighting System. 7:1–7, 1995.
S. Francia. REST vs SOAP, the difference between soap and rest : spf13.com, 2010. URL http:
//spf13.com/post/soap-vs-rest/.
V. Garg and N. Bansal. Smart occupancy sensors to reduce energy consumption. Energy and Buildings,
32(1):81–87, June 2000. ISSN 03787788. doi: 10.1016/S0378-7788(99)00040-7. URL http://
linkinghub.elsevier.com/retrieve/pii/S0378778899000407.
R. B. Gmbh. CAN Specification. 1991.
T. Hadlich. Providing device integration with OPC UA. 2006 IEEE International Conference on In-
dustrial Informatics, pages 263–268, Aug. 2006. doi: 10.1109/INDIN.2006.275791. URL http:
//ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4053398.
R. Hall, K. Pauls, and S. McCulloch. Osgi in Action: Creating Modular Applications in Java. Manning
Pubs Co Series. Manning Publications, 2010. ISBN 9781933988917. URL http://books.google.
de/books?id=y3lPPgAACAAJ.
HYDRA. The Hydra project. URL http://www.hydramiddleware.eu.
Information Society Technologies. Socrades. URL http://www.socrades.eu/.
International Standard. Building automation and control systems (BACS) - Part 3, ISO 16484-3. 2007.
International Standard. Building automation and control systems - Part 7: BACS contribution on the
energy efficiency of buildings. 2013.
F. Jammes and H. Smit. Service-oriented paradigms in industrial automation. IEEE Transactions on
Industrial Informatics, 1(1):62–70, 2005.
H. Jiawei and M. Kamber. Data mining: Concepts and Techniques, Second Edition. 2006. ISBN
9781558609013.
N. M. Josuttis. SOA in Practice: The Art of Distributed System Design. O’Reilly Media, 2007. ISBN
9780596551551. URL http://books.google.pt/books?id=jUn0mXGXUIcC.
S. Karnouskos, O. Baecker, L. M. S. de Souza, and P. Spiess. Integration of SOA-ready networked em-
bedded devices in enterprise systems via a cross-layered web service infrastructure. 2007 IEEE Con-
ference on Emerging Technologies & Factory Automation (EFTA 2007), pages 293–300, Sept. 2007.
79
doi: 10.1109/EFTA.2007.4416781. URL http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.
htm?arnumber=4416781.
R. Kazman, M. Klein, and P. Clements. ATAM : Method for Architecture Evaluation. (August), 2000.
Knopflerfish. Knopflerfish OSGi - open source OSGi service platform. URL http://www.knopflerfish.
org/.
KNXAssociation. KNX System Specifications. Technical report, 2009.
J. P. Lahti, A. Shamsuzzoha, and T. Kankaanpaa. Web-based technologies in power plant automation
and SCADA systems: A review and evaluation. 2011 IEEE International Conference on Control Sys-
tem, Computing and Engineering, pages 279–284, Nov. 2011. doi: 10.1109/ICCSCE.2011.6190537.
URL http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6190537.
J. H. Lee, H.-J. Shim, and K. K. Kim. Critical Success Factors in SOA Implementation: An Exploratory
Study. Information Systems Management, 27(2):123–145, Apr. 2010. ISSN 1058-0530. doi: 10.1080/
10580531003685188. URL http://www.tandfonline.com/doi/abs/10.1080/10580531003685188.
S.-h. Leitner and W. Mahnke. OPC UA – Service-oriented Architecture for Industrial Applications. 2006.
G. Levermore. Building Energy Management Systems: An Application to Heating, Natural Ventilation,
Lighting and Occupant Satisfaction. Taylor & Francis, 2002. ISBN 9780203477342. URL http:
//books.google.pt/books?id=hy-tFK4F9YQC.
A. Litvinov and P. Vuorimaa. Integration Platform for Home and Building Automation Systems. (PerNets):
292–296, 2011.
X. Ma, R. Cui, Y. Sun, C. Peng, and Z. Wu. Supervisory and Energy Management System of large
public buildings. 2010 IEEE International Conference on Mechatronics and Automation, pages 928–
933, Aug. 2010. doi: 10.1109/ICMA.2010.5589969. URL http://ieeexplore.ieee.org/lpdocs/
epic03/wrapper.htm?arnumber=5589969.
C. Martani, D. Lee, P. Robinson, R. Britter, and C. Ratti. ENERNET: Studying the dynamic relation-
ship between building occupancy and energy consumption. Energy and Buildings, 47:584–591, Apr.
2012. ISSN 03787788. doi: 10.1016/j.enbuild.2011.12.037. URL http://linkinghub.elsevier.
com/retrieve/pii/S0378778811006566.
A. Mensch. Devices Profile for Web Services Version 1 . 1. (July):1–43, 2009.
T. Merritt. When to use SOAP over REST — SOA Zone, 2012. URL http://soa.dzone.com/articles/
when-use-soap-over-rest.
H. Merz, T. Hansemann, and C. Hbner. Building Automation: Communication systems with EIB/KNX,
LON and BACnet. Springer Publishing Company, Incorporated, 1st edition, 2009a. ISBN 3540888284,
9783540888284.
80
H. Merz, T. Hansemann, and C. Hubner. Building Automation: Communication systems with EIB KNX,
LON und BACnet (Signals and Communication Technology). Springer, 2009b. ISBN 9783540754114.
V. Miori, L. Tarrini, M. Manca, and G. Tolomei. An open standard solution for domotic interoper-
ability. IEEE Transactions on Consumer Electronics, 52(1):97–103, Feb. 2006. ISSN 0098-3063.
doi: 10.1109/TCE.2006.1605032. URL http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.
htm?arnumber=1605032.
D. Y. R. Nagesh, J. V. V. Krishna, and S. S. Tulasiram. A real-time architecture for smart en-
ergy management. In Innovative Smart Grid Technologies (ISGT), 2010, pages 1–4, 2010. doi:
10.1109/ISGT.2010.5434771.
A. H. Neto and F. A. S. Fiorelli. Comparison between detailed model simulation and artificial neural
network for forecasting building energy consumption. Energy and Buildings, 40(12):2169–2176, Jan.
2008. ISSN 03787788. doi: 10.1016/j.enbuild.2008.06.013. URL http://linkinghub.elsevier.
com/retrieve/pii/S0378778808001448.
OASIS Open. oBIX Version 1.1. pages 1–63, 2013.
Open Group Standard. SOA Reference Architecture. 2011. URL https://www2.opengroup.org/ogsys/
jsp/publications/PublicationDetails.jsp?publicationid=12490.
Open Services Gateway Initiative. Technical Specification Overview. 2002.
A. A. Osello, Anna Acquaviva. Energy saving in existing buildings by an intelligent use of interoperable
icts. Energy Efficiency, 6(4):707–723, 2013. ISSN 1570-646X. doi: 10.1007/s12053-013-9211-0.
URL http://dx.doi.org/10.1007/s12053-013-9211-0.
J. E. Petersen, V. Shunturov, K. Janda, G. Platt, and K. Weinberger. Dormitory residents reduce
electricity consumption when exposed to real-time visual feedback and incentives. International
Journal of Sustainability in Higher Education, 8(1):16–33, 2007. ISSN 1467-6370. doi: 10.1108/
14676370710717562. URL http://www.emeraldinsight.com/10.1108/14676370710717562.
F. Reynolds. The Ubiquitous Web , UPnP and Smart Homes. pages 1–5, 2002.
B. Roisin, M. Bodart, a. Deneyer, and P. D’Herdt. Lighting energy savings in offices using different
control systems and their real consumption. Energy and Buildings, 40(4):514–523, Jan. 2008. ISSN
03787788. doi: 10.1016/j.enbuild.2007.04.006. URL http://linkinghub.elsevier.com/retrieve/
pii/S037877880700134X.
B. Roy and T. C. N. Graham. Methods for Evaluating Software Architecture : A Survey. 2008.
M. Rozlog. REST and SOAP: When Should I Use Each?, 2010. URL http://www.infoq.com/
articles/rest-soap-when-to-use-each.
SEEMPubS. Smart Energy Efficient Middleware for Public Spaces - Politecnico di Torino. URL http:
//seempubs.polito.it/.
81
D. Shrestha. A Behavior Driven Intelligent Home Automation System. 2009.
T. G. Stavropoulos, K. Gottis, D. Vrakas, and I. Vlahavas. aWESoME: A web service middleware
for ambient intelligence. Expert Systems with Applications, 40(11):4380–4392, Sept. 2013. ISSN
09574174. doi: 10.1016/j.eswa.2013.01.061. URL http://linkinghub.elsevier.com/retrieve/
pii/S0957417413000936.
S. Szucsich. Web Services in Building Automation with focus on BACnet / WS. pages 1–25, 2010.
P. Szwed, P. Skrzynski, G. Rogus, and J. Werewka. Ontology of architectural decisions supporting ATAM
based assessment of SOA architectures. (11):287–290, 2013.
The OSGi Alliance. Service Platform Compendium Specification, Release 4, Version 4.2.
\url{http://www.osgi.org/Download/File?url=/download/r4v42/r4.cmpn.pdf}, June 2009.
J.-P. Thomesse. Fieldbus Technology in Industrial Automation. Proceedings of the IEEE, 93(6):1073–
1101, June 2005. ISSN 0018-9219. doi: 10.1109/JPROC.2005.849724. URL http://ieeexplore.
ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1435740.
A. Umar. Object-Oriented Client/Server Internet Environments. Client/server. Prentice Hall PTR, 1997.
ISBN 9780133755442. URL http://books.google.pt/books?id=8txQAAAAMAAJ.
UPnP. UPnP Forum. URL http://www.upnp.org/.
C. Walls. Modular Java: Creating Flexible Applications with OSGi and Spring. Pragmatic Bookshelf,
Raleigh, NC, 2009. ISBN 978-1-93435-640-1.
S. Wang. Intelligent Buildings and Building Automation. Spon Press, 2010. ISBN 0203890817.
H. Zhao and F. Magoules. A review on the prediction of building energy consumption. Renewable and
Sustainable Energy Reviews, 16(6):3586–3592, Aug. 2012. ISSN 13640321. doi: 10.1016/j.rser.
2012.02.049. URL http://linkinghub.elsevier.com/retrieve/pii/S1364032112001438.
82
Appendix A
Application Programming Interfaces
A.1 Datapoint Connectivity API
1 package ist.smartoffice.datapointconnectivity;
2
3 /**
4 * Service definition that abstracts the connection to devices and services.
5 *
6 * @author Rodolfo Santos
7 */
8
9 public interface IDatapointConnectivityService {
10
11 /**
12 * The unique name of this implementation used to identify it in a registry
13 * of existing implementations of this API.
14 *
15 * @return a string containing the name of this API implementation
16 */
17 String getImplementationName();
18
19 /**
20 * Interface for listeners of datapoint events.
21 *
22 * @see DatapointEvent
23 */
24 interface DatapointListener {
25 /**
26 * Invoked when a datapoint value update occurs.
27 * <p>
28 * This method can be used to track external changes made in datapoints,
29 * such as a sensor update.
30 *
31 * @param address
32 * the address of the datapoint
33 * @param values
34 * the latest reading values
35 */
36 void onDatapointUpdate(DatapointAddress address, DatapointValue[] values);
37
38 /**
39 * Invoked when a datapoint error occurs.
40 *
41 * @param address
42 * the address of the datapoint
43 * @param error
44 * the error code
45 */
46 void onDatapointError(DatapointAddress address, ErrorType error);
83
47
48 /**
49 * Invoked when a datapoint address list changed.
50 *
51 * @param addresses the new datapoint address list
52 */
53 void onDatapointAddressListChanged(DatapointAddress[] addresses);
54 }
55
56 /**
57 * The type of error found in read or write operations. Tthe detection of
58 * some of the error conditions is dependent on the hardware. Therefore some
59 * service implementations may not be able to report all error codes.
60 */
61 enum ErrorType {
62 /**
63 * The operation over the datapoint is not supported. This can happen if
64 * the datapoint is {@link Metadata.AccessType#READ_ONLY read-only} and
65 * the operation is a write request, or if the datapoint is
66 * {@link Metadata.AccessType#WRITE_ONLY write-only} and the operation
67 * is a read request.
68 */
69 UNSUPORTED_DATAPOINT_OPERATION,
70 /**
71 * The datapoint was not found at the given address.
72 */
73 DATAPOINT_NOT_FOUND,
74 /**
75 * An error occurred while contacting the device containing the
76 * datapoint.
77 */
78 DEVICE_CONNECTION_ERROR,
79 /**
80 * The device containing the specified datapoint is not responding. The
81 * connection to the gateway or device can be established and the
82 * datapoint address is valid but there is no response from the device
83 * regarding the datapoint. This can be due to a change in the
84 * configuration of the device or to a device malfunction.
85 */
86 DEVICE_NOT_RESPONDING,
87 /**
88 * The datapoint previously responding longer exists. This can happen if
89 * the configuration of the device changes or for example when a
90 * physical communication port to the gateway is removed.
91 */
92 DEVICE_VANISHED,
93 /**
94 * The gateway, the bus, or the device is busy and the read or write
95 * operation cannot be completed at the moment.
96 */
97 DEVICE_BUSY,
98 /**
99 * A communication error occurred while contacting the gateway.
100 */
101 GATEWAY_CONNECTION_ERROR,
102 /**
103 * The operation could not be completed because the gateway was not
104 * found.
105 */
106 GATEWAY_NOT_FOUND,
107 /**
108 * The gateway was found but is not responding to the datapoint
109 * operation request.
110 */
111 GATEWAY_NOT_RESPONDING,
112 /**
113 * The operation could no be completed because the gateway is busy at
114 * the moment, or the connection to the gateway is busy and cannot take
115 * more commands.
116 */
117 GATEWAY_BUSY,
118 /**
119 * The datapoint operation was aborted due to an internal error on the
84
120 * service implementation.
121 */
122 SERVER_INTERNAL_ERROR
123 }
124
125 /**
126 * Interface of call-backs for datapoint read operations.
127 */
128 interface ReadCallback {
129 /**
130 * Notifies that a read operation was aborted.
131 *
132 * @param address
133 * the address of the datapoint
134 * @param reason
135 * the reason that caused the write operation to be aborted
136 * @param requestId
137 * the id of the request
138 */
139 void onReadAborted(DatapointAddress address, ErrorType reason,
140 int requestId);
141
142 /**
143 * Notifies that a value read from datapoint has arrived.
144 * <p>
145 *
146 * @param address
147 * the datapoint address that was written.
148 * @param readings
149 * an array of readings.
150 * @param requestId
151 * the request id
152 */
153 void onReadCompleted(DatapointAddress address,
154 DatapointValue[] readings, int requestId);
155 }
156
157 /**
158 * Interface of call-backs for datapoint write operations.
159 */
160 interface WriteCallback {
161 /**
162 * Notifies that a write operation was aborted.
163 *
164 * @param address
165 * the address of the datapoint
166 * @param reason
167 * the reason that caused the write operation to be aborted
168 * @param requestId
169 * the id of the request
170 */
171 void onWriteAborted(DatapointAddress address, ErrorType reason,
172 int requestId);
173
174 /**
175 * Notifies for an update in the request status. This method should be
176 * called every time a new confirmation level is reached.
177 * <p>
178 * In some situations it may not possible to guarantee that the value
179 * was written. The device or protocol may not support acknowledging
180 * writing events. This is the case for example of X10 devices. If the
181 * datapoint can be read, implementers
182 *
183 * @param address
184 * the datapoint where the datapoint was written.
185 * @param confirmationLevel
186 * the confirmation level
187 * @param requestId
188 * the request id
189 */
190 void onWriteCompleted(DatapointAddress address,
191 WritingConfirmationLevel confirmationLevel, int requestId);
192 }
85
193
194 /**
195 * Level of confirmation of datapoint write operations. Distinct
196 * confirmation levels will be returned, depending on the bus technology,
197 * gateway, and device characteristics.
198 */
199 enum WritingConfirmationLevel {
200 /**
201 * The device has confirmed that take action upon the write request.
202 */
203 DEVICE_ACTION_TAKEN,
204
205 /**
206 * The device confirmed the write operation but there is no confirmation
207 * that the device has actually performed the action requested.
208 */
209 DEVICE_CONFIRMED,
210
211 /**
212 * The write operation was sent to the gateway and confirmed. An
213 * acknowledge at this level means that the message has arrived at the
214 * gateway. There is no confirmation that the message has arrived at the
215 * device.
216 */
217 GATEWAY_CONFIRMED,
218
219 /**
220 * Write operation sent to the gateway but confirmation so far. This is
221 * the level to be used when there no confirmation is possible.
222 */
223 UNCONFIRMED
224 }
225
226 /**
227 * Adds a datapoint listener.
228 *
229 * @param listener
230 * the datapoint listener
231 */
232 void addDatapointListener(DatapointListener listener);
233
234 /**
235 * Gets the addresses of all datapoints of devices controlled by this
236 * service.
237 *
238 * @return the list of all registered datapoints.
239 */
240 DatapointAddress[] getAllDatapoints();
241
242 /**
243 * Returns the metadata of a given datapoint.
244 *
245 * @param address
246 * the for which we want to know the metadata
247 * @return the metadata object associated to the datapoint
248 * @throws OperationFailedException
249 * the operation failed exception containing the error type
250 */
251 DatapointMetadata getDatapointMetadata(DatapointAddress address)
252 throws OperationFailedException;
253
254 /**
255 * Removes a datapoint listener.
256 *
257 * @param listener
258 * the datapoint listener
259 */
260 void removeDatapointListener(DatapointListener listener);
261
262 /**
263 * Gets the latest available reading of a datapoint.
264 * <p>
265 * It is expected that implementations of this method force a reading to the
86
266 * specified datapoint. However, when the reading cannot be forced on the
267 * device, it is expected that the last available reading from the device
268 * (that could have been cached) is returned.
269 *
270 * @param address
271 * the absolute address of the datapoint to be read
272 * @param readCallback
273 * the callback to be notified when data is available or if an
274 * error occurred
275 * @return the id of the write request used to by the client to identify the
276 * acknowledge of this request
277 */
278 int requestDatapointRead(DatapointAddress address, ReadCallback readCallback);
279
280 /**
281 * Request the readings a datapoint within a given time window.
282 * <p>
283 * Implementations may query a sensor or return cached values.
284 * <p>
285 * NOTE: Since sensors are devices with limited resources, specifying
286 * <tt>start</tt> to far into the past may result in returning only a subset
287 * of the values.
288 * <p>
289 * Upon calling this method, the method {@link ReadCallback#onReadCompleted}
290 * specified of <tt>callback</tt> will:
291 * <ol>
292 * <li><b>not be called</b>, if <tt>start > finish</tt></li>
293 * <li><b>be called once</b> reporting a reading <i>r</i>, if available,
294 * such that <tt><i>r.ts</i> == start == finish</tt>, if
295 * <tt>start == finish</tt></li>
296 * <li><b>be called multiple times</b> for all readings<i>r</i>, such that
297 * <tt>start ≤<i>r.ts</i> ≤ finish</tt>.
298 * </ol>
299 * Therefore, when no information exists
300 * {@link ReadCallback#onReadCompleted onReadCompleted} will not be called.
301 * If an error occurs the {@link ReadCallback#onReadAborted onReadAborted}
302 * is called instead.
303 *
304 * @param address
305 * the absolute address of the datapoint to be read
306 * @param start
307 * the timestamp that defines the initial window
308 * @param finish
309 * timestamp that defines the final window. Should be greater or
310 * equal to start.
311 * @param readCallback
312 * the callback to the notified of the datapoint readings
313 * @return the id of the read request used later to identify the callback of
314 * this request
315 */
316 int requestDatapointWindowRead(DatapointAddress address,
317 long startTimestamp, long finishTimestamp, ReadCallback readCallback);
318
319 /**
320 * Request a datapoint write.
321 *
322 * @param address
323 * the address of the datapoint
324 * @param values
325 * the values to be written to the datapoint
326 * @param writeCallback
327 * the callback to be notified of datapoint write operations.
328 * @return the id of the read request used later to identify the callback of
329 * this request
330 */
331 int requestDatapointWrite(DatapointAddress address,
332 DatapointValue[] values, WriteCallback writeCallback);
333
334 /**
335 * The Class OperationFailedException.
336 */
337 static class OperationFailedException extends Exception {
338
87
339 /** The Constant serialVersionUID. */
340 private static final long serialVersionUID = 6714056390769181513L;
341
342 /** The error type. */
343 private final ErrorType errorType;
344
345 /**
346 * Instantiates a new operation failed exception.
347 *
348 * @param errorType
349 * the error type
350 */
351 public OperationFailedException(ErrorType errorType) {
352 this.errorType = errorType;
353 }
354
355 public ErrorType getErrorType() {
356 return this.errorType;
357 }
358
359 }
360 }
A.2 IServiceRegistry Interface
1 package ist.smartoffice.osgi.registries;
2
3 /**
4 * The Interface IServiceRegistry.
5 *
6 * @author Rodolfo Santos ([email protected])
7 *
8 * @param <T> the generic service type
9 */
10 public interface IServiceRegistry<T> {
11
12 /**
13 * Adds the service listener.
14 *
15 * @param listener
16 * the listener
17 */
18 public abstract void addServiceListener(ServiceRegistryListener listener);
19
20 /**
21 * Removes the service listener.
22 *
23 * @param listener
24 * the listener
25 */
26 public abstract void removeServiceListener(ServiceRegistryListener listener);
27
28 /**
29 * Modify service.
30 *
31 * @param serviceName
32 * the service name
33 * @param service
34 * the service
35 */
36 public abstract void modifyService(String serviceName, T service);
37
38 /**
39 * Removes the service.
40 *
41 * @param serviceName
42 * the service name
43 */
88
44 public abstract void removeService(String serviceName);
45
46 /**
47 * Adds the service.
48 *
49 * @param serviceName
50 * the service name
51 * @param service
52 * the service
53 */
54 public abstract void addService(String serviceName, T service);
55
56 /**
57 * Gets the registered services names.
58 *
59 * @return the registered services names
60 */
61 public abstract String[] getRegisteredServicesNames();
62
63 /**
64 * Gets the service.
65 *
66 * @param serviceName
67 * the service name
68 * @return the service
69 */
70 public abstract T getService(String serviceName);
71
72 /**
73 * Listener that receives notifications on lumina OSGi service’s updates.
74 *
75 * @see ServiceRegistryEvent
76 */
77 public interface ServiceRegistryListener {
78
79 /**
80 * Notifies service added.
81 *
82 * @param serviceName
83 * the service name
84 */
85 public void serviceAdded(String serviceName);
86
87 /**
88 * Notifies service modified.
89 *
90 * @param serviceName
91 * the service name
92 */
93 public void serviceModified(String serviceName);
94
95 /**
96 * Notifies service removed.
97 *
98 * @param serviceName
99 * the service name
100 */
101 public void serviceRemoved(String serviceName);
102 }
103 }
89
A.3 Datapoint Connectivity API JavaScript Wrapper
1 /*
2
3 @author Rodolfo Santos ([email protected])
4 The DatapointConnectivityServiceAPI.js for Javascript allows you to easily invoke the
DatapointConnectivityService API endpoints.
5
6 */
7
8 function DatapointConnectivityService(serviceName, remoteAddress, remotePort){
9 this.serviceName = serviceName;
10 this.remoteAddress = remoteAddress;
11 this.remotePort = remotePort;
12 }
13
14 DatapointConnectivityService.prototype.getAllDatapoints = function(callback){
15 $.ajax({
16 type: "GET",
17 url: "http://" + this.remoteAddress +":"+this.remotePort+ "/"+this.serviceName+"/datapoints",
18 dataType: "json",
19 success: callback,
20 failure: callback
21 });
22 }
23
24 DatapointConnectivityService.prototype.getDatapointMetadata = function(address, callback){
25 $.ajax({
26 type: "GET",
27 url: "http://" + this.remoteAddress +":"+this.remotePort+ "/"+this.serviceName+"/datapoints/"+
address +"/metadata",
28 dataType: "json",
29 success: callback,
30 failure: callback
31 });
32 }
33
34 DatapointConnectivityService.prototype.requestDatapointRead = function(address, callback){
35 $.ajax({
36 type: "GET",
37 url: "http://" + this.remoteAddress +":"+this.remotePort+ "/"+this.serviceName+"/datapoints/"+
address,
38 dataType: "json",
39 success: callback,
40 failure: callback
41 });
42 }
43
44 DatapointConnectivityService.prototype.requestDatapointWindowRead = function(address, startTimestamp,
finishTimestamp, callback){
45 $.ajax({
46 type: "GET",
47 url: "http://" + this.remoteAddress +":"+this.remotePort+ "/"+this.serviceName+"/datapoints/"+
address + "/" + startTimestamp + "/" + finishTimestamp,
48 dataType: "json",
49 success: callback,
50 failure: callback
51 });
52 }
53
54 DatapointConnectivityService.prototype.requestDatapointWrite = function(address, values, callback){
55 $.ajax({
56 type: "PUT",
57 data: JSON.stringify(values),
58 url: "http://" + this.remoteAddress +":"+this.remotePort+ "/"+this.serviceName+"/datapoints/"+
address,
59 dataType: "application/json",
60 success: callback,
61 failure: callback
62 });
63 }
64
90
65 // ================================================================
66
67 DatapointConnectivityService.prototype.getAllDatapointsSync = function(){
68 return $.ajax({
69 type: "GET",
70 url: "http://" + this.remoteAddress +":"+this.remotePort+ "/"+this.serviceName+"/datapoints",
71 dataType: "json",
72 async: false
73 }).responseText;
74 }
75
76 DatapointConnectivityService.prototype.getAllDatapointsSync = function(){
77 return $.ajax({
78 type: "GET",
79 url: "http://" + this.remoteAddress +":"+this.remotePort+ "/"+this.serviceName+"/datapoints",
80 dataType: "json",
81 async: false
82 }).responseText;
83 }
84
85 DatapointConnectivityService.prototype.getDatapointMetadataSync = function(address){
86 return $.parseJSON($.ajax({
87 type: "GET",
88 url: "http://" + this.remoteAddress +":"+this.remotePort+ "/"+this.serviceName+"/datapoints/"+
address +"/metadata",
89 dataType: "json",
90 async: false
91 }).responseText);
92 }
93
94 DatapointConnectivityService.prototype.requestDatapointReadSync = function(address){
95 return $.parseJSON($.ajax({
96 type: "GET",
97 url: "http://" + this.remoteAddress +":"+this.remotePort+ "/"+this.serviceName+"/datapoints/"+
address,
98 dataType: "json",
99 async: false
100 }).responseText);
101 }
102
103 DatapointConnectivityService.prototype.requestDatapointWindowReadSync = function(address, startTimestamp,
finishTimestamp){
104 return $.parseJSON($.ajax({
105 type: "GET",
106 url: "http://" + this.remoteAddress +":"+this.remotePort+ "/"+this.serviceName+"/datapoints/"+
address + "/" + startTimestamp + "/" + finishTimestamp,
107 dataType: "json",
108 async: false
109 }).responseText);
110 }
111
112
113 DatapointConnectivityService.prototype.requestDatapointWriteSync = function(address, values){
114 return $.parseJSON($.ajax({
115 type: "PUT",
116 data: JSON.stringify(values),
117 url: "http://" + this.remoteAddress +":"+this.remotePort+ "/"+this.serviceName+"/datapoints/"+
address,
118 dataType: "application/json",
119 async: false
120 }).responseText);
121 }
91
A.4 Calimero Process Communicator Interface
1 public interface ProcessCommunicator
2 {
3 /** Adds the specified event listener to receive events from this process communicator. */
4 void addProcessListener(ProcessListener l);
5
6 /** Removes the specified event listener, so it does no longer receive events from this process
communicator. */
7 void removeProcessListener(ProcessListener l);
8
9 /** Reads a boolean datapoint value from a group destination. */
10 boolean readBool(GroupAddress dst) throws KNXException;
11
12 /** Writes a boolean datapoint value to a group destination. */
13 void write(GroupAddress dst, boolean value) throws KNXTimeoutException, KNXLinkClosedException;
14
15 /** Reads an unsigned 8 bit datapoint value from a group destination. */
16 short readUnsigned(GroupAddress dst, String scale) throws KNXException;
17
18 /** Writes a 8 bit unsigned datapoint value to a group destination. */
19 void write(GroupAddress dst, int value, String scale) throws KNXException;
20
21 /** Reads a 3 Bit controlled datapoint value from a group destination. */
22 byte readControl(GroupAddress dst) throws KNXException;
23
24 /** Writes a 3 bit controlled datapoint value to a group destination. */
25 void write(GroupAddress dst, boolean control, byte stepcode) throws KNXException;
26
27 /** Reads a 2 byte KNX float datapoint value from a group destination. */
28 float readFloat(GroupAddress dst) throws KNXException;
29
30 /** Writes a 2 byte KNX float datapoint value to a group destination. */
31 void write(GroupAddress dst, float value) throws KNXException;
32
33 /** Reads a string datapoint value from a group destination. */
34 String readString(GroupAddress dst) throws KNXException;
35
36 /** Writes a string datapoint value to a group destination. */
37 void write(GroupAddress dst, String value) throws KNXException;
38
39 /** Reads a datapoint value from a group destination. */
40 String read(Datapoint dp) throws KNXException;
41
42 /** Writes a datapoint value to a group destination. */
43 void write(Datapoint dp, String value) throws KNXException;
44
45 }
92
A.5 JLifx IBulb Interface
1 package jlifx.bulb;
2
3 import java.awt.Color;
4 import java.io.IOException;
5
6 import jlifx.packet.StatusResponsePacket;
7
8 public interface IBulb {
9 byte[] getMacAddress();
10
11 String getMacAddressAsString();
12
13 GatewayBulb getGatewayBulb();
14
15 void switchOn() throws IOException;
16
17 void switchOff() throws IOException;
18
19 void colorize(Color color, int fadetime, float brightness) throws IOException;
20
21 StatusResponsePacket getStatus();
22
23 void setStatus(StatusResponsePacket status);
24
25 String getName();
26
27 int getHue();
28
29 int getSaturation();
30
31 int getBrightness();
32
33 int getKelvin();
34
35 int getDim();
36
37 void setDim(float brightness) throws IOException;
38
39 int getPower();
40 }
93
Appendix B
Software Diagrams
B.1 Service Exposition Wrappers Diagram
Service Layer
Datapoint API Service
IDataConnectivityService
DatapointConnectivity API
Service Exposition Layer
REST Wrapper Faye (Bayoux) Wrapper
DatapointConnectivityServiceREST Wrapper
WebSockets
DatapointConnectivityServicePubSub Wrapper
Stateless HTTP
DataPointConnectivityService REST Resources
DataPointListingResource
RWDataPoint Resource
GetDataPoint Resource
ReadDataPoint Resource
Faye Server (Publish/Subscription)
Bayoux Protocol
« HT
TP R
eque
st »
« JS
ON
over
HTT
P Re
spon
se »
« Cl
ient
Han
dSha
ke »
Datapoint API Clients
WEB
« on
Dat
apoi
nt U
pdat
e »
« on
Data
poin
t Add
ress
List
Ch
ange
d »
EVENTS
Figure B.1: Service Exposition Wrappers. Each IDatapointConnectivityService implementation are ex-posed by the developed OSGi Web Service Wrappers. Them they become accessible to the end-userapplications through the Web.
94
