See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/304489186

IoT platform for Smart Cities: Requirements and implementation case studies

Conference Paper · September 2016

DOI: 10.1109/RTSI.2016.7740618

CITATIONS READS

33 3,062

2 authors:

Edoardo Patti Andrea Acquaviva

Politecnico di Torino Politecnico di Torino
93 PUBLICATIONS   959 CITATIONS    226 PUBLICATIONS   2,971 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

FLEXMETER - Flexible Smart Metering for Multiple Energy Vectors with Active Prosumers View project

Power management for WSNs View project

All content following this page was uploaded by Edoardo Patti on 31 October 2018.

The user has requested enhancement of the downloaded file.

 Politecnico di Torino

Porto Institutional Repository

[Proceeding] IoT platform for Smart Cities: requirements and implementation

case studies

Original Citation:
Patti, Edoardo; Acquaviva, Andrea IoT platform for Smart Cities: requirements and implementation
case studies. In: 2nd IEEE International Forum on Research and Technologies for Society and
Industry Leveraging a better tomorrow (RTSI 2016), Bologna, Italy, 7-9 September 2016.
(In Press)
Availability:
This version is available at : http://porto.polito.it/2650739/ since: September 2016
Publisher:
IEEE
Terms of use:
This article is made available under terms and conditions applicable to Open Access Policy Article
("Public - All rights reserved") , as described at http://porto.polito.it/terms_and_conditions.
html
Porto, the institutional repository of the Politecnico di Torino, is provided by the University Library
and the IT-Services. The aim is to enable open access to all the world. Please share with us how
this access benefits you. Your story matters.

(Article begins on next page)

 IoT platform for Smart Cities: requirements and
implementation case studies

Edoardo Patti and Andrea Acquaviva

Dept. of Control and Computer Engineering, Politecnico di Torino, Italy
{edoardo.patti, andrea.acquaviva}@polito.it

Abstract—Internet-of-Things (IoT) is considered as the key iii) to provide a uniform interface to all deployed technologies.
player to move forward the Smart City vision. Indeed, pervasive
devices can enable a fain-grained monitoring of buildings and In this paper, we present our experience in developing two
energy distribution networks. Thus, such information can be distributed IoT platforms for energy management in Smart
used to enhance energy optimization in our cities. However, City. Such IoT platforms aim at providing a variety of appli-
interoperability among heterogeneous devices is a challenging cations involving different stakeholders to increase the energy
task. Furthermore, all these IoT devices produce a huge amount efficiency of a city and foster new services. These platforms
of data that must be collected and post-processed, thus entering have been deployed in a real-world scenario and the city of
into the Big Data domain. Therefore, a distributed IoT platform Turin (Italy) has been selected as case study.
for energy management has to be designed for i) enabling
the interoperability among heterogeneous IoT devices and ii) The rest of this paper is organized as follows. Section II
handling such huge amount of data. In this paper, we describe reviews relevant background literature. Section III describes
the requirements to be addressed in order to develop an IoT the requirements a distributed IoT platform has to address. Sec-
platform for Smart City. We also present two distributed IoT tion IV introduces two IoT platforms for energy management
platforms we developed to improve the energy management in in Smart City contexts and provides a comparison between
Smart City. Finally, based on our experience in a real-world case them. Based on our experience in a real-world case study,
study, we provide an estimation of the amount of energy-related Section V presents an estimation of the amount of energy-
information our presented platforms have to manage. related information an IoT platform has to manage. Finally,
Keywords—Smart City; Internet-of-Things; Software Architec- Section VI discusses the concluding remarks.
ture; Distributed Infrastructure; Big Data

I. I NTRODUCTION II. R ELATED W ORK

