Harokopio University of Athens
Department of Informatics and Telematics
MSc in Computational and Internet Technologies and Applications
Dissertation Thesis
Intelligent Smart Environments’ management system in a Smart Cities
environment
Nikolopoulos Basil
R.N.: 13111
Three Person Committee:
Mr. Dimitrakopoulos George
Ms. Nikolaidou Mara
Mr. Dimopoulos Alexandros
Athens 2015
1
Dedicated to all you crazy
people that want to build
Iron Man’s house
2
Contents
Chapter 1: Introduction ................................................................................................ 12
Chapter 2: Related Work ............................................................................................. 14
Wireless Sensor Networks ....................................................................................... 14
What is a Smart City ................................................................................................ 15
IBM’s approach ................................................................................................... 16
Oracle’s approach ................................................................................................ 19
MIT approach....................................................................................................... 20
Smart Buildings and WSN Architectures ................................................................ 22
Chapter 3: The proposed system architecture .............................................................. 26
Chapter 4: The prototype ............................................................................................. 28
Autonomous Components ........................................................................................ 28
Registry Unit ............................................................................................................ 29
The REST API ......................................................................................................... 31
Chapter 5: Working with the MicaZ family of sensors ............................................... 34
The Hardware........................................................................................................... 34
The Software ............................................................................................................ 36
TinyOS ................................................................................................................. 36
NesC ..................................................................................................................... 37
The Base Unit ...................................................................................................... 38
The sensing units.................................................................................................. 38
The programming environment ........................................................................... 40
Chapter 6: The MicaZ aggregator unit......................................................................... 44
Philosophy................................................................................................................ 44
Implementation ........................................................................................................ 44
Notes ........................................................................................................................ 46
Chapter 7: The Jennic microcontroller sensors and their Aggregation Unit ............... 48
The sensors............................................................................................................... 48
The aggregator ......................................................................................................... 49
Philosophy and reasoning of languages used....................................................... 49
Programming with QT and the analysis of the code ............................................ 49
So far, so what.......................................................................................................... 50
Chapter 8: The Registry Unit ....................................................................................... 52
Prologue ................................................................................................................... 52
Development ............................................................................................................ 52
3
Discussion ................................................................................................................ 53
Chapter 9: Assessment and future work ...................................................................... 54
Assessment ............................................................................................................... 54
Future work .............................................................................................................. 54
Chapter 10: Discussion ................................................................................................ 56
Appendix A: ATMega128L pins to MicaX pins ......................................................... 58
References .................................................................................................................... 61
Thank you notes ........................................................................................................... 64
4
5
Figures Table
Figure 1-Architecture of a monitoring and control system for smart buildings. [20].. 23
Figure 2 - Layered Architecture [22] ........................................................................... 24
Figure 3 - Proposed system architecture ...................................................................... 26
Figure 4 - Autonomous components ............................................................................ 28
Figure 5- Registry Unit's Operations Diagram ............................................................ 30
Figure 6- The MPR2400CB Sensor ............................................................................. 34
Figure 7 - MDA100 Sensor Board with Prototype Area ............................................. 35
Figure 8 - MIB520 USB Programmer ......................................................................... 35
Figure 9 - Main GUI .................................................................................................... 45
Figure 10 - Mote Control Panel ................................................................................... 46
6
7
Abstract
The internet of things era is looming and no solid architectures for the management of
the abundance of smart objects has been proposed yet. In this dissertation thesis I aim
to propose a system architecture for WSNs that caters to the self-configuration and
self-management, as well as the multi-criticality of services, without need for
homogenous WSNs, the IoT is in dire need of. This will be achieved by adding
multiple layers of abstraction over the underlying WSNs. Moreover I will create a
prototype that implements part of said architecture as proof of concept.
8
9
Περίληψη
Η εποχή του Internet of Things πλησιάζει απειλητικά, και μέχρι στιγμής δεν έχει
προταθεί μία αρχιτεκτονική συστημάτων η οποία να είναι κοινώς αποδεκτή και να
διαχειρίζεται την πληθώρα των έξυπνων εφαρμογών που ήδη έχουν αρχίσει να
κάνουν την εμφάνισή τους. Σε αυτή τη διπλωματική εργασία αποσκοπώ στο να
προτείνω μία αρχιτεκτονική συστημάτων για ασύρματα δίκτυα αισθητήρων, η οποία
να μπορεί να προσφέρει την αυτο-ρύθμιση, αυτο-διαχείριση, όπως επίσης και την
απαίτηση για υπηρεσίες με διαφορετικά επίπεδα κρισιμότητας, χωρίς να υπάρχει
απαίτηση για ομοιογένεια στο δίκτυο των αισθητήρων, τα οποία έχει μεγάλη ανάγκη
το Internet of Things. Αυτό θα το επιτύχω προσθέτοντας πολλαπλά επίπεδα
απόκρυψης πάνω από το υποκείμενο δίκτυο ασύρματων αισθητήρων. Επιπλέον, θα
δημιουργήσουμε ένα πρωτότυπο σύστημα το οποίο υλοποιεί την εν λόγω
αρχιτεκτονική ως απόδειξη ότι μπορεί να υλοποιηθεί η αρχιτεκτονική.
10
11
Chapter 1: Introduction
As the Internet of Things era is closer than ever, there will be an undeniable
deployment of many high complexity systems. To ease one’s mind from the high
complexity of these systems, several concepts have been introduced. Some of these
are reconfigurability [1], self-managed and self-optimized systems and the
exploitation of cognitive systems principles [2] [3].
A cognitive system is a system that is capable of using knowledge acquired
from past interactions with the environment, and decides its future outcome based on:
a) the mentioned knowledge, b) other goals it may have, and c) on policies that may
apply. Cognition as a concept can be perceived both as a centralized and a
decentralized manner. It is believed that distributed solutions are more appropriate for
the complex and scalable systems of the Internet of Things era. [4]
An example of a high complexity system as described above is a Wireless
System Network. In these networks, low level sensor devices are interconnected and
perform transparent tasks to achieve a common aim. Such aims may be about
minimizing energy consumption for instance. In an ideal scenario, data gathered from
a WSN and used intelligently can produce desired outcomes for a client, without the
client having knowledge that the tasks mentioned took place. These Wireless sensor
networks have all the traits of a high complexity system as a number of issues arises
in the implementation of such a network, considering the transparency of integration,
the self-managing and the efficiency.
The aim of this dissertation thesis is to create a scalable WSN using a variety
of heterogeneous sensors that is energy efficient and open to reconfiguration and selfmanagement. Moreover I aim to create aggregators that provide RESTful Web
Services for said sensor networks and an overlaying layer of middleware. With these
steps, I will add layers of abstraction over the underlying WSN and thus users will not
need to know exactly what happens at the core of the network.
The thesis is structured as follows:
Chapter 2 talks about the related work on this area
12
Chapter 3 analyzes the architecture I propose for the WSN
Chapters 4 discusses in depth the units that consist the prototype built for this
thesis
Chapters 5 through 8 have detailed descriptions of the development phase of
the prototype.
Chapter 9 tries to assess the prototype and proposes future research
Chapter 10 is the epilogue of the whole project
13
Chapter 2: Related Work
Wireless Sensor Networks
The basis of this thesis is Wireless Sensor Networks, or WSNs as we will be
referring to them from now on regularly. First of all I am going to address what a
sensor is and then briefly describe WSNs.
The definition of a sensor is, a device, transducer, which is used to sense one
or more variables of the environment. In this context however a sensor is more than
that. In reality what I call a sensor is a piece of hardware that includes the previously
described transducers but also includes hardware that makes it able to communicate
with other devices. This `other hardware` is usually a microcontroller and some radio
communication ICs, but not limited to that.
For this project I used the MicaZ family of Sensors accompanied by a
prototyping board that included transducers for sensing light and temperature.
Moreover I used another set of sensors that use Jennic (NXP) microcontrollers, which
is able to sense temperature, humidity and atmospheric pressure.
On the subject of WSNs, one may ponder, what a WSN is in fact. A WSN is a
wireless network that is created from two or more sensors. These sensors may
communicate over a wide range of protocols, not necessarily IP-based. Some of these
protocols are, Bluetooth [5], Ethernet [6], IEEE 802.15.4 6LoWPAN [7], and many
more. The networks created are usually ad-hoc and depending on the architecture
may or may not support plug and play integration of new devices. [5] [6]
One of the main challenges of WSNs is the transparent and seamless
communication of the devices registered in the network because of the plethora of
protocols one may use. Another challenge is the transparent integration of a device in
a WSN. Finally managing the huge amount of data sensors collect daily is one of the
hardest problems.
One of the main reasons WSNs are deployed is the creation of Smart
Environments. Smart Environment is a general term used to describe pervasive
14
computing environment. Usually when talking about Smart Environments, one talks
about a Smart Building or a Smart City. In such environments, computational units
are deployed to provide a client with a service needed without the client necessarily
knowing that the service has taken place. Usual aims for Smart Environments are
energy management, healthcare, public safety and public transportation. [8] [9] [10]
[11] [12]
This creates the question, what a Smart City and a Smart Building is. The next
parts aim to answer that question.
What is a Smart City
The definitions of a Smart City are various. As the concept is being known
popularly but used all over the world with different names and in different
circumstances, there are a range of conceptual variants generated by replacing smart
with other alternative adjectives. Holland’s recognized smart city as an “urban
labeling” phenomenon, particularly in terms of what the label ideologically reveals as
well as hides. The label smart city is a fuzzy concept and is used in ways that are not
always consistent. There is neither a single template of framing smart city nor a onesize-fits-all definition of smart city. This section seeks to dismantle “the diversifying
terrain of smart cities”. [13]
According to IBM “Smarter cities of all sizes are capitalizing on new
technologies and insights to transform their systems, operations and service delivery.”
[14] Why do we care about smart cities however? MIT states that “In the future, cities
will account for nearly 90% of global population growth, 80% of wealth creation, and
60% of total energy consumption. Developing better strategies for the creation of new
cities, is therefore, a global imperative.” [15]
Another big player in the game of smart cities, not mentioned until now is
Oracle. According to Oracle “City leaders, including elected and appointed local
authorities and their agency or department management, realize they must increase
investment in infrastructure and improve service delivery despite rising costs and
reduced budgets. Indeed, citizens are increasingly vocal in their communities, with
15
many of them using other means of communications among themselves and with their
community leaders, outside of the traditional town hall forums.” [12]
IBM’s approach
ΙΒΜ acts on the following three axes:



