A scalable middleware-based infrastructure for energy management and visualization in city districts

Following the Smart City views, citizens, policy makers and energy distribution companies need a reliable and scalable infrastructure to manage and analyse energy consumption data in a city district context. In order to move forward this view, a city district model is needed, which takes into account di ﬀ erent data-sources such as Building Information Models, Geographic Information Systems and real-time information coming from heterogeneous devices in the district. The Internet of Things paradigm is creating new business opportunities for low-cost, low-power and high-performance devices. Nevertheless, because of the "smart devices" heterogeneity, in order to provide uniform access to their functionalities, an abstract point of view is needed. Therefore, we propose an distributed software infrastructure, exploiting service-oriented middleware and ontology solutions to cope with the management, simulation and visualization of district energy data.


Introduction
Recently, several efforts have been oriented towards the optimization of energy Demand Response (DR), for both thermal [1] and electrical [2] systems.In this context, Wolisz et al. [3] proposed to integrate building models and geographic information systems to simulate performances of buildings in a city district.In addition, a large amount of sensor and actuator devices, used to monitor and manage the energy grid consumption, has to be taken into account to improve the accuracy of the district model in simulating and monitoring the energy DR.Following this view, we present DIMCloud (District Information Model Cloud), a distributed software infrastructure for the energy audit of an urban district, which can be extremely useful for multiple purposes, e.g.: • the design and location of new buildings in the district area; • the refurbishment of existing and historical buildings; • the planning of renewable power plants installations, such as photovoltaic systems; • the monitoring of energy consumption and production, globally or locally -down to the single room of a specific building in the district; • the simulation of control policies and energy flows in the energy distribution networks; • the increase of user awareness through data visualization, in order to promote green behaviours.
In such scenario, several technologies are involved: • Building Information Models (BIMs) [4] are frequently used to share knowledge about a facility, in order to support decisions during its whole lifecycle; they represents buildings using 3D parametric models, enriched with semantic information -such as materials and cost [5]; • System Information Models (SIMs) can be defined as 3D parametric models (such as BIMs) built to outline structure, size and capacity of energy distribution networks; they are useful to simulate the energy flows in networks; • Geographic Information Systems (GISs) [6] are used to map the geographical location of technologies deployed in the district; for instance they can be used to draw topology and geographic location of energy distribution networks, which supply power or heating to a specific area of the district; GISs provide data automation and compilation, management, analysis and modelling of advanced cartography [7]; • heterogeneous smart devices are increasingly deployed in district areas, such as smart plugs, smart clampers and environmental sensor boards; they are used to monitor energy consumption, production and environment variables such as air temperature and relative humidity; • historical databases are exploited to store data received from the deployed smart devices, for consequent analyses on them.
The heterogeneous composition of a district model impedes the direct integration of its different components.Indeed, it is often the case that two different technologies are unable to communicate, due to diverse data formats, protocols, standards and/or locations.
Further, it is necessary to design a model which is able to satisfy the following constraints: (i) each underlying technology (hardware or software) must be abstracted in a transparent way from the user's point-of-view; (ii) data retrieved from the model must be transparently integrated to Linked Data; (iii) data exchange must exploit open shared standards; (iv) one single open data format must be used, defined as independent from the data source; (v) the system must be able to acquire or release components without needing to restart the whole infrastructure.
To overcome the current lack of interoperability on the proposed scenario we devised a novel distributed infrastructure.This infrastructure is able to interconnect and integrate heterogeneous technologies and to deliver district information by means of Web Services.Moreover, thanks to this distributed infrastructure, it is possible to correlate IoT data with several different information systems (BIMs, GISs, SIMs), and to enable data post-processing in order to provide district data to several district management applications.This article is organized as follows: Section 2 explores the different motivations to design and develop such district model.Section 3 outlines the current state-ofart.Section 4 introduces our infrastructure.Section 6 proposes a generic use case for the presented infrastructure.Finally, Section 8 presents conclusions and future directions.

Motivations
Within the Smart Cities scenario, multiple actors need to tightly cooperate to exploit business opportunities and to promote technological products.The proposed infrastructure is needed (i) to provide interoperability between the heterogeneous devices deployed in the district and (ii) to create new business services which operate on multiple data sources.
Citizens, policy makers and energy distribution companies need to analyze energy data of the district for the purpose of decision support.Data must be available using a suitable infrastructure, collected by means of pervasive low-cost sensors, and used to plan and actuate control policies using pervasive low-cost actuators.It is necessary also to use reliable and lowpower networks to manage data collection.This boils down to defining a self-configurating infrastructure, which provides a significant decision autonomy and minimize installation costs.
By introducing the proposed IoT infrastructure, it would be possible to monitor and manage in (near-)real-time the energy consumption around the city district.This would be instrumental both from the energy sustainability and from the energy cost saving perspectives.