In order to move forward the Smart City vision, ICT (Infor- In Smart City and Smart Grid scenarios, different software
mation and Communications Technology) and IoT (Internet- solutions have been proposed in literature to increase the
of-Things) are recognized as key players [1] to enhance energy energy management of our cities through pervasive monitor-
optimization in cities [2]. Therefore, real-time information ing. These solutions provide also innovative services to end-
about environmental characteristics and energy consumption users. Kim et al. [7] presented a data-centric middleware for
can be accessed from pervasive and heterogeneous IoT devices Smart Grid. It allows decentralized monitoring and control
deployed in buildings and across energy distribution networks. exploiting a publish/subscribe model [8] that is appropriate for
In this scenario, one of the main challenges imposed by delivering information but, in our view, is not yet sufficient
IoT consists on enabling the interoperability across hetero- to retrieve data without having to wait for new events. For
geneous devices to build software infrastructure for cross- this purpose, such software architectures should implement
domain applications. This issue can be overcome thanks to both publish/subscribe and request/response communication
middleware technologies that enable the interoperability across paradigms.
heterogeneous data-sources, either hardware or software, by In our previous work, we presented a distributed soft-
providing an abstract view of their functionalities. Further- ware infrastructure for general purpose services in power sys-
more, considerable effort has been devoted to standardizing tems [9]. The software architecture enables the interoperability
the communication among IoT devices [3], [4], as well as ser- across heterogeneous devices to manage a Smart Grid by cre-
vice interoperability layers and frameworks [5], [6]. However, ating a secure peer-to-per network. Further following this view,
building large-scale IoT platforms capable of integrating and we proposed an architecture for integrating different data-
adopting new standards remains challenging. sources to enhance the energy efficiency in heating distribution
Once the interoperability is enabled, the energy-related networks at district level [10]. It also provides tools for big
information from heterogeneous devices can be collected data analysis to evaluate building energy consumptions [11]
and correlated into a common ”smart digital archive” for and increase the energy awareness [12].
energy management of Smart Cities. In general, IoT tech- The ReActOR system [13], is a middleware characterized
nologies enable fine-grained monitoring of our cities, also in by a tiny footprint and can be deployed as a service. It
(near-)real-time. Therefore, an IoT platform for Smart City consists of three layers: i) the Facade Layer that provides
has to be prepared in receiving and managing huge amount of Web Service, ii) the Core Layer, and iii) the Extensions Layer
information, thus entering into the Big Data domain. Hence, that gives support for different technologies. It enforces user
they have i) to be highly available, ii) to scale up rapidly and authorization by mapping each user to set of devices to be
managed. However, this middleware is limited to hardware systems and technologies. For this reason, middleware is a
devices and it does not support the integration of other different valuable software instruments to enable the interoperability
data-sources. across heterogeneous devices and to abstract their function-
SemsorGrid4Env [14] is a service-oriented architecture alities.
to design open large-scale semantic-based sensor network An IoT platform has to implement features for real-
applications for environmental management. It enables rapid time data collection from large number of different sensors
development of thin applications and allows the integration to provide actual information about events or behaviours in
of both realtime and historical data from heterogeneous data- the Smart City. Consequently, storage systems should scale
sources. This solution is tailored to environmental management horizontally to better address the data storing and access.
and cannot be applied seamlessly to a city. (Near-)Real-time data transmission is an important require-
Different research projects and initiatives contributed to ment that implies an asynchronous communication. This can
define models and guidelines to foster interoperability between be implemented by exploiting publish/subscribe approach [8],
various application domains. The IoT-A project [6] provides an which is complementary to request/response. Publish/subscribe
IoT reference model to allow the description of an IoT solution communication paradigm removes the interdependencies be-
by using shared building blocks. It also provides a reference ar- tween producer and consumer of information. This paradigm
chitecture and general advices to IoT architects. The OneM2M fosters to develop distributed services that are independent
alliance [5] aims at developing detailed technical specifications from data-sources and can react in real-time to certain events.
for a common M2M Service Layer using existing IoT and Web Recent practices in building distributed applications and
standards. However, it does not cover many aspects of IoT plat- infrastructure promote a microservice approach. This is an
forms, such as scalability, availability and deployment. Finally, emerging designing pattern that can be defined as an approach
the FIWARE [15] research project aims at designing a service to develop a single application as a suite of small services,
infrastructure for the Future Internet vision. Such infrastructure each running in its own process and communicating with
is composed by reusable components that can be selected and lightweight mechanisms [16]. These services are small, highly
complemented with additional specific components. decoupled and focus on doing a small task [17]. Hence, an
With respect to literature solutions, we present two IoT IoT platform should be designed following the microservice
software infrastructures for energy monitoring and manage- patterns to increase its flexibility and maintainability.
ment in Smart City: i) DIMMER and ii) FLEXMETER. An IoT platform needs to expose Web Services and API to
DIMMER aims at enabling the interoperability across dif- access information, either raw or post-processed, exploiting
ferent devices, either wireless or wired, to access and share open and standard data-formats. This is needed to foster
heterogeneous information about energy distribution systems, the design and development of novel services. In this view,
buildings and apartments in the district. Such information is REST architectural principles promotes easy-to-use interfaces
also correlated to parametric virtual models of buildings and that are loose coupled of individual (low level) components.
energy distribution systems with the purpose of providing This is the foundation of modern distributed Web applications.
a smart digital archive of the city. Make available these Hence, REST coupled with the microservice approach helps
data is useful to characterize the energy consumption profiles in developing software infrastructure easy to manage and easy
from the single building up to the whole district or city in to use for developing distributed applications.
order to design more efficient control policies. FLEXMETER
is a multi-service and multi-utility architecture that aims at Finally in a Smart City view, providing awareness to end-
facilitating the access of multiple actors to relevant energy users is a milestone. Indeed, user-friendly applications to inter-
related data to foster various innovative services. As DIMMER, act with the pervasive IoT devices needs to be developed. For
it enables the communication across different devices in a this reason, an IoT software infrastructure must be designed to
Smart Grid scenario. In addition, FLEXMETER offers a cloud- facilitate this interaction between users and things. In addition,
based infrastructure to collect, analyse and provide energy user feedbacks and actions could also be collected and used
information from various smart meters of different utilities to build social behaviour models to foresee user attitudes for
such as electricity, water, heating and gas. providing customizable user-centric services.

