2017 IEEE First Summer School on Smart Cities
Natal, Brazil, August 6-11, 2017
IoT-Based Smart Parking for Smart Cities
Anderson Araújo, Rubem Kalebe,
Gustavo Girão, Itamir Filho Department of Computer
and Kayo Gonçalves Engineering and Automation – DCA
Metrópole Digital Institute – IMD Federal University of
Federal University of Rio Grande do Norte – UFRN
Rio Grande do Norte – UFRN
Natal, Brazil E-mail: alberto--melo@hotmail.com E-mail: 10.bianor@gmail.com
E-mail: {ufrnanderson, rubemkalebe}@gmail.com,
{girao, itamir.filho, kayo}@imd.ufrn.br
Abstract—The advance in computing brought also solutions to
problems that can improve citizen’s life. One significant problem
involves parking vehicles, which is related to traffic congestion,
air pollution and driver stress. Due to that fact and the increase
in the number of vehicles, it becomes necessary a smart parking
proposal that mitigates those problems and interacts with the
drivers. In this paper we will describe a smart parking system
able to gather quantitative information and provide it trough an
extensible platform to drivers and other smart city applications.
The proposed system is implemented disposing ultrasonic sensors,
a web service, the FIWARE platform, and a mobile application
to Android devices, on a three-layer architecture. The paper also
aims to present the results of a proof of concept, which shows
that this approach is appropriate for monitoring parking systems
and exhibit the parking lot situation at any given moment. Thus,
it is the first step to propose a comprehensive solution for smart
cities.
I. I NTRODUCTION
In recent years, ubiquitous computing (or “ubicomp”) is
presented as one of the major challenges of research in
Computing [1], [2]. Ubicomp is viewed as a fusion of mobile
computing and pervasive computing [3]. The first one is
characterized as the user’s capability of carrying computational
services with him, which becomes an extension of the user.
The latter implies that the computer is embedded in such a
way that blends to the environment and sometimes is not
perceived by the users. This situation can allow the gathering
of environment data, also known as context, and that can be
used by a system to provide relevant information to the user,
marking the system as context-aware [4]. In light of this,
ubicomp emerges from that need to integrate mobility with
the usefulness of pervasive computing allowing the users to
interact with the environment [3].
Ubiquitous computing talks about interconnected objects but
which are not necessarily available on the Internet. For this
reason “the term Internet of Things (IoT) has come to describe
a number of technologies and research disciplines that enable
the Internet to reach out into the real world of physical objects”
[5]. With the quick development of IoT applications and the
increasingly quantity of connected devices, a large amount
of data is generated and needs to be stored, processed and
978-1-5386-1063-3/17/$31.00 ©2017 IEEE
Alberto Melo Bianor Neto
Department of Electrical
Engineering – DEE
Federal University of
Rio Grande do Norte – UFRN
Natal, Brazil Natal, Brazil
accessed. Thus, IoT is supported by cloud computing, since it
is well suited for large scale data-storage [6].
Those concepts can meet each other in order to solve urban
problems and improve citizens’ life. One well-known problem
is the increasingly use of private vehicles in large cities on
a daily basis, that affects urban mobility. In 2013, VEJA
magazine published a research performed by YE consultancy
in which fifteen districts from the expanded center of São
Paulo (a zone that concentrates the major parts of services,
jobs, and leisure and cultural equipment of this Brazilian
metropolis) if summed could receive around 509,000 cars by
day, however there is space just for 384,000 [7]. Thus, 125,000
cars cannot park and so they waste much time looking for
parking spaces, and when the drivers do not get a spot, they
park in inappropriate places.
The large amount of vehicles on the streets is caused
mainly by the shortage of parking spaces and also by the
improper management of the available spots. This situation
leads to traffic congestion that harms urban mobility. Another
consequence is the increase of air pollution provoked by
vehicle pollutants gases, since the more time they take to park,
the more gases will be released.
Therefore, it is needed computational solutions that enable a
good flow of vehicles on the streets and dispose of services to
ease parking, such as checking the parking situation before go
out. It could be also useful some method to identify the drivers
which parked, especially if they parked on reserved parking
spaces (in this paper we use the expression reserved parking
spaces for those which are allocated to specific groups, like
elderly, disabled people or women, except in the Section II),
in order to make sure they have that right.
Furthermore, a system of that domain could be also em-
ployed both in public areas, such as commercial centers,
which have strong demand for parking spaces (especially on
Christmas season, for example), and private areas, making sure
drivers can park in a fast and practical way.
Thus, this paper aims to present a smart parking system
for gathering quantitative information, proposing an exten-
sible platform where those data are available for smart city
applications and to the drivers. The proposed system follows
31
a hardware/software co-design development process that dis-
poses ultrasonic sensors, a web service, the FIWARE platform,
and a mobile application to Android devices, on a three-
layer architecture. Moreover, it implies an appropriate solu-
tion for monitoring parking systems and exhibit the parking
lot situation at any given moment. The remainder of the
paper is structured as follows: in Section II we discuss a
few solutions involving smart parking systems; Section III
proposes an architecture for this work and Section IV presents
the experimental setup and the results achieved; and, finally,
Section V summarizes this smart parking system proposal and
discuss some future steps.
II. R ELATED W ORKS
Many works involving smart parking solutions have been
proposed, such as [8], [9], [10] and [11]. Srikanth et al. [8]
proposed a parking system, called SPARK, based on Wireless
Sensor Network (WSN) technology due to the need of an
automated, easy-to-use, cost-effective and real time parking
system. That system is able to monitor and manage singular
parking spaces and provide to the users a service of parking
space reservation. Moreover, SPARK works with light sensors
for detecting vehicles and the spot data is transmitted to a sink
subsystem using radio frequency (RF).
In the work proposed by Wang and He [9] is developed a
system that sends information about the parking and make a
reservation service available to the users. A sensor network
employing ZigBee1 modules is adopted in order to monitor
the occupancy status of the parking spaces in real time. Each
module has a luminosity and a vibration sensors which are
used to detect the vehicle, and a bluetooth module which is
responsible for communicating with the user’s smartphone and
validate his identity. The user can also reserve a parking space
with his own smartphone via Internet. Based on the parking
spots status the system can analyze the parking occupation,
determine the parking price, periodically notify the users about
the price.
Kianpisheh et al. [10] focused on shopping complexes and
concerned about finding vacant parking spaces and return that
information to the drivers, in addition to detect improper park-
ing. Their system works with ultrasonic sensors, one for each
individual parking space, which are fixed on the ceiling above
each spot. The driver is guided by a LED display board, that
shows the quantity of vacant spaces and their types (vacant,
occupied, reserved and handicapped), and internal signs (that
shows the quantity of available spaces and the direction of
the aisle which has a vacant space) hanging from the ceiling
at the end of each aisle. Each individual parking space is
equipped with LED lights which are located above the space
and can show green (vacant), red (occupied), blue (assigned
for handicapped drivers) or yellow (VIP or reserved for some
reason). The LED and the sensor are connected with each other
through a phone cable. The system is composed also by zone
control units (ZCU), which control the sensors, and central
1 http://www.zigbee.org/
32
control units (CCU), responsible for processing data and send
commands to the ZCU and LED panels. Moreover, the system
holds a network switch that connects ZCU, panels and CCU,
and a management software. Finally, the improper parking
detection is done through two extra sensors at each parking
space, oriented horizontally along the lines demarcating the
left and right boundaries of the space.
A modular parking system service-oriented was also pro-
posed by Grazioli et al. [11]. In that work it is possible to draw
the parking lot area using the Google Maps API2 and specify
details, such as the positions of parking places and their price
per minute. The users are guided to the most suitable parking
lot or to chosen points, and it is also possible to monitor all
of the vehicles that are parked. That system has a web and
a mobile applications for managing the parking as well as a
web and a mobile applications to the drivers. The management
features include the possibility to create new parking lots, set
the parking price, and generate a QR code that will be used
by the drivers in order to establish the interaction with the
system. The driver features include the possibility to manage
his vehicles which are identified by its license plate, and look
for close parking lot by GPS localization, an address or a list of
parking lots. Using that application the driver can choose the
parking spot he will park and set how much time he intends to
stay parked, which the system can extend if the time expires.
However, it is not possible to get real time information about
the parking spots since there is no vehicle detection on the
parking spots. Because of this, there is an option where the
users set the percentage of how much they think the parking
lot is occupied (25%, 50%, 75% or 100%), but this feature is
not interesting since it can effect a wrong information.
In short, not all the works share points in common, each one
has its advantages and disadvantages (for example, although
the system proposed by Kianpisheh et al. [10] has a complete
parking detection method, which detects even a improper
parking, it is expensive and does not hold a strong interaction
with the drivers), and they do not provide a good support for a
smart parking as a smart city application. Neither work studied
presented a solution to identify the driver parked or check if
the driver have the right to park on a reserved parking space.
In addition, the systems described are not scalable since new
sets of sensors must be allocated for monitoring new parking
spots.
III. M ETHODOLOGY
Many projects in IoT follow a common architecture, such
as a four-layer model described by Xu et al. [12]. At the
bottom of that model there is the Sensing Layer, which has
the integration with hardware (sensors, actuators and other
devices). The communication with the layers above is done
through the Networking Layer and the Service Layer creates
and manages services to satisfy user needs. The interaction
with the users and applications is done at the Interface Layer.
2 https://developers.google.com/maps/
 Due to the research field dynamism and the different project