Background
Interoperability issues, which currently affect information management and exchange in IoT, have been debated recently.
In particular, middleware and Web Services technologies have been presented as a key factor to promote low-cost integration of heterogeneous devices, in the Internet-of-Energy and Smart Grid concepts [8].In this case, energy monitoring infrastructure are composed by embedded devices (with capabilities of communication, sensing and actuation) which cooperate and organize in a modular way.These devices are abstracted and interconnected using a middleware solution.They are able to react to incoming requests from the network (grid) and to change of status of grid variables (such as changes in energy price).Web Services are exploited to hide devices heterogeneity using a standard interface, and to allow dynamic change of devices capabilities.Further, a publish-subscribe approach [9] is used between devices, in order to avoid unnecessary network utilization.
The importance of Web Services for devices abstraction has been highlighted also in [10], which introduces a specific middleware (aWESoME) that builds an abstraction layer for heterogeneous devices (for instance, Wireless Sensor and Actuator Networks).Then, by using Web Services, it allows the discovery and the access to them in a transparent manner.Another work [11], presents a modular open infrastructure based on a Service Oriented Architecture.In fact, such architecture provides a uniform and flexible interface for constantly evolving devices, in the context of Evolvable Production Systems.The middleware SEEMPubS [12], exploited in this work as well, provides an hardware abstraction layer to enable interoperability across heterogeneous devices.In addition it exploits an event-driven and user-centric approach to develop control strategies and applications for smart energy efficient public spaces.Another middleware, ReActOR, is deployed as a lightweight service and provides user authorization.[13] It consists of three subsystems: an interface layer (Web Service), a core layer, and an interoperability layer (to support different technologies).However, this system is not able to integrate different data sources, such as district information systems.The authors of [14] present a distributed software infrastructure for general purpose services in power systems.The interoperability across heterogeneous devices is achieved by creating a secure peer-to-peer network.SemsorGrid4Env [15] is a service-oriented architecture designed for applications in management of the environment.It eases the development of thin applications and integrates real-time data with historical data.
Further, different research projects define the guidelines of interoperability across different domains.For instance, FI-WARE [16] has a vision for the Future Internet, composed by reusable components.In addition, the IoT-A project [17] allows the definition of IoT solutions using a reference architecture and shared building entities.Differently, the OneM2M alliance [18] addresses the definition of a common M2M service layer, by exploiting Web and IoT technologies.
For what concerns the integration of heterogeneous data, related to BIM/GIS applications interoperability, several recent works propose different approaches.In [19], the authors exploit partial sub-models taken from a BIM model and translate them to the geo-spatial context into ESRI Geodatabase or Shapefiles.The USIM concept [20], an Indoor GIS Building Information Model for context-aware [21] applications, achieves interoperability by using the IFC standard.In [22,23], where the integration of GIS and BIM models is used to optimize the installation of tower cranes and to provide a Supply Chain Management system for construction, the information exchange is achieved by means of relational databases (e.g., Microsoft Access).
Regarding the use of a district information model for energy data management, a recent work [3] proposes a novel concept (City District Information Model -CDIM) for the purpose of simulation of energy consumption in a city district.This model shows that a district energy simulation framework would be beneficial to increase the efficiency of energy distribution networks.This model achieves interoperability using object-relational databases.
The novel contribution of this work is a distributed software infrastructure which exposes, using Web standards, a virtual district model.This model can be queried by different applications designed for district monitoring and management.Thanks to this infrastructure, heterogeneous IoT devices can be accessed using a standard interface.Moreover, historical and (near-) real-time data can be integrated and correlated with information models of buildings, energy distribution networks and geographical areas.This infrastructure is then exploited as an open shared repository of information for the district.