III. R EQUIREMENTS OF I OT PLATFORM FOR S MART C ITY IV. I OT PLATFORMS FOR S MART C ITIES
In order to address energy management in Smart Cities, In this section, we present two distributed IoT software
a distributed IoT platform has to be scalable due to the huge infrastructures for Smart Cities that have been developed fol-
amount of data it will receive and manage. In addition, such lowing the requirements described in Section III: i) DIMMER
data are heterogeneous, so it needs to be flexible for collecting and ii) FLEXMETER.
a huge amount of miscellaneous data. This means that an
IoT platform will face Big Data domain challenges. On this A. DIMMER platform
premises, we identified the following main requirements to be DIMMER (namely District Information Modelling and
addressed in order to design and develop distributed software Management for Energy Reduction) is a distributed IoT soft-
architecture for IoT in Smart City contexts. ware infrastructure to collect and correlate heterogeneous
Interoperability among heterogeneous devices is a key energy-related data into a distributed smart digital archive for
requirement in order to enable communication and data trans- district management. It aims at providing tools to reduce both
mission of IoT devices. Indeed, the resulting software infras- energy consumption and CO2 emissions by enabling more
tructure needs to integrate in the same environment different efficient energy policies that account for real characteristics
 District Services Layer is composed of different
middleware-based components providing services at district
level. The Service Catalog provides an index of all the avail-
able services in the DIMMER platform. The Resource Catalog
exposes to applications the list of the available IoT devices
and resources. Hence, when a new middleware-enabled service
is available, this needs to register itself to Service Catalog.
Similarly, when a new IoT device is available, the Device
Connector (that integrates it in the platform) has to register it
to Resource Catalog. Thanks to these two Catalog modules, the
infrastructure is able to automatically manage all the integrated
services and IoT devices and expose them to other application.
Message Broker provides an asynchronous communication
through MQTT [3], which is a communication protocol for
publish/subscribe [8] to send data in (near-)real-time. In ad-
dition, this approach increases the scalability of the whole
Fig. 1. DIMMER platform schema infrastructure [9]. The Data Storage is in charge of collecting
data sent by IoT devices deployed in district. The DIMMER
platform has been designed also to integrate already existing
of the district and its buildings. Therefore, DIMMER exploits databases regardless of their technology and owned by other
a microservice approach to build a virtual district information actors or stakeholders. This allows the platform in integrating
model by providing the following features: a set of different databases that can work together and trans-
parently export stored information through Web Services. In
• enable the communication among heterogeneous IoT addition, the Data Storage is able to collect and provide other
devices and technologies; kind of information not strictly related to IoT devices, such as
• collect (near-)real-time data coming from IoT devices end-users feedbacks or energy distribution schedule settings.
deployed in buildings and along distribution networks The Semantic Metastore provides a semantic description of the
(e.g. heating and electrical networks) in the district; entities in the district enriched with additional attributes and
• correlate and post-process such data among them; relations to other entities exploiting semantic web technologies
(i.e. ontologies) [19]. The Simulation Engine provides features
• correlate energy-related information with BIM (Build- to simulate energy optimization policies exploiting information
ing Information Modelling) 3D parametric models, from other DIMMER components. Therefore, novel control
GIS (Geographic information system) and SIM (Sys- policies at building and district level can be simulated to eval-
tem information Model); uate their impacts using historical and real-time data correlated
• simulate innovative energy control strategies, for both with BIM and SIM models.
electrical and heating systems, taking into account also Application Layer provides users with set of tools and API
renewable sources. Such simulation can also exploits to manage, post-process and visualize data coming from the
real data and BIM models as input; lower layers. To increase user-awareness, this layer provides a
• visualize district-level energy usage and structural web portal and mobile applications to address the needs and
parameters of buildings and systems. requirements of different stakeholders. Information are also
shown exploiting both Virtual and Augmented Reality.
In addition, DIMMER aims at promoting the sharing of data
among different actors and stakeholders playing in Smart City B. FLEXMETER platform
scenarios.
FLEXMETER is a flexible smart metering architecture
As shown in Figure 1, DIMMER is a three-layered dis- for smart cities. It is a distributed IoT platform that collects
tributed infrastructure that provides both request/response and and integrates heterogeneous information from multiple energy
publish/subscribe communication paradigms. It is built on top vectors (e.g. electricity, water, gas and heating) to foster
of LinkSmart middleware [18], which provides features for innovative services to end-users. In this view, the platform is
integrating heterogeneous IoT devices. DIMMER consists of: in charge of: i) integrating different devices; ii) correlating
i) Data-source Integration Layer; ii) District Services Layer; data from smart meters of different utilities; iii) providing
iii) Application Layer. advanced services to end-users (i.e. consumers, prosumers
The Data-source Integration Layer integrates heteroge- and Distribution System Operators); iv) enhancing the retail
neous hardware and software technologies into the platform market. It aims at enabling:
through the Device Connector and the Services Provider • real-time readings management;
respectively. The Device Connector integrates a certain IoT
device by abstracting its functionalities into Web Services • real-time accounting activities management;
regardless of its low-level technology. In addition, it can work • real-time information to customers through a suitable
also as publisher and/or subscriber for all the IoT devices it interface structure;
manages. The Service Provider integrates different software
data-sources (i.e. BIM, GIS and SIM) by providing Web • detection energy thefts;
Services to access the information. • near-real-time grid level and user level fault detection
 aggregated data acquired by a single point of measurement
