Professional Documents
Culture Documents
Scientific Research
University of Manouba
National School for Computer Science
Authors:
Supervisor:
Moudhaffer Azizi
Mrs. Leila Nasraoui
Amine Arfaoui
May 1, 2017
1
Contents
1 General Presentation 8
1.1 General concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.1 The Wireless Sensor Network . . . . . . . . . . . . . . . . . . . . . . 8
1.1.2 WSN nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.3 The border router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.4 WSN communication models . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.5 WSN and IoT Communication protocol stack . . . . . . . . . . . . . 10
1.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Design 19
3.1 General design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 General Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1 Potential Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2.2 Potential WSN topologies . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.3 Potential WSN Data sending paradigms . . . . . . . . . . . . . . . . 23
3.2.4 Final choice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Detailed Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1 Overview of the project . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.3 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.4 Sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.5 Data storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2
3.3.6 Deployment diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Development 31
4.1 Software environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Data format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Border router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 UDP client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5 UDP server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6 Main application development . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.6.1 User interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.6.2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.6.3 Overview of the realized work . . . . . . . . . . . . . . . . . . . . . . 40
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5 General conclusion 42
3
List of Figures
4
4.12 data sample. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.13 Database schema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.14 Code for fetching data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.1 Time-line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5
Listings
6
General Introduction
Today, smart grid, smart homes, smart water networks, intelligent transportation, are
infrastructure systems that connect our world more than we ever thought possible. The
common vision of such systems is usually associated with one single concept; the Inter-
net of things (IoT), where through the use of sensors, the entire physical infrastructure is
closely coupled with information and communication technologies; where intelligent moni-
toring and management can be achieved via the usage of networked embedded devices. In
such a sophisticated dynamic system, devices are interconnected to transmit useful measure-
ment information and control instructions via distributed sensor networks. This project is
focused on the implementation of a platform that is able to monitor through the Internet
a set of environmental readings with the use of a low-power devices with limited processing
capabilities under an IPV6 local WSN .
In this project, a comparison between the features of the major communication protocols
for the IoT will be drawn , the choice of the network topology and the application archi-
tecture will be explained and the reason of running contiki os on our sensing devices will
be highlighted . Furthermore, a final note on the used hardware must be mentioned, in the
implementation part of this project although we made a feature comparison between some
sensor motes models, the use of Inertial-z1 as hardware development platform was not a
choice ,not just because of its availability at that current time but also because we have been
able to obtain a respectful number of them with the help of our supervisor.
7
Chapter 1
General Presentation
8
This kind offers the greater scalability among other topologies. Every node maintains a link
to other nodes within range (i.e. its neighbors) and the decision on which one to use is
reached by the used routing protocol according to the number of hops and the latency of
every route. The nodes of a WSN cannot always be of the same type, but they must support
the same standards and protocols in order to be able to communicate with each other.The
hardware of a sensor node generally includes 5 parts:
Sensors : Capture physical data from their environment. The continual analog signal
produced by the sensors is digitized by an analog-to-digital converter and sent to
controllers for further processing.
External memory : The most relevant kinds of memory are the on-chip memory of a
micro-controller and Flash memory (off-chip), RAM is rarely, if ever, used. Flash
memories are used due to their cost and storage capacity. Memory requirements are
very much application dependent.
Micro-controller : performs tasks, processes data and controls the functionality of other
components in the sensor node.
A wireless transceiver : Sensor nodes often make use of ISM band, which gives free radio
spectrum allocation and global availability. Radio frequency-based communication is
the most relevant that fits most of the WSN applications. WSNs tend to use license-free
communication frequencies: 173, 433, 868, and 915 MHz and 2.4 GHz
9
The functionality of both transmitter and receiver are combined into a single device known
as a transceiver. The operational states are transmit, receive, idle, and sleep.
IEEE 802.15.4
One of the most widely used mesh network communication standards is IEEE 802.15.4. It
defines the Physical (Layer 1) layer and the Data-Link (Layer 2) layer, and more specifically
the Medium Access Control (MAC) sublayer of that layer, of the OSI model. The first
revision of the 802.15.4 standard was released in May 2003. Today, several standardized and
proprietary network (or mesh) layer protocols run over 802.15.4 based networks, including
10
Figure 1.3: The protocols stack of a WSN.
IEEE 802.15.5, ZigBee, 6LoWPAN, Wireless HART, and ISA100.11a. This standard is
designed with one simple target in mind; to achieve the lowest power consumption. According
to this, it is designed for use in low cost, low speed communication between low power devices.
As a result, this standard describes a slower and smaller range wireless communication
method compared to the IEEE 802.11, which is the Wi-Fi we all use every day, with the
tradeoff of significant lower power consumption. The basic specifications include a 10 meter
(maximum 20 meters) communications range with a transfer rate of up to 250 kbps with other
options of 100 kbps, 40 kbps, and 20 kbps available as well. Devices are able to communicate
in one of the three possible frequency bands for operation (868/915/2450 MHz). Finally, it
uses CSMA/CA protocol as a MAC mechanism and two addressing modes; 16-bit short and
64-bit IEEE addressing.
6LoWPAN
6LoWPAN is an abbreviation of “IPv6 over Low Power Wireless Personal Area Networks”.
The 6LoWPAN concept comes from the idea that ”the Internet Protocol could and should
be applied even to the smallest devices and that low-power devices with limited processing
11
capabilities should be able to participate in the Internet of Things. 6LoWPAN enables
constrained devices that are unable to handle the traditional IP stack to function, and
connect to an IPv6 network, such as the Internet. The mapping from the IPv6 to the IEEE
802.15.4 was not an easy task to carry out, because of the many differences mainly in terms of
packet size, address resolution and maximum transmission unit (MTU) of the two networks.
It was finally achieved by compressing and encapsulating the IPv6 and UDP headers.
UDP
UDP uses a simple connectionless transmission model with a minimum of protocol mecha-
nism. UDP provides checksums for data integrity, and port numbers for addressing different
functions at the source and destination of the datagram. It has no handshaking dialogues,
and thus exposes the user’s program to any unreliability of the underlying network: there
is no guarantee of delivery, ordering, or duplicate protection. If error-correction facilities
are needed at the network interface level, an application may use the Transmission Control
Protocol (TCP) or Stream Control Transmission Protocol (SCTP) which are designed for
this purpose. UDP is suitable for purposes where error checking and correction are either not
necessary or are performed in the application. UDP avoids the overhead of such processing
at the level of the network interface. Time-sensitive applications often use UDP because
dropping packets is preferable to waiting for delayed packets, which may not be an option
in a real-time system.
MQTT
MQTT (formerly known as Message Queue Telemetry Transport) is an Internet of Things
connectivity protocol that runs on top of the TCP protocol, developed by IBM for lightweight
Machine-to-Machine communications. It implements a publish/subscribe interaction model
where the client devices do not need to impulsively request for updates; thus, reducing in
that way the drain on resources and on power on the IoT nodes and making it optimal for
use on high-latency or unreliable networks. For the same reason it is also used on mobile
12
phone applications such as Facebook Messenger. In 2013 IBM submitted MQTT v.3.1 to
the OASIS specification body and successfully completed the standardization of MQTT.
MQTT protocol follows the server/client schema with the server in this particular case
to be called broker. The clients do not communicate directly with each other, in fact all the
messages (publishes) travel through the broker. Every message, except from its text (from
now on referred to as payload), has a topic and each client can subscribe to various topics.
Topics are organized in a hierarchical manner (called topic levels), with the form of file
paths such as in a computer’s file system; e.g. “home/bedroom/light/status”. The broker
receives the publish message from a client and is then responsible for relaying the message
to every other client that has subscribed to this particular topic. It is easy to understand
that MQTT was designed for one-to-many and many-to- many communications and with
the assumption that a pre-defined relationship between participating nodes exists, because
there are no discovery or content negotiation mechanisms in the protocol. On the figure
above (figure 1.3) a simple publish/subscribe example is depicted. MQTT has five basic
methods/functions described by its specification, and could also have more, depending on
the broker’s implementation; they are:
• Connect
• Disconnect
• Subscribe
• Unsubscribe
• Publish
13
Another important feature of the MQTT protocol is the support of three different levels
of QoS (Quality of Service). The term “QoS level”, is, in fact, a form of agreement between
sender and receiver of a message regarding the guarantees of delivering a message. MQTT’s
QoS levels are the following:
The assurance of the QoS levels greater than zero is achieved with the use of ACK
(acknowledge) packets between the published and the broker. Designed as a lightweight
protocol for use on constrained devices, MQTT has some additional features towards that
target. Namely, it has support for persistent sessions and message queuing for single clients,
and the ability to retain messages on selected topics.
The first feature is really helpful on unreliable networks where clients get often disconnected
from the broker, and also saves a lot of resources on the client because there is no need to
re-subscribe to all the topics after a reconnection. When a persistent session is configured,
during the first connection of a client to the broker, it is ensured that all the subscriptions
to the topics done by that client will be retained if the client gets unexpectedly disconnected
from the broker. Additionally, all the messages that were published on the retained topics,
with QoS greater than zero, will be sent to the client after it gets reconnected.
The ability of the broker to retain the last message (together with its QoS) on a selected
topic on the other hand is useful for newly connected clients because they are immediately
updated about the status and they do not need to wait for the publishing client to send
the next status update. Finally, MQTT supports Last Will and Testament (LWT) messages
and a configurable Keep Alive time interval for client-broker connections. The LWT feature
is used in order to notify other clients about an ungracefully disconnected client by sending
them a pre-defined (during the client’s initial connection to the broker) message to a pre-
defined topic (also QoS and retained flag could be pre-defined). Secondarily, the configurable
keep alive time interval is the longest possible period of time, which broker and client can
endure without sending a message, and is really important for mobile networks due to their
peculiar handling of TCP packets
1.2 Conclusion
All along this chapter we shed some light on some known concepts about Wireless Sensor
Networks. In the following chapter, we are going to present the requirements and specifica-
tions in order to determine the functionalities of the output solution.
14
Chapter 2
15
2.1.2 Hardware development platform
When it comes to WSN, the second important decision that must be made, after the choice
of OS, is the decision of which hardware platform to use. Today there are a lot of available
options:
• Ultra-low power and limited resources platforms: Zolertia z, MSB430, CC2538SoC.
• Medium power platforms: Arduino.
• More powerful platforms: Raspberry Pi.
Except from power consumption and performance capabilities, extensibility in terms of
enough I/O connections and popular interfaces support, as well as community support,
must also been considered.
2.2 Requirements
2.2.1 Functional requirements
Our application must provide the user with the following functionalities
Display gathered data in real time: The user must be able to view readings from the
deferents devices in real time.
Synthesize data reports: The user must be able to view historical data of previous read-
ings
Generate charts of preexisting data: The application must provide some charts and vi-
sual reports.
16
2.3 Specification
2.3.1 Use case diagram
The bellow use case diagram illustrates the main functionalities of the system and the ap-
plication
Once the user opens the web interface (main page), he finds the latest received read-
ings: The temperature value, the acceleration variation and the battery level of each node
in the WSN, the information is displayed as gauge(with minimum and maximum value),
charts(Time as x and readings as y), text and numerical values . Also (still on the home
page) the user can read the time of last update and an indicator shows weather or not a
node is active. Moreover, the user can switch to another page where he can see the historical
environmental data and can chose the time interval of the readings that he wants.
17
Figure 2.3: Sequence Diagram.
server remains waiting for data coming from the scripts responsible for connecting to the
WSN through the Internet. The incoming data is then parsed and analyzed to create or lets
say change/refill the user interface with the newest values. This process indicates that the
application has to be event-driven programmed where there is generally a main loop that
listens for events, and then triggers a callback function when one of those events is detected
(it’s a paradigm used in graphical user interfaces)
2.4 Conclusion
This phase was our main focus. Meetings with our supervisor were held in order to determine
the requirements like who is going to use the system? How will they use the system? What
data should be input into the system? What data should be output by the system? These
were general questions that got answered during a requirements gathering phase.
In this chapter, we have detailed the functional and nonfunctional requirements. Therefore
the different features of the project and the needs for the application are set clear for the
next phase.
18
Chapter 3
Design
19
Figure 3.1: Service oriented architecture.
20
Choice of architecture
Our integration design is based on “EDA” , in fact :
• The sensor motes ,or let’s say the WSN don’t know what consumers may be interested in
an event .
• The sensor motes don’t know how each consumer may react to an event, and indeed expects
that different consumers may react differently
• The communication is one-way: The announcers(WSN motes ) doesn’t want to wait for
the consumers(clients) to react, indeed doesn’t know when they’ve all reacted, and isn’t
interested in the results from the reactions
Tree Topology
The network use a central hub called a root node as the main communication router. In
the hierarchy, central hub is one level below from the root node. This lower level forms a
star network. The tree network can be considered a hybrid of both the Star and Peer to
Peer networking topologies as shown in Fig 2.2. In sensor network path may be single hop
or multi hop, sensor node for getting data sense the environment and sent them to the sink
and sensor forwards them to its parent after receives data messages from its children. It is
important to find an optimal shortest path tree with maximum lifetime and shorter delay
but slightly high time complexity and but more suitable for distributed implementation.
21
Figure 3.4: Tree topology.
Bus Topology
In this topology, there is a node send message to another node on the network sends a
broadcast message onto the network that all other nodes see, but only the intended recipient
actually accepts and processes the message. Bus topology is easy to install but congestion
of traffic and single path communication. However, bus networks work best with a limited
number of nodes. If more than a few dozen nodes are added to a network bus, performance
problems will likely result.
Mesh topologies
Mesh topologies involve message can take any of several paths from source to destination.
(Recall that even in a ring, although two paths exist, messages can only travel in one di-
rection.) A mesh network in which every node connects to every other is called a full mesh
and there is partial mesh networks also exist in which some devices (nodes) connect only
indirectly to others .
22
Figure 3.6: Mesh topology.
Choice of topology
Since our WSN doesn’t have a large number of motes and and because we wanted to centralize
the process of sending data to the client, we used the “Star topology”.
The time driven delivery scheme is meant for applications that need cyclic monitoring Hence
the nodes will periodically turn their sensors and transmitters, in order to sense the envi-
ronment and send data periodically In the case of event-driven and scheme, sensor nodes
reply instantly to abrupt modifications in the sensed features because of the occurrence of a
specific query, which is suited to real time situations. It is possible to make a blend of these
2 schemes .
Choice of the WSN Data sending paradigms
Since our platform is for environmental monitoring it have to send data periodically and
it can face some severe real time situations that need to be closely monitored and rapidly
updated, that’s why we chose a mixture of time driven and event driven paradigms. In
fact, this allow the transmitters to change their different time-cycles based on the current
situation of the monitored environment.
23
3.2.4 Final choice
24
3.3.2 Software
Operating system for Sensor motes
Contiki OS meets all the requirements and it is the one we will use on this project. It is
an open source and community supported operating system designed for use in IoT and it
is written in C language. It is currently supporting a large number of different MCUs and
radios. As for protocols, its supports the commonly used TCP/IPv4 and IPv6 with the uIP
(micro-IP) stack, and it also supports the 6LoWPAN stack and its own stack called RIME.
The network stack implemented in Contiki is slightly different than the usual model typi-
cally adopted in TCP/IP. In-between the Physical and the Network layers, where, usually,
the MAC is located, Contiki has three different layers: The Framer, the Radio Duty-Cycle
(RDC) and the Medium Access Control (MAC). All these layers could be configured at
compilation time by using their respective global variables. Contiki also has threading capa-
bilities with a thread system called Protothreads and includes also libraries for a wide range
of popular applications such as HTTP, Constrained Application Protocol (CoAP), UDP, and
FTP servers, as well as other useful programs and tools, among them a MQTT client. One
of Contiki’s most prominent feature is the support of IP protocols, being one of the first
embedded operating systems to provide IPv6 support.
25
3.3.3 Network
Hardware development platform
Zolertia Z1 Z1 is equipped with a second generation MSP430F2617 low power microcon-
troller, which features a powerful 16-bit RISC CPU @16MHz clock speed, built-in clock
factory calibration, 8KB RAM and a 92 KB Flash memory. Also includes the well-known
CC2420 transceiver, IEEE 802.15.4 compliant, which operates at 2.4GHz with an effective
data rate of 250Kbps. Z1 hardware selection guarantees the maximum efficiency and robust-
ness with low energy cost. Built-in sensors
ADXL345 Accelerometer The ADXL345 is a small, thin, low power, 3-axis accelerometer
with high resolution (13bit) measurement at up to ±16 g. Digital output data is
formatted as 16-bit twos complement and can be accessed through either a SPI (3- or
4-wire) or I2C digital interface. ADXL is connected to msp430 through the USCIB1
used as I2C.
Raspberry Pi
The Raspberry Pi is a series of credit card–sized single-board computers developed in the
United Kingdom by the Raspberry Pi Foundation. Raspberry Pi is an open source hardware
technology combined with a programming language and an Integrated Development Envi-
ronment (IDE). The Raspberry Pi platform allows the user to create custom hardware and
applications to control it via its Name sake programming language. Many software languages
26
Figure 3.11: The protocols stack of a WSN.
are available on the Raspberry Pi and we are interested in two. These are the C++ and
Python. The Raspberry Pi is a low cost, small and portable size of computer board. It can
be used to plug-in to computer monitor or television, keyboard, mouse. The Raspberry Pi
uses an SD card for storage, which is fast and has no moving parts and the Pi is completely
silent.
Product Overview
• DSI display port for connecting the Raspberry Pi touch screen display
27
Application layer protocol of the WSN (MQTT)
Firstly, based on the comparison table[table 1.3], it is easy to see that MQTT offers greater
QoS options against the other protocols, which makes it perfect for use on unreliable net-
works. On top of that, it is based on TCP instead of the unreliable UDP transport protocol,
making it an even more reliable choice. One of the disadvantages of MQTT is that it has no
discovery capabilities, but that is not a problem in this case, mainly because the scenarios
of use for WSN nodes in IoT assume that all the properties (the sensors that are available
and their names/topics) are already known and therefore there is no need for discovery. The
other drawback of MQTT is that it is not a synchronous communication protocol. Once
again, this is not a problem in our case, as there is no special need for synchronous commu-
nications between the WSN nodes and it is eventually counterbalanced by the large options
of QoS. Finally, MQTT is the second most popular (after HTTP) IoT messaging protocol
used today for IoT applications according to a recent survey (IoT Developer Survey 2016 )
done by the Eclipse IoT Working Group, IEEE IoT and Agile IoT on April of 2016 and this
is an extra reason why MQTT was chosen.
Quick summary
28
3.3.4 Sequence diagram
29
3.3.6 Deployment diagram
3.4 Conclusion
In this chapter, we got a more detailed vision of how the implantation of the project is going
to be. The deployment diagram along with the sequence diagram makes it a good transition
for the next phase. In this phase the system and software design is prepared from the
requirement specifications which were studied in the previous phase. System Design helps
in specifying hardware and system requirements and also helps in defining overall system
architecture. The system design specifications serve as input for the next phase of the model.
30
Chapter 4
Development
31
The application turn the acquired data into a time series document in a MongoDB
collection
32
When data is traveling from the 6LoWPAN-network, it is shown as: “from slip to tun”.
In the opposite way the tunnel application will output: “from tun to slip”.
After this function, we will print the addresses with the function print−local−addresses().
This function only prints the address of the server and the client. The next step is done by
opening a connection to the remote server. Therefore the client opens a local socket through
which it can send data.
The server and client can only communicate if the sockets are set up in the right way. A
socket is defined by two parameters:
The IP-addresses: client and server should know the IP address of their partner, usually
the client initiates the connection, and the server replies.
Port numbers: both server and client can only communicate if their listening and writing
ports match.
After the socket has been set up, the client is able to send data to the server and to receive
data back. Sending data is done by using for example the timer. This method ensures a
33
Figure 4.5: Sending a UDP-packet at client side.
regular sending interval. The sender method is called through a callback method of the
timer. To send information to the server, the method send − packet() is used.
To receive packets from a remote device (server) the other function tcpiph andler is used.
This function is called when the tcpipe vent is raised in the main loop
• The server only binds itself to a socket. When the socket is created, the server will
wait until an incoming connection arises. At that moment, a tcpip event will be arisen
and the server parses the incoming data.
• Since the server only binds to its own socket, it will not create a client socket before-
hand. In order to respond back to a client, the server will only create a socket for the
client when data comes in from a client. The socket is then used to reply back to that
particular client.
Some additional details should be noted before proceeding to the programming of such a
node. The server’s IP address will be given by the nodes nodeid and nodemac. Therefore,
we will compile the application in mode 3. This results in the IP-address of the server being
set up as follows:
Listing 4.4: server IP address
u i p i p 6 a d d r (& ipaddr , 0 xaaaa , 0 , 0 , 0 , 0 , 0 , 0 , 0 ) ;
u i p d s 6 s e t a d d r i i d (& ipaddr , &u i p l l a d d r ) ;
34
the IP address of the server is set by the nodeid and nodemac, combined with the IPv6-
prefix of the network. This address should be used in UDP-client applications in order to
reach the server. Also, the UDP-port of the server should be the same as the one used in the
UDP-client. In order for the server to reply back to a clients request, the server implements
following method
35
Real time dashboard
The bellow figure shows the dashboard for real time monitoring. The values are refreshed
each 20 seconds (20 seconds can be adjusted of course).
• Temperature
• Acceleration
• Battery level
The figure illustrates how the User-side application works, a data flow comes from the
MQTT-SUBSCRIBER node (on the left), its format is then adjusted and transformed from
a JSON String to a JSON Object before adding the client’s local time as a JSON field using
a JavaScript function (the time takes the format of a Unix Time stamp in milliseconds).
After that a ”switch” node directs the message to 2 different flows based on the node-id field
(id) , each sub-flow store the data into a Database and extract the values into UI nodes.
• Temperature
• Acceleration
• Battery level
36
Figure 4.8: Data traveling from the broker into real time monitoring and database.
In this figure , a flow comes from the periodical event/flow generator node (on the
left),after adding the database query in the message, the flow duplicates to a couple of
flows. The flows go into the MONGODB nodes where the retrieval of the JSON files from
the 2 database collections takes place based on their date field, the the useful data is then
extracted and passed to the Dashboard nodes.
37
Figure 4.10: Data fetched from the Database into Dashboard nodes.
38
4.6.2 Database
The bellow figures illustrate the structure of our database. Each node has its own collection
of data as following:
39
4.6.3 Overview of the realized work
40
4.7 Conclusion
All along this chapter we have presented the work that needed to be done on both the software
and the hardware. We then presented the actual system via some graphical interfaces
41
Chapter 5
General conclusion
As part of the design and development project, we were assigned to design and realize an
application for monitoring wireless sensor networks. The first step in the realization of our
project was to conduct a study of the exiting wireless sensing network implantations which
led us to become familiar with WSN related concepts.
It’s only fair to state that the implantations were highly relative to the domain and that
there was no major WSN solutions to critic in the first place.
We then began the analysis and specification of needs and we have determined the differ-
ent needs that our application should satisfy and the features it should offer to the user.
Thereafter, we were interested in the conceptual study of the application from which we
have identified the general architecture and the different UML diagrams, namely use case
diagrams and sequence diagrams. Finally, we outlined the hardware and software tools used
during the implementation of our project. The connection of the WSN itself was not easy
as we had to first understand how the network motes operate. Connecting our network to
the broker was easy.
We have also introduced Screenshots that describe the various features of our application.
We had many difficulties working on this project especially since we were new to the field.
This experience was constructive and interesting. Thus, we were able to little time acquire
knowledge about the concepts of WSN, in the same way, we have been able to put our the-
oretical knowledge into practice. This project allows one to understand the structures and
the topology of today’s IoT networks. Else such networks can be deployed all over the world
the makes our everyday life smarter and more efficient.
Problems encountered
During the development phase some problems were encountered, especially with the proper
configuration of border router and also with some bugs on the msp430-gcc compiler that
prevented us from using the full 92 Kilobytes of flash memory available on the Zolertia Z1.
While the latter was not a major issue for us, it must be taken care of for future expansion
of the above implementations because some of them have almost reached the ROM usage
limit of 56 Kilobytes. As an additional note on this chapter, the lessons learned from this
work will be mentioned. Firstly, it should be noted that a slightly large amount of time was
42
used for researching the available MQTT client implementations for Contiki. This, however,
could be bypassed if Contiki had a continuously updated and detailed list of the built in
support of protocols and applications.
Open issues
In the future, we intend to develop a secure MQTT implementations for use on the IoT by
exploiting more layers of the OSI Model, with the use of the compressed version of IPSec
designed for constrained devices, or the Transport Layer, with the use of, the most popular,
TLS. Furthermore, a more comprehensive comparison of the IoT protocols with the perfor-
mance assessment of them could also be done. On a topic not strictly related to this project,
a great area of research, where much work still needs to be done, is the interoperability
in IoT. As already mentioned, IoT contains very different communication, and not only,
protocols. As a result, a method for enabling IoT devices using different communication
protocols to communicate with each other, either by using a “smart” bridge or by using
protocol conversion/translation on the application layer, would be really groundbreaking.
Time-line
43
Bibliography
44
45