Planning and management: Long term insights based on comprehensive data
analysis, followed up through efficient daily management, help a city stay vital
and safe for its citizens and businesses
Infrastructure: Fundamental services—such as roadways, mass transit and
utilities—make a city desirable and livable, but the key to keeping them viable is
readiness for constant change.
People: Smarter cities use the system of systems to their advantage when
supporting the needs of each citizen through social programs, healthcare and
education. [14]
Each of these axes tackles specific problems. Planning and management works on the
following





Public safety: Law enforcement
Public safety: Emergency management
Smarter buildings
City planning and operations
Government and agency administration
Infrastructure seeks to deal with issues about:



Energy
Water
Transportation
Finally, the axis about people seeks to undertake projects about:



Social Programs
Smarter care
Education
Public safety
The traditional “protect and serve” role has grown beyond policing. Nowadays
it includes responsibilities like, repeat offender reduction, emergency management,
and terrorism interdiction. Law enforcement solutions combine data visualization with
real-time collaboration and analytics capabilities to enable you to allocate limited
resources more intelligently. [8]
16
The benefit of using smart law enforcement is improved operational results.
This means that the agency resources can be extended by optimizing the allocation of
manpower and assets. Moreover there will be an increase in officer safety and
situational awareness by facilitating information sharing within a department, with
other law enforcement agencies and with partner organizations. Traditional policing
will enhance by shifting from reactive to proactive models. Finally the aim is to
reduce crime rates within their communities. [16]
Energy
Electricity
IBM claims that if the U.S. power grid alone was 5% more efficient, it would
be like permanently eliminating the fuel and greenhouse gas emissions from 53
million cars. With the use of IBM Intelligent Utility Network Solution the aim is to
transform the way utility organizations manage and operate transmission and
distribution systems as well as the way customers can participate in the energy value
chain. This enables more intelligence throughout the grid. This can dramatically
reduce outages and faults, improve responsiveness, enable utility companies to handle
current and future demand, increase efficiency and manage costs. [9]
The solution proposed is in essence an instrumented approach that includes
digital sensors, advances communication networks and sophisticated analytics that
can help understand demand in near real time, more effectively manage supply and
demand , and put greater control of energy usage into the hands of consumers. [9]
Utility meters are a vital source of information about resource usage, but the
data within them is often difficult and costly to collect. State-of-the-art systems that
automate data collection and link meters with network infrastructure can mean
substantial enterprise savings and better energy management for consumers. Opposed
to the ways of the past, where data collection about power usage was a monthly
scheduled job, a smart meter system takes an instrumented approach, automatically
collecting and transporting the reads at regular intervals or on demand, it is now a
conversation scheme. Smart metering is one way to transform the way electricity is
generated, transmitted, distributed and managed. By using digital sensors, advanced
communications networks and analytics, utilities can understand demand in near real
time.
17
The benefits of smart metering are numerous:









Improved reliability and response time to regulatory and market pressures.
Increase productivity and safety by automating tasks and limiting the amount
of onsite work.
Identify and locate outages.
Generate accurate load profiles for better resource planning.
Motivate customers to limit resource usage by implementing load controls.
Enable time-based customer billing (reduce peak demand, reward customers
for off-peak use).
Curtailment, connect, disconnect remotely.
Interactive relationship with utility consumers by home area networking.
Operational awareness throughout the energy value chain, providing
significant operational and planning benefits. [10]
Water
Water stress is everywhere. Water is one of the world's most abundant
substances. However, it is also fast becoming one of the planet's most stressed
resources. Access to clean water is a critical issue that affects economic activity.
Organizations forced to reassess the impact of water management on their economic
wellbeing.
The proposed solution intents to gain insights from rain to drain. Current
systems are generally standalone and limited in scalability. Smarter water
management systems need to provide an integrated operating picture with robust realtime analytics, modeling and decision support capabilities. IBM’s solution is designed
to optimize water operations and to create new opportunities for innovation.
Transportation
IBM’s solutions about traffic want to reduce traffic congestion and gridlock.
Intelligent transportation solutions are to provide traffic analysis and prediction
capabilities and a comprehensive, scalable platform for traffic management. Data is
aggregated from multiple devices that identify and measure traffic speed and volume
on city roads. [17]
People
IBM offers a variety of social solutions. These include solutions for disability
management, employment, pensions and social assistance. Moreover several
healthcare solutions are offered, like, Solutions for care management, fraud and abuse
management for payers, healthcare asset management and business analytics for
18
healthcare. Finally, their education solutions include a Framework for smarter
education, Business Analytics software for education, School solutions, Innovation in
research, Administrative solutions for education, Asset management for education,
Campus solutions for higher education and Enterprise risk management for higher
education. [18]
Oracle’s approach
Oracle in general is more focused in providing a wide variety of services
around the public sector and Local Government. There is not much done around
energy management. According to Oracle By 2050, more than two-thirds of the
world’s population will be living in urban areas. This creates some problems since
cities and communities will also act as the engines for twenty-first-century economies.
Cities have assumed central importance to a nation’s self-identity, but they are also
becoming the first line of defense to monitor for and respond against communicable
diseases and pandemics, fight poverty and inequality, combat terrorism, international
gangs, and crime syndicates.
In contrast with IBM, Oracle has some live examples of working smart cities.
The first example is Dongcheng District, Beijing. The Beijing Dongcheng District
government, together with Oracle, built a city grid management system that features:
wireless information service, geographical code inquiry system, data management,
and safety management capabilities. The system uses wireless functions to transmit
data—with no reliance on extensive cabling Accurate city planning is supported by a
high-end geographic information system that includes Oracle Spatial. The success of
the city grid management system has led to numerous other cities adopting the
system.
Another example is Boston. Boston is facing a revenue shortfall. To reduce
costs while continuing to improve services, city administrators can access timely,
consistent, and meaningful intelligence from their operational data system, Boston
About Results (BAR). Bar allows to: Track tax-collection trends and intervene to
prevent revenue loss, monitor call-center volume about specific problems to identify
macro-level issues, allow city department managers to develop performance
improvement plans and track their gains. [19]
19
The three pillars
Oracle’s solutions fit within Three Key Pillars
Smart Innovations: Resolve up to 90 percent of service requests through integrated
multichannel services, including self-service Web/chat; local single numbers such as
311, 1823, and 133; Facebook; Twitter; e-mail.
Smart Processes: Analyze service delivery, infrastructure expenditures, constituent
feedback, and other key areas to determine what areas to prioritize, streamline,
extend, consolidate, or even discontinue.
Smart Infrastructure: Modernize the underlying IT infrastructure to enable better
integration, interoperability and the provision of shared services. [19]
MIT approach
MIT’s axes
MIT has many research axes that concern smart cities. These are: Urban
Analytics and Modeling, Incentives and Governance, Mobility Networks, Places of
Living and Work, Electronic and Social Networks, and Energy Networks. [20]
Urban Analysis and Modeling
Urban Analytics focuses on data-driven analyses of economic activity, urban
perception, human behavior, mobility patterns, and resource consumption to inform
the city design process. Projects about urban analysis and modeling include:




Data-driven analysis of economic activity, human behavior, mobility patterns,
resource consumption, etc. in order to inform an evidence-based process of
designing new cities
Parametric urban design tools to schematically define mobility nodes, streets,
building massing, and location of resources to create nested compact urban
cells (walkable neighborhoods)
Urban energy, mobility, water, food, and waste simulator for new, post-oil
cities
Typology of streetscapes, pathways, mobility nodes, and responsive
technology for cities [21]
Incentives and Governance
Urban services are poorly distributed and require significant effort to maintain
and upkeep. Projects in this theme address the creation of new, network-centric
20
methods for managing reactive urban systems. This will be influenced by crowdsourced intelligence and respond in real-time to the needs of urban residents.
Projects about incentives and governance include: New network-centric
methods for managing reactive, data-driven city systems, replace one-size-fits-all
systems with exchange networks in order to obtain more stable, fair, and socially
efficient services, dynamic incentives for re-balancing shared-use and interacting
systems, urban-scale serious projects to shape use of resources such as shared-used
mobility, variable-rate power, and flexible workspaces. [22]
Mobility Networks
Research in this theme includes the development of a sophisticated multimodal mobility recommendation engine that ties together a variety of modes, from
carpooling to bike sharing, and is influenced by real-time data such as weather
patterns, traffic, and past user behavior.
Projects
concerning
recommendation
engines,
mobility
new
urban
networks
vehicles
are
Multi-modal
including
electric
mobility
scooters,
automobiles, bike-lane vehicles, etc., autonomous vehicle technology and vehiclepedestrian interfaces, charging and locking technology for shared-use vehicle
systems, and interfaces for shared-use vehicle systems, including proactive,
persuasive system. [23]
Places of Living and Work
The traditional office building is rapidly becoming obsolete as a place for
personal work. Boundaries between home and the workplace are dissolving rapidly,
spurred
by
advanced
computation
and
synchronous
and
asynchronous
communication. The design and prototyping of personalized, transformable urban
housing will enable city dwellers to maximize the functionality of a small apartment,
thereby improving livability and convenience.
Projects about the above research field are personalized, transformable urban
housing, time-shifted, shared space-on-demand for collaborative work, modular,
personalized hydroponic and aeroponic urban farming, sensing and algorithms to
understand fine-grained human activity for responsive lighting, HVAC, health, energy
conservation, and communication in the home and workplace. [24]
21
Electronic and Social Networks
Social networks enable the instant proliferation of ideas and events. Some
have even contributed to sociopolitical movement and revolutions. Projects in this
theme explore electronic nervous systems, from the scale of the human body to the
city. These decentralized electronic and social networks can form the basis for new
patterns of learning, recreation, production, and health.
Areas of interest are Electronic nervous systems, from the scale of the human
body to the city, decentralized, contextualized, and social forms of communication to
transform patterns of learning, recreation, production, and health, trust networks to
provide security and insure privacy for otherwise invasive systems that make use of
person activity data. [25]
Energy Networks
Today, networked demand response systems can reduce peak loading on our
aging electric grids but the integration of renewable energy sources is still difficult
due to intermittency. Projects in this theme focus on the exploration of DC microgrids
for compact urban cells that incorporate localized renewable energy generation
sources such as rooftop solar and microturbines.
Some projects about energy networks are Dynamic smart grids that respond to
human mobility and behavior patterns, electric (DC) microgrids for compact urban
cells and renewable energy, second-life of auto batteries for energy buffer and vehicle
charging, DC power networks for residential buildings. [11]
Smart Buildings and WSN Architectures
One of the most integral parts of a Smart City are the Smart Buildings and
Smart Homes. Smart buildings are pervasive computing environments. As such, they
require a large number of active units, like sensors, actuators, and computation
devices that work in harmony to provide transparently a rich set of services. These
services aim to accomplish the greater aims of the smart city the building is part of, or
to make the inhabitants’ lives easier. Earlier prototypes of smart buildings had a
tedious ad-hoc integration routine that required a great deal of work for each device to
be made a part of the system. [6]
22
As one may easily understand, creating a service-rich and robust environment
would be too difficult if it were to be maintained and created manually. That led to the
creation of platforms that replace the manual integration of smart devices, with a
scalable plug and play mechanism. One such platform is the ATLAS platform [6]
Solving the issue of transparent integration of smart devices, whether that may
that be sensors, a Smartphone, or anything else, is an active area of research. There
have been numerous proposals as to how it should be implemented. The issues that
arise range from, the fact that there are numerous communication protocols that a
device can use to try to communicate with the environment, to how can they all be
orchestrated to improve efficiency.
One approach that is widely accepted is having a bridge between each WSN
Figure 1-Architecture of a monitoring and control system for smart buildings. [20]
that allows the WSN to be accessed using the IP stack. This creates the possibility for
RESTful services to be created that are easy to use and work with. While there is a
considerate overhead that is introduced by IP-based protocols, the increased
possibility for different devices to connect is certainly worth it. [7]
Other proposals believe that the solution is using the Bluetooth or the
“Bluetooth low energy” technology. The incentives behind choosing Bluetooth are
that it creates low-cost links between any device that implements the protocol, as well
the fact that it is wireless and uses the universally available, unlicensed, 2.4-GHz
radio frequency spectrum, which means that devices will communicate in the same
way anywhere in the world. [5]
Another interesting aspect of Smart Buildings WSN management is creating
middleware to add abstraction layers over the underlying services provided. By
23
adding the aforementioned abstraction, one is able to create applications and manage
a Smart Building way easier that by having to be able to understand the underlying
WSN architecture and the way the devices are programmed. What’s more, by using
middleware one can exploit all of the advantages a layered architecture has to offer.
One could divide the layers on the following basis:
a) Physical devices, the lowest level
of devices, like sensors.
b) Gateway devices, aggregator
devices that connect the sensors to
the world.
c) Middleware, this is where a major
abstraction layer is added, as the
middleware is responsible for
making the right calls towards the
gateways without the user
knowing exactly what happens
bellow.
d) Web Services, services provided
by the middleware.
e) Client application, the application
that the user uses. [26]
Figure 2 - Layered Architecture [22]
24
25
Chapter 3: The proposed system
architecture
As said before, in this thesis I will be implementing a WSN. The envisioned
system consists of heterogeneous components as presented in Figure 3. Data will be
gathered from a set of sensors embedded inside a building, regarding both the
environment and the state of the user. The data will be available through a registry
unit, and will be accessed in a service – based basis. Each time a service is called, data
will be analyzed in a distributed manner, and the system will decide upon how
devices in the house should operate in order to meet the user’s needs.
Figure 3 - Proposed system architecture
26
As one may easily see, the system is composed from multiple units. The first
one is the WSN, which consists of numerous heterogeneous sensing devices.
The next step in analyzing the figure is the Registry Unit and the middleware
unit. Although they are different units in essence, they aim to provide a single service,
the availability of data. This unit is the main interface between the sensor network and
the outside world. It provides RESTful web services for others to use, whether they
are automated decision units or applications. Each service related to the smart
building application will be related to an Autonomic Decision Making (ADM) unit
that will have access to all sensor data. Each ADM unit may be related to many
devices while each device may be related to many services.
The proposed system also includes a pattern repository that is able to store
combinations of sensor data sets and sets of devices’ operation statuses based on
user’s feedback. The existence of such a repository minimizes delays.
Requirements will be used as an input to ADM. The requirements’ sets may
differ based on different user profiles for the same building.
The last but very important part of the system’s architecture is the user. The
user may access a report of all devices’ operation (through a smartphone application)
and provide feedback to the system. As already stated, different user profiles will be
identified from the system within the same building.
It is obvious that the architecture has been designed with scalability in mind.
The added layers of abstraction help the development of a system with this kind of
architecture since each unit doesn’t need to know exactly how the other units operate,
but instead is a standalone component that uses the information available upon
request.
27
Chapter 4: The prototype
In this chapter I will talk about, in detail, the units developed for the prototype
I developed for this thesis.
Autonomous Components
The autonomous components of
the prototype include Aggregation Units,
Application Components and Service
Components, as described in Figure 4.
Aggregation units control sensing
units, implemented based on different
technologies. Each sensing unit can be
either a data source, feeding aggregators
with
data,
accepting
or
a
device
instruction
controller,
from
the
aggregators to control a specific device.
Aggregators offer an abstraction layer
over the underlying WSN. They are
responsible for checking the condition of
Figure 4 - Autonomous components
each sensing unit in the network as well
as for providing services. That abstraction layer allows us to transparently control a
large number of nodes without ever having the need to get to low level programming.
Moreover, aggregators can ask for data from other aggregators giving them access to
WAN/LAN-wide data and make decisions in a smart manner, taking into account not
only their own status but other aggregators' too.
In addition, the aggregators allow for transparent energy management of the
sensors. The WSN uses a pull model, where the base node/aggregator is responsible
for receiving data from the sensors, and while the sensors are not polled for data they
stay in a hibernation state that allows for reduced energy consumption. That means
that sensors will only report their data when they are asked for. However, in cases of
extreme conditions, like a spike in temperature that persists and could mean a fire
28
broke out, a sensor node can be programmed to send urgent messages to inform the
aggregator of the event, and the aggregator can be programmed to inform an end user
of it, as a critical event.
Currently, aggregators for two types of Sensor Networks (SN) are
implemented. SN#1 consists of MicaZ sensor nodes, while SN#2 is formed by Jennic
(NXP) microcontrollers. A proprietary network layer over the IEEE802.15.4 standard
has been developed in SN#2 as an efficient replacement for the ZigBee (and JenNet).
The aggregator unit for SN#1 offers a set of services for polling the condition of
sensing units and toggling hardware settings, like turning on switches on the sensor
node's extension protoboard. The aggregation unit has self-configuration properties,
containing a decision-making layer enabling the configuration of the protocol used to
communicate with sensors (either pull or push model) based on the aggregator’
services currently employed by other components to reduce energy consumption. It is
apparent that such a feature offers a great deal of abstraction regarding WSN
configuration, each is handled internally by the aggregator, without ever involving the
users of aggregator services. The aggregator created for SN#2 is of different
philosophy. It is rather simple and uses a push model to communicate with sensors,
where they continuously emit data and an aggregator logs it. In this case, the
aggregator provides services for read the sensors' data.
Apart from the aggregator units, autonomous components also include
components related to services and applications. Application components are software
modules using sensor data to provide complex services, while service components
provide services to end-users
Registry Unit
The registry unit constitutes a simplified DNS-like service (Figure 5). It
supports three kinds of requests: to GET data, to POST/REGISTER data, and to
DELETE data. The Registry is currently implemented in a tiny power efficient single
core x486 compatible device. It runs a full featured Linux OS (Debian Wheezy). An
http server hosts the services consisting the Registry API.
29
Any component may
poll the registry unit so as to
get
a
list
of
available
components
(either
aggregators
or
application/service
components) in the area.
Moreover, it may ask for
available
services
of
specific
component.
a
A
registry entry consists of: the
component
description,
information for the IP it is
available
at,
and
the
component’s services, followed
Figure 5- Registry Unit's Operations Diagram
by a short description of each service. For example, an application component may
poll the registry with an aggregator id and a sensor id as HTTP parameters. The
registry should let the application component know about the available services the
aggregator offers on sensor level on that specific sensor. Such services might be for
instance, a switch toggle, a specific sensor reading or a battery level.
Components are the only ones responsible for posting the data to the registry
unit through a registration procedure. This procedure is done over HTTP as well. A
component is also responsible for renewing his registry records when a service/sensor
node is no longer available. The registry unit can opt to delete a component and the
services it offers, denoted with the unique ID, assigned to at the register process, if the
component has not renewed his records in a while. The services provided are, at the
time being, fully RESTful and therefore can be easily manipulated and be used.
Moreover all reply messages are in JSON form to allow for easier manipulation of the
data received. A developer willing to develop an application using a WSN that uses
the registry unit, can simply poll the registry for the services' descriptions and get
started without much trouble.
The registry unit acts as discovery service for the users currently entering the
smart building and a registry service for the autonomous components currently
30
available. As such, no information about the underlying WSN and sensor types is
maintained in the registry. Aggregators are responsible for the correct documentation
of their services and that allows us to consider a layer of abstraction over the WSN.
In the following, the REST API designed for aggregation units and registry is
presented.
The REST API
This section briefly presents the REST API designed for the prototype. All messages
shown are JSON encoded messages.
Aggregator API calls for SN#1
aggregatorIP:8181/sensors -> returns a list of sensors available
aggregatorIP:8181/sensor/ID -> returns data of specific sensor with id = ID
aggregatorIP:8181/sensor/ID/light|temp -> returns data about light|temperature of specific
sensor with id = ID
aggregatorIP:8181/sensor/ID/switch -> toggles the switch available on the sensor node and
returns the state of the sensor node as if aggregatorIP:8181/sensor/ID was called
Aggregator API calls for SN#2
aggregatorIP:8080/sensors -> returns a list of sensors available
aggregatorIP:8080/sensor/ID -> returns data of specific sensor with id = ID
aggregatorIP:8080/sensor/ID/temp|humi|pres -> returns data about
temperature|humidity|atmospheric pressure of sensor with id = ID
Registry unit API calls (Services intended for aggregator use)
registryIP:8282/register -> uses post headers to register a list of services available at an
aggregator. The registry unit responds with a unique ID that the aggregator should use in
following API calls as a parameter.
registryIP:8282/delete -> uses post headers to delete a specific service earlier registered at the
registry unit. Registry unit responds with OK or NOT_OK followed by an error code
31
registryIP:8282/update -> uses post headers to update a specific service earlier registered at
the registry unit. Registry unit responds with OK or NOT_OK followed by an error code
Registry unit API calls (Services intended for everyone including aggregators)
registryIP:8282/getServices -> returns a list of all services currently registered at the registry
unit.
registryIP:8282/getAggregators -> returns a list of all available aggregators.
registryIP:8282/describe/serviceID -> returns a description provided from the aggregator at
register time for service with id = serviceID. It should be noted that an aggregator does not
need to know of the services' IDs as they are used only by the registry unit to denote different
services.
registryIP:8282/describe/aggregatorID/path/service -> Same as before, but with different
notation for ease of use
32
33
Chapter 5: Working with the
MicaZ family of sensors
The Hardware
The first sensor I
used for the prototype is
the
MicaZ
MPR2400CB
family
from
Memsic. It uses an Atmel
ATMega
128L,
8bit
microprocessor which runs
at
8 - 16 MHz. Moreover
it
features
4Kbytes
of
RAM. Said sensor has a
built
in
Figure 6- The MPR2400CB Sensor
Radio
Communications module which supports a RF Range of 2.4 - 2.48 GHz and supports
data transfer rates of 38.4 Kbits/s and up to 250 Kbits/s. This sensor doesn’t have any
sensing transducers built on it. 2AA batteries are needed for the unit to operate.
In Figure 6 we have the depiction of the under-side of the MPR2400CB
sensor. Analyzing the picture we have:
1.
2.
3.
4.
5.
Plug for optional external power, if we do not want to use batteries
On Off switch
ATMega 128L microprocessor, underneath the sticker
Built in LEDs that the microprocessor handles
The 51pin extension port
In order to sense environmental variables with this sensor one must attach
sensing transducers as an add-on. The sensor provides a 51 pin extension port on
which one can attach a breakout or a prototyping board. In essence, this extension port
provides an interface for the pins of the embedded ATMega 128L. For the prototype I
have decided to use the Memsic MDA100 Sensor Board with a Prototype Area. The
34
MDA100 includes transducers for
sensing temperature and light levels.
Moreover it provides a prototype area
on which, one can extend the
capabilities of the sensor unit, by
adding more hardware.
In Figure 7 we can see the
MDA100 Sensor Board and the
Prototype Area. Analyzing the picture
Figure 7 - MDA100 Sensor Board with Prototype Area
we have as follows:
1. Prototype area. Here some pins are connected through 4, the extension port, to
the ATMega128L microcontroller. Other pins are not connected anywhere in
order to provide free pins for prototyping.
2. The light levels sensing transducer
3. The temperature sensing transducer, also known as a thermometer
4. The 51-pin extension port. It connects the prototype area to the ATMega128L.
One of the most difficult issues with the prototyping board was matching the
prototype area’s pins with the pins of the ATMega128L. Someone could suppose that
pin 1 for instance of the microcontroller is connected to pin A1 of the prototyping
area. This however turned out to be wrong. Thankfully a matching between the
ATMega128L pins and the Prototype Area’s pins was found and can be found on
Appendix A [27].
The last integral part of this is
the MIB520 USB Programmer
component. The MIB520 provides
USB connectivity to the MICA
and IRIS Mote for communication
and in-system programming. In
addition to data transfer, the
MIB520CB also provides a USB
programming
interface.
MicaZ
Figure 8 - MIB520 USB Programmer
latch onto the MIB520’s extension
port shown at 2. Analyzing Figure 8 we have as follows:
35
1. The USB port for connecting to PCs.
2. 51 Pin port like the one found on MicaZ units and the Sensor board
3. These LEDs are the same as the ones on the MicaZ unit. They correspond
to the LEDs on the MicaZ unit latched on the MIB520. Because the MicaZ
unit’s LEDs are not easily visible when it’s latched onto the MIB520 these
LEDs can be used instead.
4. These LEDs are separate from the LEDs at 3. They are used by the
programmer to indicate correct connection of a MicaZ unit and whether
there is I/O happening.
5. Reset Switch
The Software
This section will be divided in five parts. First I will talk about TinyOS, then
about the NesC programming language, then about the firmware on the MicaZ unit
used as a base station, then about the firmware of the MicaZ sensing units and finally
for the programming procedure and the setting up of the programming environment.
TinyOS
TinyOS is an open source, BSD-licensed operating system designed for lowpower wireless devices, such as those used in sensor networks, ubiquitous computing,
personal area networks, smart buildings, and smart meters [28]. The MicaZ motes
work with TinyOS.
The way it works is that when someone wants to write a firmware/application
to be ran on a MicaZ unit, after programming the application, which I will be talking
about later, has to compile the whole TinyOS binary along with the application and
have it written to the unit.
The main advantage of TinyOS is that it adds a layer of abstraction over
several parts of the MicaZ units. It provides libraries in order to simplify the
programming of applications. These libraries range from reading ports of the
microprocessor used, to sending RF messages. What’s more, in many occasions, the
libraries used while programming do not need to have a specified platform, which
means that you can use the exact same code for programming any device that is
capable of running TinyOS that you used for the MicaZ. A full documentation and
guides for programming with TinyOS can be found at the official TinyOS
Documentation Wiki [29].
36
NesC
TinyOS uses nesC as a programming language. NesC is a component-based,
event-driven programming language used to build applications for the TinyOS
platform. It is very similar to C as it is built as an extension to C.
Programs written in nesC are made from two components, a Configuration file
and a Component file.
The Configuration file connects component events, signals etc. between each
other and usually are named with the convention of `applicationNameAppC.nc`, e.g.
SimpleAppC.nc. A simple configuration file could look like this:
configuration SimpleAppC{
}
implementation{
components SimpleC, MainC;
SimpleC.Boot -> MainC.Boot;
}
There are two components in this program: the component called SimpleC and
the Main component MainC. The MainC component provides the Boot.booted signal
which essentially is the entry point of the application.
The Component file contains the actual implementation of the application I
want to create. The component should be named exactly like it is stated in the
configuration file, in this case `SimpleC.nc`. The names of component files should
also follow the convention of `componentNameC.nc`. A simple component file for the
configuration stated above could be the following:
module SimpleC{
uses interface Boot;
}
implementation{
event void Boot.booted()
{
//The entry point of the program
}
}
Finally, in order to compile the application we have to create a Makefile with
the following lines:
COMPONENT=SimpleAppC
37
include $(MAKERULES)
and call it with:
make micaz
More info about programming with nesC can be found in the TinyOS Wiki
under the tutorials section [30].
The Base Unit
In order to receive radio messages and to make use of them, I would have to
receive them first. The TinyOS radio messaging library supports communication
channels at some level. What’s interesting about this is that a Multicast/Broadcast
channel is available and that way there can be messages that are to be received by
everyone listening to that channel.
When setting up the TinyOS programming environment at the PC that is to be
used for the firmware programming, a set of ready examples of firmware are also
made available. More on the installation of the programming environment will follow
but for the time being what we need to know is that one of the examples is a base
station firmware.
This base station firmware works as follows. A MicaZ unit is to be latched on
the USB interface. Then, this MicaZ unit, using the embedded RF unit, it listens to the
multicast channel and forwards all the data received to the USB/Serial interface.
Moreover, the base station supports sending messages on the multicast channel which
is something that I will be using as well. Although quite simple, it was perfect for the
prototype and was used as is, without any alterations to the code. What one does with
the data made available at the Serial port is something that we will discuss later on.
Something to be noted is that the MicaZ unit latched onto the USB interface,
doesn’t need batteries, as it is powered from the USB.
The sensing units
Having talked about the base unit we can now move on and discuss the
sensing units’ firmware but before that I would like to take a moment and talk about
the philosophy behind the way the sensing system works.
38
It is common belief and can be deducted from common sense that a sensing
unit running on batteries that are not rechargeable would be too costly if it were to
deplete its energy sources in a short span of time. Moreover, wasting CPU cycles, and
thus battery charge, for sensing that will never be used is also something unwanted.
That way I decided to use a pull model for the communications. By pull model I mean
that the sensing units do stay in a state of hibernation until a message is received from
the multicast channel or a message towards the specific unit is received. This
hibernation state is a low power consuming mode that helps alleviate the burden of
changing batteries too often. It should be noted that in the four months of working
with the MicaZ units, I did not have to change batteries, although they were turned off
for long periods of time.
Having stated my reasoning for the choice of the pull model of
communications I will now explain briefly how the units work. Each unit, or node,
has a unique ID assigned to it when the firmware is to be written to. Moreover, it
supports a list of services, which are, as said before, a light sensing service and a
temperature sensing service. In addition to these two, I added the functionality to
control a single pin of the ATMeg128L via RF communications, to act as a switch.
The reason is that, a sensor should be able to turn on or off a switch according to
messages received from the central unit of communications, the base station. Each
node supports all or a subset of these services. Which services are available is denoted
by an integer that ranges from 0 to 7; 3 bits in essence, each bit representing a service.
After the initial set up of the parameters at the boot sequence of the application
the node hibernates and waits for a message. There is a predefined list of messages a
node can send and receive and are as follows:
1. Poll Request: A message for a request of identification of the node
2. Poll Acknowledge: The answer to that message
3. Read Request: A request to get the readings of a transducer defined in the
body of the message
4. Read Acknowledge: The answer to the above message
5. Switch Poll: A request for the state of the switch handled by the switch
service
6. Switch Answer: The answer to the above message
7. Switch Change: A request to change the state of switch handled by the
switch service
39
According to the message received a node acts in a predefined manner, and sends
back a response on the multicast channel.
There is no point in going in details as far as the code is concerned, as this is
not the point of this Chapter. The code is available online on GitHub at
https://github.com/Nikolopoulos/MScThesis/ if anyone is interested in it.
The programming environment
In order to program the MicaZ units one must have set up correctly the
programming environment for that. Although instructions are available at the TinyOS
Wiki page [29], I will be discussing how to set up your programming environment on
this chapter as well to denote any personal notes. I will be describing the installation
of TinyOS on a Debian machine.