(i.e. smart meter). To visualize such information, this layer
provides GUI (Graphical User Interface) via a web portal and
mobile applications that increase user awareness about energy
consumption.

C. Comparison between DIMMER and FLEXMETER plat-

forms
In this section, we compare the two presented IoT software
infrastructures for Smart Cities. As shown in Table I, both
DIMMER and FLEXMETER are in charge of receiving and
managing a huge amount of data coming from IoT devices
deployed in building and energy distribution systems across
the city. Hence, data storage and management is a key is-
sue. DIMMER has to manage and correlate heterogeneous
data also regarding structural parameters of buildings (BIM),
distribution network (SIM) and georeferenced information
(GIS). For this purpose, we designed the platform to manage
different databases and export data through web services. In
this view, each stakeholder playing in a Smart City scenario
Fig. 2. FLEXMETER platform schema
can share its information by including its databases into the
DIMMER network. In addition, DIMMER exploits semantic
web technologies to provide semantic description of entities
in the city (e.g. devices, building and systems) and to better
allowing optimal alarming and first intervention sys- correlate information between them about BIM, GIS, SIM
tems to be adopted; and measured data [19]. On the contrary, FLEXMETER is in
• demand response together with optimal integration of charge of managing various time-series data from IoT devices
distributed generation and storage systems. (i.e. smart meters) about electricity, heating, water and gas.
Hence, the platform includes a single point databases manager
FLEXMETER has been designed following the microser- to store data in time-series and/or NO-SQL databases (e.g.
vice patterns. As shown in Figure 2, it is a four-layered MongoDB or InfluxDB) that provides scalability features for
distributed architecture that exploits, as DIMMER platform, Big Data analysis and management.
both request/response and publish/subscribe communication
paradigms. It consists of: i) IoT Devices Layer; ii) Middleware As shown in Table I, both platforms has been developed
Layer; iii) Business Layer; iv) Services Layer. Its core has been following a microservice approach [16] to increase flexibility
developed starting from SiteWhere platform [20], which has and maintainability by developing small services focused on
been extended to address FLEXMETER objectives. SiteWhere doing small tasks [17]. DIMMER extends the LinkSmart mid-
is a multi-tenant and multi-protocol open platform for Internet- dleware and creates a network of distributed software running
of-Things. on different servers and/or computers across the city. Vice-
versa, FLEXMETER has been designed as a single instance
The IoT Devices Layer consists of IoT devices (i.e. het- that can optionally run in a cluster of servers allowing multi-
erogeneus smart meters) integrated into the platform that send tenancy. A tenant refers to a group of customers with shared
data via the Message Broker exploiting the MQTT protocol [3]. common access and privileges to software instance. Multi-
The Middleware Layer is based on SiteWhere and pro- tenancy software infrastructure is a single instance of software
vides features to manage devices, collects information in that serves various tenants by providing to each tenant a
scalable NoSQL or time-series databases (e.g. MongoDB or dedicated share of the same software instance. FLEXMETER
InfluxDB respectively) and access them through REST API. multi-tenancy also allows separate data storage and processing
Among the management of devices, this layer also provides pipelines.
features to self register new devices and expose its resources Finally, DIMMER and FLEXMETER exploit both
to applications. request/response and publish/subscribe communication
The Business Layer post-processes data by aggregating paradigms and provide third-party actors with REST API to
(per minute, hour, week, month) and storing them in time- foster new services.
series. In addition, it manages users by authenticating them
and associating their profiles to energy-related information. V. E STIMATION OF ENERGY INFORMATION FOR THE
Finally, the Services Layer exposes modules to address T URIN CASE STUDY
energy flows management and user awareness. Indeed, the As mentioned in Section IV, both DIMMER and
algorithms running in this layer are devoted to demand- FLEXMETER platforms has been designed to receive a huge
response and fault detection that may occur across the en- amount of data from several IoT devices deployed in a urban
tire energy distribution network. It implements also Non- city context. Both platforms are deployed in Turin (Italy) to
Intrusive Appliance Load Monitoring (NIALM) [21] services perform tests in a real-world environment. DIMMER platform
to disaggregate energy consumption of appliances from the is fully operating, while FLEXMETER is still under deploy-
 TABLE I. C OMPARISON BETWEEN DIMMER AND FLEXMETER PLATFORMS
