POLITECNICO DI TORINO

ICT for Smart Societies

PROGRAMMING
FOR
IOT
LESSONS’ SUMMARY

BENNICI SILVIA - S256743

MAFFEI MARZIA - S260321
RENDE GENNARO - S218951
1 Introduction
1.1 Introduction: The Internet of Things scenario
The definition of IoT has changed during the years, from thinking that the future would
have been made of computers connected on the network, to having many devices with their
own IP address. IoT means enabling devices to communicate between them in a language
that allows the exchange of information. The big advantage that IoT offers is the collection
and crossover of data that can be managed in very complex algorithms and also can be
accessed/visualized anytime, everywhere.

1.2 The Network Issue

The way our machines communicate nowadays is with the
IP layer over TCP or UDP. IoT is exploiting the IP proto-
col, the problem is that it is not exactly designed for small
systems, devices. The protocol stack is typically executed by
PCs, which have a certain amount of computational power to
process much faster the network stack with all the layers (Fig-
ure [1]). Processing the full stack requires a lot of power which
is not suitable for small sensors, moreover TCP is mostly made
for long lasting connections and not for sending data occasion-
ally: the reason is a cost quite expensive (in terms of time) Figure 1: Stack layers
to establish a connection. Another major aspect to take into
consideration is that in IoT projects we also need to consider scalability: when we connect
thousands of objects in the network, we have to scale over a hundred/billion of devices and
consider also that we could have IDs problems. With IPv6 we have been able to get the
identification of single devices with a personal IP in the network, indeed, one of the most used
IoT protocols is 6LowPAN. So now we can have small sensors that work in the web because of
IPv6.

1.3 Security and Privacy

There is a problem in security in the
network mostly known as man-in-the-middle.
When we connect an object with another ob-
ject, or an object with a server the net-
work connection can be interrupted by some-
one else without being noticed. At the bot-
tom line, we have to develop cryptographic
protocol to encrypt data. All of this thou,
comes with a very high price in terms of
money.
Figure 2: Man In The Middle

1
1.4 IoT challange
With IoT we have the challenge to implement internet web services over small tiny objects
and over low bit-rate wireless networks. All these small devices are connected to a gateway
which can be a Raspberry PI and the communication can be over Wi-Fi (on 2.4 GHz or 5
GHz). The information acquired by the small devices, for example sensors, are sent to the
collector which is connected to a station and then to a data center that can be anywhere and
precesses the data received. All the sensors are connected in a local network called Personal
Area Network (PAN). PAN is a small network with a range of few meters, typically located
in a house.
Middleware is a software that manages the information and the connections to the devices
(sensors) in a way such that admins can modify these data, while users have some limitations.
It also implements some form of security and authentication. Another useful task that the
Middleware can do is translating incoming information to make them understandable to the
IoT system, so you can connect any type of device to your system.

1.5 Data Analytics & Visualization

Typically we want to do some processing and visualization of the data: many APIs will
help us in this task, we don’t need to develop the graphics.

Figure 3: IoT Ecosystem

1.6 Publish Share

The concept of Publish / Share is very important; the term "Subscribe" is used because
we subscribe to a device (e.g. the temperature sensor) and we get data not continuously
(pooling-based) but instead we are notified only when a certain change, that is of our interest,
is occurred (e.g. when from 20 degrees we reach 25 degrees). In this way we don’t have to
receive data in a continuous flow, or wasting time to ask information to a sensor: if a change of

2
value occurs, then a message is received. The subscription is possible thanks to the "Broker":
a software that keeps track of subscriptions. It is a mediator that sends only the information
of your interest, for which you have subscribed. This mechanism uses a protocol called MQTT
which will be explained more in section 5.

1.7 Web Services, Micro-Services & IoT

When we connect to an HTML Server, we are asking a
server to show a webpage, that is a service, a function...but
how do we use it? We suppose to have a Building Automation
Server to control all of my devices (e.g. sensors). One of the
sensors posts the value it obtained to a server, which is a sub-
scriber of that device, and understands the value because of
the language chosen (e.g. JSON or XML). In a IoT environ-
ment it is useful to exploit external services provided by other
IoT devices (e.g. sensors), known as "MicroServices" which is
an ensemble of independent services implemented by a single
Figure 4: microservices
program.

1.8 Data Exchanging in Web programming

The web consists of a lot of systems, devices and applications that need a common language
to communicate between them and in 1980/1990 was defined the SGML (Standard General-
ized Markup Language) which is a standard for defining generalized markup languages for
documents; SGML describes the syntactic and structural aspect of each markup language.

1.9 HTML - HyperText Markup Language

HTML is a real implementation of what is described in SGML and it is used to describe
web pages. It is not just a portion of text, it has to be considered in a graphical way because
it has the goal to produce a visualization: the webpage. This M.L. is made of ELEMENTS
which are keywords that describe the type of element that we are treating (e.g. <title> My
Web Page <title>).

1.10 XML - eXtensible Markup Language

XML is a direct son of SGML, it is used only to exchange in-
formation among devices and applications. It is human-readable
but also machine-readable. Along with the XML file there’s a DTD
(Document Type Definition), which embeds the semantic knowledge
of the document. This language’s main drawback is that it requires
a lot of memory/bandwidth thus it is not suitable for low memory
Figure 5: Tree structure
devices.
An XML document has a tree structure and each sub-tree (or node)
is an element which can include data and have attributes.

3
1.10.1 Logical Organization of the XML Document
An XML document may include declarations, processing instructions and comments, an
example is shown below:

Figure 6: XML document

1.10.2 The XML declaration

It is placed at the beginning of the document and specifies the XML version and character
encoding used in the document:

Figure 7: XML declaration

1.10.3 DTD: element declaration

DTD specifies "Element name" and "Content name" with the syntax:

Figure 8: DTD’s syntax

Model Types are:

• EMPTY. The element must be empty
• ANY. Any contents are admitted (no check)
• Element. The element must contain only elements
• Mixed Content. The element may contain both elements and data

4
1.10.4 DTD: element declaration
Element Model let specify name, order, optionality and multiplicity of nested elements by
a simple grammar.

A model is either an element or sequence of models or alternative of models:

• A comma denotes a sequence
• A vertical bar denotes an alternative

Multiplicity is specified by the postfix operators:

+ = the model must occur 1 or more times
* = the model must occur 0 or more times
? = the model must occur 0 or 1 times (is optional)

(a) (b)

Figure 9: DTD: element models

1.10.5 DTD: Default Declaration

Indicates if the attribute is compulsory or what is its default value. It may take 4 different
forms:

• #REQUIRED: The attribute is compulsory (no default)