The first thing anyone should do is to install the Java JDK from the official
Java site http://java.sun.com.
Afterwards, the following list of compilers must be installed on your system
(this
covers
atmel’s
microprocessors
only):
o avr-binutils from www.tinyos.net/dist-2.1.0/tools/linux/avr-binutils2.17tinyos-3.i386.rpm
o avr-gcc
from
www.tinyos.net/dist-2.1.0/tools/linux/avr-gcc4.1.2-1.i386.rpm
o avr-libc
from
www.tinyos.net/dist-2.1.0/tools/linux/avr-libc1.4.7-1.i386.rpm
o avarice
from www.tinyos.net/dist-2.1.0/tools/linux/avarice-2.41.i386.rpm
o insight (avr-gdb)
from www.tinyos.net/dist-2.1.0/tools/linux/avrinsight-6.3-1.i386.rpm
o avrdude
from
www.tinyos.net/dist-2.1.0/tools/linux/avrdudetinyos-5.6cvs-1.i386.rpm

The next step is to install the TinyOS Toolchain. The TinyOS-specific tools
are the NesC compiler and a set of tools developed in the tinyos-2.x/tools
source code repository. They are also installed using rpms. There are two
Linux versions of tinyos-tools, depending on whether you have a 32-bit or 64bit machine. The first is the i386 RPM and the second is the i686 RPM. If you
have a 64-bit Java VM, it is important that you install the i686 RPM or
otherwise the Java support may not work properly.
40
o NesC
from
http://tinyos.stanford.edu/tinyos-rpms/nesc-1.3.11.fc9.i386.rpm
o Deputy from http://www.tinyos.net/dist-2.1.0/tinyos/linux/tinyosdeputy-1.1-1.fc9.i386.rpm
o tinyos-tools from http://tinyos.stanford.edu/tinyos-rpms/tinyos-tools1.4.0-3.ubuntu.i386.rpm
or
http://tinyos.stanford.edu/tinyosrpms/tinyos-tools-1.4.2-20120807.x86_64.rpm
After successfully installing the above tools you are ready to move to the final
step. Install the TinyOS 2.x source tree! Get the code from the TinyOS release
repository:

wget http://github.com/tinyos/tinyos-release/archive/tinyos-2_1_2.tar.gz
tar xf tinyos-2_1_2.tar.gz
This will extract the actual TinyOS code in a folder named tinyos-releasetinyos-2_1_2 inside the directory the command was issued. It is advised that
you put this folder somewhere other than your downloads’ folder. Something
like /etc or /opt is fine.
You will need to add some environment variables to your shell. The following
file includes the necessary ones. Substitute the placeholder <local-tinyos-path>
with the path where you chose to place the code in the previous section (full path
required!).
# Here we setup the environment
# variables needed by the tinyos
# make system
export
export
export
export
export
TOSROOT="<local-tinyos-path>"
TOSDIR="$TOSROOT/tos"
CLASSPATH=$CLASSPATH:$TOSROOT/support/sdk/java
MAKERULES="$TOSROOT/support/make/Makerules"
PYTHONPATH=$PYTHONPATH:$TOSROOT/support/sdk/python
echo "setting up TinyOS on source path $TOSROOT"
Suppose you named this file tinyos.env. There are now at least two possibilites to
have these variables accessible in your shell:


Place it as root user in /etc/profile.d/
Place it in <local-tinyos-path> and add the following line to your .bashrc
source <local-tinyos-path>/tinyos.env
You can also add the contents of the file directly to the .bashrc.
41
To make the changes work, the easiest way is to open a new terminal window.
In order to program motes you will need to access the serial ports. This can be done
by joining the group that grants this privilege. sudo gpasswd -a <your-user> dialout
This change only takes effect when log out and log in again. [30]
You are good to start programming MicaZ units now! After creating your
application using the information from previous chapters and the TinyOS wiki [29]
you are ready to make your first build. First things first, you must connect the unit you
wish to write the application to, to the USB interface. Afterwards, the USB interface
should be connected to the PC. If you have connected it there should be two new USB
ports at /dev looking something like /dev/ttyUSB0 and /dev/ttyUSB1. These two ports
are important. The first one is used to WRITE to the programmer and the second one
to READ from the programmer. You are now ready to issue your make command.
Making looks something like this:
SENSORBOARD=mda100 make micaz install,2 mib520,/dev/ttyUSB0
Let’s analyze the command.
1. SENSORBOARD=mda100 tells the compiler that we are using the mda100
sensorboard, this way knows which libraries to include
2. make, the common make command
3. micaz, this tells the compiler which platforms specific libraries it should use
4. install, install it on the MicaZ unit
5. install,2, the semicolon 2 argument gives the unit a specific ID number, in this
case 2.
6. mib520, it is the model of the USB interface I am using
7. /dev/ttyUSB0, this is the port to be used to install the firmware
Your MicaZ unit should now be using the firmware you created!
Something important to note is that in the folder you extracted tinyos2_1_2.tar.gz in previous steps, there is a folder named apps. In that folder there are
numerous examples of mica firmware that should not be too difficult to understand
after some practice. Try beginning with Blink application. It is one of the most basic
ones.
42
43
Chapter 6: The MicaZ aggregator
unit
Philosophy
One may ask why an aggregator is needed. As described before, between the
MicaZ Units and the registry unit, there is going to be a “bridge”. This bridge, or
aggregator as we will be referring to it from now on, is an orchestrator. It is
responsible for providing services over a Web RESTful API to the world, while
maintaining in memory the status of the WSN. It has already been discussed why I
decided to use the pull model for the communications so I will not go into details for
that, but I will mention that the aggregator is responsible for “asking” the nodes for
data, more on that later on.
In reality, the aggregator unit is an application written in Java that using the
TinyOS libraries provided from the TinyOS development framework manages in real
time the WSN. This program is cross platform and should work on any machine
running Java, provided that the TinyOS libraries are compatible with the OS which
the machine runs. For the prototype I used a machine running Debian wheezy on an
x64 processor.
Implementation
Previously, I mentioned that I had a MicaZ unit act as a base station that
forwarded messages as raw data to a serial port. Unfortunately, the latest versions of
Java do not support reading from serial input directly. On the other hand, fortunately,
the creators of TinyOS took care of that by creating a serial forwarder.
The serial forwarder is a nifty little program, bundled together with the
TinyOS package that reads input from the serial port and forwards it as is to a virtual
44
web port, whose number you specify yourself in order to avoid conflicts. By default
the serial forwarder forwards data to port 9001.
The MicaZ’ aggregator is organized in the following Java Packages:






GUI
Lib
Conductor
SensorPlatforms
Util
Webserver
Each of these packages contains a number of classes that I will analyze now.
1. GUI: This package contains classes that are responsible for the Graphical
user interface that is available in the standalone version (when the web api
is not supported)
a. mainFrame: This class creates and handles the initial window of
interface that a user is presented with. The window itself has a list
of all available sensors with the services it supports. Selecting a
node to see its details calls the micaDetails class.
Figure 9 - Main GUI
b. micaDetails: This class is responsible for presenting the user with a
simple GUI for controlling the nodes available at the WSN.
45
Figure 10 - Mote Control Panel
2. Lib: Most of the classes in this package are message description classes
generated automatically from the `mig` tool that comes bundled with
TinyOS toolchain. Apart from these classes, another class that contains
Static Constants is included.
3. SensorPlatforms: this package, for the time being, contains one class that
is a descriptor class for the MicaZ units used. In essence this class is used
to represent each unit.
4. Util: this package contains two classes.
a. Control: This class contains the most important code of the
application. Every action that can be performed is provided from
this class.
b. Util: this class contains some utility methods, like sum of numbers
etc. It is used primarily because when a sensor’s data is requested,
the unit responds with a number of sensing results, not only one
result. Then we have to get the mean of that number etc.
5. WebServer: this package contains the code that is required for the Web
API to work. It has two classes:
a. Server: this is a listening server class for accepting connections
which are then forwarded as threads to another class that does the
rest of the communications.
b. DoComms: this class is the class that does the computations
required and requested from every request from the Web API.
6. Conductor: this, final, package contains the main class of the program as
well as a class that handles the messaging between the base station and the
rest of the WSN.
Notes
As it is obvious, this application is not simple and thus it would not be
beneficial to go in details about it. What should be noted about the application in
general is that it is multi-threaded, and thus can be easily ported to multi core
platforms as well that the threads the server spawns are managed from the Java
threadpool and no additional threadpool has been created.
46
It is also important to note that, as I said before, in order for this application to
work, we need to deploy the Serial Forwarder first. Having said that, I would like to
say that when I talk about the “aggregator unit”, I refer to the system that includes
both the System Forwarder and the Managing Application.
Although I presented a GUI for users to control MicaZ units from their
desktop, one should not be confused and conclude that this is a desktop application.
The GUI is ONLY available per request from the user. Under normal conditions, the
application runs with no GUI, from terminal, and provides the said Web API.
47
Chapter 7: The Jennic
microcontroller sensors and their
Aggregation Unit
We have already discussed that one of the main points of this thesis is the
heterogeneity of the WSNs and the fact that this gets hidden by the abstraction layers
added by the middleware.
In that light, it is obvious that you cannot have a
heterogeneous WSN base without having at least two types of sensors. For the second
sensors network I used sensors that use Jennic (NXP) microcontrollers.
The sensors
In contrast to the MicaZ nodes, the sensors of this network did not support
reprogrammable firmware. Moreover, these sensors worked with a push model. By
push model I mean that the sensor constantly senses the environment and sends data
over wireless ZigBee communication, which may or may not be picked up by anyone.
That means that this kind of sensor and therefore WSN, is less energy efficient than
the WSN created with the MicaZ units. To help out with this, the sensors do not
require batteries provided from the user to run, but instead use a built in rechargeable
battery.
The sensors are capable of sensing temperature, humidity, and atmospheric
pressure. The values are pure values from an Analogue to Digital converter, and thus
have no meaning on their own. The values go from 0 to 1023.
Accompanying the sensor was a USB dongle for the PC. This dongle read the
data transmitted by the sensors of this type and pulled it on the serial port. The
messages are pure hexadecimal streams of data in the form of
D #sensorID temperatureVal humidityVal pressureVal
If one wanted to read the stream for debugging reasons, he can use any serial
reading software, like netcat or cutecom. Analyzing the data read from using cutecom
I was able to create a profile for this data and get started towards building the
aggregator for this sensor network.
48
The aggregator
Philosophy and reasoning of languages used
Like I said before, this sensor network makes use of a push model. This means
that the aggregator will have to deal with constant pings from the sensors, while
maintaining its integrity and stability and being able to process multiple web requests
in order to provide a seamless experience when using the Web API.
Since Java does not support serial communications anymore, I had to turn to
an old friend, C and C++ languages. In reality I used the Qt framework [31] which
provided loads of useful libraries, from managing threads by creating threadpools to
reading from the serial port using one function. I urge anyone wanting to program any
application in C or C++ to look into this framework first.
Programming with QT and the analysis of the code
Programming with Qt was really simple. The qtcreator package was already
available for the Debian machine I already talked about so setting up the environment
was as simple as using an apt-get install command.
I will not go into depth as to how the Qt framework works but it is really
simple and a simple google search, not to mention a Youtube search, returns lots of
results with tutorials on how to do virtually anything on Qt. What I will do instead is
analyze the way I implemented my aggregator unit for this sensor network.
The application consists of four cpp files, accompanied by their header files.
The four files are the following:
1. main.cpp: This file contains the initialization of the aggregator, it starts the
reading of the serial port thread, and starts the listening server.
2. portInterface.cpp: this file contains the code that is responsible for reading
the serial port. It creates a list of all available sensors, as in all the sensors
that their data is currently getting received by the dongle and provides the
interface for fetching data for specific sensors etc.
3. connectionHandler.cpp: this file is responsible for handling incoming
connections. After a connection is received a thread is spawned and the
request is handled in a different thread. These threads are managed by a
threadpool to maximize the aggregator’s stability.
4. client.cpp: this file is responsible for analyzing the request a client has sent
and requesting the appropriate data from the portInterface. It should also
be noted that is in part responsible for JSONising the data that will be
responded.
49
It is obvious that although the files are not many in number, they provide lots of
functionality and are quite complex in nature.
As with the other aggregator, this one too runs as a standalone console
application. Both aggregators can be ran on a single machine since they listen on
different ports.
So far, so what
This sub-chapter’s purpose is to sum up what I have accomplished so far and
thus will remain short and concise.
I have created two different WSNs, which are comprised from different sensor
units. Sensor network 1 uses MicaZ family of sensors while Sensor Network 2 uses
sensors based on Jennic microcontrollers. This means I have achieved heterogeneity
on the subject of the WSNs available on a given site.
For each network I have created an intermediate aggregation unit which serves
as a way for the outside world to talk with the sensor networks, adding a layer of
abstraction over the underlying WSN. The API calls are the same for both WSNs and
thus, despite the fact that the WSNs work in completely different manner with
different technologies involved, a user gets a seamless, transparent and easy to work
with interface.
It should be noted that, in the architecture I propose, for each sensor
technology an appropriate aggregator unit must be built. Although this may seem
tedious, it is in fact a step towards better transparency in WSNs. The reason for that is
that the burden for the aggregators falls onto the companies creating the sensors and
users need not to know how the underlying architecture works, it just works.
The aggregators, however, work on some IP address and some port. A user,
whether that is an application or a person or whomever, must know where to look for
the service he wants. In addition, the user would like to know what services are
available. This is where the Registry Unit comes into play.
50
51
Chapter 8: The Registry Unit
Prologue
Ah, the registry unit, the molten core of the prototype. The proposed
architecture. It is apparent now why it is needed. Its role is to act as a simple DNS like
server, or WSDL registry for RESTful Web Services, if that makes any sense.
Aggregators need to contact the registry unit that is available at the network
they are part of in order to register the services they provide. Moreover, they should
contact the registry unit for any changes in their services. They should also provide
descriptions for their services in humanly readable form.
On the other hand, the registry unit is responsible for maintaining the list of
available aggregators and available services as fresh as possible, by kicking
irresponsive aggregators, and should serve clients that request data via the Web API.
It should be noted that the Registry Unit adds another layer of abstraction, as a user
needs only to specify on which IP the registry unit is running on, like you specify a
DNS server’s IP to connect to the internet, and a well written application should cater
for the rest.
What the registry unit does is that it provides a client with data about which
aggregators are available, which services they provide and what IP and Port are they
available at.
Development
The registry unit is a Web Server developed in java. In contrast to the
aggregator unit of the MicaZ nodes, no additional libraries were needed, apart from
the ones built into Java JDK. The code is organized in the following packages:




registryUnit: contains the main class
util: contains utility classes, like a hashing class, a statics class and a tools
class
webServer: this package is similar to the one named the same in the MicaZ
aggregator unit
infrastructure: this package is the core of the code. It contains the classes
that describe the aggregators, the requests, the communications(request
and answer) and the Services. Moreover it contains a class that tries to
52
describe the observable universe from the registry unit’s point of view and
contains the class that is responsible for executing each request received.
The registry unit is a console application that starts a server. The server is
multithreaded and can thus be made into a multicore application without a lot of
hassle.
We have already discussed the services that the registry unit provides via its
RESTful web API in chapter 4 and will not analyze them any further.
Discussion
The importance of the registry unit is undeniable as it adds the most important
layer of abstraction. By incorporating the registry unit in the architecture, the users
can at any time know every service that is available, with minimal configuration. Of
course, the use of a registry unit means that the aggregators must be configured in a
way that they are able to find the registry unit. This, however, is as easy as adding an
IP to an XML file, and therefore is easy for even a simple user of computers to do it.
Having said that, it is obvious that anyone in the network can use the registry
unit in order to get the available services. This means that other aggregators can learn
about the services available from other aggregators. Adding to that, an AI unit can be
programmed to make use of the services and the aggregators as it has been proposed
in the architecture layout in chapter 3. This way the architecture caters the needs of
self-configurability and self-maintenance and can be used in Smart Environments that
aim in such concepts.
It should be noted, that the registry unit does not provide the services it
describes, but just states the existence of them. After the user has gotten a service
description from the registry unit, he is prompted to call the service at the aggregator
unit using its details, as they are described from the registry unit’s answer. Some may
argue that this makes the registry unit redundant and that it serves no actual purpose
in adding abstraction over the aggregators’ network. In reality, the registry unit is the
most important part of the prototype, because it helps in discovering services without
having to create a multicast channel and having polls coming back and forth. Unlike
on the WSNs where we care a little less, on IP based networks we care a lot about
traffic on the channels and such congestions should be avoided at all costs!
53
Chapter 9: Assessment and future
work
Assessment
Having talked about how I implemented the prototype and gone through the
development phase it is apparent that I have not developed a demonstrator prototype
that implements the whole proposed architecture. I have, however, made a step
towards self-maintaining and self-configuring WSNs.
The prototype adds two main layers of abstraction via the use of middleware.
First, I have the layer that hides the WSNs from the user. This layer hides not only the
sensors but also their technologies, as in the hardware used. With this layer I make a
unified Web API for talking with the WSNs.
The second layer of abstraction is added from the registry unit. It is
responsible for handling every change in the available services, alongside of course,
with the aggregators, as they are the ones that will inform the registry unit for any
changes. It also keeps services list fresh by kicking inactive aggregators.
It should also be noted that the technology of each aggregator is not of
interest, only the Web API they provide matters. By making aggregators that conform
to standards I can start building applications that used them without user input, which
is the point, transparency.
Future work
As future work I have to note the completion of the proposed architecture, full
with every component described. The way it is designed caters to the needs of Smart
Environments, may that be buildings or homes or offices or anything. In addition to
that aggregators could be built for other sensors available too.
Another extension is adding security over the communications. At the present
time the messages are all plaintext and can be intercepted. Moreover anyone can
54
spoof their identity and pose as anyone else so adding security would be a solid step
for future work.
55
Chapter 10: Discussion
In my dissertation thesis I have proposed a system architecture for Smart
Environments. The way it is designed provides the foundations for scalable WSN
deployment in any conceivable Smart Environment while taking into consideration
multi-criticality of services, self-management and self-configuration. Moreover, the
WSNs can be heterogeneous and this is an integral part of this thesis
In addition I developed a prototype that implements the proposed architecture
up to a certain point. The reason for not completing the whole architecture was time
constraints. The prototype has two heterogeneous WSNs that use different
technologies. Two aggregators have been created, one for each of these WSNs. The
aggregators, too, are heterogeneous as they use different programming languages, but
offer a unified and conformed to preset standards RESTful web API. This unified API
is the first layer of abstraction over the WSNs.
The next step was to create a central unit that is responsible for creating a
registry of the services available through the web API from the aggregators. I called it
the registry unit. It is responsible for maintaining a list of all available aggregators
along with the services they provide together with their services’ descriptions. A user
of the system is to poll the registry unit for the services available. This adds a second
layer of abstraction because it removes the need for manual discovery of the services
available.
The code for the prototype is available on a public repository on GitHub at
https://github.com/Nikolopoulos/MScThesis/ for anyone to look at and mess with.
In conclusion I proved the feasibility of Smart Environments with
heterogeneous WSNs working in harmony with other devices and applications. The
most important thing is that all of this happens without ever revealing the models of
communication or the hardware they use.
56
57
Appendix A: ATMega128L pins to
MicaX pins
ATMega
PORT
MicaX
PIN
PIN
NAME
DESCRIPTION
PA0
51
8
LED3
Yellow LED
PA1
50
9
LED2
Green LED
PA2
49
10
LED1
Red LED
PA3
48
N/A FLASH_CS
U5 - Flash memory
PA4
47
N/A SERIAL_ID
U6 - Flash memory
PA5
46
7
Turns on Volt Ref for ADC7 Battery Monitor
PA6
45
N/A CHP_OUT
PA7
44
44
PB0
10
N/A none
10K pulldown, enables SPI
PB1
11
18
SPI_SCK
U3 DCK - Radio and program
PB2
12
16
SPI_MOSI
Program in, not used internally
PB3
13
17
SPI_MISO
U3 DIO - Radio data and program out
PB4
14
23
PWM0
(available PWM out)
PB5
15
24
PWM1A
(available T/C1A PWM out)
PB6
16
49
PWM1B
(available T/C1B PWM out)
PB7
17
N/A none
tied to PB1 for SPI clock
PC0
35
29
PW0
(available)
PC1
36
30
PW1
(available)
PC2
37
31
PW2
SB Sounder
PC3
38
32
PW3
SB Mic pwr
PC4
39
33
PW4
SB Accel pwr
PC5
40
34
PW5
SB Mag pwr
PC6
41
35
PW6
SB switch tone/mic to ADC2
PC7
42
14
PW7
(available)
PD0
25
21
I2C_CLK
I2C interface clock
PD1
26
22
I2C_DATA
I2C interface data
BAT_MON
THERM_PWR
U3 CHP_OUT - Radio
Temp sense enable, onboard thermistor to
ADC1 (opt)
58
PD2
27
19
USART1_RxD
U5 - Flash memory
PD3
28
20
USART1_TxD
U5 - Flash memory
PD4
29
N/A PALE
U3 PALE - Radio
PD5
30
15
U5 - Flash memory
PD6
31
N/A PCLK
U3 PCLK - Radio
PD7
32
N/A PDATA
U3 PDATA - Radio
PE0
2
27
UART_RxD0
Serial comm to external RS232 & program
PE1
3
28
UART_TxD0
Serial comm to external RS232 & program
PE2
4
25
AC+
SB tone decode (opt?)
PE3
5
26
AC-
PE4
6
6
INT0
(available ( interrupt & PWM out)
PE5
7
5
INT1
SB Light pwr ( interrupt & PWM out)
PE6
8
4
INT2
PE7
9
3
INT3
(available interrupt & timer in)
PF0
61
43
ADC0
U3 RSSI - Radio signal strength
PF1
60
42
ADC1
SB Therm/Light (sel with INT1/2)
PF2
59
41
ADC2
SB Tone/Mic (sel with PW6)
PF3
58
40
ADC3
SB Accel XFILT (opt)
PF4
57
39
ADC4
SB Accel YFILT (opt)
PF5
56
38
ADC5
(available)
PF6
55
37
ADC6
SB Mag (opt)
USART1_CLK
SB Vref (opt?)
(AC+/- are a voltage
compare pair...)
SB Temp pwr, MicaZ Radio recv int
(
interrupt & timer src)
Vref LM4401 Battery Level (turn on with
PF7
54
36
ADC7
PA5)
(compares ref to floating board
power)
PG0
11
33
RD
ExtMem Read (probably available)
PG1
12
34
WR
ExtMem Write (probably available)
PG2
13
43
ALE
ExtMem latch (probably available)
PG3
18
N/A TOSC1
32.768KHz xtal
PG4
19
N/A TOSC2
32.768KHz xtal
RESET
20
48
Reset
RSTN
59
Vref
62
2
VSNR
ADC reference voltage -- connected to VCC
Vpower
21
50
VCC
+3.3 volt power
Gnd
22
1
GND
0 volts
Gnd
N/A
51
GND
0 volts
UTIL
N/A
45
THRU1
N/A
UTIL
N/A
46
THRU2
N/A
UTIL
N/A
47
THRU3
N/A
60
References
[1] R.Reussne W. Hasselbring, "Towards trustworthy software systems," IEEE
Computer, vol. 29, no. 4, 2006.
[2] S. Haykin, "Cognitive radio: brain-empowered wireless communications," IEEE
Journal on Selected Areas In Communications, vol. 23, no. 2, 2005.
[3] et al R. Thomas, "Cognitive networks: adaptation and learning to achieve end-toend performance objectives," IEEE Commun. Mag., vol. 44, no. 12, 2006.
[4] Information and Communication Technologies (ICT), "Project “End-to-End
Efficiency” (E3)," in 7th Framework Programme (FP7) of the European
Commission, 2009.
[5] Michael Dunbar, "Plug-And-Play Sensors in Wireless Networks," IEEE
Instrumentation & Measurement Magazine, 2001.
[6] Jeffrey King, Steven Pickles, Hicham Elz Raja Bose, "Building Plug-and-Play
Smart Homes Using the Atlas Platform".
[7] Philipp Sommer, Roger Wattenhofer Lars Schor, "Towards a Zero-Configuration
Wireless Sensor Network Architecture for Smart Buildings".
[8] IBM.
Smarter Cities solutions
for
law enforcement.
[Online].
http://www.ibm.com/smarterplanet/us/en/smarter_cities/planning_management_so
lutions/index_C.html
[9] IBM.
IBM
Intelligent
Utility
Network
Solution.
[Online].
http://www.ibm.com/smarterplanet/us/en/smarter_cities/solutions/solution/infrastr
ucture_solutions/L420447J94627B46.html
[10] IBM.
Smart
metering
and
beyond.
[Online].
http://www.ibm.com/smarterplanet/us/en/smarter_cities/solutions/solution/infrastr
ucture_solutions/K626033G66635H91.html
[11] MIT. Energy Networks. [Online]. http://cities.media.mit.edu/research/energynetworks
[12] Oracle.
Oracle's
Solutions
for
Smart
Cities.
http://www.oracle.com/us/industries/public-sector/smart-cities.htm
[Online].
[13] Theresa A. Pardo Taewoo Nam, "Conceptualizing Smart City with Dimensions of
Technology, People, and Institutions," in 12th Annual International Conference on
Digital Government Research.
[14] IBM.
Smarter
Cities.
http://www.ibm.com/smarterplanet/us/en/smarter_cities/overview/
[Online].
61
[15] MIT
University.
CITY
http://cities.media.mit.edu/about/cities
SCIENCE.
[Online].
[16] IBM.
IBM
Intelligent
Law
Enforcement.
[Online].
http://www.ibm.com/smarterplanet/us/en/smarter_cities/solutions/solution/plannin
g_mgt_solutions/K177808H05987F38.html
[17] IBM.
IBM.
[Online].
http://www.ibm.com/smarterplanet/us/en/smarter_cities/infrastructure_solutions/in
dex_C.html
[18] IBM. Solutions for more instrumented, interconnected and intelligent systems.
[Online].
http://www.ibm.com/smarterplanet/us/en/smarter_cities/solutions/human_solution
s/#solutions_education
[19] Oracle.
Solutions
for
smart
cities.
[Online].
http://www.oracle.com/us/industries/public-sector/solutions-smart-cities-br1574173.pdf
[20] MIT. Reasearch Themes. [Online]. http://cities.media.mit.edu/research/overview
[21] MIT.
Urban
Analysis
and
http://cities.media.mit.edu/research/urban-analysis
Modeling.
[22] MIT.
Incentives
and
Governance.
http://cities.media.mit.edu/research/incentives-and-governance
[Online].
[Online].
[23] MIT. Mobility Networks. [Online]. http://cities.media.mit.edu/research/mobilitynetworks
[24] MIT.
Places
of
Living
and
http://cities.media.mit.edu/research/places-of-living
Work.
[Online].
[25] MIT.
Electronic
and
Social
Networks.
http://cities.media.mit.edu/research/electronic-social-networks
[Online].
[26] Alberto M. C. Souza Jose R. A. Amazonas, "A Novel Smart Home Application
Using an Internet of Things Middleware".
[27] Michael Schippling. MICA2,z ATMEGA128 Pin and Port Usage -- v2.0. [Online].
http://www.etantdonnes.com/Motes/ATMEGApins.txt
[28] TinyOs. TinyOs - Home Page. [Online]. http://www.tinyos.net/
[29] TinyOS Documentation Wiki. TinyOS Documentation Wiki. [Online].
http://tinyos.stanford.edu/tinyos-wiki/index.php/TinyOS_Documentation_Wiki
[30] TinyOS
Development
Wiki.
TinyOS
Tutorials.
http://tinyos.stanford.edu/tinyos-wiki/index.php/TinyOS_Tutorials
[Online].
62
[31] The QT Company. Qt | Cross-platform application & UI development framework.
[Online]. http://www.qt.io/
63
Thank you notes
No thesis is complete without a list of a thousand people you want to thank. I
will try to keep it short this time around though.
1. First and foremost I would like to thank the research team that helped me with
the design of the architecture, Mr. George Dimitrakopoulos, Mr. George
Bravos, Mr. Alexandros Dimopoulos and last but certainly not least, Ms. Mara
Nikolaidou.
2. I would like to thank my family and my girlfriend for managing to keep me
calm when I was under heavy pressure.
3. I would like to thank Mr. Alberto Messias and Mr. Amazonas Jose for kindly
offering me a copy of their paper A Novel Smart Home Application Using an
Internet of Things Middleware free of charge
4. I would like to thank Michael Schippling for creating the excellent table that is
featured in appendix A.
5. My crazy friends that every year celebrate summer at Scharokopio events
6. And of course, I would like to thank you, you the person that read this whole
thing. You are perfect, don’t you ever let anyone tell you otherwise!
PROTIP: To defeat the Cyberdemon, shoot at it until it dies.
64