A distributed system in a Pervasive Computing scenario
In a Smart City context, following the Internet-of-Things and Ubiquitous Computing views, we designed a distributed software infrastructure to ease the visualization and simulation of energy consumption at district level.DIMCloud (District Information Model Cloud) integrates heterogeneous data-sources, both hardware and software, exploiting the SEEMPubS middleware [12].As shown in Figure 1, DIMCloud links the district energy consumption data with semantic and geographic information, such as the building in which the data has been collected.DIMCloud abstracts the different data-sources thanks to a set of specific Integration Proxies that translate the low level technology into Web Services.We identified two typologies of Integration Proxy: Device-Proxy for abstracting hardware technologies (see Section 4.2) and Database-Proxy for abstracting heterogeneous information collected with different database technologies (see Section 4.3).
The requests are dispatched to the correct Integration Proxy by the Ontology Manager, as shown in Figure 1.The references between different data-sources are modelled by means of an ontology and are exploited by the Ontology Manager during the integration of different data (for instance, to integrate the data of a building with its geographical location and sensors measurements).
The Integration Layer is in charge to integrate heterogeneous technologies.It exploits the concept of Integration Proxy to enable the interoperability across heterogeneous data-sources by abstracting a certain technology to Web Services, either hardware (see Section 4.2) or software (see Section 4.3).Hence, the Integration Layer acts as a bridge between the middleware network and the underlying technology, translating whatever kind of language the low-level technology speaks into Web Services.
The Services Layer provides developers with a set of components that expose their functionalities as Web Services.This layer is the core of SEEMPubS and it is designed for developing Smart Environment applications.In the following we introduce its main components: • The Network Manager establishes a peer-to-peer (P2P) network allowing direct communication between all the other entities and applications into the middleware network.Web Service calls are routed through the Network Manager that creates a SOAP (Simple Object Access Protocol) tunnel to the requested service endpoint [26] regardless whether they are behind a firewall or NAT (Network Address Translation); • The Event Manager provides an event-based communication based on publish/subscribe service [9] for SEEMPubS Web Services.This allows the development of loosely-coupled event-based systems and increases the scalability; •  • The Context and Ontology Frameworks together manage semantic knowledge about the application domain and the implemented systems.This includes metadata about sensors and actuators and also their relation to domain model objects such as appliances, buildings and rooms.Finally, they provide developers with Web Services to query any kind of information from a rich domain model (for instance, the location or capabilities of a sensor, a list of all sensors in a building or an actuator with a certain control capability); • The Rule Framework provides standard interfaces for implementing event-driven control strategies to manage smart energy efficient environments.
Finally, in the proposed architecture the higher layer is the Application Layer.It provides a set of tools, API and Web Services for developing distributed middleware-based applications to use the integrated systems and to post-process data coming from the lower layers.

Integrating heterogeneous devices
In order to integrate heterogeneous devices into DIM-Cloud and to enable their interoperability, different Integration Proxies were developed (one for each considered technology).Such Integration Proxy, also called Device-Proxy, abstracts the underlying heterogeneous technologies translating their functionalities into Web Services.Its main features are: • enabling the integration of heterogeneous devices and interfacing them to the whole proposed infrastructure by means of Web Services, through which access sensor data; • collecting environmental data coming from sensor nodes into a local database, which can be accessed asynchronously; • pushing environmental information into DIM-Cloud exploiting an event-based approach provided by Event Manager; • allowing the remote control of actuator devices.
Therefore, the Device-Proxy, as shown in Figure 3, communicates directly with the heterogeneous devices or device networks.It is a software consisting of three layers: i) Technology Interface Layer (OSI 3), ii) Database Layer and iii) SEEMPubS Web Services Layer (OSI 6).
The Technology Interface Layer directly receives all the incoming data from the devices, regardless of communication protocols, hardware or network topology.Each technology needs a specific Technology Interface to interpret incoming information and to store them into the integrated Database that represents the second layer of the Device-Proxy.Since data are locally collected, the Database Layer makes to whole infrastructure reliable with respect to backbone network failures.The SEEMPubS Web Services Layer exposes the underlying technology's functionalities as Web Services.It enables the interoperability between heterogeneous devices and eases their remote management and control.Finally, from this layer environmental data are sent in realtime to other applications, such as the Measurements Database, which collects data coming from the district's devices.Such information is sent exploiting the publish/subscribe approach provided by the Event Manager (see Section 4.1).meanings depending on the database.For these reasons, the strategy which involves integrating all the different databases into a single one is not viable.

Providing uniform access to data sources
Therefore, we decided to create an Integration Proxy for each database (in this case called Database-Proxy), which provides a Web Services interface to data.In this way, the system is both modular and scalable, because each database which needs to be connected can be integrated and maintaned into the system with minimum effort.I.e., each database must be provided with its Database-Proxy.