• “default ”: The attribute is optional. If absent, the indicated default value is used.
• #IMPLIED: The attribute is optional, and the default value is undefined. Any value
can be used if the attribute is absent.
• #FIXED default: The attribute is optional, but fixed. If present, it must have the
indicated default value.

1.11 DTD: example

(a)

Figure 10: DTD’s examples

5
1.12 JSON - JavaScript Object Notation
JSON is a lightweight text based data exchange format, it is completely language inde-
pendent, it is easy to understand/manipulate and generate and it is NOT a markup language.
Just like XML it is made in plain text formats, hierarchical and self-describing (human read-
able). Unlike XML, JSON is lighter and faster, uses typed objects and much less syntax. This
is the structure of a JSON file:

Figure 11: JSON example

The data types used are Booleans true or false and also Null (nothing or no value), while
for the numbers we use:

Figure 12: Data types: Numbers

6
2 CherryPy
2.0.1 Introduction and first web application
CherryPy is a versatile web-framework that allows to eas-
ily translate object-oriented programming (made of classe) to
web applications, so we can run applications that work on
the net across multiple devices. This is how you mount a
first a application [13]. CherryPy to run this application
that returns the string "Hello World!", has to tun a web
server that uses the HTTP protocol. In our case the server is
located on the localhost at http://127.0.0.1:8080/ where
"8080" is the port. As we said before, the web application
Figure 13: First web application
was originally a class and in our case it is called "class
HelloWorld(object)", to put it on the server we have to
make it visible with the line "@cherrypy.expose". When we run the code with CherryPy,
our terminal says that the "ENGINE Bus STARTED", meaning that the web server has been
enabled for our Python application [14].

Figure 14: Status web server

2.0.2 First web application with different URLs

Now we will exploit multiple classes and CherryPy allows us to do so by deploying dif-
ferent URLs. By default we open the index which is the landing webservice that response
to the HTML request of localhost:8080. If instead of the index application I need another
one, I write my URL like this: http://127.0.0.1:8080/generate, where "generate" is the
name of the class/web application that I’m recalling [15]. In both methods I had to use
"cherrypy.expose" to make it visible to the web application.

Figure 15: First web application with different URLs

7
2.0.3 First web application with different URLs and parameters
We can also pass parameters input using the URL and the "?" means that we are pass-
ing some new values and we specify the name of the parameter and its value by typing
"http://127.0.0.1:8080/generate?lenght=16". Notice in [16] how among the function
"generate" there’s a parameter "length" so we need to specify it in the URL.

Figure 16: Example with different parameters and a value passed through URL

As we saw in [16] we are passing through the URL the value 16, but we must convert it
since it is a string, that’s why there’s a conversion of the parameter "int(length)".

2.0.4 Tracking end user activities

The HTTP protocol works with sessions which are the
channel where the Server and the Client exchange informa-
tion. CherryPy keeps information during a session that’s why
we can use a function such "display" in [16], because the
data are maintained. To start a session we write in the main
what we see in [17]. Since the session is enabled, CherryPy Figure 17: Enabling a session in main
will store the information by saving the string as shown in [18].

Figure 18: Saving a string for using it later in a session

8
2.0.5 Providing static resources
Web applications almost always make use of javascript, files, images or videos and CherryPy
provides support to serve static content to end-users. These resources are for example files
useful to define the UI (User Interface) of the web application that we are developing. Since
these static resources are in our hard disk, we need to specify the directory in the conf section
by writing: tools.staticdir.root. The following line is needed to get dynamically where is
running my application tools.staticdir.root:os.path.abspath(os.get.cwd()). We then
need to do the mapping so that when we type this URL: localhost:8080/static the web
application will know that it has to read the static files; to do so we add as is it presented
in [19] the lines ’tools.staticdir.on’:True and ’tools.staticdir’.dir:’./public’. In
this example we have a simple HTML file where there’s a static element which is style.css.

Figure 19: How a static resource is provided

2.1 REST Web Services and Methods

Representational state transfer (REST) or RESTful is a class of web services to send/exchange/retrieve
informations between machines, across the web. As most of the other web services approach,
REST exploits the HTTP protocol (which means that the web service can be found with an
URL)with different "methods" called CRUD (Create, Read, Update, Delete):

• POST ——> Create new documents;

• GET ——–> Retrieve information on a resource on the internet;

• PUT ——–> Update or Modify or Replace a document, it does more than GET because it can update a file;

• DELETE –> Delete.

Methods GET and POST are both used to submit data, but POST allows to transfer larger
quantities of data.
From now on, our Python application will be a web service since our class will became
REST Methods and the cherrypy.expose becomes exposed = True as we can see from [20].
Moreover we will use an HTTP compliant engine instead of the default option with CherryPy
by adding the line ’request.dispatch’:cherrypy.dispatch.MethodDispatcher(). So we
force the responses content-type to be text/plain and we finally ensure that GET requests will
only be responded to clients that accept that content-type by having an Accept: text/plain

9
header set in their request. However, we do this only for that HTTP method as it wouldn’t
have much meaning on the other methods.

Figure 20: REST Python Code

2.2 RESTful-style (URL)

2.2.1 URI
Cherry Py is able to read and manage URLs and we can see an example in [21]. Every
element in the string localhost:8080/first/second/3/fourth is divided by a "/". The field
*uri can be managed as an array.

Figure 21: RESTful-style parameters with *uri

2.2.2 PARAMETERS
In a URL, the section after ? is called a query-string.
? is unique for the whole URL. The query-string is used
to contextualize the URL by passing a set of (key, value)
pairs.

• The format is key=value;

• Each pair being separated by a & character.

Figure 22: RESTful-style parameters with
**params

10
If we look at [22] we can see that the parameters can
be managed as a dictionary.

2.2.3 URI and PARAMETERS

Here [23a] we see how both settings can be implemented and managed separately. While
in [23b] we see how also this implementations works for the different functions.

(a) GET function (b) Class mounted

Figure 23: RESTful application in Python

2.3 Hosting a single application

To host a single application the easy way is to use cherrypy.tree.mount()function. It
takes at least an argument, the instance of the application to host. Use it together with
cherrypy.engine.start() and cherrypy.engine.block().

(a) Application without "/string" (b) Application with "/string" (c) Application with "/string"
and "/conf"

Figure 24: RESTful application in Python

2.4 Hosting multiple applications

On the other hand, as we can see in [25], is also possible to mount more applications withe
different configurations "/conf" or not.

11
 Figure 25: RESTful applications in Python

2.5 HTTP Status Code

HTTP provides status codes for defining the outcome of the communication. They are
organized in five classes:

•1xx - Informational •2xx - Successful •3xx - Redirection •4xx - Client Error •5xx - Server Error

2.5.1 HTTP status codes: 2xx – Successful

This class indicates that the client’s request was successfully received, understood, and
accepted.

Figure 26: 2xx – Successful

2.5.2 HTTP status codes: 4xx – Client Error

This class is intended for cases in which the client seems to have erred. The server SHOULD
include an entity containing an explanation of the error situation, and whether it is a temporary
or permanent condition.

Figure 27: 4xx – Client Error

12
2.5.3 HTTP status codes: 5xx – Server Error
This class indicates cases in which the server is aware that it has erred or is incapable of
performing the request. The server SHOULD include an entity containing an explanation of
the error situation, and whether it is a temporary or permanent condition.

Figure 28: 5xx – Server Error

2.6 Raising HTTP Status Code

Use raise cherrypy.HTTPError() to manage an HTTP status code as shown in [29]

Figure 29: Line to raise an error in CherryPy

13
3 Web Programming
3.1 Webserver and webclient
The world of IoT is based on the web and it is crucial to focus on the difference between a
WebServer and a WebClient. With a certain URL we reach a specific machine on the web while
with a certain port we reach a specific application, for example: http://192.168.4.232:8080.
Overall, this is the mechanism we use to reach a remote point in the network. The communi-
cation between the Server and the Client happens thanks to the HTTP protocol, which is based
on REST. In all IoT applications REST is largely used, but we will focus on other alternatives
such as MQTT.

3.2 HTTP requests

HTTP is used by the client to make requests to the server and this is possible by ex-
ploiting GET, PUT/POST and DELETE. PUT and GET are the most used: the first updates a
request made already by POST while the second one is activated each time a web client (like a
browser) connects to a web server asking forn an HTML page. An example of a GET request
is http://localhost:8080/hello where we are asking to the local host for the "hello"’s
URL web page.

3.3 HTML pages

HTML is the programming language used to visualize a web page when a client connects
to a web server. The code of an HTML tells us how the page should look like. It can also
contain scripts to be executed(Javascript) and it can be associated with style specifications
(CSS). In the end, what we have to think, in order to better visualize in mind HTTP and
HTML, is seeing HTTP as an envelope while HTML as the letter inside of it. However, when
two machines have to communicate, we don’t use HTML because it is not efficient, but we
use JSON because we don’t need to do any formatting. There are many ways we can use
an HTML page, we can input text in fields or compile and submit forms through a POST
request; moreover, an HTML page can contain information to trigger specific methods in the
classes used by webservers as in the case of POST requests in a form (see Figure [30a]). We
can also insert pieces of code to be executed by the web server, for example to fill in some
content based on variables values (see Figure [30b])

(a) action trigger and POST (b) Pieces of code in HTML

method for a form

Figure 30: HTML pages functions

14
3.4 Web Service and IoT
The client can be, in our IoT system, a browser. If I want to visualize all the data from
my sensors, I can do it through a browser. The client will connect to a webserver, which is
the device itself and a small computer such as a Raspberry, which provides some intelligence
to the device, can be used to run the webservice. Our Raspberry will send information to
another webserver located in another device that maybe has more sensors. In general what
we have to keep in mind is that:
• A device will implement a webserver in a certain language using a web library
– E.g. python with cherrypy, Java, etc. . .
• Through the webservices the device can be:
– Configured
– Send data/commands
– Receive data/commands
• E.g. using GET/POST methods
• The client can be another device or a data collector node
• Webserver should be light

Now let’s see an example of how we can exploit HTML

files and then we will see exactly how back-end (HTTP)
and front-end (HTML) work together. In Figure [31]
is presented a piece of CherryPy code, which contains a
class and 2 functions, the first one (def hello(self, *uri,
**params)) reads the HTML page shown in Figure [32a]
and the second one (def reply(self, *uri, **params))
reads the HTML file named "page.html" shown in Figure
[32b]. Now let’s focus on Figure [32a] where we see the
HTML code shown in Figure [30a]; as said before here
we will be asked to fill out a form and then submit it
thanks to the method POST. The action "/reply" will trigger
the def function def reply(self, *uri, **params) method
(a) index.html
POST. The action "/reply" will trigger the def function def
reply(self, *uri, **params) which means that the vari- Figure 31: HTML pages functions
ables name="greet" and name="name" will be submitted to
the webservice.

(a) hello_form.html (b) page.html

Figure 32: HTML pages functions

15
3.5 How POST works
1. The browser first hits the web application at /hello but it sends a GET, so our Genera-
tor.hello method runs and returns the hello_form (see Figure [33a] and [33b]).

2. You fill out the form in the browser, and the browser does what the <form> says and
sends the data as a POST (see Figure [33c]).

3. The web application then runs the Generator.reply method rather than the Genera-
tor.hello method to handle this request (see Figure [33d]).

4. This index.POST method then does what it normally does to send back the hello page
like before (see Figure [33e])

(a) (b)

(c) (d)

(e)

Figure 33: Process of how Browser and a Web app communicate

16
4 Connectivity
When we choose the technology for our IoT environment we have to take into account
different aspects, from battery lifetime to power consumption and costs.
In terms of frequency we have two alternatives: the Sub-GHz and the 2.4GHz transceiver.
Lots of standards, like Bluetooth and WiFi, use the 2.4GHz, so many manufacturers assume
that the 2.4GHz is the de facto transceiver frequency.
Typically, the higher the frequency, the higher the bit-rate, that is why WiFi doesn’t use
Sub-GHz frequencies. A 2.4GHz network supports data rates greater than 1Mbps. On the
other side, Bluetooth, while using 2.4GHz, supports small data rate and it is used to connect
small devices in a small range. The advantage of Bluetooth with respect to WiFi is the
lower power consumption, but in Bluetooth it is not possible to implement authentication and
protection as in WiFi. 2.4GHz is used by Bluetooth also because the size of the antenna is
smaller than the one needed for Sub-GHz networks (high frequency means small wavelength
and small wavelength means small antenna). However, a 2.4GHz radio has limited range
(so it is suited to connect devices in a small range), poor wall penetration and high power
consumption.
Sub-GHz networks require a bigger antenna, but it has less problems of compatibility with
other networks. Moreover, Sub-GHz frequencies have a higher capability of wall penetration
and are useful to setup a stable channel, without interference. These characteristics make
Sub-GHz networks ideal for IoT devices like sensors, that need to last many years on a single
battery, work with low bit-rates and need to have wide coverage.
Considering a typical situation in which the PC will work, we have a wireless network with
a gateway. The gateway is connected to the network, which is connected through an Ethernet
protocol (using the MAC layers) and, through a WAN, it is possible to reach the server.
The more complex is the protocol, the more time and energy it takes to transmit/receive a
packet. This complexity generates an overload in the transmission management, that is why
in IoT applications we need to be careful of the complexity of the network layer. With device
consuming small amount of energy and having low computational capabilities, we can’t afford
a complex protocol.
Networking concepts:

• Packet switched networks: data are transmitted in packets

• Packet encapsulation: Header (info about packet) + Payload (actual content)
• Packet routing: how packets reach the final destination
• PAN: Personal Area Network, typically a network of wireless nodes, with a concentrator
or coordinator collecting data, that can also be the gateway node connecting the PAN
to the external world
• LAN: Local Area Network, typically Ethernet or WiFi, it has a computer acting as an
inteface with the external world (gateway)
• WLAN: connection of LANs, made of routers that get packets to their final LAN

4.1 Protocols
In terms of PAN, on the data link layer, one of the most used protocols in IoT applications
is the 802.15.4. It is a physical+MAC layer protocol, used for connecting wireless nodes and

17
IoT devices in a short range. If we want to use 802.15.4 in a network of objects interconnected
to the internet, we must be able to use the Internet Protocol (IPv4 or IPv6) on top of 802.15.4.
IP is typically used for WiFi (802.11) or Ethernet (802.3), not for small sensors networks.
On top of IP we need the transport protocol, which can be either UDP, TCP or ICMP. UDP
is a lightweight protocol, but it is less reliable than TCP and it doesn’t have retransmission.
TCP is more reliable, but it is heavier in terms of protocol overhead.
For IoT applications we prefer IPv6 because of the larger number of available addresses.
In fact, one of the main problems in sensor networks is that each sensor needs to have its own
unique ID and IPv4 has not enough addresses.
The 802.15.4 protocol has a data rate of 20-25Kbps, in comparison with the 11Mbps of
Wifi or the 200Mbps of Ethernet. In terms of energy consumption there is a big difference,
because devices working with 802.15.4 have a lifetime of hundreds/thousands of days, while
WiFi nodes lasts for a time between a fraction of a day and 5 days. In terms of the physical
layer specification, this protocol works with QPSK modulation. 802.15.4 has been designed
for low power, large scale and low cost.

4.2 Header format

Using IPv6 over 802.15.4 means that we have a large packet header that we need to put
in a small space. The solution is to compress it. The compression is done by removing useless
information and replacing others with some more concise. We use a fragment of the packet,
the DSP (dispatch), to specify how the rest of the header has been compressed. If the fist two
bits are "00", then it is not a LowPAN frame. Depending on these first two bits I can identify a
simple IPv6 header compressed ("01"), a mesh header or a header that includes fragmentation.
Then we have two fields called "header compression 1", for the IP compression, and "header
compression 2", for the UDP compression. The total sum of this information is lower than
the 40 bytes of network header. After the header we have the proper UDP packet.
If we have to support routing mesh network, we need an additional field called "multi-
hop", that encodes some information about how the routing is done. If we need to implement
fragmentation, we need another additional field.

4.3 Fragmentation
Fragmentation is needed because we can’t fit a whole IP packet into a PAN packet, so we
need to divide the payload in slices. When performing the fragmentation, we lose information
about the sequence number of packets and we won’t be able to reconstruct them in the correct
order. This means we need additional information in order to be able to rebuild the correct
sequence, the tag information and the offset information.
The tag information is used to associate all the fragments belonging to the same packet.
The offset information is a sequence identifying the order in which the packet should be put.
Then for each fragment, we have also the size information, telling us how large the packet is.
Fragments of a packet may be lost during transmission, so we use a 60 seconds timeout in
order to avoid that the receiver waits forever for the missing fragment in the sequence. If the
timeout expires the packet is discarded.

18
4.4 Link layer routing
A functionality we need to support is the link layer routing, i.e. the capability of routing in
a mesh network. This functionality is implemented at the PAN level, because one hop at the
IP level may mean many hops at the link layer. In order to implement this we need additional
information, which are the link address of the next hop and the number of remaining hops.

4.5 Energy profile

We use an oscilloscope to look at the energy consumption of a transmitting device using
the 802.15.4 protocol. On the x axis we have the time (from 0 to 10 ms), on the y axis we
have the power in mA.
We have an initial period in which the devices powers up and configures the radio. Then
we have the CCA (Clear Channel Assessment), during which the devices checks if the chan-
nel is clear. Then the transmitter encrypts the payload and loads its buffer, preparing for
transmission.
After the transmission, the device switches to receiver
mode, listening for the ACK.
Transmission requires more power than the initial phase
and listening for ACK requires a little more energy than trans-
mission.
When talking about power we also need to consider other
factors, for example overhearing. If we are in a shared
medium, a device can hear something that is not destined for Figure 34: Energy profile
him and discard the packet. Moreover, the larger the header
is, the more time we need to transmit and the more power we consume.

5 MQTT
MQTT (Message Queuing Telemetry Transport) is a machine-to-machine connectivity pro-
tocol. It is designed as an extremely lightweight publish/subscribe messaging transport pro-
tocol used for IoT.
It is useful to send small quantities of real time data. To visualize these data it is possible
to use a REST HTTP connection. It consumes a small amount of power, the protocol stack is
simple and the code footprint (size) is very small. It supports a QoS (Quality of Service), so
it is possible to implement reliable messaging, including retransmission. This makes MQTT
suited to work on unreliable networks, like the mobile network.
The publish/subscribe paradigm is the most important feature of MQTT. While the stan-
dard request/response paradigm requires an overhead, while the pub/sub is more like the
interrupt system. The subscriber subscribes for a certain type of data it is interested in and
waits for the publisher to publish those data, without making any request. This means there
is no waste of bandwidth for implementing the polling-based mechanism.
Moreover, the MQTT protocol keeps the connection open using very little power. The
overhead is very small (2 bytes) and this reduces the power consumption needed to keep the
connection between the devices.

19
 Looking at the network stack, we always have the physical/MAC layer, the IP layer and
the transport layer (TCP/UDP). If we use REST, we have the HTTP protocol on top of which
we implement REST. If we use MQTT we don’t need HTTP, MQTT takes the place of both
HTTP and REST. On top of MQTT we can put whatever data format we want (JSON, XML,
...). An alternative to HTTP is CoAP, a lightweight protocol for IoT based on 6LowPAN.
Possible stacks:
• PHY/MAC → IPv6 → TCP/UDP → HTTP → REST → JSON/XML/...
• PHY/MAC → IPv6 → TCP/UDP → MQTT → JSON/XML/...
• PHY/MAC → 6LowPAN → TCP/UDP → CoAP