requisites and goals, sometimes that architecture needs some
kind of adaptation. Thus, for this work we propose a three-
layer architecture as presented in the Figure 1 and which will
be discussed in the rest of this section.
Fig. 1. Three-layer architecture proposed.
A. Sensing Layer
Vehicle detection for parking space occupation is performed
by this layer. Different techniques are used for detecting
vehicle parking, especially vision-based and sensor-based tech-
niques [10]. The fundamental difference between them is the
scalability: while sensor-based solutions involves a sensor or
a set of sensors to each spot, a camera is used for monitoring
many spots on vision-based solutions. There is no perfect
solution to this problem and the choice of the detection method
depends on the project requisites and goals [13]. Sensor-based
solution are categorized as either intrusive or non-intrusive
[10].
Our solution works with a ultrasonic sensor at each parking
space, since this is a non-intrusive technique with simple
installation and low cost, as well as a consolidated method in
smart parking system solutions [10], [14], [15]. The ultrasonic
sensors transmit pulse waves between 25 to 50 kHz to the road
by detecting transmitted energies, which are reflected back to
the sensor [14]. The weakness of that approach is the sensor
sensitivity to temperature changes and extreme air turbulence.
The ultrasonic sensors placed in the parking spaces identify
if it is occupied or vacant by measuring the distance in relation
to the vehicle. If the measured distance is within the specified
range, then the controller will define the parking space as
occupied, otherwise it will be defined as vacant. Figure 2
illustrates the circuit operation, where the system will set only
the first parking space (Spot 1) as occupied as the only one
where a car is parked.
Each sensor is controlled by an ESP8266, a 32-bit SoC
(system on a chip) with a Wi-Fi module embedded. According
to the manufacturer, this chip is an energy-efficient solution
for IoT applications.
In addition to the Wi-Fi module, the chip also holds a
processor that allow it to connect with sensors and other
devices through input/output pins and can be programmed in
C++. There are several ESP modules, such as ESP-01 and
33
Fig. 2. Detection of changing in parking space status.
ESP-12 and the essential difference among those modules is
the number of input/output pins.
When a new parking spot is installed, it first communicates
with a web service in order to acquire an identifier name (ID).
Then, it only communicates with the context broker changing
the occupancy status in agreement with the sensor reading.
With regard to the power management, the ESP8266 chip
may consume about 170 mA, when it is performing in its
highest capacity, as provided in the device datasheet [16].
However, the device holds three power management modes:
modem-sleep, light-sleep and deep-sleep, which provides the
lowest power consumption among those. In that mode, Wi-Fi
and CPU are off and only the real-time clock (RTC), which
is responsible for resuming the chip usual operation, stays on,
consuming about 20 uA. This feature is very useful for projects
powered by batteries.
B. Processing and Storage
The intermediate layer holds the data processing and stor-
age, and context information.
Web services are software assembled over the Internet
that use standard protocols to perform functions or execute
business processes, thus allowing the exchange of data among
computers and devices [17]. For this reason, in this layer there
is a web service in order to communicate with the parking
spaces and the applications, functioning as a middleware for
processing and storing data from both layers above and below.
The web service implemented follows the REST architecture,
which has become the default for most Web and mobile
applications, and it is characterized by its performance and
scalability [18], [19]. The communication through the web
service is done by HTTP protocol, especially GET and POST
requests, and the payloads are based on JSON3 model.
NoSQL databases are vastly used in IoT applications [20]
[21]. When compared against relational databases, NoSQL
databases are more scalable, provide a better performance and
have a more flexible data model, addressing several weakness
of the relational model [22]. Therefore, a NoSQL database is
used for storing the parking system data.
When the web service receives the introduction message
from a new spot, it checks if that spot was already registered
by querying the geographical position, so it returns a new ID
3 http://www.json.org/
or the previous one. That is done in order to avoid multiple
registrations from a single spot. With that ID, the spot can
communicate to the context broker.
C. Context Broker
The intermediate layer also handle with context information,
given that implementing smart applications requires gathering
and managing context information, as was introduced previ-
ously. FIWARE is a middleware platform supported by the
Future Internet Public-Private Partnership (FI-PPP) project of
the European Union and has been vastly used on Europe
[23]. Moreover, FIWARE platform provides a rather simple
yet powerful set of APIs.
Orion Context Broker is a Generic Enabler4 from FI-
WARE platform that implements the NGSI (Next Generation
Service Interfaces) REST API, which is used to allow the
communication among the different Generic Enablers (GEs).
NGSI is defined based on context entities, which are virtual
representation of the several characters of the real world, such
as a bus, a table, a room or even a person. The context entities
are represented through context elements, which holds a set of
context element attributes. This last can hold a set of meta-
data.
Orion supports the management of the whole life cycle of
context information including updates, queries, registrations
and subscriptions. The context elements are registered and
managed through updates and queries. It is also possible to
subscribe to context information so when some condition
occurs, such as a change in a context element, Orion sends
a notification [24].
D. Applications Layer
The users have access to parking system information
through the Application Layer.
FIWARE has a class of GEs to applications/services and
data delivery, where WireCloud is well-known. WireCloud5
is a application mashup platform useful for creating web
applications that interacts with others FIWARE GEs, and
prototype or even produce final solutions. The following
description was entirely taken from the documentation [25],
which introduces that mashups in WireCloud are built in the
context of workspaces. A workspace consists of the set of
widgets and operators that can be mashed-up, even spanning
multiple tabs. Widgets and operators in a workspace can
share data though data flow or event-based mechanisms. Once
you have chosen the desired widgets, you can wire them to
enable their intercommunication and to achieve coordinated
behaviour. Widgets and operators in WireCloud, are capable
of sending and/or receiving events and data through well-
identified ports called endpoints. When you connect two
compatible endpoints, the second one (i.e. the input or target
endpoint) prepares to receive data flows and/or events coming
from the first one (i.e. the output or source endpoint).
4 https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/
Summary of FIWARE Open Specifications
5 https://wirecloud.readthedocs.io/en/stable/
34
One of the best ways to reach out the users is through
the smartphones, since this is more and more present in
people’s daily life6 . Moreover, although small they have great
processing power which before was only possible in desktops.
Therefore, it is currently possible to interact with the users
through a mobile application and dispose the parking system
data on it. This approach is more practical to the users than
using web applications. Thus, we developed an application
for helping drivers to get the parking information in real time.
This approach is cheaper and more effective for showing the
parking places and even guide the drivers to them.
IV. E XPERIMENTAL R ESULTS
In this section we discuss how the system proposed was
implemented and therefore present the results.
A. Experimental Setup
There is a circuit at each parking space that is responsible
for monitoring the vehicle entrance and exit from a spot. This
circuit is composed by an HC-SR04 ultrasonic ranging sensor7
and an ESP-12 chip, in accordance with the Figure 3.
Fig. 3. Circuit for managing a parking space.
The range distance measurement of the sensor vary from
2 cm to 4 m and the thresholds definition depends on the
dimensions of the parking spaces. For this experiment we have
set the ultrasonic sensor minimum threshold as 4 cm (given
that if some pin disconnects then it always reads 0 cm) and
the maximum threshold as 100 cm, being appropriated for our
tests. The sensors were positioned in front of the vehicles at
each parking spot.
The project intends to use the energy source available in
the parking lot, that is to say electric sockets will be used
for powering all the circuit. However, the hardware devices
operate with direct current flow (DC) and so it is needed a
device for converting alternating current (AC) into DC. Thus,
in this project is used an adapter power supply and a MB102
power supply module8 for supplying the proper voltage to
sensors and ESP8266.
The web service employed was implemented using Python
and some useful libraries. Pymongo9 was used in order to work
6 http://www.pewglobal.org/2016/02/22/smartphone-ownership-and-
internet-usage-continues-to-climb-in-emerging-economies/
7 http://www.micropik.com/PDF/HCSR04.pdf
8 http://www.petervis.com/Raspberry PI/Breadboard Power Supply/
YwRobot Breadboard Power Supply.html
9 https://api.mongodb.com/python/current/
with MongoDB database. Two web application frameworks
were also used: CherryPy10 and Flask11 . The main methods
supported are:
• /clearSpots: a GET request that removes all docu-
ments from the database collection of parking spots;
• /getSpots: a GET request that returns a JSON holding
the ID, type and geographical position (latitude and
longitude) of each parking spot registered;
• /createSpot: a POST request that receives a JSON
payload with the parking spot type and its geographical
position (latitude and longitude). After that, it stores the
new entry in the database and registers it on Orion. This
method returns an ID to the new spot.
The latitude and longitude attributes were took manually
and the sensors were deployed at each respective location.
The spots context information registered on Orion have the
same structure and an example is shown in Figure 4.
singular FIWARE instance which was deployed using Docker
Compose15 .
The user mobile application was developed to Android
devices using Java and a Google Maps API for presenting
the parking occupancy situation, where each marker represents
a parking space and the colors shows its status. A red one
represents an occupied spot, while a green one represents a
vacant spot without restrictions. A blue marker represents that
a disabled parking place is vacant. Moreover, the application
queries the context broker at each 3 seconds.
B. Results
The parking system information are presented as in Figure
5 and Figure 6. The first one is part of the mashup application
that runs on WireCloud, and the other is the main screen of
the mobile application which will be used by the drivers.

