Figures Table - Home of Invention and Madness · Web viewUnder normal conditions, the application...
89
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
Transcript of Figures Table - Home of Invention and Madness · Web viewUnder normal conditions, the application...
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
ContentsChapter 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
3
Development............................................................................................................52
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
Figures TableFigure 1-Architecture of a monitoring and control system for smart buildings. [20]..23Figure 2 - Layered Architecture [22]...........................................................................24Figure 3 - Proposed system architecture......................................................................26Figure 4 - Autonomous components............................................................................28Figure 5- Registry Unit's Operations Diagram.............................................................30Figure 6- The MPR2400CB Sensor.............................................................................34Figure 7 - MDA100 Sensor Board with Prototype Area..............................................35Figure 8 - MIB520 USB Programmer..........................................................................35Figure 9 - Main GUI....................................................................................................45Figure 10 - Mote Control Panel...................................................................................46
5
6
AbstractThe 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.
7
8
ΠερίληψηΗ εποχή του Internet of Things πλησιάζει απειλητικά, και μέχρι στιγμής δεν έχει
προταθεί μία αρχιτεκτονική συστημάτων η οποία να είναι κοινώς αποδεκτή και να
διαχειρίζεται την πληθώρα των έξυπνων εφαρμογών που ήδη έχουν αρχίσει να
κάνουν την εμφάνισή τους. Σε αυτή τη διπλωματική εργασία αποσκοπώ στο να
προτείνω μία αρχιτεκτονική συστημάτων για ασύρματα δίκτυα αισθητήρων, η οποία
να μπορεί να προσφέρει την αυτο-ρύθμιση, αυτο-διαχείριση, όπως επίσης και την
απαίτηση για υπηρεσίες με διαφορετικά επίπεδα κρισιμότητας, χωρίς να υπάρχει
απαίτηση για ομοιογένεια στο δίκτυο των αισθητήρων, τα οποία έχει μεγάλη ανάγκη
το Internet of Things. Αυτό θα το επιτύχω προσθέτοντας πολλαπλά επίπεδα
απόκρυψης πάνω από το υποκείμενο δίκτυο ασύρματων αισθητήρων. Επιπλέον, θα
δημιουργήσουμε ένα πρωτότυπο σύστημα το οποίο υλοποιεί την εν λόγω
αρχιτεκτονική ως απόδειξη ότι μπορεί να υλοποιηθεί η αρχιτεκτονική.
9
10
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 reconfigurability1, self-managed and self-optimized systems and the exploitation
of cognitive systems principles23.
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 self-
management. 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
11
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
12
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, Bluetooth5, Ethernet6, IEEE 802.15.4 6LoWPAN7, 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.56
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
13
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.89101112
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 one-
size-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
14
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 safetyThe 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
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
15
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
EnergyElectricity
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.
The benefits of smart metering are numerous:
Improved reliability and response time to regulatory and market pressures.
16
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
WaterWater 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 real-
time analytics, modeling and decision support capabilities. IBM’s solution is designed
to optimize water operations and to create new opportunities for innovation.
TransportationIBM’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
PeopleIBM 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
healthcare. Finally, their education solutions include a Framework for smarter
education, Business Analytics software for education, School solutions, Innovation in
17
research, Administrative solutions for education, Asset management for education,
Campus solutions for higher education and Enterprise risk management for higher
education.18
Oracle’s approachOracle 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
The three pillarsOracle’s solutions fit within Three Key Pillars
18
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 approachMIT’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 ModelingUrban 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 cities21
Incentives and GovernanceUrban services are poorly distributed and require significant effort to maintain
and upkeep. Projects in this theme address the creation of new, network-centric
methods for managing reactive urban systems. This will be influenced by crowd-
sourced intelligence and respond in real-time to the needs of urban residents.
19
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 NetworksResearch in this theme includes the development of a sophisticated multi-
modal 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 mobility networks are Multi-modal mobility
recommendation engines, new urban vehicles including electric scooters,
automobiles, bike-lane vehicles, etc., autonomous vehicle technology and vehicle-
pedestrian 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 WorkThe 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
Electronic and Social NetworksSocial networks enable the instant proliferation of ideas and events. Some
have even contributed to sociopolitical movement and revolutions. Projects in this
20
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 NetworksToday, 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
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
21
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
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
22
Figure 1-Architecture of a monitoring and control system for smart buildings. [20]
Figure 2 - Layered Architecture [22]
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
23
24
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
25
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.
26
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 ComponentsThe 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, or a device controller,
accepting instruction 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 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
broke out, a sensor node can be programmed to send urgent messages to inform the
27
Figure 4 - Autonomous components
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 UnitThe 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.
28
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 a
specific component. A
registry entry consists of: the
component description,
information for the IP it is
available at, and the
component’s services, followed
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
29
Figure 5- Registry Unit's Operations Diagram
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
30
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
31
32
Chapter 5: Working with the MicaZ family of sensors
The Hardware
The first sensor I
used for the prototype is the
MicaZ family MPR2400CB
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 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. Plug for optional external power, if we do not want to use batteries2. On Off switch3. ATMega 128L microprocessor, underneath the sticker4. Built in LEDs that the microprocessor handles5. 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
33
Figure 6- The MPR2400CB Sensor
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
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 transducer3. The temperature sensing transducer, also known as a thermometer4. 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 A27.
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 latch
onto the MIB520’s extension port
shown at 2. Analyzing Figure 8 we have as follows:
34
Figure 7 - MDA100 Sensor Board with Prototype Area
Figure 8 - MIB520 USB Programmer
1. The USB port for connecting to PCs.2. 51 Pin port like the one found on MicaZ units and the Sensor board3. 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 SoftwareThis 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.
TinyOSTinyOS is an open source, BSD-licensed operating system designed for low-
power wireless devices, such as those used in sensor networks, ubiquitous computing,
personal area networks, smart buildings, and smart meters28. 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 Wiki29.
35
NesCTinyOS 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
36
include $(MAKERULES)
and call it with:
make micaz
More info about programming with nesC can be found in the TinyOS Wiki
under the tutorials section30.
The Base UnitIn 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 unitsHaving 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.
37
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 node2. Poll Acknowledge: The answer to that message3. Read Request: A request to get the readings of a transducer defined in the
body of the message4. Read Acknowledge: The answer to the above message5. Switch Poll: A request for the state of the switch handled by the switch
service6. Switch Answer: The answer to the above message7. Switch Change: A request to change the state of switch handled by the
switch service
38
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 environmentIn 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 page29, 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-binutils-2.17tinyos-3.i386.rpm
o avr-gcc from www.tinyos.net/dist-2.1.0/tools/linux/avr-gcc-4.1.2-1.i386.rpm
o avr-libc from www.tinyos.net/dist-2.1.0/tools/linux/avr-libc-1.4.7-1.i386.rpm
o avarice from www.tinyos.net/dist-2.1.0/tools/linux/avarice-2.4-1.i386.rpm
o insight (avr-gdb) from www.tinyos.net/dist-2.1.0/tools/linux/avr-insight-6.3-1.i386.rpm
o avrdude from www.tinyos.net/dist-2.1.0/tools/linux/avrdude-tinyos-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 64-bit 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.
39
o NesC from http://tinyos.stanford.edu/tinyos-rpms/nesc-1.3.1-1.fc9.i386.rpm
o Deputy from http://www.tinyos.net/dist-2.1.0/tinyos/linux/tinyos-deputy-1.1-1.fc9.i386.rpm
o tinyos-tools from http://tinyos.stanford.edu/tinyos-rpms/tinyos-tools-1.4.0-3.ubuntu.i386.rpm or http://tinyos.stanford.edu/tinyos-rpms/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.gztar xf tinyos-2_1_2.tar.gz
This will extract the actual TinyOS code in a folder named tinyos-release-
tinyos-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 TOSROOT="<local-tinyos-path>"export TOSDIR="$TOSROOT/tos"export CLASSPATH=$CLASSPATH:$TOSROOT/support/sdk/javaexport MAKERULES="$TOSROOT/support/make/Makerules"export 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.
40
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 command3. micaz, this tells the compiler which platforms specific libraries it should use4. install, install it on the MicaZ unit5. 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 using7. /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 tinyos-
2_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.
41
42
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
43
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.
b. micaDetails: This class is responsible for presenting the user with a simple GUI for controlling the nodes available at the WSN.
44
Figure 9 - Main GUI
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.
NotesAs 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.
45
Figure 10 - Mote Control Panel
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.
46
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 sensorsIn 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
47
I was able to create a profile for this data and get started towards building the
aggregator for this sensor network.
The aggregatorPhilosophy 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 framework31 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 codeProgramming 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
48
be noted that is in part responsible for JSONising the data that will be responded.
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 whatThis 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.
49
50
Chapter 8: The Registry Unit
PrologueAh, 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.
DevelopmentThe 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
51
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.
DiscussionThe 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!
52
Chapter 9: Assessment and future work
AssessmentHaving 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 workAs 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
53
spoof their identity and pose as anyone else so adding security would be a solid step
for future work.
54
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.
55
56
Appendix A: ATMega128L pins to MicaX pins
ATMega MicaX
PORT 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 BAT_MON Turns on Volt Ref for ADC7 Battery Monitor
PA6 45 N/A CHP_OUT U3 CHP_OUT - Radio
PA7 44 44 THERM_PWRTemp sense enable, onboard thermistor to
ADC1 (opt)
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
57
PD1 26 22 I2C_DATA I2C interface data
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 USART1_CLK 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-SB Vref (opt?) (AC+/- are a voltage
compare pair...)
PE4 6 6 INT0 (available ( interrupt & PWM out)
PE5 7 5 INT1 SB Light pwr ( interrupt & PWM out)
PE6 8 4 INT2SB Temp pwr, MicaZ Radio recv int
( interrupt & timer src)
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)
PF7 54 36 ADC7
Vref LM4401 Battery Level (turn on with
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
58
RESET 20 48 RSTN Reset
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
59
Referencesx
[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-to-end 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_solutions/index_C.html
[9] IBM. IBM Intelligent Utility Network Solution. [Online]. http://www.ibm.com/smarterplanet/us/en/smarter_cities/solutions/solution/infrastructure_solutions/L420447J94627B46.html
[10] IBM. Smart metering and beyond. [Online]. http://www.ibm.com/smarterplanet/us/en/smarter_cities/solutions/solution/infrastructure_solutions/K626033G66635H91.html
[11]MIT. Energy Networks. [Online]. http://cities.media.mit.edu/research/energy-networks
[12]Oracle. Oracle's Solutions for Smart Cities. [Online]. http://www.oracle.com/us/industries/public-sector/smart-cities.htm
[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. [Online]. http://www.ibm.com/smarterplanet/us/en/smarter_cities/overview/
60
[15]MIT University. CITY SCIENCE. [Online]. http://cities.media.mit.edu/about/cities
[16] IBM. IBM Intelligent Law Enforcement. [Online]. http://www.ibm.com/smarterplanet/us/en/smarter_cities/solutions/solution/planning_mgt_solutions/K177808H05987F38.html
[17] IBM. IBM. [Online]. http://www.ibm.com/smarterplanet/us/en/smarter_cities/infrastructure_solutions/index_C.html
[18] IBM. Solutions for more instrumented, interconnected and intelligent systems. [Online]. http://www.ibm.com/smarterplanet/us/en/smarter_cities/solutions/human_solutions/#solutions_education
[19]Oracle. Solutions for smart cities. [Online]. http://www.oracle.com/us/industries/public-sector/solutions-smart-cities-br-1574173.pdf
[20]MIT. Reasearch Themes. [Online]. http://cities.media.mit.edu/research/overview
[21]MIT. Urban Analysis and Modeling. [Online]. http://cities.media.mit.edu/research/urban-analysis
[22]MIT. Incentives and Governance. [Online]. http://cities.media.mit.edu/research/incentives-and-governance
[23]MIT. Mobility Networks. [Online]. http://cities.media.mit.edu/research/mobility-networks
[24]MIT. Places of Living and Work. [Online]. http://cities.media.mit.edu/research/places-of-living
[25]MIT. Electronic and Social Networks. [Online]. http://cities.media.mit.edu/research/electronic-social-networks
[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. [Online]. http://tinyos.stanford.edu/tinyos-wiki/index.php/TinyOS_Tutorials
61
http://www.ibm.com/smarterplanet/us/en/smarter_cities/solutions/human_solutions/#solutions_education
[31]The QT Company. Qt | Cross-platform application & UI development framework. [Online]. http://www.qt.io/
x
62
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 events6. 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!
63
PROTIP: To defeat the Cyberdemon, shoot at it until it dies.
64