5.1 Publish/Subscribe
The concept of publish/subscribe is like an interrupt-based system, while reequest/response
is a polling mechanism. Publish/subscribe is an asynchronous communication that allows the
development of loosely-coupled event-based systems.
With the pub/sub paradigm we have a direct link between client and server, so it removes
the dependencies between producer and consumer of information. This direct communication
is broken by the message broker, a third actor that is aware both of who produces the infor-
mation and who needs it. So there are at least three actors in a pub/sub system: the broker,
the publisher and the subscriber.
• Broker: central system that receives data from the sensors/publishers and forwards them
to all the interested subscribers; it’s an advanced interrupt controller
• Publisher: device (like sensor) that publishes the data
• Subscriber: client that makes a subscription to the broker for certain types of data
The different kinds of data a client can subscribe to are called topics. The publisher sends
a message with a certain topic (every message must have a topic), so that the broker can
forward it correcty to the interested clients.
The communication is event-based because we never know when a certain information is
sent by the publisher. When a publisher sends information, it creates an event, the broker
recognizes that something was raised by the publisher and forwards it to the subscribers. This
means that the pub/sub approach can react in real-time.
It is a scalable communication system, this means that new actor can come in the system.
A single broker can manage a huge number of subscribers and publishers.
MQTT was designed for real-time data, so it has a support for Quality of Service. In
MQTT QoS means how the information is sent and how it is received. The higher the level of
QoS, the higher the latency. It is possible to specifiy the type of QoS we want:
• QoS 0: the message is delivered once or never; no guarantees about the message delivery
from the publisher to the broker
• QoS 1: the message can be delivered once or more, we have to ensure that it is delivered
at least once; if the data is lost, there is a mechanism asking for retransmission; in this
case it is possible that multiple copies of the same data are received (because ACK may
be lost)

20
 • QoS 2: the message is delivered exactly once; it is based on two levels of ACK (an
handshake between broker and subscriber/publisher before sending the information)

The publisher defines the QoS level each time it sends a message, the subscriber defines it only
once at the moment of subscribing for a topic.
The broker acts also as a buffer, storing the data, so that the subscriber can retrieve the
data if lost.

5.2 MQTT vs. HTTP - Power

In the plots of Figure 35 we have the power consumed by MQTT in blue and the power
consumed by HTTP in orange.
On a 3G network, sending 1kByte of message, we can see that at the beginning, during the
setup of the communication, MQTT consumes less because the protocol has a light overhead,
while HTTP has a larger one.
In the Wifi network, the overall power is smaller. In the case of MQTT we have power
consumption at the beginning, while in the case of HTTP the power consumption is high
during all the communication.
In terms of battery, 3G consumes more than WiFi.
The third graph shows the power needed to keep the connection alive in a 3G network.
Using MQTT we pay a high price in setting up the communication (because of the broker
setup), but it is convenient if we need to send lots of data on a long-time connection. On the
other hand, in HTTP the cost of setting up the connection is smaller, while it is more costly
to keep it going, so HTTP is more suited for short communications.

Figure 35: MQTT vs. HTTP - Power

21
5.3 MQTT model
In the MQTT terminology, the subscribers and the publishers are the clients, while the
broker is the server.
The MQTT client is implemented by a library installed on top of CherryPy. This library
will exploit an already present transport layer network stack. On the logical network we will
have a TCP connection level and an MQTT session level.
The MQTT session identifies a connection between a client and the server. It will allow
the server to create a list of subscriptions from the client. Each time the broker receives a
messages, it forwards it to the queue corresponding to a certain topic.
A subscription is also a connection between a client and the broker, but it is defined as an
attachment of the client to a topic. The subscription can be transient or durable:

• transient: it ends with the session, so there is a 1-to-1 correspondence between the
subscription and the session; when the session is closed, the subscriber is detached from
the network; messages sent when the connection is close are lost.

• durable: it spans over multiple sessions; if the client will be disconnected from the
network, the subscription will last; the messages delivered during the disconnection
period will be received when the client reconnects.

The topic system in MQTT is hierarchical. This hierarchy is built up using "/", for
example: sensor/sensorID/information. In order to subscribe to multiple information it is
possible to use wildcards: "+" or "#".

• "+": for a single level of the hierarchy, for example sensor/1234/+ gives us all the
messages coming from the sensor with sensorID=1234; it can be used in any level of the
hierarchy
• "#": for all the remaining levels of the hierarchy; it can only end the topic string, for
example sensor/# gives us all the messages from all the sensors

5.4 MQTT message format

The header is fixed and very small (2 bytes). The first 4 bits are for the message type, 1 bit
for DUP (message is duplicated or not), 2 bits for QoS level, 1 bit for the RETAIN (persistent
or durable connection). The second byte tells us how long the rest of the packet is.

• 4 bits: message type

• 1 bit: DUP (message is duplicated or not)
• 2 bits: QoS level
• 1 bit: RETAIN (persistent or durable connection)
• 1 byte: how long the rest of the packet is

When the RETAIN bit is 1, it means that the published message will be saved and when
a new client subscribes to the topic, the retain message will be sent.

22
5.5 Callback
Each method of the MQTT library is associated with a callback. A callback is a func-
tion that is executed as a consequence of some events. This means that the callback is an
asynchronous function.
Example: when the connection happens, it will trigger the on_connect() callback.

5.6 Mosquitto
The message broker Mosquitto is open source and implements two versions of MQTT:
v3.1 and v3.1.1. The client library provided to establish the communication with this broker
is called Paho.
There are seven steps to establish the communication:
1. create a client instance
2. the client instance must connect to the broker using the connect() method
3. call a loop function to maintain the network traffic flow with the broker
4. use the subscribe() method to subscribe to a topic
5. use the publish() method to publish messages to the broker
6. use the unsubscribe() method before disconnecting
7. use the disconnect() method to disconnect from the broker
The Paho Client() is the client contractor object that will manipulate and read all the
connection with the broker. The Paho Client() receives the following inputs:
• client_id: string used to identify client connecting to the broker
• client_session: boolean that determines the client type, if True the broker will remove
all information about this client when it disconnects, if False it means the subscription
is durable
The connection is managed through the connect() function, that receives four parameters:
• host: hostname or IP address of the broker
• port: default is 1883, but the connection has no authentication or any sort of protection,
a protected connection can be set on port 8883
• keepalive: maximum period in seconds allowed between two communications with the
broker, if the broker doesn’t receive anything after this interval, it will consider the client
dead
• bind_address: IP address of a local network interface to bind the client to
Paho loop functions help maintaining alive the connection between the client and the
broker. The loop function must be called, otherwise the connection could be closed in an
unpredictable way. There are different loop functions (and they should not be mixed):
• loop(timeout 6= 0, max_packets = 1): calls regularly to process network events; it
waits until the network socket is ready, then handles the incoming/outgoing data; every
timeout the loop function sends a message to the broker saying that the client is alive,
so the timeout value must be lower than the keepalive value of the connect() function

