design and simulation of an interoperable iot platform for
TRANSCRIPT
Politecnical University of Catalonia
Master Thesis
Design and simulation of an interoperableIoT platform for automatic actuation in
buildings
Author:
David Sembroiz
Supervisors:
Dr. Davide Careglio
Dr. Sergio Ricciardi
A thesis submitted in fulfilment of the requirements
for the Master in Innovation and Research in Informatics
in the
Broadband Communications Research Group
Computer Architecture Department
January 2016
POLITECNICAL UNIVERSITY OF CATALONIA
Abstract
Barcelona School of Informatics
Computer Architecture Department
Master in Innovation and Research in Informatics
Design and simulation of an interoperable IoT platform for automatic actuation in
buildings
by David Sembroiz
Internet of Things have gained a lot of momentum lately due to the new advancements in
technology and wireless communications. Moreover, the appearance of cheaper sensors that are
able to be placed anywhere has accelerated the growth of such field. These improvements have
enabled the creation of new applications or scenarios such as Smart Cities or Smart Buildings.
Focusing on Smart Buildings, the main trend of current systems is to efficiently manage the
resources in order to avoid the waste of energy. However, the proactiveness of those solutions
is quite limited. We propose a solution in which automatic actuations are taken depending on
the current state of the building. Since the testing of the solution in the real environment can
be expensive, we modelled and simulated this large-scale scenario.
Companies have foreseen these opportunities and nowadays it is easy to find a plethora of con-
trol and management systems for homes. However, their heterogeneity arises an interoperability
problem when creating large-scale scenarios. In order to cope with this heterogeneity, we intro-
duce an architecture that takes advantage of a cloud IoT service called ServIoTicy that allows
the abstraction of the underlying WSN. This architecture is used to feed the simulator with real
sensor data.
Acknowledgements
I would firstly like to thank to my supervisors Davide Careglio and Sergio Ricciardi for giving
me the opportunity to work with them once again.
Special thanks to my family, for allowing me to study what I really like and enjoy, and for being
always by my side.
Last but not least, I would also like to thank a very special person that has made these last
months unforgettable.
ii
Contents
Abstract i
Acknowledgements ii
Contents iii
List of Figures v
List of Tables vi
Abbreviations vii
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Report Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Background 6
2.1 Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Technology Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Enabling Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 IoT Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2 IoT: An Environmental Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Smart Buildings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Architecture 21
3.1 Layered Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1 Perception Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.1.2 Environmental Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.3 ServIoTicy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.4 Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1 Flashing a new device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.2 Creating the Perception-Environmental Interface Communication . . . . . 34
3.2.3 Creating a new Service Object and Pushing Data . . . . . . . . . . . . . . 35
iii
Contents iv
4 Simulator 40
4.1 Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1.1 People Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.2 Database Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1.3 Rule Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1.4 MQTT Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.1.5 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1.6 Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2 Work-flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.1 Preparation of the Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.2.2 Running the Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5 Results 62
5.1 Office Building Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.1.1 Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1.2 Lights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1.3 Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2 Study Building Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2.1 Temperature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2.2 Lights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3 Deployment Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6 Conclusions and Future Work 72
6.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2.1 Sensor Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2.2 Enhanced Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7 Cost and Time Analysis 75
7.1 Time Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7.2 Cost Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
A Environmental Interface Documentation 79
B Simulator Class Diagram 83
Bibliography 85
List of Figures
1.1 Evolution of Connected devices against World Population . . . . . . . . . . . . . 1
1.2 Detailed number evolution of the Internet of Things . . . . . . . . . . . . . . . . 2
1.3 IoT Vertical silos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Temperature data from four international science institutions . . . . . . . . . . . 17
3.1 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 XM1000 Mote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 ServIoTicy Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 Create Service Object Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . 36
4.1 Simulator: Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Managers Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3 Simulator: State Diagram of people’s actions . . . . . . . . . . . . . . . . . . . . 42
4.4 Professor probability over time for the different actions that can be executed. . 44
4.5 Student probability over time for the different actions that can be executed. . . 45
4.6 PAS probability over time for the different actions that can be executed. . . . . 47
4.7 Simulator: HVAC Rule State Diagram . . . . . . . . . . . . . . . . . . . . . . . . 49
4.8 Simulator: Light Rule State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.9 Simulator: Computer Rule State Diagram . . . . . . . . . . . . . . . . . . . . . . 52
4.10 Weather’s temperature model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.11 Weather’s humidity model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.12 Weather’s luminosity model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.13 Complete Simulation Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . 58
4.14 Preparation of the Simulation Sequence Diagram . . . . . . . . . . . . . . . . . . 60
5.1 Office building energy consumption history comparison . . . . . . . . . . . . . . . 63
5.2 Office building temperature evolution . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3 Office building lux evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.4 Office building computer evolution . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.5 Study building energy consumption results . . . . . . . . . . . . . . . . . . . . . . 67
5.6 Study building temperature evolution . . . . . . . . . . . . . . . . . . . . . . . . 69
5.7 Study building lux evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.1 Gantt Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
B.1 Simulator: Computer Rule State Diagram . . . . . . . . . . . . . . . . . . . . . . 84
v
List of Tables
2.1 RFID Frequency bands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 TinyOS nesC program file division . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 XM1000 Conversion coefficients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1 Ids table specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2 Associations table specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3 Device energy power for every state . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4 Internet of Things devices power . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.5 Simulation Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.1 Overall Office building energy consumption results. . . . . . . . . . . . . . . . . . 64
5.2 Overall Study building energy consumption results. . . . . . . . . . . . . . . . . . 68
5.3 Estimated deploying cost. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.1 Hours spent in every Project Task . . . . . . . . . . . . . . . . . . . . . . . . . . 77
7.2 Project Tools cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
vi
Abbreviations
BEMS Building Energy Management System
BLE Bluetooth Low Energy
CMOS Complementary Metal-Oxide-Semiconductor
CTP Collection Tree Protocol
ECTS European Credit Transfer and Accumulation System
FTSP Flooding Time Synchronization Protocol
HVAC Heating, Ventilation and Air Conditioning
ID IDentifier
IoT Internet of Things
ISM band Industrial, Scientific and Medical radio band
JSON JavaScript Object Notation
MQTT Message Queing Telemetry Transport
NFC Near Field Communication
OS Operating System
PAS Administration and Service Personnel
REST REpresentational State Transfer
RFID Radio Frequency IDentification
RPL IPv6 Routing Protocol for Low-Power and Loosy Networks
SO Service Object
WSN Wireless Sensor Network
vii
To my father
viii
Chapter 1
Introduction
Internet of Things is commonly defined as the network of physical and virtual objects, devices
or things that are capable of collecting surrounding data and exchanging it between them or
through the Internet [1]. To enable data collection, these things are embedded with sensors,
software and electronics, and the exchange capability is achieved by connecting them to the
Internet.
Having this network connectivity, things can be sensed and remotely controlled, creating a new
Internet paradigm in which the number of interconnected devices grows rapidly than before due
to the new business opportunities.
Figure 1.1: Evolution of Connected devices against World Population
Figure 1.1 compares the connected devices against the World population. As it can be seen,
between 2008 and 2009, the number of connected devices surpassed the World population,
creating a key moment in the Internet of Things history. For Cisco IBSG, this key moment
represents the birth of the Internet of Things [2]. However, the term Internet of Things was
firstly coined by Kevin Ashton, cofounder and executive director of the Auto-ID Center at MIT,
in 1999 [3].
1
Chapter 1. Introduction 2
Focusing on the devices per people ratio, it might seem low, but it has to be taken into account
that the comparison is made against the whole World population and not only against the
connected people, which is significantly lower. For instance, there are approximately 3 billion
people that use Internet today [4]. Using Figure 1.1, the ratio increases to 7.81 in 2015, instead
of 3.47.
Figure 1.2: Detailed number evolution of the Internet of Things
Figure 1.2 shows the growth of connected devices in more detail. Cisco states that by 2020, this
number will be higher than 50 billion [5] even though their theories are based on the knowledge
of the current Internet and new advancements in technology can vary this number substantially
in further years.
As it can be seen, the term thing can refer to a wide variety of devices such as weather moni-
toring stations, commerce stock management, automobile park assisting tools or field operation
devices that assist in search and rescue operations, among others. As technology advances, the
integration of Internet of Things in almost every field is just a matter of time, creating oppor-
tunities for a better interaction between the real world and computer-based systems, resulting
in improved efficiency, accuracy and economic benefit [6].
Within this context, terms such as Smart Grids or Smart Cities appeared to take advantage of
sensor data collection and thus, enhance quality and performance of urban services (transport
and traffic management, energy, health care, water, etc.) and, most importantly, reduce costs
and resource consumption.
Smart Cities have gained lot of interest lately due to environmental and economical changes that
are happening. One of the most important problems that the World is currently suffering is the
Chapter 1. Introduction 3
climate change. The amount of pollution being released to the environment has risen to alarm-
ing levels and the usage of smart objects enable new management opportunities. These new
management systems aim to lower the pollution by monitoring the city and avoiding wasteful
scenarios.
Figure 1.3: Internet of Things vertical silos.
Smart Buildings are gaining even more popularity than Smart Cities due to the wide business
opportunities and the number of potential clients. Companies such as Samsung have started to
create their own Internet of Things platform [7] for home users that improves occupant comfort
and also reduces energy consumption and operating costs. As it can be seen in Figure 1.3,
these platforms are usually vertical silos ranging from the physical sensors up to end user
applications that allow the control and management of those sensors. However, this verticality
does not allow the interoperability between company solutions, which limits and hampers the
creation of heterogeneous systems with a large number of connected devices.
Regarding the amount of information that these systems gather and manage, the trend of the
last years indicates that it is growing at a very fast pace. This increment is directly linked with
the necessity of accurately represent and understand the context in order to provide valuable
information to the user and also to automatically actuate in a proper way. This shift in the
design has created a new topic of interest in the Internet of Things field, which is the Modeling
and Simulation of large-scale IoT scenarios. That is, instead of deploying a real WSN as the first
testing tool, experts have found the necessity to firstly model and virtually simulate large-scale
scenarios in order to massively reduce costs and also to check the viability of the scenario under
study.
1.1 Motivation
Internet of Things enables the possibility to gather huge amount of data from different objects.
These data usually serve as an input for management and user applications that extract valuable
Chapter 1. Introduction 4
information to act accordingly. For instance, by burying sensors in parking lots, it is possible
to track the available places and inform about the current parking state. In the field of Smart
Buildings, the proliferation of Building Energy Management Systems (BEMS) have allowed
people to improve their daily lives by managing their resources efficiently. However, the majority
of this applications have a reactive or simply informative behaviour.
The lack of proactiveness and intelligence limits the level of efficiency that can be achieved,
and by enhancing the systems, it is possible to create more efficient resource management tools
capable of lowering even more the amount of energy consumed. These efficient management
tools are intended to contain machine learning techniques to predict people’s behaviour in order
to anticipate future movements so that their associated actions are scheduled to avoid wasteful
scenarios.
Knowing this possibility, and after having talked with associated professors about their usual
daily behaviour, it came as a surprise the large amount of energy that was being wasted by
simply leaving consuming objects on when it is not strictly necessary. Focusing on the UPC
Campus Nord D6 Building, HVAC systems were also tracked to discover that they are overused
during many daily hours, and even maintained on whilst outside temperature is acceptable or
windows are open. The lack of control on such systems and the unnecessary waste of energy is
the main motivation of this Master Thesis.
In order to be able to gather the necessary building information, the deployment of a WSN is
mandatory. As it has been said before, the lack of standardization makes difficult the interop-
eratibility of company solutions. That is why there is an important necessity of a middleware
that enables the communication between heterogeneous WSN. This was the second motivation
for this Master Thesis.
1.2 Goals
The main goal to be accomplished in this project is the efficient resource management of the
UPC Campus Nord D6 building. By having a Smart Manager capable of controlling all the
sensitive devices inside the building and the interaction of people with them, it is expected to
lower the overall consumption of the building without disturbing the people working inside.
To do so, and as a first approach, a simulation tool is built to recreate the building and its
people’s movements. This simulator is enhanced with a Smart Manager which is responsible
for taking decisions about the different consuming elements. For instance, if a person leaves
his room, the Manager detects that the room is empty and thus, lights are turned off and the
computer is switched to suspended mode.
Chapter 1. Introduction 5
Instead of providing the simulator with random sensor data, we decided to use a limited amount
of real sensors alongside virtually recreated ones. This decision drives us to the second goal, the
creation of a middleware capable of dealing with different market solutions, making it possible
to be extended in future projects.
1.3 Report Structure
The remainder of this thesis is organised as follows.
Chapter 2 Explanation of the background of Internet of Things and Smart Buildings.
Chapter 3 Specification of the full built architecture to support a future real sensor de-
ployment across the building.
Chapter 4 Specification and Implementation of the Simulator.
Chapter 5 Presentation of evaluation results.
Chapter 6 Final conclusions and insights on the benefits and contribution of this work in
future projects.
Chapter 7 Evaluation of the cost and time analysis of this master thesis.
Chapter 2
Background
This chapter presents the current state of the Internet of Things. Firstly, the concept is intro-
duced and defined. Next, an overview of the technology improvements that have made possible
the creation of profitable WSN are listed. Then, current enabling technologies and software are
presented. After that, the most important environmental problem is explained. Finally, current
state of Smart Buildings is mentioned.
2.1 Internet of Things
The improvements in technology and the easiness with which devices can be connected to the
Internet have made the term Internet of Things a fact no longer related to the Future Internet.
Instead, it can be seen that the term is already among us. Wireless connections such as RFID,
NFC or ZigBee have enabled the possibility to enhance simple objects to allow the collection of
their surrounding data.
Oxford Dictionaries define the Internet of Things as “The interconnection via the Internet of
computing devices embedded in everyday objects, enabling them to send and receive data” [8].
The ITU-T defines the Internet of Things, more accurately, as “a network of physical and virtual
objects or things that are capable of collecting surrounding data and exchanging it between them
or through the Internet” [9].
As it can be extracted from both definitions, the new trend is to interconnect everything that
can be interconnected, and embed small computing devices to any kind of object that can offer
valuable information.
6
Chapter 2. Background 7
2.1.1 Technology Improvements
Moore’s Law [10] is alive and well. As electronic chips continue to decline in size and cost whilst
improving in performance and processing power, the economics of sensor-based applications
substantially improve, enabling new types of Internet of Things systems and applications by
easing their deployment and lowering their cost.
The most important improvements are the following:
• Smaller, more durable sensors. New sensors size allows the possibility to wear or even
ingest them, and its robustness allows the monitoring of delicate and dangerous scenarios
such as high-speed rotating machinery (e.g., jet engines, generator turbines).
• Multi-processor chips. Chip manufacturers are manufacturing up to 15 processor cores
per chip. These types of multi-processor chips offer more compute power and enable many
more capabilities in smaller form factors.
• Increasing processor performance and efficiency. IBM, for instance, is working
on a new chip technology called SyNAPSE [11]. With 5.4 billion transistors, this fully
functional and production-scale chip is one of the largest CMOS chips ever built, yet,
while running at biological real time, it only consumes 70 milliwatts which is orders of
magnitude less power than a modern microprocessor.
• Lower cost. Economies of scale are enabling a rapid decline in price of all types of
electronic components, reducing the cost to embed sensors and microchips into everyday
objects.
2.1.2 Enabling Technologies
To allow all the expected billion of devices to communicate with each other, a communication
technology is needed. Currently, there are plenty of wireless communication standards and every
one have strengths for certain applications. Even though the usage of multiple technologies may
result in a fragmented network approach, choosing the best standard for every situation is key
for covering the necessities of different scenarios.
The following sections show the most commonly wireless technologies used that enable the
Internet of Things.
2.1.2.1 RFID
Radio-frequency Identification is an electromagnetic proximity wireless detection and data trans-
action system [12]. Its is a similar concept to bar code but it enhances previous technologies in
Chapter 2. Background 8
terms of non-optical proximity communication, information density and two-way communica-
tion capability. By attaching RFID tags to objects and using a reader, it is possible to gather
the tag information easily and cleanly.
Operational RFID systems often combine tags with database systems in order to collect the
information to later usage. For instance, by attaching tags to boxes, it is possible to recog-
nise their content without having to open the truck containing them. Also, in supply chain
productions, it is possible to detect the current state of each product being manufactured.
The elements of an RFID system are divided into tags and two-way readers. Tags are attached
to objects and the readers send a signal to the tag and read its response. These tags can also
be divided into active, passive or battery-assisted passive.
Active tags are proactive elements that utilize their on-board battery to periodically broadcast
its signal over the radio. This feature allows the tags to send stronger signals to the readers,
enabling long distance communications. Moreover, low-level signals are received by the tags
since there is no necessity to power them up. By being proactive, the communication with the
reader can also be started by the tags when a reader is detected nearby.
Passive tags are the cheapest and smaller ones because they have no battery attached. In order
to create a communication, passive tags rely on the energy transferred by the reader. Once this
energy is received, the tag’s microchip or integrated circuit becomes powered and its signal is
transmitted. The main drawback of these tags is the maximum distance between the tag and
the reader. Since the received tag signal must be strong, both elements must be within several
meters of each other.
Battery-assisted passive tags lie between those previously explained. The battery allows longer
communications and storage capabilities, but the communication still needs to be started by
the reader.
Independently of the type of tag, they all contain at least two parts: an integrated circuit for
storing and processing information, modulating and demodulating the signal, collecting power
from the signal among other specific functions; and an antenna for receiving and transmitting the
radio frequency signal. All the information is stored in a non-volatile memory that increases its
capacity as the complexity of the tag becomes higher. This memory can be read-only, in which
the information is written while manufacturing the tag, or read/write where object-specific
information can be written into the tag by the system user.
Regarding the readers, they can also be passive or active. Passive readers are often placed in
fixed locations to create specific interrogation zones in which active tags are attached to moving
objects such as transportation cargos. Active readers are usually hand-held mobile devices used
Chapter 2. Background 9
to read fixed tags. For instance, counting the stock of a shop by reading the elements on the
different shelves.
Depending on the type of tag and reader, RFID systems are classified into Passive Reader Active
Tag (PRAT), Active Reader Passive Tag (ARPT) and Active Reader Active Tag (ARAT). The
main behaviour remains equal for all the systems, usually the reader transmits an encoded signal
to interrogate the tag, and the tag responds with its unique tag serial number and may also
include product-related information.
The global RFID market is increasing its value rapidly due to the multiple usages of such
systems. Some of the most famous ones are:
• Asset Tracking and Management
• Access Control
• Timing Sporting Events
• Smartdust
Table 2.1 shows the different bands in which RFID can operate depending on the requirements
of the applications in terms of range and data speed.
Band Regulation Range Data Speed
120-150 kHz Unregulated 10cm Low13.56 MHz ISM band 10cm - 1m Low to Moderate433 MHz Short Range Devices 1 - 100m Moderate865 - 868 MHz (Europe) ISM band 1 - 12m Moderate to High2450-5800 MHz ISM band 1 - 2m High3.1 - 10 GHz Ultra Wide band Up to 200m High
Table 2.1: RFID operating frequency bands. Taken from [13].
RFID has risen as the key enabling technology for Internet of Things. By having smart tags
attached to sensor devices, it is possible to monitor the environment and send the data to a
Internet connected gateway that stores and manages the information.
2.1.2.2 NFC
Near Field Communication [14] is an evolution of RFID in which chips operate as part of a
wireless link. The radio communication between NFC devices is done by putting them together
or very close, typically to a distance of 10 cm or less. Early attempts of business models were
not successful due to the distance limitation, but NFC has risen as an enabling Internet of
Things technology thanks to Internet-connected devices with NFC tags inside them such as
Chapter 2. Background 10
smartphones. By providing specific applications to them, it is possible to accomplish multiple
market solutions depending on the mode in which the NFC device can work:
• NFC Card emulation mode enables the payment of transactions by making the NCF tag
act as a smart card.
• NFC Reader and writer mode enables smartphones to read NFC tag information and also
modify it.
• NFC P2P mode enables the peer to peer communication of NCF devices in an adhoc
fashion.
NFC tags can contain data (typically less than 8 Kb of memory) and may include sensitive
personal information thanks to the manufacturing standards defined by the NFC Forum [15] in
which four distinct types of tags that provide different communication speeds, security levels
and memory capacity are defined. There is also the possibility of applying encryption algo-
rithms to the stored information to reach the security levels needed for managing Credit Cards
information, for instance.
NFC is standardised in ISO/IEC 18092 and operates at 13.56 MHz, a globally available unli-
censed radio frequency ISM band.
2.1.2.3 Bluetooth Low Energy
Bluetooth Low Energy (BLE) or Bluetooth Smart is an enhancement of the Bluetooth tech-
nology in which the management of the connections and the energy consumption are more
intelligent.
Internet of Things has shifted the connection paradigm to one in which the maintenance of
the connection is no longer the main issue. Instead, the new generation of Bluetooth focuses
on sending small bits of data when needed and then putting the connection to sleep during
periods of non-usage. With this behaviour, when two devices are paired, the waste of energy is
negligible because the connection is dormant unless its usage is needed.
Bluetooth Smart has been specially designed for the smart home, health, sport and fitness
sectors according to the target market specified by the Bluetooth SIG [16]. These sectors are
emerging low energy consuming sectors and some of the advantages that they take advantage
of are:
• Low power requirements
• Small size and low cost
Chapter 2. Background 11
• Compatibility with a large installed base of mobile phones, tablets and computers
Bluetooth Smart uses the same frequency band as the standard Bluetooth, which is the 2.4 GHz
radio frequency, allowing dual-mode devices to share a single radio antenna.
2.1.2.4 ZigBee
ZigBee is a standard based on the IEEE 802.15.4 specification specially targeted for long battery
life devices in wireless mesh networks. Its low cost and low power make it mainly targeted for
wireless personal area networks (WPANs) in which the battery life-time is more important than
the transmission speed. ZigBee is intended to be simpler and less expensive than other wireless
personal area network specifications such as Bluetooth or Wi-Fi.
ZigBee chips are typically integrated with radios and microcontrollers that have a small flash
memory and thus, low power consumption. They operate in the 2.4 GHz ISM band as well as
the 868 MHz in Europe and 915 MHz in the USA, for instance.
However, its simplicity also limits some important aspects such as the data transmission rate
and the communication distance. By operating in the ISM band, it is possible to reach 250
Kbps and the communication distance vary between 10 and 100 line-of-sight meters depending
on power output and environmental characteristics.
All these features make it ideal for the Internet of Things. Applications such as wireless control
and monitoring hugely benefit from ZigBee since battery-powered sensors can be placed in
hardly reachable locations for a long time without the necessity of changing the batteries.
2.1.2.5 Wi-Fi IEEE 802.11ah
Even though Wi-Fi might not seem the most suitable technology enabling IoT, it is starting to
gain popularity due to the necessity of having a standard technology for connecting devices to
each other or the cloud. The choice of technology is usually dictated by the physical charac-
teristics of the environment, such as the presence of wood, concrete, metal, etc., the density of
sensors, desired range and data rates mainly. Wi-Fi has been the most successful ubiquitous
standard of connectivity used in homes, enterprises, schools, hospitals, etc.
However, the legacy Wi-Fi specification has some drawbacks that endanger the maintenance and
scalability of such environments. Among these drawbacks or challenges with the underlying
802.11 technology, we find high power consumption, scalability problems due to the limited
number of devices that can be connected to a Wi-Fi Access Point and range limitations. To
Chapter 2. Background 12
address these challenges and establish Wi-Fi as the main standard technology enabling IoT, the
IEEE 802.11ah amendment has been created.
802.11ah is a wireless networking protocol that utilizes sub 1 GHz license-exempt bands (900
MHz band) and narrow communication bandwidths (150 kbps) to provide extended range Wi-Fi
networks compared to conventional Wi-Fi networks operating in the 2.4 GHz and 5 GHz bands.
Key targets introduced in 802.11ah are longer transmission range, several new power-saving
features and an increased number of stations associated with one Access Point (AP). In order
to cope with all these targets, important physical layer (PHY) and Medium Access Control
layer (MAC) modifications had to be made.
The new PHY layer design is based on the 802.11ac standard just moved to the new spectrum.
To accommodate narrower channel bandwidths, the IEEE 802.11ah PHY layer is obtained by
down-clocking 10 times the IEEE 802.11ac PHY layer. As for the MAC layer, the Traffic Indi-
cation Map of the 802.11ac MAC layer has been extended to allow for more number of stations
and better power savings are achieved by a mechanism called page segmentation. Sections 4
and 5 of [17] respectively explains with more detail the introduced mechanisms in both layers.
2.1.2.6 IPv6 over Low power Wireless Personal Area Networks
The IPv6 over Low power Wireless Personal Area Networks or 6LoWPAN concept was originated
from the idea that the Internet Protocol should be applied to every kind of device, even the
smallest ones. Since these devices usually are low-powered and limited in terms of processing
capabilities, a new light-weighted Internet Protocol was necessary to allow them to participate
in the Internet of Things.
One of the key features of 6LoWPAN is the creation of encapsulation and header compression
mechanisms that allow the transmission and reception of IPv6 packets over IEEE 802.15.4 based
networks.
The main specification of 6LoWPAN can be found in [18], which has an updated version with
header compression in [19] and a second update with neighbour discovery optimizations in [20].
However, the nature and behaviour of 6LoWPAN and IEEE 802.15.4 networks significantly
differ. In order to interconnect both networks, some design challenges had to be faced (see an
overview in [21]).
Chapter 2. Background 13
2.1.3 IoT Operating Systems
The Internet of Things embodies a wide spectrum of devices ranging from sensors powered by
very small microcontrollers to very powerful devices such as smartphones. Current Internet-
host operating systems or sensor networks OS are not capable of fulfilling the vast requirements
of such wide variety of devices. In order to avoid redundant developments and maintenance
costs of IoT products, a new type of operating system is needed in which the unification and
compatibility are two of the main needed features.
Following sections present the most commonly Operating Systems used and their characteristics.
2.1.3.1 TinyOS
TinyOS is the most popular Operating System designed for low-power wireless devices such
as wireless sensor networks, personal area networks and specially smart cities and buildings.
TinyOS provides software abstraction of the device hardware. For instance, TinyOS represents
a sensor of a device as a simple class with generic functions to query the value instead of having
to understand the structure of the data packet.
That is why TinyOS is specially designed for microcontroller-based devices or motes with sensors
attached and connection capabilities at network or link level. It is also designed for constrained
devices with very few memory and storage capabilities as well as very low power consumption.
Thanks to its wide microcontroller and radio chip support, it is possible to find basic applications
to start from when writing a new solution. Moreover, the strong low-power operation capabilities
that TinyOS offer are extended to the wireless networking. This allows to write single-hop
communication applications using this operation model. In the case of multi hop communication,
TinyOS multi hop protocols already use this feature. CC2420, the leading 802.15.4/ZigBee radio
chip is especially supported, with plenty of detailed information.
Regarding the programming language, TinyOS platform uses its own language called network
embedded systems C (nesC) [22]. NesC is a component-based language which allows the creation
of software out of components that are assembled afterwards to form complete programs. The
behaviour of these components is represented via interfaces that are exposed to the user. Every
interface that represents a component have to implement all the required functions. The flow of
a nesC program is determined by events. Whenever a new event arrives in terms of a hardware
interruption, the associated callback is executed to completion.
As for the networking protocols, TinyOS supports the most excellent designed protocols which
have become part of the nowadays Internet. This has been achieved thanks to the usage of
Chapter 2. Background 14
TinyOS by many low-power wireless research groups. The following sections introduce the most
important supported protocols.
2.1.3.1.1 Flooding Time Synchronization Protocol
The advances in wireless communication and in micro electro-mechanical systems are leading
to cheaper low-power sensing devices. This achievements guide us towards new WSN with
hundreds or even thousands of nodes interacting and communicating with each other. In some
applications, there is also the necessity of coordinating and synchronizing the sensing intervals
with maximum precision. From this scenario the Flooding Time Synchronization Protocol
(FTSP) [23] appeared, specially designed for resource limited wireless platforms and also offering
robustness against node and link failures. In order to achieve this, FTSP uses periodic flooding
of synchronization messages and implicit dynamic topology update.
To achieve high precision performance, it uses MAC-layer time-staming [24] and comprehensive
error compensation including clock skew estimation.
2.1.3.1.2 Collection Tree Protocol
The Collection Tree Protocol (CTP) [25] is a tree-based collection protocol which provides
best-effort anycast datagram communication to one of the collection roots in a network and is
specially designed for relatively low traffic rates.
In order to use CTP in a network, some nodes must advertise themselves as a root nodes. The
rest of the nodes are transmitters to the roots. Since CTP is address-free, the transmitters are
not bound to send their data to an specific root. Instead, they implicitly choose their root by
choosing a next hop node. The election of such hop is done via what is called a routing gradient.
In the case of CTP, the routing gradient is called Expected Transmissions (ETX). All the root
nodes have an ETX of 0, and for given a random transmitter, its ETX is calculated as the sum
of the ETX of its parent plus the ETX of its link to its parent. While deciding the next hop, a
node must choose as a parent the neighbour with the lowest ETX value.
This algorithm have two main problems though: routing loops and packet duplication. Routing
loops usually occur when a node chooses a new route with significantly higher ETX than its
old one. This situation may happen in response to a link failure with a candidate parent. This
new route might contain a descendant node, and by choosing it, the loop cannot be avoided.
To cope with this problem, CTP introduces two mechanisms.
First, every CTP packet contains a node’s current gradient value. If CTP receives a packet with
a gradient value lower than its own, then an inconsistency in the tree is detected. To solve this,
Chapter 2. Background 15
CTP broadcasts a beacon packet that should arrive to the node which sent the incorrect packet
and adjust its routes accordingly.
If a part of the network is isolated from the rest, the ETX of a packet will constantly increase
since the loop is unavoidable due to the lack of links. The second mechanism introduced by
CTP is to not consider packets with ETX higher than a threshold, which is dependent in every
implementation.
Packet duplication can occur when an ACK packet is not received by a transmitter. Moreover,
routing loops can aggravate this problem since a node can legitimately receive a packet more
than once. To cope with this problem and avoid retransmission that can flood the network,
CTP data packets have an additional time has lived (THL) field which is incremented in each
hop. A link-level retransmission will have the same THL value, whilst a looped version of the
packet is unlikely to do so.
2.1.3.1.3 Deluge T2
Deluge is a data dissemination protocol that allows the propagation of large amounts of data
from one or more source nodes to the rest of nodes over a multi hop wireless sensor network
[26].
Nodes from a wireless sensor network often require hardly reachable or even dangerous locations
to be monitored and the intervention of humans during this monitoring can disturb the results.
Furthermore, these networks are reaching very high numbers in terms of connected nodes that
make the manual interaction with them intractable. Also, once a network is deployed, its re-
quirements and environments may change over time, creating a new necessity of reprogramming
the whole network.
Deluge mitigates these problems by providing a tool to disseminate new sensor images and
propagate them through the network automatically. This feature adds the needed flexibility for
developers to adapt a wireless sensor network to his current necessities.
Deluge T2 [27] is an effort to port Deluge 2.0 from TinyOS 1 to TinyOS 2. Currently, Tmote
Sky (TelosB), MicaZ, Iris and mulle motes are supported.
2.1.3.1.4 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
RPL addresses one of the main issues regarding Internet of Things. As it has been previously
said, by 2020 it is thought that more than 50 billion devices will be connected to the Internet.
Chapter 2. Background 16
Since each of these devices must have a unique identifier and it is no longer possible to allo-
cate IPv4 addresses [28], the transition to IPv6 to cope with this large amount of devices is
mandatory.
In particular, this protocol specifies the IPv6 Routing Protocol for Low-power and Lossy Net-
works. These networks consist of constrained nodes with limited processing power, memory and
energy consumption which are interconnected by means of lossy links typically supporting only
low data rates. Additionally, in most of the cases the traffic patters are more complex than a
point-to-point and the number of network nodes is very high.
Additional information regarding the protocol and its full specification can be found in its
Request for Comments [29].
2.1.3.2 Contiki
Contiki is an open source Operating System specially designed for memory constrained solutions
with particular focus on low-power wireless devices. One of the main advantages of Contiki is
the limited amount of resources needed to run. According to its creators, any device with 10
kB of RAM and 30 kB of ROM is capable of running Contiki.
Contiki provides network mechanisms for both IPv4 and IPv6 networking by means of the uIP
TCP/IP stack and uIPv6 stack respectively. Equally to TinyOS, the IPv6 stack contains the
RPL routing protocol for low-power lossy networks and it also contains the 6LoWPAN header
compression and adaptation layer for IEEE 802.11.4 links.
Moreover, it also privides a Rime stack which contains a set of custom lightweight networking
protocols specially designed for low-power wireless networks aimed for situations in which the
overhead of the other stacks is prohibitive. Among its communication primitives, we find single-
hop unicast and broadcast as well as multi-hop unicast and network flooding.
In order to constrain even more the energy consumed by devices, Contiki introduces a new
protocol called ContikiMAC [30]. This protocol uses a power efficient wake-up mechanism with
a set of timing constraints to allow the device to keep its transceivers off most of the time.
Apart from the previous features, Contiki introduces a network simulator called Cooja [31]
capable of simulating large and small networks of Contiki motes. Each mote may belong to
either of the following classes:
• Emulated Mote: the entire hardware of the mote is emulated. This method is slower but
allows precise inspection of the system behaviour.
• Cooja Mote: Contiki code is compiled for and executed on the simulation host.
Chapter 2. Background 17
• Java Mote: the behaviour must be reimplemented as a Java class.
A single Cooja network simulation may contain a mixture of motes from either of the three
classes, and it is also possible to include non-Contiki motes thanks to the emulated mode
schema.
2.1.3.3 More Operating Systems
Besides the two main Operating Systems explained before, there are numerous new solutions
that aim to cover the weaknesses of the rest and also to include new features.
Within these new solutions we can find FreeRTOS, the new IoT OS developed by Google called
Brillo or Riot [32] among others with less impact.
2.2 IoT: An Environmental Solution
In the last decades, the average Earth temperature has increased at the fastest rate in record
history, and the vast majority of scientists agree that such climate change is largely due to
human-caused pollution.
Figure 2.1: Temperature anomaly data history. Taken from [33].
As it can be seen in Figure 2.1, during the last 30 years, the average temperature has been
constantly increasing at a very fast pace. In order to change that trend, individual action is not
enough and massive global changes must be carried out. In this scenario, Internet of Things
and Machine to Machine communication can be the key response.
Chapter 2. Background 18
Even though IoT cannot directly address the climate change problem, it enables the possibility
to deal with the energy consumption in different situations which is one of the main reasons of
the high air pollution emissions.
The most important current solutions are:
• Smart Grid systems collect data related to electricity consumption by using sensors
placed at power meters, voltage sensors, fault detectors and other devices connected to
the utility. This allows, for instance, the monitoring of a home consumption. If the
system detects that there has been no recent activity inside, the power-hungry devices
can be automatically turned off.
• Smart parking lots and traffic systems enable the possibility to reduce vehicle fuel
consumption by telling the driver where to park without having to look for a free spot.
Moreover, a traffic signal synchronization can drastically reduce travel time and fuel con-
sumption.
• Smart home devices such as thermostats and lightning systems can recognise patterns
and automatically adjust the devices to save energy during low-usage periods.With these
systems, not only the power bill is lowered, but also people are more aware on how to
individually contribute to solve the overall problem.
2.3 Smart Buildings
Over the last few decades, Intelligent Buildings have been largely researched and developed.
However, the term Intelligent is starting to be interchanged by the Smart one in many recent
publications.
Even though both terms might seem equivalent, there are substantial differences that have to be
understood in order to use each one appropriately. These differences are mainly related to three
distinct drivers which explain the building progression over the last years: longevity, energy and
efficiency and comfort and satisfaction.
The methods to achieve progress in each of these drivers can also be grouped into four different
aspects:
• Intelligence: methods by which building information is gathered and responded to.
• Control: interaction between occupants and the building.
• Materials and construction: building physical form.
Chapter 2. Background 19
• Enterprise: methods by which building usage information is collected and used to improve
occupant performance.
Depending on the type of building, each of these aspects may be focused upon and utilised to
different extents. Moreover, even though the development of each aspect has been effective over
the time, they have specially been developed independently of each other.
Having set the ground to understand what aspects a building must have to be Intelligent or
Smart, their difference lies into the development of these aspects.
Many scientists agree that Intelligent Buildings are an evolution of Automated Buildings. Fol-
lowing the same pattern, Smart Buildings are meant to be the evolution of Intelligent Buildings.
Contrary to Intelligent Buildings, Smart Buildings are self-aware and grid-aware, interacting
with a smart grid system whilst focusing on real-time demand side response. Their level of
responsiveness, adaptability and flexibility are key areas in which they can differentiate from
previous generations.
These areas can be seen as the pillars for a correct definition. However, among them, adaptability
is the heart of it. The integration between all aspects of the building allows the differentiation
between previous generations of buildings and Smart Buildings. Adaptability uses internally
gathered information as well as external from a range of sources to prepare the building for a
particular event before it happens. Therefore, this feature enhances buildings with proactiveness
instead of being reactive. Examples of adaptability are the ability to account for:
• Variation in people’s perceptions of comfort at different times of day and year.
• Changes in occupants or building usage.
• Heterogeneous occupancy data characteristics.
• Varying yearly external weather conditions.
Smart Buildings are able to adapt to these changes whilst maintaining or increasing if possible
energy efficiency and occupant satisfaction.
Control is one of the most debated aspects. Both fully automated buildings and human con-
trolled buildings can perform very well. However, an intermediate point would be the most
desired scenario since user would be allowed to easily interact when undesired conditions are
present whilst maintaining their comfort most of the time without their interaction with the
building. For instance, whilst varying the building temperature according to the external con-
ditions, it is possible to inform the occupants beforehand about which conditions will they
encounter in order to adapt their comfort. Additionally, when arriving, Smart Buildings could
Chapter 2. Background 20
direct them to an area within their personal comfort preferences. Contrary to that behaviour,
Intelligent Buildings may only collect and react to current weather conditions by slightly varying
the HVAC system.
The term enterprise makes reference to a topic already introduced before which is related to the
current market alternatives. Since current systems are created without following any standard,
the heterogeneity of the solutions hampers their compatibility. Thus, instead of having a major
common network in which every system is fed with external information and his own, they act
as independent subsystems. Enterprise consists of the combination of such systems to unify
them and create a bigger network.
In conclusion, it can be said that Smart Buildings are an evolution of Intelligent Buildings with
integrated aspects of control and enterprise, implemented both individually and as an adaptable
system.
They are mainly occupant-based, which allows the creation of active participants that incorpo-
rate feedback to and from their behaviour inside the building. Smart Buildings also delegates
some of the comfort decisions to the users whilst maintaining regulated control. Learning is
developed over time. That is, data from the past is gathered and interpreted in order to adapt
the future actions so that comfort and satisfaction are enhanced. Prediction, if the building
is equipped with intelligent operational systems, is achieved by looking into previous unused
useful information through which energy efficiency and potential improvements in comfort can
be accomplished.
Chapter 3
Architecture
This chapter presents the architecture developed to acomplish the homogeneity goal stated be-
fore. This architecture aims to unify and simplify the communication between different platform
sensors and applications.
Firstly, an overall view of the architecture is explained and more specific details are given in
the subsequent sections.
3.1 Layered Architecture
Internet of Things is rapidly gaining popularity, and companies are starting to create a vast
variety of sensors that differ one from another. To cope with this heterogeneity, our architecture
aims to decouple the different components as much as possible in order to create a modular
system in which upgrade and extension are easily accomplished.
To this aim, a layered architecture has been thought in which the dependencies between the
different layers are minimal. Moreover, this decoupling allows us to reuse components in future
projects.
Figure 3.1 shows the final architecture divided into 4 separated layers:
• Perception Layer: lowest layer that groups all the real and virtual sensors as well as the
gateways.
• Environmental Interface: layer that receives the data from the different gateways, pro-
cesses it to a proper format and sends it to the ServIoTicy layer.
• ServIoTicy Layer: external platform that stores sensor data and makes it publicly available
to the Internet by means of Cloud Service Objects.
21
Chapter 3. Architecture 22
• Application Layer: this layer can be fulfilled with any kind of end user application that
requires sensor data. In our case, a Simulator has been built to check and lower the power
consumption of an office building by avoiding wasteful scenarios.
This four-layered architecture is an extension of the commonly accepted 3-layer architecture
[34, 35]. The only difference is located in the Network layer, which can be seen as the Middleware.
In our case, it has been divided into 2 separated layers to take advantage of the already developed
ServIoTicy layer. Equivalent upgraded architectures are already being used in some Service
Oriented Industry solutions [36] and their implications are thoroughly discussed in [37].
3.1.1 Perception Layer
As it can be seen in Figure 3.1, the perception layer comprises all the sensor nodes of the
network. In our case, the sensors are divided into two different categories: real and virtual. In
order to test the scalability of the system, a large Wireless Sensor Network (WSN) is needed
to guarantee a high traffic demand and a non trivial scenario. Since real sensors are expensive,
only a small part of the network is composed of those, and the rest is virtually recreated with
individual processors simulating the behaviour of real motes.
After having analysed the different motes’ market alternatives, we opted for an advanced mote
manufactured by Advanticsys [38] and named XM1000 [39], which contains three sensors as-
sembled (temperature, humidity and light).
In the following sections we present more in depth the specifications and characteristics of the
motes and sensors.
3.1.1.1 XM1000
This is the main real mote used in our system. Its versatility and compatibility have been the
main reasons for the decision of choosing it. Its main specifications are the following:
• IEEE 802.15.4 WSN mote
• TI MSP430F2618 Microcontroller, CC2420 RF [40]
• TinyOS 2.x & ContikiOS Compatible
• User & Reset Buttos
• 3 LEDs
• USB Interface
Chapter 3. Architecture 23
Figure 3.1: Architecture overview.
Chapter 3. Architecture 24
• Dipole Antenna
The XM1000 is fully compatible with the TelosB platform, which allows the usage of software
available for that platform without having to massively change it. It also supports TinyOS,
which is the most commonly Operating System used when referring to Wireless Sensor Networks.
Figure 3.2: XM1000 Mote
The mote contains three sensors with the following specifications:
• Light 1 Hamamutsu R© S1087 Series [41]: Visible Range (560 nm peak sensitivity wave-
length)
• Light 2 Hamamutsu R© S1087 Series [41]: Visible and Infrared Range (960 nm peak sensi-
tivity wavelength)
• Temperature and Humidity Sensirion R© SHT11 [42]
– Temperature Range: -40 to 123.8 oC ± 0.4 oC
– Humidity Range: 0 to 100% RH ± 3% RH
In the implementation, the task assigned to these motes is twofold. As it has been listed before,
the mote has both USB and antenna communication capabilities. To take advantage of those
features, some of them act as gateways instead of only as a mere transmitters. These gateways
are responsible for interconnecting the close-by motes in small subnetworks, to later gather all
their sensing data and forward it.The rest of the motes only act as data transmitters using IEEE
802.15.4 wireless communication.
The compatibility with TinyOS allows us to adapt each mote behaviour to our necessities by
flashing any kind of program to their memory. In our case, we have written a program that
samples the sensor data every t seconds and sends it via radio message. The time t chosen for
Chapter 3. Architecture 25
the sampling rate varies depending on the location and the measure. For instance, measuring
the temperature inside a building should have a higher rate than measuring it outside, since
inside conditions can vary faster due to HVAC systems.
In the case of the gateway nodes, their behaviour is extended not only to sample sensor data,
but also to interconnect all the close-by sensors and gather all their sample data sent via radio
communication. Once all the data is gathered, it is forwarded via a serial forwarder. The
association between sampling nodes and gateways is done on-line: once the first message is
sent, the closest gateway will include the new node in its subnetwork and will be responsible
for its future messages. If a node is unable to reach a gateway, its messages are lost.
Regarding their autonomy, the sensors have a battery attached to them which allows us to place
them anywhere in the building. This arises a very common problem in this area which is the
autonomy problem. Since these devices can be sometimes hard to reach, their battery lifespan
must be long enough not to suppose a problem. To achieve this, the motes’ programs have
been written using a low power consumption model, in which devices only awaken to sample
data. This allows us to maintain them the majority of the time in sleep mode in order to lower
significantly their battery consumption and thus, extend their lifespan.
3.1.1.2 Virtual Sensors
As it has been said before, these sensors enable the possibility to scale a network without having
to spend the budget in real sensors. They are implemented as individual processes and all of
them are executed equally, but tuned with different parameters to create an heterogeneous, and
thus more real, scenario.
In order to create a variety of virtual sensors and manage them easily, a Java tool has been
created. This tool allows to start a new virtual sensor with the desired behaviour. By combining
this tool with scripts, it is possible to feed our system with any number of heterogeneous sensors.
The invocation of the tool is done as follows.
java client -port <PORT_ADDRESS > -id <LOCAL_ID > -mode <BEHAVIOUR > [-regonly]
The explanation of the arguments is the following.
Chapter 3. Architecture 26
-port <PORT ADDRESS> Local port to which data messages are sent. PORT ADDRESS
must be opened beforehand.
-id <LOCAL ID> Local identifier used to identify the local model of the virtual
sensor. The identifier selection and usage is explained in Sec-
tion 3.2.3.1.
-mode <BEHAVIOUR> Parameter to specify the virtual sensor mode. Currently, the
only supported modes are xm1000 and computer.
-regonly (optional) Registration only parameter. If it is set, the virtual sensors
only send 2 messages to guarantee that it has been listened.
After sending the 2 messages, they stop.
3.1.2 Environmental Interface
This layer is responsible for receiving all the data and parsing it accordingly to be valid for
the ServIoTicy layer. It can be seen as an standardisation message interface. To follow the
high usability paradigm that was mentioned before, this interface has been created by modules.
There are two main modules, called listeners, that receive the messages depending on the type of
mote that is sending data: the Physical Listener receives real sensor messages, and the Virtual
Listener receives virtual sensor messages.
Figure 3.1 shows both listeners and it can also be noticed that the physical listener is subdivided
into modules in order to be compatible with multiple platforms.
This structure allows to rapidly and easily upgrade the system with new platforms or new
type of motes by just creating the new platform-specific files and attaching it to the current
implementation.
This layer is responsible for communicating with ServIoTicy in order to push the updated sensor
data. To create this interaction, there are several local files needed to store sensitive information
and guarantee that the communcation is properly done. These files are stored as follows:
servioticy/
data/
template_ <platform >.json
data_ <localID >.json
models/
<platform >.json
sensor_ <localID >.json
res/
id<localID >
Something worth to mention is that the localIDs are local identifiers upwardly assigned to each
mote in order of arrival.
Chapter 3. Architecture 27
The data folder stores the updated messages for every mote of the system in the files data <localID>.
It also stores one template for each platform supported by the interface in the template <platform>.json
files. Details about the content of these files are shown in Section 3.2.3.2.
The models are directly related with the data structure. Each <platform>.json file specifies
the correct message structure for every supported platform. These templates are then copied
to sensor <localID> files to associate the correct localID with the correct model. An example
of a model is shown in Section 3.2.3.1.
The res folder contains the relationship between localIDs and ServIoTicy IDs. Section 3.2 shows
and explains the usage of these files in more detail.
Even though the necessity of this layer can be discussed, it has been decided to create it in
order to substantially lighten the software installed in the sensors and the gateways.
3.1.3 ServIoTicy
ServIoTicy is an online platform developed by the BSC [43] during the COMPOSE project
[44]. It allows for fast and simple composition of IoT data streams, offering a multi-tenant data
architecture. As for its communication capabilities, it allows REST and Publish/Subscribe
asynchronous communication.
The communication content must be transmitted by means of JSON formatted data-objects.
The extension and acceptance of this format as a standard allow us to homogenize all the
received data independently of the transmitting platform. The structure of the files used is
shown in Section 3.2.
These communication capabilities were the main reason for choosing the integration of the
platform inside our project. Combining this layer with our underlying environmental interface,
it is possible to completely hide the architecture of the WSN and also the heterogeneity of the
sensors to the public Internet or to the end user applications.
Figure 3.3 breaks down the platform in all its components. Since we are using this software as
a service, the elements inside the box are not necessarily relevant for our project. Focusing on
the interactions with the platform, it can be seen that having an Environmental Interface below
this layer makes things much easier.
By standardising the messages in the interface, the platform is directly fed with valid formatted
JSON messages that are then stored and processed. On the other side of the box, these data
are available for everyone that requests it via direct queries or a subscription pattern as it has
been previously mentioned.
Chapter 3. Architecture 28
Figure 3.3: ServIoTicy Architecture.
3.1.4 Application Layer
As the top layer of the stack, the Application Layer is responsible for interacting with the user
by attending their requests or by just showing the desired information. This layer can be filled
with any kind of end user application, but in order to take advantage of the underlying system
architecture, it is desirable that this application requires sensor data that is directly requested
or asynchronously received by ServIoTicy.
For instance, a non-interactive application may show in a real-time map the information obtained
from every sensor in order to allow the user to monitor a building or a house.
As it has been previously mentioned, this project aims to reduce the energy consumed in a
building by preventing wasteful scenarios in which elements are being unnecessarily used or
overused. It can be seen that the accomplishment of this goal requires the interaction with the
objects. However, this interaction must be automatic according to a set of restrictions that
guides the behaviour of such objects.
A real testing of this system would require the deployment of a WSN throughout the building.
This deployment is risky since there are no preliminary results that ensures the viability of the
solution. Instead, it has been decided to firstly build a simulator which models the building and
the external conditions as close as possible to reality. This will allow us to check whether it is
possible to save energy or not and then decide if the real deployment is worth.
All the specification and details of the simulator are explained in Chapter 4.
Chapter 3. Architecture 29
3.2 Specification
This section presents in more technical detail how the work-flow of the system is. It covers from
the flashing and insertion of a new sensor up to the reception of messages by the application
attached to the application layer.
3.2.1 Flashing a new device
This is one of the two manual actions in all the work-flow of the system. When a new mote
needs to be introduced, it firstly needs a valid software inside to be able to properly communicate
with the whole system. Since there are plenty of different platforms currently being sold in the
market, some parameters of the software need to be tuned before flashing.
These actions are easier when working with TinyOS. The final sampling software installed in
the motes is divided into 3 files and it is publicly available at GitHub [45]. Table 3.1 shows the
file division.
File Name Description
program.h Message structureprogramAppC.nc Components’ listing and function associationsprogramC.nc Actual implementation of the functions
Table 3.1: TinyOS nesC program file division.
This file division is imposed by TinyOS and the naming of the files is also relevant. The only
flexible part is the program name.
In order to better understand how the software works, the content of the files is shown and
explained in the following paragraphs.
The message structure located in the file program.h is the following:
Chapter 3. Architecture 30
#ifndef XM1000RADIO_H
#define XM1000RADIO_H
enum {
AM_XM1000MSG = 7
};
typedef nx_struct XM1000Msg {
nx_uint32_t nodeid;
nx_uint32_t temp;
nx_uint32_t hum;
nx_uint32_t light;
nx_uint32_t batt;
} XM1000Msg;
#endif
Firstly, the name of the program is defined. Then, a unique identifier is associated with the
message name. This unique identifier allows the receiver to forward the messages to the proper
listener to manage them accordingly. Then, the actual message structure is defined. However,
this file does not allow the receiver to parse the message properly. In order to allow the receiver
to know the message structure, a tool provided by TinyOS is used, which is the Message Interface
Generator (3.1.2 explains more in depth the usage if this tool).
Once the structure is defined, the file programAppC.nc associates each of the components with
a function as it can be seen in the following code:
Chapter 3. Architecture 31
#include "XM1000Radio.h"
configuration XM1000RadioAppC {}
implementation {
components XM1000RadioC as App;
components MainC , LedsC;
components new TimerMilliC () as Timer;
components ActiveMessageC;
components new AMSenderC(AM_XM1000MSG);
components new SensirionSht11C () as TempHumSensor;
components new HamamatsuS10871TsrC () as LightSensor;
components new VoltageC () as Battery;
App.Boot -> MainC;
App.Leds -> LedsC;
App.Timer -> Timer;
App.Packet -> AMSenderC;
App.AMPacket -> AMSenderC;
App.AMSend -> AMSenderC;
App.AMControl -> ActiveMessageC;
App.Temp -> TempHumSensor.Temperature;
App.Hum -> TempHumSensor.Humidity;
App.Light -> LightSensor;
App.Batt -> Battery;
}
In the beginning, all the needed components are listed. They are separated in three blocks
depending on their purpose. The first block lists the platform components such as the Timer and
the LEDs. Then, the Radio Communication is specified, with the message structure previously
defined for the sender. Finally, the different sensors are listed.
After the listing, each component is associated with a function of the Application in order to
merge the actual implementation with the component names.
File programC.nc contains the code for the different functions. First of all, all the physical
interfaces specified before are listed to be used:
Chapter 3. Architecture 32
module XM1000RadioC {
uses {
interface Boot;
interface Leds;
interface Timer <TMilli >;
interface Packet;
interface AMPacket;
interface AMSend;
interface SplitControl as AMControl;
interface Read <uint16_t > as Temp;
interface Read <uint16_t > as Light;
interface Read <uint16_t > as Hum;
interface Read <uint16_t > as Batt;
}
}
After the usage module, the implementation is divided into functions that are asynchronously
called every time a new event happens. Once the mote has booted, the Boot.booted() function
is called. The only purpose of this function is to initiate the Radio Message interface, to allow
further message transmissions.
event void Boot.booted (){
call AMControl.start();
}
When the Radio Message Interface is started, a new event is triggered and the function AM-
Control.startDone() is executed. This function starts a Timer which triggers every SAM-
PLE SECONDS. The sampling time t that was mentioned before can be modified in here.
int SAMPLE_SECONDS = 5;
event void AMControl.startDone(error_t error){
if (error == SUCCESS) {
call Timer.startPeriodic(SAMPLE_SECONDS * 1000);
}
else {
call AMControl.start();
}
}
Now, and every SAMPLE SECONDS, the event Timer.fired() is triggered, which contains the
core of the program. This method starts by requesting all the data of the sensors to later
build an AMPacket with the structure previously defined. After the construction, the packet is
broadcasted via Radio Antenna.
Chapter 3. Architecture 33
event void Timer.fired (){
call Temp.read();
call Light.read();
call Hum.read();
call Batt.read();
if (!busy) {
XM1000Msg* pkt = (XM1000Msg *) (call Packet.getPayload (&pkt , sizeof(XM1000Msg)))
;
pkt ->nodeid = TOS_NODE_ID;
pkt ->temp = TempVal;
pkt ->hum = HumVal;
pkt ->light = LightVal;
pkt ->batt = BattVal;
if (call AMSend.send(AM_BROADCAST_ADDR , &pkt , sizeof(XM1000Msg)) == SUCCESS) {
busy = TRUE;
}
}
}
When requesting sensor data by means of the read() functions, it has to be taken into account
that the values read are not correct measure values. Instead, some conversions have to be made
in order to adjust to digital readout to a proper measure. Specifically for the XM1000 mote,
the following functions give correct temperature, humidity and luminosity values respectively:
TCelsius = d1 + d2 ∗ SOt
RHlinear = c1 + c2 ∗ SORH + c3 ∗ SORH2 (%RH)
RHtrue = (TCelsius − 25) ∗ (t1 + t2 ∗ SORH) + RHlinear
Light =1.5 ∗ SOl ∗ 6250
4096
Where SOt, SORH and SOl are the raw digital readings of the sensors, and the rest of variables
are fixed coefficients. In the case of the true Relative Humidity, a temperature compensation
has to be performed taking into account the current temperature. Table 3.2 shows the value of
these coefficients, extracted from [41, 42].
Coefficient Value
d1 -40.1d2 0.01c1 -2.0468c2 0.0367c3 -1.5955 * 10−6
t1 0.01t2 8 * 10−5
Table 3.2: Conversion coefficients for XM1000 motes.
Chapter 3. Architecture 34
Once the Sensor.read() function ends, the function Sensor.readDone() is triggered. This func-
tion is responsible for applying the required conversions in order to obtain a valid measure value.
This value is then stored in a global variable to allow its future usage when building the packet.
Only the temperature function is shown since the rest of them are analogous to this.
event void Temp.readDone(error_t result , uint16_t value){
if (result == SUCCESS) {
TempVal = convert(value);
}
else {
printf ("Error reading temperature sensor \r\n");
}
}
When all the files are correctly created, the device is flashed with the new software using the
following commands:
make platform install bsl , USB_port
For instance, in the case of a XM1000 mote flashed using a UNIX OS and located in port 0,
the command is
make xm1000 install bsl ,/dev/ttyUSB0
After having flashed the mote, it automatically starts the booting process which will eventually
trigger the sampling and broadcasting of messages.
3.2.2 Creating the Perception-Environmental Interface Communication
Once the device is ready for sending sample messages, we need to ensure that the Environmental
Interface is capable of understanding the new format message. To do so, we make use of a
TinyOS tool called MIG (Message Interface Generator) that creates a Java class for a given
format message with methods that allow us to query the different message fields without having
to deeply understand the message structure. This class is then added to the Environmental
Interface as an extension.
To create this Java class, MIG is used as follows:
mig tool -target=known -tinyos -platform -java -classname=full -class -name msg -format -file
message -type -o output
The tool argument specifies which tool should be generated, in our case, the Java tool is used.
The msg-format-file specifies the application’s top level nesC file and the message-type specifies
the C type of the message being processed. This C type makes reference to the header file in
Chapter 3. Architecture 35
which the message-type is defined. As an output file, the platform name is used to maintain an
understandable file hierarchy. More information about the Message Interface Generator can be
found in the official specification [46].
The last module that needs to be created to complete the communication is the Listener. This
Java class is unique for every new platform introduced and can be shared between platforms
with the same message format. The Listener makes use of the created Java class by the MIG
to understand and easily query the message fields of the received packets.
It only contains the two following methods:
messageReceived(to, message)
parseMessage(message)
The first one is called when a new message arrives and the second one is responsible for adapting
the message format to a valid JSON format for ServIoTicy. The received sensor data is also
locally saved (only the last received value) and then pushed to the ServIoTicy platform. This
publication to the Internet triggers the creation of a new Service Object if the sender has not
yet been registered.
As it can be seen in the following block of code, the MIG reduces the code needed to treat a
new message
Message message;
XM1000Msg msg = (XM1000Msg) message;
msg.get_temp ();
msg.get_hum ();
msg.get_light ();
By simply using the platform name as a casting, the generic message is automatically converted
to an XM1000 message and the queries become much easier, just by asking for the name of the
different fields as msg.get field()
3.2.3 Creating a new Service Object and Pushing Data
Once everything is set, the system is now capable of managing the new platform messages.
Figure 3.4 shows the sequence diagram of every new message that is generated and sent through
the system.
As it can be seen, when a sensor sends a new message, it is firstly received by its gateway, who
acts only as a forwarder. Once this message reaches the environmental interface, the main logic
starts.
Chapter 3. Architecture 36
Figure 3.4: Create new Service Object sequence diagram.
First of all, it checks whether the localID is already associated with any Service Object ID. If
not, the registration of the device is triggered. Thus, the first message ever sent by every device
acts as a registration message.
3.2.3.1 Register new Service Object
In the case of having to register a new Service Object, the first thing that is done is the creation
of the sensor model file. This file contains a valid JSON structure in which the different data
channels are specified. These models are predefined templates for every platform that are then
copied with the proper name (currently, each sensor model is named as sensor <localID>). For
instance, in the case of a Computer sensor (sensor that tells whether the computer is on, off or
suspended), the template is the following:
Chapter 3. Architecture 37
{
"name": "Sensor",
"description ": "",
"streams ": {
"data": {
"channels ": {
"computer ": {
"type": "number"
}
}
}
},
"customFields ": {
"model": "Computer",
"location ": "",
"associations ": "computer/computer"
},
"actions ": [],
"properties ": []
}
The model needs to be completed by adding the sensor location. At the moment, the location
is manually introduced, but we are working on a GPS-based approach in which the system
automatically updates this field. Another important field inside the model is the name of the
streams. As it can be seen, this model only contains one stream called data, which will then be
used as part of the Publish/Subscribe communication parameters.
For the creation of the model, a localID needs to be assigned. This assignment is simply done
upwardly in order of arrival.
After creating the model, the registration with ServIoTicy is enabled. To do so, a new request is
made using as a parameter the model previously created. This request returns a unique identi-
fier, the Service Object ID. To ensure that future messages do not trigger again the registration,
the Service Object ID is stored in a local file called id<localID>.
As it has been previously said, the system must separate the south gate of the environmental
interface from the north gate. In order to achieve this, the Service Object IDs must be publicly
available from the Internet, to avoid the necessity to browse local files.
It has been decided to host a cloud relational database to store all the necessary information
to be able to use the Service Objects with any kind of application. Specifically, there is a table
with the following fields:
Service Object ID, Model , Location , Associations
The Service Object ID allows any application to take advantage of the Publish/Subscribe com-
munication available in ServIoTicy. Instead of having to constantly query the service for up-
dates, whenever a new one arrives, it is directly forwarded to the subscribers of the proper
Chapter 3. Architecture 38
Service Object. This asynchronous communication lowers the consumption by reducing the
necessity of constantly query the service.
The model and location are used to know which type of message is being received and also to
know where the sensor is located, to be able, for instance, to separate them by room.
The last field is an auxiliary one specific for our application. It is used to know the relation
between the different sensors of a device and the type of actuator that each one handles. For
instance, the following association
"temperature/hvac ,humidity/hvac ,luminosity/light"
means that the temperature and humidity sensors are related to the HVAC system, and the
luminosity sensor is related to the light. For detailed database information refer to Section 4.1.2.
The last needed action to complete the registration is the activation of the Publish/Subscribe
communication. To do so, another request to ServIoTicy is needed, in which the Service Object
ID is the only parameter. After enabling Publish/Subscribe communication, the messages sent
to ServIoTicy are forwarded to all the subscribers of that specific Service Object.
Now the registration is completed, and any future message will avoid the registration since the
association of the localID and the Service Object ID is stored in the local file id<localID>
3.2.3.2 Push Data
After the initial registration, any new message only triggers the pushing of the data to ServI-
oTicy. Specifically, when a new message arrives, the localID from the message allows the reading
of the Service Object ID. Then, the message is formatted to the proper following JSON structure
and sent to ServIoTicy. The following code shows a formatted message for a Service Object
composed by a stream that contains a single channel with values for humidity, luminosity and
temperature.
{
"lastUpdate ": 1441798021334 ,
"channels ": {
"humidity ": {
"current -value ": 52.93
},
"luminosity ": {
"current -value ": 1643
},
"temperature ": {
"current -value ": 13.470229680528277
}
}
}
Chapter 3. Architecture 39
Once the message is pushed, it most surely be stored as the last sent message. ServIoTicy saves
the messages taking into account the lastUpdate field, and the most recent message will always
be the one with higher value. ServIoTicy also ensures that it is eventually forwarded to all the
subscribers of the associated Service Object.
Chapter 4
Simulator
This chapter presents the tool built to cover the main goal of the thesis. This tool aims to
lower the energy consumption of a given building by avoiding states in which building elements
are wasting energy or being unnecessarily overused. Since the creation of a real WSN to test
our assumptions is expensive, this tool is integrated inside a simulator that mimics as close as
possible the real conditions of the building.
The conditions that the simulator takes into account are the external weather, the building
architecture and most importantly, people’s behaviour inside the building. As a building, it
has been decided to simulate the UPC Campus Nord D6 because of the high amount of energy
that can be saved according to the current behaviour of most professors that have their office
in there.
Regarding the building elements that the simulator keeps track of, only the most important
ones are chosen, which are HVAC systems, lights and computers.
4.1 Specification
Following the high usability paradigm that has been used when building the driver architecture
presented in Chapter 3, the simulator has been created by modules or managers.
As it can be seen in Figure 4.1, there is a central manager responsible for interconnecting the
rest of the modules as well as carrying on the simulation. This figure shows a basic schema in
which the interconnection between the rest of the managers is not drawn. Figure 4.2 presents
the class diagram which aims to explicitly display the relations between the different managers.
The next sections aim to break down each of the managers in order to better understand the
behaviour behind them and how all the elements are interconnected.
40
Chapter 4. Simulator 41
Figure 4.1: Simulator Managers.
Figure 4.2: Class Diagram of all the managers.
4.1.1 People Manager
As its name indicates, this manager is responsible for keeping track of each person of the
simulation and also for executing the actions that are requested by the main manager.
Each person that participates in the simulation must either be a Professor, a Student or a
PAS. Currently, each of these types have a profile assigned which dictates their behaviour. This
behaviour is implemented as a set of states that each person can individually traverse.
Figure 4.3 shows the state diagram of a person. Firstly, and before starting the simulation, a
file including all the people is read. This file contains the following format:
name , location , type
After reading all the file, people are marked as unassigned. When the execution starts, every
time a new room is fully specified (i.e. all the sensor have been registered and at least one
message has arrived for each of them), all the people belonging to that room are moved to the
outside state. The rest of the state changes are dictated on-line while running the simulation,
according to the profile of the person.
Chapter 4. Simulator 42
Figure 4.3: State Diagram of people’s actions.
4.1.1.1 User Profiles
As it has been previously said, each person must belong to the Professor, Student or PAS group.
The behaviour of each of these groups is specified using probabilities over time. That is, for a
given hour of the day, the probability of having a person executing an specific action is given.
This method has been chosen due to the possibility to create multiple simulations with variation
in the actions performed. Moreover, it is highly difficult to exactly mimic the behaviour of all
the people inside a building, but this method offers a good approach in which the uncertainty
is also taken into account by adding probabilistic decisions.
Currently, the models are static throughout the simulation. In the future, these models may
individually adapt to every occupant behaviour in order to extract patterns and offer more
accurate information about each of them.
The following sections present the current user profiles and their probabilities over time more
accurately.
4.1.1.1.1 Professor Profile
Figure 4.4 shows the probabilities over time for the possible actions that can be executed by
a professor. As it can be seen in Figure 4.4(a), the probability of entering the building is
maintained relatively high during the majority of morning hours. This is due to the fact that
entrance is not usually imposed, and some professors might have previous activities that delay
their entrance. After lunch the probability increases again because of the professors that work
on evening classes.
Regarding the random walks, Figure 4.4(b) shows that during the morning it is highly possible
for a professor to leave his office. This can be due to the necessity of having to give lessons or
Chapter 4. Simulator 43
because of meetings in bigger rooms. The trend is also maintained after lunch but with lower
probability. These random walks can last from 5 minutes up to 120 minutes, depending on its
purpose, which can be leaving for having a small break or attending to a meeting.
Lunch is usually centered during the midday but as it can be seen in Figure 4.4(c), some
professors might need to have lunch very early to avoid queues and time wasted. Regarding the
duration of their lunch time, it can vary between 30 minutes and 90 minutes.
The exit of the building shown in Figure 4.4(d) is mainly centered after lunch and in the evening.
Mostly all the professors have a complete working schedule and their activities do not allow them
to leave their office before the evening.
4.1.1.1.2 Student Profile
Figure 4.5 shows the probabilities over time for every student action. As it can be seen, the
flexibility of such actions is limited, since students usually have common fixed schedules due
to the class hours. Regarding their entrance, as shown in Figure 4.5(a), it usually happens
during a tight morning time interval (between 7h and 9:30h), or after lunch for the students
with afternoon timetables. This second interval is wider since afternoon entering hours may
vary between 13h and 16h.
With respect to random walks shown in Figure 4.5(b), students have a more relaxed behaviour
since they tend to leave classrooms once in a while. Even though the probability exists almost
throughout the whole working day, it can be seen that during midday the probability increases.
The duration of these walks is significantly small, from 5 minutes to 20 minutes, since class
hours are always one after the other. Lunch probabilities (Figure 4.5(c)) are very similar to
professor ones, since they both share the same dinning places and most of the working hours.
Students have between 30 minutes and 60 minutes to have lunch.
Figure 4.5(d) shows the exit probabilities, which are the most different ones compared to other
user profiles. Even though most of the students share the same timetable, few of them have
a reduced one. This behaviour is expressed by having significant exit probability after every
lesson class. Apart from that, the two common exit intervals are present (14h to 15:30h and
20h to 21:30h).
4.1.1.1.3 PAS Profile
As it can be seen in Figure 4.6, the time intervals in which every action can be executed are
very sharp due to the fact that PAS people have a fixed schedule with little flexibility. Current
Chapter 4. Simulator 44
0
0,1
0,2
0,3
0,4
0,5
0,6
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Entrance
Entrance
(a) Professor entrance probability.
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Random Walks
Random Walks
(b) Professor random walks probability.
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Lunch
Lunch
(c) Professor lunch probability.
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Exit
Exit
(d) Professor exit probability.
Figure 4.4: Professor probability over time for the different actions that can be executed.
Chapter 4. Simulator 45
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Entrance
Entrance
(a) Student entrance probability.
0
0,1
0,2
0,3
0,4
0,5
0,6
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Random Walks
Random Walks
(b) Student random walks probability.
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Lunch
Lunch
(c) Student lunch probability.
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Exit
Exit
(d) Student exit probability.
Figure 4.5: Student probability over time for the different actions that can be executed.
Chapter 4. Simulator 46
working schedule for PAS people starts at 9:30h and lasts for 4:30h until the evening turn enters
at 15h. This is a common schedule that can vary in some cases.
PAS people group multiple sectors, from administrative roles to cleaning services. This wide
role coverage makes difficult the accurately mimic the random walks, since some PAS people
do not leave their office but others do for most of their working hours. This has been solved by
providing a relatively high random walk probability for most of the working hours as it can be
seen in Figure 4.6(b). This heterogeneity is also shown in the duration of the walks, which can
vary between 5 minutes and 60 minutes.
Lunch time shown in Figure 4.6(c) is fixed between 13:30h and 15:30h depending on their turn,
since many PAS working places cannot be unattended for a long period of time. PAS people
have between 30 and 60 minutes to have lunch.
As regard to the exit (Figure 4.6(d)), their schedule varies from 16:30h up to 19:30h. This wide
range is due to the heterogeneity of PAS roles and the variability in the number of contracted
hours.
4.1.2 Database Manager
The Database Manager is responsible for creating and managing the connections to the database.
As it has been previously said, this database publicly exposes the necessary information to the
Internet in order to completely decouple any application from the underlying Wireless Sensor
Network. Once the simulator is started, a new connection to the database is created but, in order
to allow the system to receive messages from sensors that are connected once the application
has already begun, a Database Listener is also added. This listener is responsible for receiving
new insertion notifications and for managing them accordingly.
4.1.2.1 Database Schema
The current database is hosted in an internal server and is composed of 2 tables called ids
and associations. Even though both tables are hosted together, their purpose differ. The ids
table has been thought to be purely informative in order to allow applications to know the
characteristics and placement of the sensors. The associations table is more application-specific
and can be locally hosted. However, it has been decided to use the same host for ease.
Table 4.2 is specifically designed for our simulator. This table tracks the state of sensor regis-
tration with ServIoTicy to know whether the sensors have been registered or not. Once all the
sensors for a specific rule of a room are registered, the creation of the rule in the simulator is
Chapter 4. Simulator 47
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Entrance
Entrance
(a) PAS entrance probability.
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Random Walks
Random Walks
(b) PAS random walks probability.
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Lunch
Lunch
(c) PAS lunch probability.
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Exit
Exit
(d) PAS exit probability.
Figure 4.6: PAS probability over time for the different actions that can be executed.
Chapter 4. Simulator 48
Field Name Description
servioticy id Public Service Object ID used to query SerVioTicy for sensor data.model Name of the sensor platform or virtual model.location Location of the sensor, from a general scenario to a more specific one.associations Relation between model sensors and automation rules. This field can be seen
as an application specific one but its usage might be extended to others.created Time of sensor creation. For validity purposes.
Table 4.1: Ids table specification.
Field Name Description
location Location of the sensor, from a general scenario to a more specific one.actuator Type of actuator.sensors Relation between sensors and Service Object IDs.rule Name of the rule to be executed once the sensors are completed.registrations left Auxiliary parameter to know when the sensors have been fully specified.state Currently unused. State of the device after automatic actuations happen.
Table 4.2: Associations table specification.
enabled. Once every rule for every room have been specified, the simulator can be started and
this table remains unused until future simulations.
4.1.2.2 Database Listener
The Database Listener is one of the most important features that allows the on-line registration
of new sensors in the system without the necessity to stop and start it every time. The Listener
is constantly waiting for notifications of new row insertions in the database. These notifications
are sent by the underlying WSN Database Manager: every time a new sensor is registered
in ServIoTicy, a notification is sent to the database who instantly forwards it to the Listener,
informing about this new registration. Once this notification is received, it is possible to acquire
the newly inserted Service Object ID thanks to the created field and send the information to
the MQTT Manager in order to subscribe and receive future updates.
4.1.3 Rule Manager
This manager can also be seen as the Smart Manager. It is responsible for creating and assigning
to each newly created room the associated rules for it. Whenever a new event happens with
the people of an specific room, all the rules are evaluated to check whether it is possible to take
actions or not. These actions are primarily focused on increasing people’s comfort but also on
reducing the amount of energy consumed. This second decision process only takes place if it is
possible to do it without disturbing the people.
Chapter 4. Simulator 49
Currently, the only supported rules are related to HVAC systems, lights and computers. Never-
theless, additional rules can be easily added and already created ones can be upgraded. In the
near future, rules related to more consuming objects will be added, and the extension of the
environmental conditions will be performed. Passive elements such as windows and doors will
also be added.
4.1.3.1 HVAC Rule
This rule is responsible for comparing the current environmental conditions with the temperature
inside the room to decide which action must be performed.
Figure 4.7: State Diagram of the HVAC Rule.
Figure 4.7 shows the state diagram of the HVAC rule. Initially, all the HVAC systems are off
since the building is empty. From this state, it is possible to switch the HVAC on when a
person enters the room and the temperature is not within the acceptable range. Moreover, if a
person enters the room but the current temperature is good enough, the HVAC is switched to
a maintain state in which the amount of consumed energy is lower than when working at full
capacity.
If the HVAC system is on, there are several possibilities. First of all, if there is a necessity of
keeping it on, its behaviour may vary between heat and cold, depending on the current room
temperature. Once the desirable temperature is reached, the HVAC is switched to the maintain
state in order to save energy. In the event of the occupant leaving the room, going for lunch or a
good outdoor temperature, there is no necessity of maintaining the HVAC on, so it is switched
to the off state. However, random walks are not equally treated since they are usually for a
short period of time. In that case, the HVAC is set to its maintain state until the person returns
to the room.
Chapter 4. Simulator 50
The following code summarizes the rule behaviour:
If HVAC is ON:
- Change to OFF: room is empty OR good environmental temperature
- HEAT or COLD: person inside AND bad environmental temperature
- MAINTAIN: person inside OR random walking
If HVAC is OFF:
- Change to ON: someone has entered AND environmental temperature is bad
- MAINTAIN: person inside OR random walking
Apart from switching the state of the HVAC systems, this rule is also responsible for simulating
the moderation of the temperature inside a room. Currently, the model that informs about
which is the good environmental temperature is specified using the temperature and humidity
models shown in Sections 4.1.5.1 and 4.1.5.2. Regarding the values, the following code shows
when the current temperature T is good enough by also taking into account the current relative
humidity RH.
22 < T ≤ 23 if RH < 45
21 ≤ T ≤ 22 if RH > 60
21.5 ≤ T ≤ 22.5 if 45 ≤ RH ≤ 60
As it can be seen, relative humidity slightly modifies the comfort temperature due to the thermal
sensation phenomena. When the HVAC is off, every time the rule is executed, the temperature
of the room varies in a 1% of the difference between outside and inside temperature until any
of the above requirements are met. The following formula shows the behaviour in that case:
N = R± |E −R|100
Where N is the new room temperature, R is the current room temperature and E stands for the
current environmental temperature. This temperature moderation is executed every 1 minute.
In the case of the HVAC system being on, the temperature variation differs. In this case, every
10 minutes, the temperature of the room suffers a 1 oC variation. All of these decisions are a
simplified version of the work done in [47].
4.1.3.2 Light Rule
This rule compares the current state of the light inside a room with the environmental light. It
has been seen that many office rooms use the light when it is not strictly necessary, or even it
is left on whilst no one is inside.
Chapter 4. Simulator 51
Figure 4.8: State Diagram of the Light Rule.
Figure 4.8 shows the state diagram of the Light rule. This rule is very intuitive and straight-
forward. The light is switched on whenever someone enters the room and the environmental
light is not enough for normal office and PC work. The light level is constantly being monitored
so that the light can be switched on if the environmental light level goes under the acceptable
threshold. This can only happen if the room is not empty.
In order to switch the light off, the room must be empty or, contrary to before, the environmental
light level must surpass the acceptable threshold. The current acceptable threshold, according
to [48], has been set to 500 lux. The decision of using lux instead of lumens lies in the fact that
sensing data obtained from real sensors are given in that measure.
This behaviour may be summarized as follows:
If light is ON:
- Change to OFF: room is empty OR environmental light is enough
If light is OFF:
- Change to ON: someone enters the room OR
environmental light is bad while occupant inside
4.1.3.3 Computer Rule
Computers are a very delicate element when working in an office. Most of the people leave
their computers on during the night not to have to switch it back on the next day. If this
behaviour is allowed with no restriction and more people adopt it, the amount of energy being
wasted at nights is huge and unnecessary. Nevertheless, leaving the computer on at night can
be necessary sometimes. For instance, time-intense simulations are usually executed during non
working hours to avoid waiting for results. The current rule does not allow this behaviour, but
it will be introduced in future upgrades.
Regarding the actual rule, it has been soften from the original one by introducing a suspended
state in which the computer is just suspended if the person leaves the room for a moment.
Figure B.1 shows the state diagram of the Computer rule. Whenever a person enters the room,
the computer is automatically booted. From this new state, the possibilities are switching it
Chapter 4. Simulator 52
Figure 4.9: State Diagram of the Computer Rule.
back off if the person leaves the room for an exit (i.e., leaving the building until the next day),
or transitioning to the suspended state because the person is leaving for a moment (i.e., having
a meeting in another room or lunch time).
The behaviour is summarized as follows:
If computer is ON:
- Change to SUSPENDED: everyone has left for a meeting or lunch
- Change to OFF: occupant has left the room
If computer is SUSPENDED:
- Change to ON: occupant has returned to the room
If computer is OFF:
- Change to ON: occupant has entered the room
4.1.4 MQTT Manager
This manager is responsible for creating the connection between ServIoTicy and our application.
Moreover, it can also be seen as the entry point for all the data that are received since ServIoTicy
is the unique provider.
As it has been previously said, in order to receive update messages from the Service Objects,
it is needed to subscribe to them. This step is introduced after connecting to ServIoTicy, and
the Service Objects IDs are known thanks to the external database explained in Section 4.1.2.
After querying the database, a new subscription is created for every Service Object ID with the
following format:
topic = APIKEY/id/streams/channel/updates
client.subscribe(topic)
Chapter 4. Simulator 53
Even though the channel name is flexible, it has been decided to use the same channel for every
type of sensor named data in order to ease the implementation. However, this pattern can be
changed by adding a more complex implementation to the subscription function.
Additionally, the implementation of the protocol requires the creation of a class extending
from MqttCallback. When a new MQTT connection is performed, the callback is set as an
asynchronous reception entry in which new Publish/Subscribe messages will arrive without
having to constantly query the service. This callback must implement 3 specific functions:
void deliveryComplete(IMqttDeliveryToken arg0)
void messageArrived(String topic , MqttMessage message)
void connectionLost(Throwable arg0)
For our purpose, the first function does not need to be implemented since the simulator is not
going to send messages to the service, only receive them. Once a new message is received,
the second function is called. The topic parameter allows the simulator to know the Service
Object ID that sent the message. With this information and the current implementation of the
database, it is possible to know all the necessary specifications of the sensor. This approach
allows further updates of the models if required information needs to be displayed or used.
Now that the sensor is detected, the message can be parsed with the appropriate structure,
and the information is passed to the core of the simulator to create the necessary objects and
associations.
4.1.5 Models
In order to recreate as close to reality as possible the simulations, several external conditions
have to be taken into account. For our purpose, in particular, weather is a very important factor
that can radically change the results. For instance, if the light outside is sufficient, all the inside
ones can be switched off, lowering the energy consumption considerably.
Currently, models for temperature, humidity and luminosity are used. The modular implemen-
tation eases future enhancements and extensions of such models. Since these measures can be
expressed by a single value, the models are expressed as an average hourly measurement for the
duration of a day.
4.1.5.1 Temperature
Figure 4.10 shows the current daily temperature model used. As it can be seen, the temper-
ature is maintained in lower values throughout the day. These values have been obtained by
monitoring the daily temperature of Barcelona in a standard day of November. Even though
Chapter 4. Simulator 54
this model does not represent the whole year, it can be seen that the summer case would be
analogous but, instead of using the HVACs to heat the room, they would be used to cold it.
This model represents the most important external influence since heavy energy consumption
elements such as HVAC systems rely on it in order to alter their behaviour. Temperature values
shown in the plot are expressed in Celsius degrees.
0
2
4
6
8
10
12
14
16
18
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
TEM
PER
ATU
RE
(ºC
)
HOUR
Daily Temperature
Figure 4.10: Weather’s temperature model.
4.1.5.2 Humidity
The humidity model shown in Figure 4.11 is the one with less impact when deciding the be-
haviour of the simulation elements. Humidity slightly modifies the comfort temperature inside
a building. Therefore, this model is also linked to the HVAC systems. The correlation between
humidity and temperature lies in a phenomena called thermal sensation. When the tempera-
ture is cold, humidity intensifies that sensation. Analogously, when the weather is hot, humidity
also augments that sensation. Values shown in the plot express the hourly relative humidity
percentage.
0
10
20
30
40
50
60
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
REL
ATI
VE
HU
MID
ITY
(%)
HOUR
Daily Relative Humidity
Figure 4.11: Weather’s humidity model.
Chapter 4. Simulator 55
4.1.5.3 Luminosity
The luminosity model shown in Figure 4.12 is directly related to the light rule explained before.
As it can be seen, during the morning the amount of lux is very low, and the value increases as
the Sun rises.
0
200
400
600
800
1000
1200
1400
1600
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
LUX
HOUR
Daily Luminosity
Figure 4.12: Weather’s luminosity model.
4.1.5.4 Building
The specification of the building is another key point for the simulation. As it has been pre-
viously said, the first simulations have been run using the UPC Campus Nord D6 building
structure since their behaviour is known and it will also be possible to physically test if the
obtained results are actually relevant.
Currently, the building is divided into rooms that can be either professor, student or pas rooms.
Professor rooms are individual rooms composed by 2 computers, 5 lights and 1 HVAC system.
In the case of student rooms, since every one can hold up to 15 students, there are 15 computers.
Moreover, 1 HVAC system is responsible for the whole room and 5 lights are distributed across.
As for the PAS rooms, even though they are not all equal, for a first approach the model has
been homogenised to ease the implementation. Currently, each room contains 3 computers, 5
lights and 1 HVAC system and the average number of people inside these rooms is 5.
Regarding the number of rooms of each type, it can vary throughout different simulations to
see whether different building specifications share the same energy savings or not. In the case
of the main simulation, the building is composed of 40 professor rooms, 5 students rooms and
5 PAS rooms. Additionally, the second simulation is performed with 35 students rooms and 5
PAS rooms to check the behaviour variation of a building mainly composed of shared rooms.
Chapter 4. Simulator 56
4.1.5.5 Electric Power Usage
This section presents the energy model used for every consuming device used in the simulation.
Currently, the only devices that contribute to the consumption of the building are HVAC sys-
tems, lights and computers. However, additional devices can be easily added by specifying their
consuming model and their number in each of the different rooms.
HVAC systems have 3 possible states, which are on, off and maintain. While the HVAC is in off
state, its consumption is negligible. While being in the on state, this device reaches the highest
power usage, which are 1200W . The maintain state also consumes a vast amount of energy, but
it is relatively lower compared to the on state. Specifically, its power usage is approximately
900W . This is due to the fact that when reaching the desired temperature, there is no necessity
to maintain the compressor on to continue heating or cooling the room. Instead, only the fan
is kept working. After some time, when the temperature varies, the compressor will start again
for a short period of time. This cycles allow the saving of a large amount of energy.
Regarding the lights, their state can only be on or off. Same as before, lights in the off state
does not consume energy. When they are in the on state, each light uses 40W .
As for the computers, their state can either be on, off or suspended. Switched off computers,
again, do not have any energy consumption, and if they do, it is actually negligible. While
being in the on state, their power reaches 200W . If they are switched to the suspended state,
their power is lowered until the 25W . Table 4.3 summarizes the consumptions for every given
possible state. As it can be seen, some of the states are not currently being shared. This can
change in the future with new updates and new model improvements.
Device State
OFF ON Maintain Suspended
HVAC 0 1200 900 -Lights 0 40 - -Computer 0 200 - 25
Table 4.3: Energy power of devices in every state in Watts.
Additionally, the usage of sensors and gateways in the system impacts the energy consumption
negatively, since they also need energy to work. This consumption has to carefully be taken into
account in order to later check whether the development of the new system allows the saving of
energy.
As it can be seen in 4.4, the consumption of the sensors compared to the actual devices is almost
negligible. Before running any simulation, these data allows us to think that the impact of such
devices in the overall consumption will be almost null and that any savings that are achieved
will be legit.
Chapter 4. Simulator 57
Device State
ON Idle Sleep
Sensor 0.05 0.02 0.01Gateway 10 - -
Table 4.4: Internet of Things devices power in Watts.
4.1.6 Register
The register is the module of the simulator responsible for maintaining the state of every con-
suming element updated and also for calculating the energy consumption at each step.
To keep track of the everything, the register contains a separate counter for every state of every
element that contributes to the energy consumption. For instance, as it was previously said,
HVAC systems have three states: off, on and maintain. Therefore, the register will contain a
counter for the HVACs in the on state and the HVACs in the maintain state. There is also
an off state counter that might seem irrelevant, but it is used to avoid possible simulation
inconsistencies in the number of devices.
For simulation purposes, this approach is good enough since it covers all of our necessities.
However, in the future this module will be substituted by creating specific classes for every
consuming element that keep track of their state and allows the introduction of single custom
behaviour.
4.2 Work-flow
This section aims to deeply explain all the logic behind the simulator and how the simulations
are performed. In order to take advantage of the architecture developed, and allow the simulator
to receive real sensor data, the work-flow can be divided into two phases.
The first phase can be seen as a preparation step. During this phase, the simulator asyn-
chronously waits for sensor messages until all of them are registered. Once everything has been
registered, the second phase starts and the simulation is run in one of the possible modes. The
decoupling of these two phases allows us to disable the simulations in the future, when a real
deployment of the system will be performed.
Figure 4.13 shows an overall view of both phases. As it can be seen, during the beginning, all
the connections are created and the subscriptions to ServIoTicy are enabled. The information
for the connections is read from an external file that contains all the configuration. By using
this approach, it is possible to change the database or the ServIoTicy server without having to
modify the application.
Chapter 4. Simulator 58
Figure 4.13: Complete simulation work-flow.
Chapter 4. Simulator 59
After that, the first phase starts with a loop that is maintained until all the rooms are defined
and all the people are assigned. This steps are deeply explained in Section 4.2.1.
When the loop is finished, the simulation is run. Table 4.5 shows the current available modes
and their purpose.
Mode Description
Mode 0: Basic Scenario All the energy consuming elements are on between entranceand exit.
Mode 1: Current Scenario Rules are applied to lights and computers, but HVACs are onfrom 7am to 8pm.
Mode 2: IoT Scenario Rules are applied to all elements throughout all the day.Mode 3: Repeat Simulation The list of events obtained from the last simulation is repeated.
Table 4.5: Simulation Modes.
Even though current modes are limited, it is possible to create a new simulation schema and
add it to the implementation by simply assigning an unused mode.
4.2.1 Preparation of the Simulation
The preparation starts when the application is run. This phase is responsible for building
the scenario defined by the sensor models from scratch. Since this information is not known
beforehand, the system creates the rooms as the sensors’ new locations arrive.
As Figure 4.14 shows, every time a new sensor message arrives, it is directly forwarded to the
main manager. The topic allows the extraction of the Service Object ID, and the static database
previously created informs about the current location of this Service Object.
Now, it is possible to start the registration process. First of all, the system checks whether the
location was previously created or not. If not, the new room is built and, additionally, all the
people of that room are assigned to it.
With the room already in the system, the process for each sensor is analogous. Firstly, the
manager checks whether the sensor inside an specific room exists. If not, the sensor is created
and attached to the room. Something worth to mention is that received messages often contain
information about more than one sensor. In order to cope with that possibility, each message
is deeply examined and each value is treated as an individual sensor. Therefore, a message
containing temperature, humidity and luminosity will create 3 simulation sensors inside the
room.
While registering a sensor, it is also possible to complete an association rule as explained in 4.2.
If a rule is completed, the rule manager of that specific room registers it.
Chapter 4. Simulator 60
Figure 4.14: Preparation of the Simulation Sequence Diagram.
Chapter 4. Simulator 61
Now, every future message of an already registered sensor will not have any impact on the
structure of the building and only the data will be read and used accordingly.
In order to finish this phase, two conditions have been set. The first condition is related to
the rooms: every room that has been created in the system must have all its sensors defined
and all its rules registered. Even though the number of rooms and their locations are not
known beforehand, the number of sensors in each one is predefined as it has been stated in
Section 4.1.5.4. The second condition is related to the people: all the people that is specified in
the people’s file have to be assigned to a room.
4.2.2 Running the Simulation
Now that the building schema has been created and all the rooms are fully specified, it is possible
to start the simulation. Before starting it, a record file is enabled to save all the events that will
happen in order to easily repeat the simulation afterwards if needed.
Simulations last for 24 virtual hours, and they are expressed in steps. Currently, each hour
is composed of 360 steps, which makes a full simulation last for 8640 steps. The main de-
cision behind those arbitrary numbers is strongly related to the HVAC model explained in
Section 4.7. After having assorted both simulation steps and temperature variations over time,
it has been decided to simulate people’s transitions every 5 minutes. That is, every 30 steps
(CURRENT STEP % 30 == 0 ), the simulator moves to a new state.
As for the people, during every transition phase it is only possible to move from one state to
another, without doing multiple jumps. Since the order of checking the transitions matter, the
following one has been purposed:
1. Enter building
2. Go for a random walk
3. Return from the random walk
4. Go for lunch
5. Return from lunch
6. Leave building
After moving the people accordingly, the rule manager of every room that has suffered a change
executes the rules in order to check whether it is necessary to modify the current state of any
element. Then, the current energy consumption is calculated. This allows us to draw the
evolution in consumption throughout the simulation and compare different scenarios.
Chapter 5
Results
This chapter presents and analyses the average results obtained after running several simula-
tions. All the parameters and decisions made have been presented in Chapter 4.
Results are shown in multiple comparisons. First of all, an overall comparison of the power
usage between the current simulation modes is shown to check whether it is possible to save
energy by using the Smart Manager. Moreover, in order to see how the HVAC, computer and
lights modify their state, additional plots are shown linking their state evolution with their
direct environmental conditions.
5.1 Office Building Simulation
This section aims to compare the UPC Campus Nord D6 building energy consumption using
the currently available modes in the simulator.
Although it is possible to only show the results obtained from the simulations in which the
Smart Manager is active, a comparison is needed in order to conclude if they are actually good
enough to carry on a real deployment.
The Basic Scenario of the simulator covers this necessity by calculating the overall energy
consumption when all the consuming elements are on throughout the working hours. That is,
the devices of every room are only on between the entrance and exit of the person responsible
for that room, independently of his behaviour throughout these hours. Moreover, simulations
using this scenario are run with all the smart elements disabled. That is, HVAC systems do
not control by themselves the temperature of the room and the computers have all the energy
aware solutions disabled. Having these conditions, this scenario can be seen as an upper energy
consumption threshold. Even though it might seem extremist, the current behaviour of people
inside the building is accurately reflected with these decisions.
62
Chapter 5. Results 63
The second scenario, the IoT scenario, is the one in which all the Smart capabilities are on. This
means that it has to also be taken into account the consumption of IoT devices such as sensors,
gateways and servers that are monitoring environmental conditions. During these simulations,
energy consuming elements change their behaviour accordingly as explained in Chapter 4.
Additionally, the current scenario has also been implemented in which HVAC is monitored as
a unique system which is on from 7 am to 8 pm, without taking into account temperature
regulations or unnecessary usage. For the rest of the elements, (lights and computers), the same
rules as the IoT scenario have been utilised.
0
20
40
60
80
100
0 1 2 3 4 5 6 7 8 9 10
11
12
13
14
15
16
17
18
19
20
21
22
23
KIL
OW
ATT
HOUR
Office Building Electric Power
Basic Scenario Current Scenario IoT Scenario
Figure 5.1: Office building energy consumption history comparison.
Figure 5.1 shows the electric power in kilowatts used at every moment throughout a whole day.
As it can be seen, during the initial daily hours the power usage is negligible due to the fact that
no elements are on since the building is empty. Once the entrance hour is reached, typically
between 7 am and 9 am, it can be seen that the power of the basic and the IoT scenarios is
relatively equal because of the necessity to adjust room temperatures by using the HVACs at its
full capacity. However, once the desired temperature is reached, which usually happens after 2
to 3 hours, it can be seen that the IoT scenario achieves a good energy saving by turning HVAC
systems into maintain state, disabling the compressor which is the element that can potentially
consume the majority of the energy.
If compared to the current scenario, it can be seen that the power usage is much more distributed,
and elements are switched on as they are needed, instead of having the sharp power peak at 7
am.
When most of the people have arrived, the power usage of the basic scenario is kept at its high
level due to having everything on, but the IoT Scenario presents variability thanks to the actions
taken when people leave their room for a short period of time. Moreover, when lunch hour is
reached, the IoT Scenario lowers the building power usage substantially.
Chapter 5. Results 64
The current scenario also presents variability during working hours. However, the IoT scenario
achieves good energy savings thanks to the intelligence granted to the HVAC systems.
In the afternoon, people start to leave the building, and thus, the power of all the scenarios is
reduced. The basic and the IoT scenario even reach similar values until all the people have left
the building. In the case of the current scenario, even if all the people have left before 8pm, the
HVAC is kept on wasting energy.
Scenario Avg Hourly Cons Total Daily Power Peak
Basic 26,83 kWh 643,95 kW 81 kWCurrent 37,47 kWh 899,26 kW 79,55 kWIoT 18,46 kWh 442,94 kW 68,51 kW
Table 5.1: Overall Office building energy consumption results.
Table 5.1 shows the average hourly energy consumption in kilowatts−hour as well as the overall
daily energy consumption. As it can be extracted from the table, the IoT Scenario allows the
savings of a 30% of energy by enhancing consuming devices with Smart technology compared
to the basic scenario. Taking into account that this is an ideal simulation analysis, and that in
real developments this percentage would possibly not be reached, it is still a good enough result
to continue believing that an IoT building enhancement allows the savings of a good amount
energy.
If compared instead to the current scenario, in which a huge amount of energy is wasted, the
savings ascend to almost 50%. This result has to be carefully taken into account due to the
model used for the simulation. The importance of HVAC systems in the current scenario makes
this result susceptible to strong changes depending on the model used. Therefore, in order to
accept this result, additional steps should be taken in order to completely mimic the behaviour
of the HVACs.
From this point, any additional feature such as prediction and scheduling will lower the con-
sumption even more if optimal steps are taken. However, there exist another aspect to take into
consideration when trying to reach the optimality, which are the needed effort and resources to
improve the solution. That is, there will be one point in which resources would cost more than
the actual savings that they provide, so trying to reach a good enough savings percentage is
sufficient.
According to current average kilowatt-hour pricing, which is around 0,145 ¤/kWh, the amount
of money saved by enhancing the building with Smart technology is around 29 ¤/day compared
to the basic scenario and 65 ¤/day if we take into account the current scenario.
Chapter 5. Results 65
5.1.1 Temperature
This section aims to show how the temperature of a room evolves throughout the simulation
due to the variations of the HVAC system and the outdoor temperature.
0
1
2
0,0
5,0
10,0
15,0
20,0
25,0
0 1 2 3 4 5 6 7 8 9 10
11
12
13
14
15
16
17
18
19
20
21
22
23
HV
AC
STA
TE
TEM
PER
ATU
RE
(ºC
)
HOUR
Temperature
Environmental Temperature Room Temperature HVAC State
Figure 5.2: Office building temperature evolution.
As it can be seen in Figure 5.2, the outdoor temperature follows the same pattern as previously
shown in Figure 4.10. Additionally, the state of the HVAC system is shown by referencing its
on state with a 2, its off state with a 0 and its maintain state with an intermediate value.
From the plot, some conclusions can be extracted. Firstly, since indoor temperature is not
usually the one desired when arriving, the HVAC system must start adjusting the temperature
by working at its full power. However, once the temperature has been reached, its state can
change to maintain, and this state will be held as long as the room is occupied or it is left for
a short period of time. Lunch has been considered as a long enough leaving to keep the HVAC
system working. For this reason, it can be seen in the plot that during lunch hours the HVAC
is switched off. Even though the HVAC is switched on again when returning after lunch, the
power needed to adjust again the room temperature is much less than the potential power of
maintaining it in a maintain state during the lunch period.
5.1.2 Lights
Similar to the room temperature shown in the above section, this section aims to show how the
light state varies depending on the outside luminosity.
As it can be seen in figure 5.3, the luminosity of the room is strongly altered by the outdoor
one. For this reason, outside lux is not shown in this figure since it follows the same pattern as
the inside one for most of the time. Focusing on the state of the lights, it can be seen that its
Chapter 5. Results 66
0
1
0
200
400
600
800
1.000
1.200
1.400
1.600
0 1 2 3 4 5 6 7 8 9 10
11
12
13
14
15
16
17
18
19
20
21
22
23
LIG
HTS
STA
TE
LUX
HOUR
Luminosity
Room Lux Lights State
Figure 5.3: Office building lux evolution.
state is maintained off until the person enters the room, which is usually between 7 and 9 am.
Once this occurs, indoor lux is kept at an appropriate working value. However, when outdoor
lux reaches a good enough level, lights can be switched off and thus, save energy. Something
worth noticing is that once the outside lux is acceptable, indoor lux is not regulated by any
means. In future updates this will change thanks to passive elements such as windows.
5.1.3 Computer
In the case of the computer, the comparison cannot be made against any environmental element
since computers only take into consideration the behaviour of the room’s occupant.
0
1
2
0 1 2 3 4 5 6 7 8 9 10
11
12
13
14
15
16
17
18
19
20
21
22
23
CO
MP
UTE
R S
TATE
HOUR
Computer
Computer State
Figure 5.4: Office building computer evolution.
Chapter 5. Results 67
Figure 5.4 shows the state transitions of a computer inside a room. Value 2 references the
on state, the suspended state is referenced by the value 1 and value 0 makes reference to the
off state. As it can be seen, during the morning, transitions between on and suspended are
performed due to the short period random walks. Once the lunch hour arrives, the computer
is also switched to suspended. Even though lunch usually takes a reasonable amount of time,
switching off the computer during that period could possibly decrease people’s comfort when
returning to their room. During the evening, in the case of the showed room, professor does
leave his room for another short period of time. Therefore, the computer transitions again
between the on and the suspended states.
As it can be extracted from the plot, this graph is clearly influenced by the behaviour of the
people. Hence, the state transition of the people occupying the room can be deducted from
here.
5.2 Study Building Simulation
Additionally to the main simulation of the D6 building, it has been decided to check the results
of a similar building in which the office room and students room numbers are interchanged.
That is, the building is mainly composed of shared rooms.
This has been done to check whether the composition of the rooms have any effect on the
overall energy consumption results since the state pattern of the consuming devices change
significantly. For instance, since shared rooms are most of the time occupied, the time windows
in which devices can be turned off are very small or even non existent.
0
10
20
30
40
50
60
70
80
0 1 2 3 4 5 6 7 8 9 10
11
12
13
14
15
16
17
18
19
20
21
22
23
KIL
OW
ATT
HOUR
Study Building Electric Power
Basic Scenario Current Scenario IoT Scenario
Figure 5.5: Study building energy consumption results.
As it can be seen in Figure 5.5, the basic and the IoT scenario present an almost equal initial
behaviour. Similarly to the previous simulation, this is due to the fact that during entrance
hours, almost every room must switch all the devices on in order to adjust the room to a proper
Chapter 5. Results 68
comfort level. In the case of the current scenario, it can be seen that HVAC is switched on
beforehand, but the behaviour of the subsequent hours presents a very similar shape to the
other scenarios.
Once rooms have been adjusted, it can be seen that the IoT scenario substantially reduces
energy power mainly thanks to the intelligence granted to the HVACs. However, it can also be
seen that the current scenario reduces the energy consumption even though HVACs do not have
any intelligence.
During the rest of the hours, the variability of all the scenarios is very limited, and this is
due to the fact that shared rooms are very restricted in terms of state transition possibilities.
When lunch hour arrives, slight variations are seen in the current and the IoT scenario due to
computer transitions. In the evening, when people start to leave the building, all the modes
start to reduce the electric power usage. However, the current scenario achieves this slowly since
HVACs cannot be turned off by any means.
In this particular simulation, it can also be seen that the current scenario even turns the HVAC
system off earlier than expected, since at 8 pm there are still people inside, as it can be deducted
from the other two scenarios.
Scenario Avg Hourly Cons Total Daily Power Peak
Basic 30,49 kWh 731,7 kW 70,2 kWCurrent 33,52 kWh 804,61 kW 71,4 kWIoT 23,92 kWh 574,12 kW 70,31 kW
Table 5.2: Overall Study building energy consumption results.
Table 5.2 shows a summary of the consumptions obtained. As it can be seen, having a building
mainly composed of shared rooms has a different impact in the consumption than the first
simulation performed. Even though the savings are still significant, around 22% compared to
the basic scenario, this percentage has been substantially reduced due to the inability to modify
the state of the consuming elements every small time window due to their absence.
If compared to the current scenario, the savings are higher, around 28% but, equally to stated
in the first simulation, this result must be carefully taken and the HVAC model must be also
taken into consideration.
Another value to analyse is the peak electric power. As it can be seen, the IoT scenario presents
a higher peak value than the basic scenario and this can be explained because of the necessity
to switch everything on during the first daily hours. This initial behaviour is presented in
these both scenarios, but the IoT one has to also take into consideration the electric power of
monitoring devices such as sensors, gateways and servers.
Chapter 5. Results 69
Following sections present the behaviour of both HVAC and lights in the case of shared rooms.
In this simulation, it has been decided to not show the behaviour of the computers since it
follows the same pattern as the previous simulation. The only difference is that rooms are
composed of more computers, but each of them behaves as an individual.
5.2.1 Temperature
As it has been previously said, since the building is mostly composed of shared rooms, the
elements must remain working for a long period of time during the day. Figure 5.6 shows the
temperature evolution comparison between outdoor and room temperature as well as the state
of the HVAC system. As it can be seen, once the room is occupied and the HVAC system
achieves the desired room temperature, it changes its state to maintain and remains for the
rest of the day until the room has been emptied. Therefore, shared rooms are less flexible than
individual rooms since the devices suffer much less state transitions.
0
1
2
0,0
5,0
10,0
15,0
20,0
25,0
0 1 2 3 4 5 6 7 8 9 10
11
12
13
14
15
16
17
18
19
20
21
22
23
HV
AC
STA
TE
TEM
PER
ATU
RE
(ºC
)
HOUR
Temperature
Environmental Temperature Room Temperature HVAC State
Figure 5.6: Study building temperature evolution.
5.2.2 Lights
In the case of the lights, the behaviour does not suffer any variation if compared to the first
simulation. This is due to the fact that most of the people’s state transitions are done once the
outdoor light is good enough. Therefore, the variation is not reflected in the states of the lights.
5.3 Deployment Cost
This section aims to calculate the overall cost of deploying the Internet of Things devices
virtually utilised in the simulations to create a real scenario in the D6 Campus Nord building.
Chapter 5. Results 70
0
1
0
200
400
600
800
1.000
1.200
1.400
1.600
0 1 2 3 4 5 6 7 8 9 10
11
12
13
14
15
16
17
18
19
20
21
22
23
LIG
HTS
STA
TE
LUX
HOUR
Luminosity
Room Lux Lights State
Figure 5.7: Study building lux evolution.
The specification of the building is explained in Section 4.1.5.4. Something that has to be taken
into account is that when doing a real deployment of such system, additionally to sensors and
monitoring devices, actuators are also needed.
Table 5.3 summarises all the devices needed and their cost. The XM1000 sensor, as previously
explained, is responsible for monitoring room environment conditions. Hence, each room must
contain one of these sensors. Regarding the monitoring and actuation of computers, each of
them must contain a complete system composed of a power monitoring to know its state, and
also an actuator. Even though it is difficult to find current solutions in the market, it has been
estimated that the cost of such mechanism is the one shown in Table 5.3.
Light monitoring and actuation is similar to the computer one. However, their cost is slightly
superior due to the difficulty to integrate them into the current building structure.
Regarding HVAC monitoring and actuation, since these systems already have some intelligence,
the monitoring part is easier and cheaper. However, actuators still need to be added.
Gateways have been thought as small computers connected to the Internet responsible for inter-
connecting and gathering all the sensors, creating a unique WSN. The position of these gateways
inside the building is a critical architecture decision that has to be carefully analysed. This deci-
sion is directly related to the communication range that the sensors achieve. Specifically, it has
been empirically tested that XM1000 sensors are capable of communicating via radio antenna
in a 20 meter range from the closest gateway. Therefore, since the building has 3 floors, it has
been decided to place 6 gateways, separated in two groups of 3, equally distributed in the roofs
of floors 1 and 2.
Chapter 5. Results 71
Finally, a central server responsible for receiving all the information gathered in the gateways
and for sending it to ServIoTicy is needed. Since this server communicates with the gateways via
Internet, its position do not have any impact in the architecture. However, having it inside the
Local Area Network can enhance the security of such system by avoiding exposing the gateways
to the Internet.
Additionally of all the must-have elements presented before, ServIoTicy offers the possibility to
mimic their system by creating our own server. This possibility allows us to change, if needed,
the behaviour of the system for future improvements or adjustments. In the table, the cost of
deploying such server has also been added.
Device Price Quantity Total
Environment monitoring (XM1000) 95 ¤ 50 4750¤Computer monitoring and actuation 40 ¤ 170 6800¤Lights monitoring and actuation 45 ¤ 50 2250¤HVAC monitoring and actuation 35 ¤ 50 1750¤Gateways 110¤ 6 660¤Server 350¤ 1 350¤ServIoTicy server 700¤ 1 700¤
Total 17260¤
Table 5.3: Estimated deploying cost.
As it can be seen, the total cost of needed devices ascends to 17260¤. Taking into account
previous savings results deducted from 5.1, which are around 29-65¤/day, the total time needed
to amortise such deployment would be between 8 months and 1 and a half years. However, this
time might be increased by unexpected expenses such as having to replace damaged sensors,
batteries replacements, hardware improvements or extension of the current system.
Overall, and taking an average daily savings, it can be concluded that the deployment cost could
be redeemed in 2 years.
Chapter 6
Conclusions and Future Work
This chapter summarizes the contributions and achievements of this research and outlines the
future research directions.
6.1 Conclusions
The development and simulation of the overall architecture have allowed us to extract interesting
conclusions that are summarised as follows.
Regarding current WSN state of the art, it can be seen that motes have substantially evolved
and a real deployment is currently feasible with some monetary help. Moreover, the variety and
quality allows the creation of heterogeneous WSN that cover any necessity.
It has also be seen that the vertical silos problem is very common and many platforms are being
developed in order to ease the interconnection of several enterprise solutions. ServIoTicy is one
of them with relative low living time, but very promising.
Focusing now in the main purpose of this thesis, the automatic actuation in buildings taking
into account the user comfort and the building energy consumption, it has been seen that an IoT
platform is perfectly feasible for automatizing actions inside a building without the necessity of
human interaction. However, going beyond that point, it has also be seen that these actions can
be predicted and scheduled to increase occupant comfort and also to reduce the overall building
energy consumption by avoiding having elements in an unnecessary state for some time. Even
though these features are still in an early development phase, in the near future they will be
extended.
By only introducing a Smart Manager and providing the building with a set of sensors, it is
possible to create such system. Since the real development is costly, the simulations performed
72
Chapter 6. Conclusions and Future Work 73
and their results shown in Chapter 5 allows us to conclude that it is relatively easy to save
energy in a building in which its occupants are not aware about how could their actions help to
save energy.
However, these conclusions do not have to be extrapolated to every building. Instead, an initial
study of the occupant behaviour needs to be carried out. In some cases, the overall building
consumption could be at its lowest possible level at every time. The deployment of a real
IoT platform in such building may increase occupant comfort by automatizing actions, but
it can also have a drawback related to energy consumption: the introduction of sensors and
gateways can increase the building energy consumption. In that case, the people responsible
for the project should weight both sides in order to see whether it is worth the extra energy
consumption compared to the increment in occupant comfort.
6.2 Future Work
The development of this Master Thesis has allowed the familiarisation with the extensive world
of Internet of Things. Specifically, this thesis sets the grounds for future projects and it also
has enabled the possibility to test current solutions in order to find better alternatives or face
unexpected problems.
Even though every layer of the built architecture works properly, there are several aspects that
can be enhanced as it has been stated throughout the thesis. These enhancements can be
seen as future opportunities for providing a more reliable, automated and bigger system. They
are presented following the same thesis structure, starting from the sensors’ software until the
simulator.
6.2.1 Sensor Automation
Although the automation of the sensors has been thoroughly studied in order to avoid as much
as possible the manual interaction, some aspects still remain undone.
• Remote sensor flashing.
• Automatic and reliable recognition of new sensors by the current WSN.
• Automatic Perception-Environmental Interface communication creation.
Regarding the remote sensor flashing, there still exists the necessity to at least flash a valid
initial program that allows the usage of the remote TinyOS capabilities. Once this has been
Chapter 6. Conclusions and Future Work 74
done, by means of Deluge T2 as explained in Section 2.1.3.1.3, it is possible to remotely send a
new image to a sensor to alter its behaviour.
Another enhancement might be the reliability and security improvements when introducing a
new sensor in the network. If gateways do not have any message control, it is possible for an
attacker to install a sensor in the range of a gateway and send internal harmful messages.
As for the communication creation, the needed drivers are currently manually configured. By
means of wrappers as explained in [49], for instance, it is possible to automatize this process
easily. Since the purpose of the thesis differs from this aspect, it has been decided to avoid going
deep in this section and leave it for future research.
6.2.2 Enhanced Simulator
Since the beginning of the development, the simulator structure has been thought to allow
further upgrades and enhancements in the features, but most importantly, in the smart manager
module. However, some optional parts remain undeveloped and might be necessary in the near
future.
Currently, the simulator is unable to interact with real automators that would modify the status
of real devices such as HVAC systems or computers. This feature was not initially introduced
since it is not mandatory for simulation purposes because of the possibility to mock state
transitions. Once a real WSN is deployed, this feature must be prioritized.
Regarding the smart manager, as it has been said before, future improvements are related to
the creation of better rules and the addition of newer ones that introduce more elements to the
system. For instance, some elements that are not currently being taken into account and might
be important are doors, windows or microwaves and heaters of dinning rooms.
Additionally, if instead of deploying a real WSN, the usage of the simulator is required, there
might be the necessity of improving some scenario definition parameters:
• Enhance building definition.
• Generalise user profiles and allow undetermined number of roles.
• Extend the possible set of events.
All of these improvements are thought to allow the public release of the simulator in order to
give back to the community part of the knowledge and tools provided, and also to contribute
with it.
Chapter 7
Cost and Time Analysis
This chapter aims to show and explain the analysis of the time spent reading, developing and
testing all the required tools as well as the cost of these activities.
7.1 Time Analysis
The development of this master thesis started at the beginning of April with the planning and
lasted for approximately 7 months. During the first phase, the whole time was spent reviewing
current documentation in order to find information related to aspects that were interesting for
our thesis. This includes information regarding the new world of Internet of Things and specific
aspects such as enabling technologies and Operating Systems.
Once the reviewing was completed, we shifted to the following phase that was the development
of all the software needed for the real sensors. Since this aspect means working on an unknown
environment for us, we firstly set up the required tools and studied the development of software
in the chosen IoT OS, which was TinyOS.
When everything was ready, the actual development started and also the testing phase after-
wards. Following the bottom to top approach, after finishing the sensor development, we moved
on to developing the Environmental Interface, in order to finish the south gate of ServIoTicy.
Since ServIoTicy was also an external unknown platform, we had to mainly study its API in
order to know its advantages and its behaviour. After seeing that the platform suited perfectly
for our project, we started the development of the Environmental Interface, which can be seen
as a driver tool specifically for the ServIoTicy platform.
75
Chapter 7. Cost and Time Analysis 76
Firstly, we created the communication between the sensors and the Interface. After that, we
saw that, in order to later test the scalability of the tool, virtual sensors were also required not
to waste unnecessary founds by buying extra sensors.
At that point, the connection between the Interface and ServIoTicy was made and tested for
almost one month to ensure that every message was correctly formatted and stored.
During the development of the Interface, since some parts were analogous on the north gate, we
also started developing the basic structure of the simulator. The MQTT module, responsible
for the connection with ServIoTicy, was developed after finishing the previous activities.
When the connection was created, every tool under development was connected, and the first
state of the system work flow was created. Whilst introducing new features and enhancing the
current ones, we also continued with the testing.
Finally, once the simulator was completed, we focused on testing the correctness of the assump-
tions and also on tuning the parameters in order to ensure that the simulated scenario presents
as much similarities as possible to the real scenario.
Figure 7.1: Gantt Project Diagram.
Figure 7.1 shows the above explanation in a Gantt Diagram in which the activities have been
grouped in different phases. During August, the project was stopped due to vacations.
Chapter 7. Cost and Time Analysis 77
7.2 Cost Analysis
This section presents the overall project cost in terms of working hours, software used and
hardware bought. As it has been previously explained, virtual sensors occupy a huge part in
the WSN developed, allowing to reduce the projects costs massively.
The Gantt diagram shown in Figure 7.1 allows us to check the final number of working hours.
Additionally, Table 7.1 clearly shows these times.
Task Hours
Planning 60hThesis Writing 200hDocumentation Review 132hSensor Software Development 84hEnvironmental Interface Development 108hSimulator Development 240hPresentation Preparation 40h
Total 864h
Table 7.1: Hours spent in every Project Task.
Taking into account that the master thesis is worth 30 ECTS credits according to the academic
regulations, and that each ECTS credit is equivalent to 25 - 30 hours of study, the master thesis
work should last for 750 - 900 hours. Looking at the table, it can be seen that we have achieved
the required amount of hours.
The current salary of an engineer is around 30¤ per hour. That means that the project price
amounts to 25920¤ only taking into account working hours.
Even though the project costs were cut thanks to the creation of virtual sensors, we had the
necessity to buy some real sensors to check that every part of the code was working prop-
erly. Specifically, 3 XM1000 (explained in Section 3.1.1.1) sensor motes were bought, with an
individual price of 95¤.
Luckily, the rest of the hardware was borrowed from the university and the software used was
either Open Source or free to use for university students. Table 7.2 summarizes and groups the
tools used while developing the project and sums up the total project cost.
As it can be seen, almost all the project cost comes from working hours. However, if a real WSN
were deployed, the cost of the sensors would have increased substantially due to the necessity
of buying a high amount of them. Even though this cost has been avoided thanks to the virtual
sensors, the spending will have to be faced in the near future in order to deploy a real WSN
and empirically test the assumptions extracted from this master thesis.
Chapter 7. Cost and Time Analysis 78
Hardware
Tool Units Price per Unit Total
XM1000 Sensor mote 3 95¤ 285¤ServIoTicy Server 1 - -
Software
MiKTeX 1 Open Source -Eclipse 1 Open Source -MS Office Excel 1 Student License -GanttProject 1 Free to Use -
Others
Working hours 864 30¤ 25920¤
Total 26205¤
Table 7.2: Cost of every tool used during the project.
Appendix A
Environmental Interface
Documentation
This appendix explains the required files and file structure of the Environmental Interface.
A.1 Required Files
The initial required files are the following:
• EnvIface.jar
• database.properties
• client batch.java
• servioticy/ folder
All the files from above must be placed in the same path. Before being able to execute, there
are some files that need to be completed. Specifically, fill in the database.properties with the
inside instructions and create a file inside servioticy/res named key with the user API KEY.
A.2 Create Models
Models are stored inside servioticy/models. Before starting the execution, all the IDs must have
a sensor associated. If this step is needed, execute the following commands:
cd servioticy
java modelGenerator #rooms
79
Appendix A. Environmental Interface Documentation 80
The model generator accepts the number of rooms to be created as a parameter. Currently,
every room is composed of 2 sensors, so if we introduce 50 as a parameter, 100 models will be
created.
A.3 Start Gateway
Once all the files are created and configured, it is possible to start the gateway. To do so, type
the following command:
java -jar EnvIface.jar -comm <Source > -port <#PORT >
In order to be able to correctly start the Interface, at least one parameter is needed, either the
comm source or the port number. The comm parameter allows the usage of physical sensors by
enabling the message reception via the gateways. If this option is used, the computer listening
from the gateway must know the USB port in which it is connected. For instance, the following
command would start both listeners, enabling the physical and virtual message reception:
java -jar EnvIface.jar -comm serial@/dev/ttyUSB0:xm1000 -port 9090
As it can be seen, the comm source is not trivial, firstly, we indicate that the gateway is connected
to the serial port followed by the current USB port used. Finally, we indicate the correct baud
rate of the serial port, which is given by a predefined TinyOS mask. Additionally,TinyOS
provides a tool that allows the forwarding of the received data to enable remote querying. This
tool must be started before running the Environmental Interface.
java net.tinyos.sf.SerialForwarder -comm serial@/dev/ttyUSB0:xm1000
java -jar EnvIface.jar -comm sf@localhost :9002 -port 9090
If the execution starts without errors, messages showing the current state of both listeners will
be shown.
A.4 Start Clients
Now it is possible to start the virtual client and send messages. If the client is not compiled,
run the command:
javac client_batch.java
After compiling, start the client with the desired number of IDs. This number must be even if
the execution of full rooms is desired (check A.7 for current room structure).
java client_batch -port <#PORT > -ids <#IDS >
Appendix A. Environmental Interface Documentation 81
The port used for the virtual clients must match the one used when starting the Environmental
Interface.
If the behaviour of the client needs to be changed, edit the client batch.java file accordingly. The
structure of the messages, however, must remain exactly as it is in order to allow the gateway
to properly parse the content.
For an example about how to setup physical sensors, refer to Section 3.2.1.
A.5 Behaviour
Once the gateway and the clients are executed, the behaviour of the system goes as follows:
• Create database table if it is not present
• For every ID, check if it has been registered in ServIoTicy. To do so, it checks whether
the file servioticy/res/id* exists or not. If it does not exist, the model is registered
in ServIoTicy and the file servioticy/res/id* is created and the ServIoTicy ID is also
introduced in the database.
• Send 2 messages for every client.
A.6 Remove IDs
In order to remove one ID from the system, it is sufficient to remove the corresponding servioti-
cy/res/id* file. However, in order to maintain a clean system and to avoid leaving garbage in
ServIoTicy, the scripts delete.sh and deleteAll.sh can be used after modifying them accordingly.
In order to use these scripts, curl and psql programs need to be installed.
The delete.sh script removes a single ID from the system:
sh delete.sh res/key res/id*
The deleteAll.sh removes all the IDs under servioticy/res from the system:
sh delete.sh res/key
If the deletion of the id files is done manually, it is recommended to also manually delete the
Service Objects IDs from the database using pgAdmin III.
Appendix A. Environmental Interface Documentation 82
A.7 Sensor Information
The system currently accepts two types of sensors: xm1000 and computer. The xm1000 sensor
offers temperature, humidity and luminosity information. The computer sensor is a single value
that indicates the current computer status (on, off, suspended, etc.).
Every room contains a single sensor of every type. Therefore, the local file numbering hierarchy
followed for synchronizing the files inside servioticy/data, servioticy/models and servioticy/res
is the following.
For a given room x, its sensors have assigned the local IDs 2x − 1 and 2x which respectively
repesent the xm1000 and the computer sensors.
Appendix B
Simulator Class Diagram
This appendix shows a complete view of the simulator’s class diagram. Many irrelevant functions
and variables have been hidden in order to ease the reading and showing of the overall picture.
For an even more detailed view of the simulator, please refer to the source code publicly available
at GitHub [50].
83
Ap
pen
dix
A.
Sim
ula
tor
Cla
ssD
iagra
m84
Figure B.1: State Diagram of the Computer Rule.
Bibliography
[1] International Telecommunication Union. Series Y: Global Information Infrastructure, In-
ternet Protocol aspects and Next-Generation Networks. June 2012. doi: 10.1109/TII.2014.
2300753.
[2] Dave Evans. The internet of things: How the next evolution of the internet is changing
everything. Technical report, 2011.
[3] That ”Internet of Things” thing. URL http://www.rfidjournal.com/articles/view?
4986.
[4] Internet users in the World. URL http://www.internetworldstats.com/stats.htm.
[5] Cisco: Seize New Opportunities with the Cisco IoT System. URL http://www.cisco.
com/web/solutions/trends/iot/portfolio.html.
[6] Ovidiu Vermesan and Peter Friess. Internet of Things: Converging Technologies for Smart
Environments and Integrated Ecosystems. River Publishers, 2013.
[7] Samsung SmartThings. URL http://www.smartthings.com/.
[8] Oxford Dictionaries Internet of Things Definition. URL http://www.
oxforddictionaries.com/es/definicion/ingles/Internet-of-things.
[9] Internet of Things Global Standards Initiative: Internet of Things Definition. URL http:
//www.itu.int/en/ITU-T/gsi/iot/Pages/default.aspx.
[10] Moore’s Law. URL http://www.mooreslaw.org/.
[11] SyNAPSE: A Brain-Inspired Chip. URL http://www.research.ibm.com/
cognitive-computing/neurosynaptic-chips.shtml.
[12] C.M. Robrts. Radio frequency identification (RFID). Computers & Security, 25:18–26,
2006. doi: 10.1016/j.cose.2005.12.003.
[13] Stephen A. Weis. RFID (Radio Frequency Identification): Principles and Applications.
85
Bibliography 86
[14] Roy Want. Near Field Communication. IEEE Pervasive Computing, 10(3):4–7, 2011. ISSN
1536-1268. doi: 10.1109/MPRV.2011.55.
[15] NFC Forum. URL http://nfc-forum.org/.
[16] Bluetooth SIG. URL http://www.bluetooth.com/.
[17] Weiping Sun, Munhwan Choi, and Sunghyn Choi. IEEE 802.11ah: A Long Range 802.11
WLAN at Sub 1 GHz. Journal of ICT Standardization, 1:83–108, July 2013. doi: 10.
13052/jicts2245-800X.125.
[18] G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler. Transmission of IPv6 Packets
over IEEE 802.15.4 Networks. RFC 4944, RFC Editor, September 2007. URL http:
//www.rfc-editor.org/rfc/rfc4944.txt.
[19] J. Hui and P. Thubert. Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based
Networks. RFC 6282, RFC Editor, September 2011. URL http://www.rfc-editor.org/
rfc/rfc6282.txt.
[20] Z. Shelby, S. Chakrabarti, E. Nordmark, and C. Bormann. Neighbor Discovery Optimiza-
tion for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). RFC 6775,
RFC Editor, November 2012.
[21] N. Kushalnagar, G. Montenegro, and C. Schumacher. IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and
Goals. RFC 4919, RFC Editor, August 2007. URL http://www.rfc-editor.org/rfc/
rfc4919.txt.
[22] David Gay, Philip Levis, Robert von Behren, Matt Welsh, Eric Brewer, and David Culler.
The nesC Language: A Holistic Approach to Network Embedded Systems. In Proceedings
of the ACM SIGPLAN 2003 Conference on Programming Language Design and Implemen-
tation (PLDI), June 2003.
[23] Miklos Maroti, Branislav Kusy, Gyula Simon, and Akos Ledeczi. The Flooding Time
Synchronization Protocol. In SenSys Proceedings of the 2nd International Conference on
Embedded Networked Sensor Systems, 2004. doi: 10.1145/1031495.1031501.
[24] Shu Wang and Tae won Ahn. MAC layer timestamping approach for emerging wireless
sensor platform and communication architecture, 2009. URL http://www.google.com/
patents/US20090310572.
[25] Rodrigo Fonseca, Omprakash Gnawali, Kyle Jamieson, Sukun Kim, Philip Levis, and Alec
Woo. TEP 123: The Collection Tree Protocol. 2006.
Bibliography 87
[26] Adam Chlipala, Jonathan Hui, and Gilman Tolle. Deluge: Data Dissemination for Network
Reprogramming at Scale.
[27] Deluge T2. URL http://tinyos.stanford.edu/tinyos-wiki/index.php/Deluge_T2.
[28] Free Pool of IPv4 Address Space Depleted. URL https://www.nro.net/news/
ipv4-free-pool-depleted.
[29] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP.
Vasseur, and R. Alexander. RPL: IPv6 Routing Protocol for Low-Power and Lossy Net-
works. RFC 6550, RFC Editor, March 2012. URL http://www.rfc-editor.org/rfc/
rfc6550.txt.
[30] Adam Dunkels. The ContikiMAC Radio Duty Cycling Protocol, December 2011. URL
http://soda.swedishict.se/5128/.
[31] Contiki OS: Cooja Simulator. URL http://www.contiki-os.org/start.html#
start-cooja.
[32] Emmanuel Baccelli, Oliver Hahm, Mesut Gunes, Matthias Wahlisch, and Thomas C.
Schmidt. RIOT OS: Towards an OS for the Internet of Things. In 32nd IEEE INFO-
COM, Turin, Italy, 2013. IEEE, IEEE.
[33] NASA Global Climate Change: Vital Signs of the Planet. URL http://climate.nasa.
gov/scientific-consensus/.
[34] Miao Wu, Ting-Jie Lu, Fei-Yang Ling, Jing Sun, and Hui-Ying Du. Research on the
Architecture of Internet of Things. International Conference on Advanced Computer Theory
and Engineering (ICACTE), 2010. doi: 10.1109/ICACTE.2010.5579493.
[35] Debasis Bandyopadhyay and Jaydip Sen. Internet of Things: Applications and Challenges
in Technology and Standardization. Wireless Personal Communications, 58:49–69, April
2011. doi: 10.1007/s11277-011-0288-5.
[36] Li Da Xu, Senior Member, IEEE, Wu He, and Shancang Li. Internet of Things in Industries:
A Survey. IEEE Transactions on Industrial Informatics, 10(4), November 2014. doi:
10.1109/TII.2014.2300753.
[37] Youngjin Yoo, Kalle Lyytinen, Richard Boland, Nicholas Berente, james Gasking, Doug
Schutz, and Nikhil Srinivasan. The next wave of digital innovation: Opportunities and
challenges. Technical report, 2010.
[38] Advanticsys. URL http://www.advanticsys.com.
[39] AS-XM1000 Mote Module. URL http://www.advanticsys.com/shop/asxm1000-p-24.
html.
Bibliography 88
[40] TI MSP430F2618 Microcontroller Manual. URL http://www.advanticsys.com/shop/
documents/1322654976_MSP430F2618.pdf.
[41] Hamamutsu S1087 Series, . URL http://www.advanticsys.com/shop/documents/
1320249860_Light_Hamamatsu_S1087.pdf.
[42] Sensirion SHT11. URL http://www.advanticsys.com/shop/documents/1320249906_
Temperature_Humidity_Sensirion_SHT1x.pdf.
[43] Barcelona SupercomputingCenter. URL http://www.bsc.es/.
[44] COMPOSE: Collaborative Open Market to Place Objects at your Service. URL http:
//www.compose-project.eu/.
[45] TinyOS XM1000 Radio Sensing Software, . URL https://github.com/DavidSembroiz/
XM1000.
[46] TinyOS MIG Specification. URL http://www.tinyos.net/tinyos-1.x/doc/nesc/mig.
html.
[47] A. Sreedevi, Ankit Kaul, and K. Radhika. Modeling and Simulation of an HVAC System for
Energy Analysis and Management of Commercial Buildings. In Proceedings of International
Conference on Circuits, Communication, Control and Computing (I4C)), 2014.
[48] The Engineering ToolBox: Illuminance - Recommended Light Levels, . URL http://www.
engineeringtoolbox.com/light-level-rooms-d_708.html.
[49] Charith Perera, Arkady Zaslavsky, Peter Christen, Ali Salehi, and Dimitrios Geor-
gakopoulus. Connecting Mobile Things to Global Sensor Network Middleware using
System-generated Wrappers. May 2012.
[50] Simulator Source Code, . URL https://github.com/DavidSembroiz/
Knowledge-Manager.