"contextElement" : {
"type" : "Spot",
"isPattern" : "false",
"id" : "Spot2",
"attributes" : [
{
"name" : "isOccupied",
"type" : "boolean",
"value" : "true"
},
{
"name" : "latitude",
"type" : "float",
"value" : "-5.832565"
},
{
"name" : "longitude",
"type" : "float",
"value" : "-35.205331"
}, Fig. 5. Widget running on WireCloud showing the parking occupancy
{ situation.
"name" : "type",
"type" : "string", The map is centered on our testing area (Metrópole Digital
"value" : "elderly" Institute) and the satellite image is given by Google Maps and
}
]
is not in real time. The map holds markers for each parking
} space that was configured and the marker color changes
dynamically in accordance to spot status changes. The color
scheme is as described previously.
Fig. 4. Orion context information about Spot 2. Thus, the driver can have real time access to the parking
lot information at any given moment. The driver has also a
The WireCloud mashup just holds one widget and two notion of spot location.
operators. An NGSI Source12 and a Spot To Pol (implemented
for this work) operators are used in order to access the context V. F INAL R EMARKS AND F UTURE W ORKS
broker and process valid data for showing visually through In this paper, we described the development of a smart
the widget. A Map Viewer13 is a widget used for showing the parking system able to gather quantitative information and
parking occupancy situation. provide it trough an extensible platform to drivers and other
The middleware layer which includes the processing and smart city applications. The solution was implemented with
storage components, and the context broker were deployed in ultrasonic sensors, a web service, using the FIWARE platform,
a private cloud created using OpenStack14 . We also have a and a mobile application to Android devices in which the
10 http://cherrypy.org/ drivers can have a feedback of the parking lot occupancy.
11 http://flask.pocoo.org/ Furthermore, the solution is based on the proposed three-layer
12 https://github.com/wirecloud-fiware/ngsi-source-operator architecture which is responsible for modularize the system
13 https://github.com/WireCloud/map-viewer-widget
14 https://www.openstack.org/ 15 https://docs.docker.com/compose/