Describing the district structure using ontologies
A district model built with a high level of detail can be very complex.For instance, depending on the size of a city district, there can be tens of buildings and hundreds, or even thousands, different deployed devices.For reason, it is necessary to use a suitable structure describe accurately the relationships between the different entities of the district.
Therefore we devised the use of an ontology, to provide a semantic description of the model, which is presented in Figure 4.This district ontology is composed by three levels of nodes: • the root node (e.g.D1 in Figure ) defines the district and its global properties (for instance, the URI of its GIS Database-Proxy, the name of the district, etc.); • the intermediate nodes (e.g.B1, S1 in Figure ) represent the buildings and/or the energy distribution networks inside the district area; they also hold the URIs of the BIMs and/or SIMs Database-Proxies Web Services, and additional attributes, such as the IDs of the buildings and/or the energy distribution networks in the GIS associated with the district area; • the leaf nodes (e.g.DEVx in Figure ) define the heterogeneous devices deployed in the district; each leaf node is connected with the intermediate node (building or energy distribution network) in which it is placed; further, additional attributes, such as the ID of the device in the measurements databases, can be stored inside the corresponding node.
The ontology is structured as a tree: the leaf nodes (devices) are connected with their intermediate node (building or energy distribution network), which is itself connected to the root node.Therefore, from the root node of the district, it is possible to reach every data source belonging to the district.
The ontology manager receives a REST HTTP query from a client and, by exploiting parametrized SPARQL

Data modelling and exchange
In order to export the models behind the Databaseproxies, it was necessary to use Autodesk Revit for the development of the BIM model and ESRI ArcGIS 10 for the development of the GIS model.The two models can describe the same objects, but at different scale.BIM consists of building a 3D parametric model that contains information about the different features of construction elements, such as measures, materials, costs, physical data, manufacturer or any other data that the designer considers important for the project in addition to geometric data [5].Geographic information systems (GIS) include a wide set of tools to process geographic information.This collection of tools is used to operate information, such as datasets, attribute fields, and cartographic elements for printed maps.Geoprocessing is used in all phases of a GIS for data automation, compilation, and management, analysis and modelling of advanced cartography [7].American Institute of Architects (AIA), the Level of Detail is essentially how much detail is included in the model element.Differently, Level of Development is the degree of reliability of information stored in the model.Hereafter, we will use LOD as Level of Development.We developed the models using LOD 100 for the GIS model and LOD 100/LOD 300 for the BIM model.
AIA reports the definitions of the types of the chosen LOD in [27] • LOD 100: The Model Element be graphically represented in the Model with a symbol or other generic representation, but does not satisfy the requirements for LOD 200.Information related to the Model Element (i.e., cost per square foot, tonnage of HVAC, etc.) can be derived from other Model Elements; • LOD 300: The Model Element is graphically represented within the Model as a specific system, object or assembly in of quantity, size, shape, location, orientation.Non-graphic information may also be attached to the Model Element.
After choosing the appropriate LODs we started the modeling phase on both Revit and ArcGIS.In Revit, we developed the model of the building with Local Masses at LOD 100, and then we improved it using LOD 300.Afterwards, we enriched the BIM model with semantic information and we oriented the building and the context models appropriately.Using Shared parameters we customized the model in order to equip it with additional informations.
Working on ArcGIS, we defined the geographic coordinates' system (in this case study we used the WGS84 ellipsoid) and we made shapefiles (.shp) of buildings and addresses.Shapefiles are used to store non-topological geometries and attribute information [28], such as construction typology or data, and were developed to describe the GIS model.
Finally, to share data between the different applications, we tested several formats to avoid errors and data losses.To develop the interoperable process between Revit and ArcGIS we considered Industry Foundation Classes (IFC) [29], Open DataBase Connectivity (ODBC), City Geography Markup Language (CityGML) [30], .rvt,.fbx,.accdb,.mdb,.shp.We decided to export BIM and GIS models by means of relational databases [31].

Platform deployment in a real world case study
We deployed the proposed software infrastructure as a prototype in a real district in Turin (Italy).Around 50% of private and public buildings in this district is served by the heating network.This network is monitored using a large number of sensor devices, deployed in each heat-exchanger.Each sensor collects different measurements (water flow, temperature, etc.) every 5 minutes.By means of an embedded gateway located in each heat-exchanger these measurements are sent via GPRS to a remote data-storage unit.
The platform also features GIS, SIM and BIM integration proxy services, in order to provide district data from these information systems of the district.The SIM services provide the models of the heating distribution network.A geo-referenced model of the district area is accessed via the GIS services.Further, six buildings have been modelled by means of the BIM methodology.These buildings represent different typologies of building, depending on dimension, use, construction period, materials and orientation.By exploiting GIS, SIM, and BIM services, it is possible to gather data regarding the district in several different formats: e.g.IFC, JSON or GBXML.
Finally, we deployed wireless sensor networks to monitor indoor air temperature and relative humidity in six representative buildings for the district.