23
 • loop_start() & loop_stop(): implements a multithreading approach, started by the
loop_start and killed by the loop_stop

• loop_forever(): blocks the application and never ends until the disconnect() function
is invoked

Once the connection is opened, Paho implements the publish and subscribe methods:

• publish(): it receives four arguments:

– topic: the string that identifies the communication flows
– payload: the actual message to send
– qos: the QoS level to be used
– retain
it returns a tuple (result, mID), where result indicates success or if the client is not
connected and mid is the message ID (mID) for the publish request; a ValueError
Exception is raised if the topic is invalid

• subscribe(): it receive two arguments:

– topic: the topic the client wants to subscribe to
– qos: the QoS level to be used
this arguments can be passed in three different ways:
– a string and an integer
– string and integer tuple subscribe(("mytopic",1)) representing the topic and the
QoS
– a list of string and integer tuples subscribe([("mytopic1",0),("mytopic2",1)]),
this allows the client to subscribe to multiple topics with different QoS
as the pulblish(), it returns (result, mID) and raises an exception if a topic is invalid

• unsubscribe(): used by a client to unsubscribe from a topic

5.7 MQTT Examples

5.7.1 Example 1 - callback loop
In Figure 36 we can see a Python script that creates a loop and waits in a loop.
One of the lines is the broker address. We have two options for the broker address:

• if the broker is another PC in our local network, then the broker address is the IP address
of that PC
• if the broker is a public one, then we use the address of the server, like iot.eclipse.org

The line client1 = mqtt.Client() creates an instance of MQTT client and we have all
the methods related to it, like client1.on_connect=on.connect, where we attach a callback
called on_connect.
With client1.loop_start() we start processing the callbacks, the code goes on and when
the event attached to the callback happens, the callback function will be executed.

24
 Figure 36: Python script that creates a connection

5.7.2 Example 2 - Publish/Subscribe

In the Python script in Figure 37 we have two callbacks, one that happens at the connection
like before and one that happens when the subscriber receives a message (client1.on_message
= on_message).
As argument of client.subscribe() we provide the name of the topic we want to sub-
scribe to. The topic name is a string.
In this case the client also acts as the publisher with client1.publish().

Figure 37: Python script with subscribe

5.7.3 Example 3 - two different clients

In the Python script in Figure 38 we have a pub/sub example with two different clients.
client2publishes on the topic bulb1 and client1 subscribes to that same topic. When
client2 publishes a message on the topic, the broker receives it and forwards it to client1.

25
 Figure 38: Python script of pub/sub with two different clients

6 Microservices
In the past (10 − 15 years ago) the application design approach was MONOLITHIC :
the application was a single executable that performed all the functionalities. When these
functionalities started to grow in number, this approach revealed itself to be not adequate.

6.1 Main issues of the monolithic approach

• complex realization

• not suitable for cloud computing

• not scalable

6.1.1 Complex realization

An application has to go through many stages before being released: it has to be designed,
built, tested, modified after the test, released and then updated continuously. Realizing a
monolithic application means that alla the teams that work on the different stages mentioned
above must be synchronized: if some members have some delay, all the others will suffer
from that. In the end, these application took too long to be released, had many bugs and
required many updates.

6.1.2 Not suitable for cloud computing

Nowadays applications are separated from the platform: they run across the web, on
different devices so to minimize the cost for the users (we don’t need to buy powerful and
costly devices, but just rent the computational power for the time need). Considering this
scenario, a monolithic application (that run on a single powerful device) is completely useless.

26
6.1.3 Not scalable
A monolithic software had different components, one to deal with a single feature, and one
single database. To make it scalable, the whole application had to be replicated in different
servers, but here a huge problem of synchronization rises: all the databases have to work in
sync, if one crashes, the whole system is down.

6.2 Characteristics of monolithic applications

The application is built by putting together many components and in the end the developers
have to deal with very large codes. This makes it easy to develop but brings many issues:

• it’s not clear who is the owner of the single component

• the code is difficult to read and debug

• if a single component fails the whole application doesn’t work

• it takes too much time to modify/fix it

• it’s not flexible and difficult to scale

In the end all the bugs and the long time to wait for an update is frustrating for the customer.
Moreover, nowadays the keywords for any application are FLEXIBILITY and SCALABIL-
ITY.

6.3 The Microservice approach

Instead of having one single heavy software that performs all the tasks, we prefer to write
many different small softwares each one performing just one task. All the softwares can run on
different devices and cooperate together exchanging data across the internet using lightweight
protocols like REST and MQTT (it works like a puzzle). This way we solve many problems
at once:

• the codes are light and can run in parallel, so they can yield the result is less time

• each code is easy to build and debug and the teams can work separately: this also cuts
the releasing and updating time of the app

• the service is easily scalable and very flexible (we can add new features just writing a
small piece of code that exchanges data with the others)

• it is clear who is the owner of the single component and security is improved because
the developer can hide some data

• the user doesn’t need to buy expensive devices (each task requires little computational
power)

• each small software can deploy a different language and technology (the developer is free
to choose the most appropriate for the single task)

27
6.4 Principles behind the microservice approach
• Each service relies on each other’s public API. Developers and users must define formats
and APIs (agree on the way they exchange data ). This is a crucial point, because if we
change format or API our software will not be able to exchange data with the others.

• Use the right tools for the specific task. Since applications communicate using public
APIs and a predefined data-format, application A doesn’t need to know what kind of
technology, language is using application B, nor if there were any updates.

The new challenge with this approach is to have a good architecture design phase, so to avoid
chaos and bottlenecks among microservices.

7 Platform for IoT Applications

Cloud computing relies on IoT distributed platform. The most important issues are:
• Interoperability : each software uses not only a different device, but also a different
language and technology.In spite of that all the services must be able to cooperate with
each other (for example it would be nonsense to change all the devices just because
there’s a new technology).

• Scalability : this means that the service can be scaled up or down to include different
devices, merge a huge amount of uses and data.

• Reliability : we must avoid failures, inconsistency and fragmentation of data. So

we have to implement error detection/correction algorithms and/or data interpolation
according to the use-case.

• The system must evolve over time rapidly and with no/small impact on the architecture.