35

Fig. 6. The mobile application main screen.
and achieve a low coupling, making it extensible and easy to
maintain.
Based on the results, we concluded that this approach is
appropriate for monitoring parking systems and exhibit the
parking lot situation at any given moment. Thus, it is the first
step to propose a comprehensive solution for smart cities.
As future works, we intend to incorporate cameras for
monitoring parking spaces, since it is an interesting scalable
solution and the architecture supports its insertion. We also
intend to acquire qualitative information by knowing which
driver is parked at each parking spot. This can be done through
RFID tags for each driver or by inserting QR codes at each
spot, which would be scanned by the mobile application that
should send both driver credentials and the spot identification
to the parking system.
R EFERENCES
[1] A. d. L. Carvalho, F. d. Ponce de Leon et al., “Grandes Desafios da
Pesquisa em Computação no Brasil–2006–2016,” São Paulo: Sociedade
Brasileira de Computação, 2006.
[2] J. M. Frye, “NSF Major Research Centers Programs,” https://www.nsf.
gov/od/oia/presentations/jf/HBCU-UP Talk.pdf, 2009, Last access in:
2017-04-29.
[3] R. B. de Araujo, “Computação ubı́qua: Princı́pios, tecnologias e de-
safios,” in XXI Simpósio Brasileiro de Redes de Computadores, vol. 8,
2003, pp. 11–13.
[4] G. D. Abowd, A. K. Dey, P. J. Brown, N. Davies, M. Smith, and
P. Steggles, “Towards a better understanding of context and context-
awareness,” in International Symposium on Handheld and Ubiquitous
Computing. Springer, 1999, pp. 304–307.
[5] C. Floerkemeier, M. Langheinrich, E. Fleisch, F. Mattern, and S. E.
Sarma, The Internet of Things: First International Conference, IOT 2008,
Zurich, Switzerland, March 26-28, 2008, Proceedings. Springer, 2008,
vol. 4952.
36
[6] D. Linthicum, “The cloud is the secret weapon in the Internet of
things,” http://www.infoworld.com/article/2608029/cloud-computing/
the-cloud-is-the-secret-weapon-in-the-internet-of-things.html, 2014,
Last access in: 2017-04-29.
[7] A. Pinho, “A dificuldade de parar o carro em São Paulo,” http://vejasp.
abril.com.br/cidades/deficit-de-vagas-para-estacionar-carros-sao-paulo/,
2013, Last access in: 2017-04-29.
[8] S. Srikanth, P. Pramod, K. Dileep, S. Tapas, M. U. Patil et al., “Design
and implementation of a prototype smart parking (SPARK) system using
wireless sensor networks,” in Advanced Information Networking and
Applications Workshops, 2009. WAINA’09. International Conference on.
IEEE, 2009, pp. 401–406.
[9] H. Wang and W. He, “A reservation-based smart parking system,” in
Computer Communications Workshops (INFOCOM WKSHPS), 2011
IEEE Conference on. IEEE, 2011, pp. 690–695.
[10] A. Kianpisheh, N. Mustaffa, P. Limtrairut, and P. Keikhosrokiani,
“Smart parking system (SPS) architecture using ultrasonic detector,”
International Journal of Software Engineering and Its Applications,
vol. 6, no. 3, pp. 55–58, 2012.
[11] A. Grazioli, M. Picone, F. Zanichelli, and M. Amoretti, “Collaborative
mobile application and advanced services for smart parking,” in Mobile
Data Management (MDM), 2013 IEEE 14th International Conference
on, vol. 2. IEEE, 2013, pp. 39–44.
[12] L. Da Xu, W. He, and S. Li, “Internet of things in industries: A survey,”
IEEE Transactions on industrial informatics, vol. 10, no. 4, pp. 2233–
2243, 2014.
[13] K. Yamada and M. Mizuno, “A vehicle parking detection method using
image segmentation,” Electronics and Communications in Japan (Part
III: Fundamental Electronic Science), vol. 84, no. 10, pp. 25–34, 2001.
[14] M. Idris, Y. Leng, E. Tamil, N. Noor, and Z. Razak, “Car park system:
A review of smart parking system and its technology,” Inf. Technol. J,
vol. 8, no. 2, pp. 101–113, 2009.
[15] G. Revathi and V. S. Dhulipala, “Smart parking systems and sensors:
A survey,” in Computing, Communication and Applications (ICCCA),
2012 International Conference on. IEEE, 2012, pp. 1–5.
[16] “ESP8266EX datasheet,” http://espressif.com/sites/default/files/
documentation/0a-esp8266ex datasheet en.pdf, 2017, Last access
in: 2017-05-18.
[17] D. Fensel and C. Bussler, “The web service modeling framework
WSMF,” Electronic Commerce Research and Applications, vol. 1, no. 2,
pp. 113–137, 2002.
[18] Wikipedia, “Representational state transfer,” https://en.wikipedia.org/
wiki/Representational state transfer, 2017, Last access in: 2017-05-06.
[19] M. Vaqqas, “Restful web services: A tutorial,” http://www.drdobbs.
com/web-development/restful-web-services-a-tutorial/240169069,
2014, Last access in: 2017-05-06.
[20] M. Asay, “Why you need NoSQL for the internet of things,” http://
readwrite.com/2014/11/28/internet-of-things-nosql-data/, 2014, Last ac-
cess in: 2017-05-04.
[21] E. Marchal, “Why nosql is the future of IoT,” https://thestack.com/iot/
2016/02/15/why-nosql-is-the-future-of-iot/, 2016, Last access in: 2017-
05-04.
[22] MongoDB, “Advantages of NoSQL,” https://www.mongodb.com/scale/
advantages-of-nosql, 2017, Last access in: 2017-05-04.
[23] “Fiware map,” http://map.fiware.org/actors/smes, 2017, Last access in:
2017-05-18.
[24] Orion, “Welcome to Orion context broker,” https://fiware-orion.
readthedocs.io/en/master/, 2017, Last access in: 2017-05-04.
[25] Wirecloud, “User guide,” http://wirecloud.readthedocs.io/en/latest/user
guide/, 2017, Last access in: 2017-05-04.