Data-sources Software Architecture features Communication Paradigms
Platform Measurementes Semantic web Built-in API for
BIM SIM GIS Microservice Multi-tenant Distributed Request/Response Publish/Subscribe
from IoT devices technologies simulation engine third-party actors
DIMMER X X X X X X X X X X X
FLEXMETER X X X X X X

TABLE II. A MOUNT OF SAMPLED DATA PER DAY IN T URIN

Utility number of samples sampling time number of smart meter bytes per day DIMMER FLEXMETER
50 5 min
Heating 5.6 k 5 GB X X
50 1h
Water 5 1h 300 k 2.3 GB X
Gas 10 24 h 300 k 0.2 GB X
10 15 min 31 GB X
Electricity 500 k
10 1s 27 TB X

ment. In this Section, we present the amount of information (in VI. C ONCLUSIONS
terms of Gigabytes per day) both platform have to manage for In this paper, we discussed the main requirements a
a city like Turin that counts around 890 thousand inhabitants. distributed IoT platform for Smart City has to address. We
Both platforms are designed to receives heating and electrical also presented DIMMER and FLEXMETER, which are two
data sent by IoT devices deployed in buildings and distribu- IoT platform developed to provide services regarding multi-
tion networks. FLEXMETER manages also information about energy flows. We also discussed the impact, in terms of
water and gas distribution networks. gigabytes/terabytes, a massive deployment of IoT devices in
As shown in Table II, in Turin the heating network serves a city like Turin can have and consequently the amount of
around 5.6 thousand buildings. Each building is equipped with energy-related information the presented platforms have to
IoT devices that send 50 samples every 5 minutes to monitor handle.
the energetic parameters and other 50 samples every hour
to monitor distribution network parameters. Based on already ACKNOWLEDGEMENTS
collected data, every day both IoT platforms have to receive
and store around 5 Gigabytes of information. The research is funded by EU FP7 DIMMER project under
grant agreement No. 609084 and EU H2020 FLEXMETER
Regarding the water distribution network, in Turin there are project under grant agreement No. 646568.
around 300 thousand meters. In our case studies, we adopted
smart meters that send 5 samples every hour. Considering to
deploy these new meters in the whole city, the FLEXMETER R EFERENCES
platform have to manage 2.3 Gigabytes of data per day. [1] J. Jin, J. Gubbi, S. Marusic, and M. Palaniswami, “An information
framework for creating a smart city through internet of things,” IEEE
Similarly to water distribution network, the gas distribution Internet of Things Journal, vol. 1, no. 2, pp. 112–121, April 2014.
network in Turin includes about 300 thousand meters. In [2] A. Zanella, N. Bui, A. Castellani, L. Vangelista, and M. Zorzi, “Internet
FLEXMETER, we are integrating new smart meters that send of things for smart cities,” IEEE Internet of Things Journal, vol. 1, no. 1,
10 samples every day. Thus, replacing the old meters with pp. 22–32, Feb 2014.
the new means that the FLEXMETER platform handles 0.2 [3] “Message Queue Telemetry Transport (MQTT),” Available:
http://mqtt.org/.
Gigabytes per day.
[4] Z. Shelby, K. Hartke, and C. Bormann., “The Constrained Application
Finally, we need to distinguish two different cases for the Protocol (CoAP),” 2014, Available: http://coap.technology/.
electrical energy consumption. Indeed, depending on services [5] “OneM2M Alliance,” Available: http://onem2m.org.
to provide, the sampling time can change. In DIMMER, [6] A. Nettstraeter, “Architectural reference model for IoT,” EC FP7 IoT-A
we correlate electricity data to BIM (Building Information (257521) D, 2012.
Modelling) and SIM (System Information Models) to de- [7] Y.-J. Kim, M. Thottan, V. Kolesnikov, and W. Lee, “A secure decen-
velop new control strategies for demand-response and perform tralized data-centric information infrastructure for smart grid,” IEEE
simulations. In this case, a sampling time in the range of Communications Magazine, Nov. 2010.
10 or 15 minutes is enough. In Turin there are about 500 [8] P. T. Eugster, P. A. Felber, R. Guerraoui, and A.-M. Kermarrec, “The
many faces of publish/subscribe,” ACM CSUR, June 2003.
thousand meters, replacing them with novel smart meters that
send 10 samples every 15 minutes, 31 Gigabyte per day have [9] E. Patti, A. L. A. Syrri, M. Jahn, P. Mancarella, A. Acquaviva,
and E. Macii, “Distributed software infrastructure for general purpose
to be stored in the DIMMER platform. On the other hand, services in smart grid,” IEEE Transactions on Smart Grid, vol. 7, no. 2,
FLEXMETER aims at providing also services about fast fault pp. 1156–1163, March 2016.
detection and NIALM. In this second scenario, a sample rate [10] E. Patti, A. Acquaviva, A. Sciacovelli, V. Verda, D. Martellacci,
of 1 second is needed. Thus in Turin, 500 thousand meters, F. Castagnetti, and E. Macii, “Towards a software infrastructure for
sending 10 samples per second, produce about 27 Terabytes of district energy management,” in 12th IEEE EUC, 2014, pp. 215–220.
information par day to be managed by FLEXMETER platform. [11] A. Acquaviva, D. Apiletti, A. Attanasio, E. Baralis, L. Bottaccioli, F. B.
Castagnetti, T. Cerquitelli, S. Chiusano, E. Macii, D. Martellacci, and
In conclusion, in urban energy contexts next Smart Cities E. Patti, “Energy signature analysis: Knowledge at your fingertips,” in
have to be equipped with scalable and distributed IoT plat- 2015 IEEE International Congress on Big Data, June 2015, pp. 543–
forms. Indeed, depending on the services to provide, the 550.
amount of managed information will be in the order of [12] A. Acquaviva, D. Apiletti, A. Attanasio, E. Baralis, F. Boni Castagnetti,
Gigabytes or Terabytes per day. T. Cerquitelli, S. Chiusano, E. Macii, D. Martellacci, and E. Patti,
“Enhancing energy awareness through the analysis of thermal energy
 consumption,” in The 4th workshop on Energy Data Management,