• Modularity : services must be built so that they can be combined between them.

• Extendibility : services must be built so that new functionalities can be added.

• Decentralization : this is the case of the distributed system. The service is broken
into different microservices localized in different parts of the world but linked through
the internet.

• Flexibility : services must be built so that new requirements can be added without
having a strong impact on the rest of the platform.

• Synchronous communication : all microservices must have the possibility to retrieve

data from other microservices using REST/MQTT without waiting for new inputs (ask-
ing the user to insert them again). In this type of communication data is sent in a
continuous stream.

• Asynchronous communication : allows near real-time data transmission by exploit-

ing publish/subscribe approach and event-based communication. In this type of com-
munication data is sent intermittently, thus it support variable bit-rate.

28
 • Standardization : this encourages data exchange by exploiting common interfaces and
open data-formats.

• Security : it is crucial to provide authentication, confidentiality and privacy to the

users.

8 Middleware
In the Italian dictionary we find this definition of Middleware: "Insieme di software che
fungono da intermediari fra strutture e programmi informatici, permettendo loro di comunicare
a dispetto della diversità dei protocolli o dei sistemi operativi".
A Middleware is a computer software that provides services to software applications
beyond those available in the operating system.

• it consists of different software components and it’s a distributed software: it can run in
parallel on different computers

• its purpose is to make easy the communication among protocols and operating systems

• it allows the user to retrieve informations/data from a database, know how the system
evolves, detect which devices belonging to our platform are connected to the internet.

• it’s a software that connects other software components or other applications

• lies between operating system and applications on each side of our network

8.1 LinkSmart Middleware

LinkSmart is an opensource middleware for heterogeneous IoT devices; it has features to
discover which devices belong to our platform and helps applications to exploit the IoT devices
connected (overcomes the common problem of incompatibility between proprietary protocols
and devices, thus we are dealing with interoperability). Finally it abstracts the IoT device as
a web service and allows the user to easily access data.
It consists of two main components: LocalConnect and GlobalConnect.

8.1.1 Some definitions

• Device is a physical IoT device with communication capabilities and exposes various
resources.

• Resource is the abstraction of the "real" resource (sensors,actuators) belong to the IoT
by a device and hosted by the device. Ith has a state that can be manipulated (turned
on/off)

• Service is a network service available on the network (e.g. Web Service, Message Broker)
providing a protocol endpoint

29
8.1.2 LocalConnect
LocalConnect has three components: Device Connector, Service Catalog and Re-
source Catalog.
The Device Connector is the one that provides interoperability among heterogeneous
devices. It stands at the edge of the platform and it implements the following functionalities:

• Manage devices and resources in the Resource Catalog (publish/update/remove(if failure

occurs) registrations)

• Provide communication with devices over the network via MQTT, HTTP/REST, etc.

The Device Gateway is an implementation of the Device Connector. It acts like a gate-
way between the low-level hardware access protocol and a TCP/IP network. Its components
are shown in Figure 39.

Figure 39: Device Gateway

• Device Agent : implements the low-level communication with the devices using differ-
ent interface protocols (interoperability: it can translate from a protocol to another)

• Process Manager : executes the right device agent, depending on user settings (knows
which device agent is connected to a specific request)

• Service Component : responsible of establishing the communication with other con-

nected devices through internet protocols like MQTT/REST

8.1.3 Service Catalog

The Service catalog helps the user in discovering the components of the software and where
they are deployed. It describes the services available in the network by exposing JSON-based
RESTful API. It can be considered as the entry point for applications and other components
(Device Gateway) to discover the registered services.

8.1.4 Resource Catalog

The Resource Catalog is a registry of all the IoT devices connected and functioning; it is
updated each time a new device is connected/disconnected. It exposes a simple JSON-based
RESTful API which is used by Device Connectors and Applications that exploit the
catalog in order to know where a device is, what is the end-point and what are its resources.

30
8.1.5 Communication Flow
Here is described the information flow necessary to a device to become part of the network
to an application to exploit the network functionalities (see Figure 40).

1. By default the end-point of the Service Catalog is known

2. Resource Catalog registers

3. Device connector looks for RC: it has to ask SC first

4. DC knows where RC is and can contact it to register devices and resources

5. Application looks for RC: it has to ask SC first

6. App gets in touch RC is and asks for the list of devices

7. App asks for a specific service

Figure 40: Communication flow in LinkSmart

The Resource Catalog can be disconnected, in this case , the Service Catalog must remove the
RC from its available resources.

8.2 GlobalConnect
Since LocalConnect works in a private (routable) network, GlobalConnect acts as a Border
Gateway that exposes the local network to the internet by enabling transparent communica-
tion of application and services (see Figure 41).

Figure 41: GlobalConnect as Border Gateway in LinkSmart

31
9 IoT software infrastructure
Today the IoT ecosystems are composed of various software stack running on host comput-
ers , such as servers or cloud systems. These systems are used for data processing,storage,network
management, authentication and as registry for services and devices.
A certain number of middlewares and platforms (either commercila or open) are available
and they support, among others, data stream processing, complex event processing, machine
learning, big data analytics.
Platform as a Service (PaaS) is a category of cloud computing services that provides an
already made platform, so that costumers can develop, run and manage applications without
having to build the whole infrastructure.
PaaS can be either a public cloud service (in this case the consumer has minimal configu-
ration options), or a private service inside a firewall.
Beside PaaS, there are other categories of similar services: Software as a Service (SaaS)
which is a software that runs on a cloud and Infrastructure as a Service (Iaas) that allows
the costumer to rent the infrastructure. PaaS lies between the Saas and IaaS.
Some examples of Paas are:

• AWS by Amazon allows to secure data and interactions

• Cloud Foundry provides a choice of clouds,developer frameworks and application ser-

vices

• Predix is optimized for secure connectivity and analytics at scale

• Bluemix by IBM

• ThingSpeak by Mathworks

• Microsoft Azure

• Iottly by a local company in Turin

9.1 ThingSpeak
ThingSpeak allows applications and devices to send data streams on the cloud, collect and
analyse them and trigger reactions. Operations like create/update/delete a channel can be
done using the REST API calls (GET, POST, PUT, DELETE); update the channel feed can
be done using REST or MQTT-publish (the channel is given an ID).

10 Service life cycle

A Smart city platform is an ecosystem composing of people, processes, tools and tech-
nologies (it can be seen as a system of systems); the goal is to realize and deliver services
(functionalities) to end-users. Such services are bound to a specific context and stakeholders’
requirements (stakeholders can be :Municipalities, governments, cities, utility providers,ICT
companies, organizations of various type).