Use cases for district monitoring applications
During the gathering and post-processing of district data, there are three different types of involved entities: • the client application, which carries out the data request to the system; • the Ontology Manager of the system, which manages the whole system; • the different Integration Proxies of different entities interested by the query (buildings, energy distribution networks, geographical areas, smart devices and historical databases).
Figure 8 can be considered the most generic use case, from which it is possible to create more complex interactions.It is composed mainly by two flows, which must be executed exactly in the following order: i) the client application sends a request to the Ontology Manager, regarding the interested district area description; ii) the client application sends data requests to the different Integration Proxies of the interested district area.It is important to underline that, in the second flow, the data requests to the different Integration Proxies can be executed in a different order, or interleaved.
In the first flow (steps 1, 2), the client application queries the Ontology Manager regarding a specific district area modelled by the system.The Ontology Manager refers to the district ontology and returns to the client application the requested information.In particular, the returned information can be: • the Integration Proxies URIs of the Geographic Information Systems interested by the query; • the Integration Proxies URIs of the Building Information Models (for buildings) and of the System Information Models (for energy distribution networks); • the buildings, energy distribution networks and smart devices IDs in the interested district area; • the Integration Proxies URIs of the historical databases that holds the sensor measurements for the interested district area; • other attributes of the interested district area.
Subsequently (steps 3-SSm), once the client application receives all the URIs of the involved Integration Proxies, it sends data requests to each one of them.Then, it post-processes the with other context attributes.For instance, it can label the data of a specific building with the building label in the Geographic Information System.
Finally, since responses have been already translated to a standard open format by their own Integration Proxy, and post-processed by the client application, they are assembled into a single one response to the original data query.
The proposed generic use case is a typical flow of information through the infrastructure, which is exploited by two different applications: • the Benchmarking tool (Figure 6) uses the infrastructure to compare different buildings' energy behaviour.The user of this application defines the parameters used to filter buildings that should go in the benchmark analysis (such as building typology, building use, etc.).Due to privacy concerns, each building is represented by a virtual building which summarize the features of all the similar buildings under review.The benchmarking tool retrieves data from the Integration Proxies of the BIMs, GISs and SIMs.Interested end-user for this tool are building managers, households and energy distributors; • the WebGIS Dashboard (Figure 7) is a web application which integrates different layers of information.This application makes use of 2D and 3D maps to show heating and electricity consumption around the district, both to provide monitoring of sensor networks and advanced data analysis through the integration of different kind of data.It is a multi-tier application which retrieves data from the Integration Proxies of the BIMs, GISs and SIMs.Proposed end-user for this dashboard are building managers, households, energy distributors, energy managers and public administrators.

Conclusions
A district-based simulation can be beneficial to optimize energy consumption, with respect to simulations based on BIM.In this work, we introduced a different approach to model the district, in which different datasources, both hardware and software, are involved.In our infrastructure, each data-source, through a specific Integration Proxy, becomes part of the distributed software infrastructure that is based on SEEMPubS middleware.Furthermore, the underlying hardware functionalities are translated into Web Services providing an abstract view of the devices.This eases the development of distributed application to monitor and manage realtime energy consumption at district level.We believe that the proposed software infrastructure is crucial to manage district energy data in order to increase awareness and sustainability of energy consumption in smart district scenarios.

Acknowledgement
The research is funded by EU, FP7 SMARTCITIES 2013 District Information Modelling and Management for Energy Reduction (http://dimmer.polito.it).

Figure 1 .Figure 2 .
Figure 1.DIMCloud software infrastructure The Trust and Crypto Managers together make the communication secure between two entities in the middleware network.The Trust Manager enables mutual authentication between actors by 4 EAI Endorsed Transactions on Cloud Systems 12 2016 -06 2017 | Volume 3 | Issue 9 | e1

Figure 3 .
Figure 3. Device-Proxy schema Within the proposed system, a considerable part of data sources is composed by databases.For instance, Building Information Models (BIMs) and System Information Models (SIMs) can be exported to relational databases.However, the technologies used by the multiple DataBase Management Systems (DBMSs) are heterogeneous and mostly incompatible one with each other.Further, between two different databases it is possible to have conflicting values, i.e., values which have different 5 EAI Endorsed Transactions on Cloud Systems 12 2016 -06 2017 | Volume 3 | Issue 9 | e1

Figure 4 .Figure 5 .
Figure 4. Ontology schema First, we addressed the choice of the Level of Development and the Level of Detail.Referring to the 6 EAI Endorsed Transactions on Cloud Systems 12 2016 -06 2017 | Volume 3 | Issue 9 | e1