March 2015, pp. 64–71.
[13] D. T. Neves, M. Santos, and M. Pinto, “Reactor: A middleware as
a service to interact with objects remotely,” in Industrial Technology
(ICIT), 2015 IEEE International Conference on, March 2015, pp. 2433–
2439.
[14] “SemsorGrid4Env,” Available: http://www.semsorgrid4env.eu/.
[15] “FI-WARE,” Available: https://www.fiware.org/.
[16] M. Fowler and J. Lewis, “Microservices,” 2014, Available:
http://martinfowler.com/articles/microservices.html.
[17] S. Newman, Building Microservices. O’Reilly Media, Inc., 2015.
[18] “LinkSmart,” Available: https://linksmart.eu/redmine.
[19] P. Brizzi, D. Bonino, A. Musetti, E. Patti, and M. Axling, “Towards
an ontology driven approach for systems interoperability and energy
management in the smart city,” in International Multidisciplinary Con-
ference on Computer and Energy Science (splitech2016), July 2016.
[20] “SiteWhere,” Available: http://www.sitewhere.org/.
[21] A. Zoha, A. Gluhak, M. A. Imran, and S. Rajasegarar, “Non-intrusive
load monitoring approaches for disaggregated energy sensing: A sur-
vey,” in Sensors, 2012.

View publication stats