32
 Figure 42: Service Life Cycle is a loop

A Use case is a list of actions or event steps, typically defining interactions between
an actor (human or external system) and a system, to achieve a goal. Use case analysis is
fundamental in software engineering!
Services can vary in properties and level of complexity based on the applicable use case.
A general Service Life Cycle is a loop of the kind represented in Figure 42

• Service Definition : the service is described highlighting the main features and func-
tionalities

• Service Design : requirements are analyzed and functions/features identified

• Service implementation : the service is implemented and tested

• Service Delivery : the service is continuously monitored to ensure meeting the perfor-
mance requirements; potential improvements are identified

• Service Decommission : disposal or replacements of a service

• Service Re-Definition : after the decommission, the loop starts again for updating the
service

11 Containers
A Container is a software technology to implement microservices. As it is shown in
Figure 43 each virtual machine needs a different Operating System, while using containers it is
possible to build different applications over the same Operating System (like this a developer
doesn’t need a virtual machine for each microservice).
The original Linux container is known as LXC and it is a system-level virtualization method
for running multiple isolated systems (applications) on a single host (as explained in the
definition above). Moreover, a container can be moved across any Linux server that supports
the container environment.

33
 Figure 43: Structure of a system without and with containers

11.1 Dockers
Docker is a project to build LXC containers that can run a single process and make
containers more flexible; it basically brings cloud-like flexibility to any infrastructure capa-
ble of running containers. Docker containers allow to deploy, replicate, move and back-up a
work even more quickly and easily.

Docker Container
If an environment consists of If an environment consists of
N processes, the developer needs N N processes, the developer needs 1
containers (each one with a single process) container (containing all the process)

The advantages of docker containers are:

• the application is independent the configuration of low-level resources

• when a container is moved from one host to another the environment for the application
remains the same

There are also some limitations to dockers:

• a developer can’t run agents, log scripts or daemons inside

• it’s not easy to make small changes to an application: it’s better to start a new updated
docker

In practice, the first step is to install Docker and then activate the container engine.
When the engine is running, different commands (provided by the Docker) can be launched
from the command line. The simplest thing is to try "hello-world" by typing

docker run hello-world

where "docker" is the Docker environment, a sort of interpreter; "run" is one of the possible
commands and "hello-world" is the name of the image (this is not an executable but an
image). The Docker will check if there is an "hello-world" image and run it; like this it
creates an instance of the image. The instance is a container and it’s possible to create many
containers out of the same image.

34
12 Multithreading in Python
Threads are often called "light-weight" processes because operating systems require fewer
resources to create and manage threads rather than processes. Their characteristics are:

• multiple threads within a process share the same dataspace with the main thread, there-
fore they can easily communicate with each other (more than if they were in different
chunk of memory)

• threads don’t require much memory overhead: they are cheaper than processes

• a thread has a beginning, an execution sequence and a conclusion. An instruction pointer

keeps track of its current state

• it can be interrupted (pre-empted) can be temporary put asleep (on hold); this is called
yielding

In python the interpreter controls all the threads of a program and the Global Interpreter
Lock (GIL) ensures that the interpreter runs only one thread at a time.
To use threads in Python one has to import threading library; it is also possible to use the
threading.Thread class and use its methods, which are:

• run() : entry point of a thread; it implements the tasks that the thread performs

• start() : starts a thread by calling the run method

• join([time]) waits for threads to terminate

It is also possible to know the currently running thread (treading.currentThread), the

list of currently active threads (treading.enumerate),set and get a thread object name
(setName/getName).

12.1 Thread Life Cycle

Figure 44: State diagram showing the life cycle of a thread

35
 A newly created thread begins its life cycle in the born state; after invoking the start
method, the thread is placed in the ready state. After that, the run method obtains the GIL
and enters the running state. When the run method returns or terminates (for any reason),
the thread enters the dead state. While waiting for a resource to be available, a thread enters
the blocked state; if a thread calls the time.sleep function, it releases the GIL and enters the
sleeping state. All these states (except the dead state) return to the ready state as soon as a
condition is met.
If thread A is running and calls thread’s B join method, it forfeits the GIL and waits
thread B to die before proceeding.
A Deadlock happens when one or more threads wait forever for an event that cannot
occur; an Indefinite postponement happens when when one or more threads is delayed for
an unpredictably long time.

Figure 45: Thread Example

12.2 Thread Synchronization

Sections of code that access shared data are referred to as critical sections; Thread
Synchronization (or Mutual Exclusion) ensures that when a thread accesses shared data,

36
 Figure 46: Thread Example1

all the other threads can’t access them simultaneously. Module threading provides sev-
eral thread-synchronization mechanism (locks and condition variables). For example, class
threading.RLock clreates lock objects; a lock can enter the locked state by calling method
acquire (notice that only one thread can acquire lock at a time) and is unlocked when calling
method release.

12.3 Semaphores
A Semaphore is a variable that controls access to common resources or to a critical
section.
It basically maintains a counter that specifies the maximum number of threads that can
access a resource simultaneously; this counter is decreased each time the resource is accessed
and when it reaches zero no other thread can access the resource until it has been released by
another thread.

37
Figure 47: Thread Example1 Output

Figure 49: Semaphores Example part1

38
 Figure 48: Thread Example2

Figure 50: Semaphores Example part2

39
 Figure 51: Semaphores Example output

13 Machine learning for IoT

Machine learning makes it possible to process the data at sensor level and only send the
final summary of the analysis over the network (an example of sensors able to do this kind of
processing are the Cognipoints,which track movements inside a building so to save energy
when there’s no one). This approach, will yield a thinner volume of data and a shorter response
time.
When applying a deep-learning approach, the engineer’s main focus is to define the neural
network’s core architecture.

13.1 Artificial neurons: first generation

(a) First generation (b) Second generation

Figure 52: Artificial neurons

Artificial neurons of first generation can only give digital outputs, but they can easily deal
with data that have digital input and output. They need a hidden layer because with

40
a single layer only a threshold is used, but for some functions (like XOR) more than one
threshold is needed.

13.2 Artificial neurons: second generation

They apply an activation function with a continuous set of possible output values to a
weighted sum (or polynomial) of the inputs; a common activation function is the sigmoid
function: 1/(1 + e−y )(typical neural networks are feed-forward and recurrent sigmoid). These
nets are able to compute arbitrary boolean functions and it has been shown that neural nets
from the second generation can compute certain boolean functions with fewer gates than neural
nets from the first generation (they are more efficient). Furthermore, they are able to compute
functions with analog input and output: any continuous function with a compact domain and
range can be well approximated by a network of this type with a single hidden layer.

41