S.2.g Meter and Sensor Data Management Service

Servizio di gestione dei dati energetici degli edifici proposto nel Progetto Sunshine Meter and Sensor Data Management Service for Buildings proposed in the context of Project Sunshine LUCA GIOVANNINI1 – MARCO BERTI2 - MARCO ZUPPIROLI3,C PIERGIORGIO CIPRIANO1 – UMBERTO DI STASO2 1 Sinergis Srl - Trento, Italy 2 Fondazione Graphitech - Trento, Italy 3 Dipartimento di Architettura, Università degli Studi di Ferrara, Italy c Corresponding author: [email protected]

RIASSUNTO.

Nell'ambito dello sviluppo della piattaforma SUNSHINE (www.sunshineproject.eu), dedicata allo sviluppo di servizi informativi a supporto di una gestione energetica più efficiente di edifici e impianti di illuminazione, è stato sviluppato un servizio di Sensor Data Management che estende le comuni funzionalità di meter data management dei dati di lettura di consumi al management di dati che provengono più genericamente da sensori di diverso tipo. I pilot del progetto SUNSHINE forniscono in-fatti non solo i dati relativi al consumo energetico (elettricità, gas, teleriscaldamento, etc), ma anche altri tipi di dati (ad es. le condizioni meteo esterne agli edifici e la tempe-ratura interna) che pure necessitano di essere raccolti e gestiti.

Tutte queste diverse tipologie di dati sono memorizzate nello stesso database e ge-stite attraverso procedure comuni e seguendo protocolli di comunicazione standard che saranno descritti in questo articolo.

SUMMARY.

During the development of SUNSHINE’s platform (www.sunshineproject.eu), aimed at developing information services to support a more energy-efficient manage-ment of buildings and light lines, a Sensor Data Management Service has been imple-mented extending the simple management of smart metering data to the management of data coming more generally from heterogeneous sensors. The reason being that SUN-SHINE’s pilots are providing not just consumption data (electricity, gas heating, district heating, etc), but also other types of data (e.g. weather or indoor temperature) that also need to be collected and managed.

http://www.sunshineproject.eu/

Servizio di gestione dei dati energetici degli edifici proposto nel Progetto Sunshine

All these data types are stored in the same database and managed with common procedures and conforming to standard communication protocols which will be de-scribed in this paper.

Parole chiave: edifici, efficienza energetica, dati di consumo, sensori, impianti HVAC.

Key words: buildings, energy efficiency, meter data, sensor data, HVAC systems

1. INTRODUCTION

SUNSHINE project (Smart UrbaN ServIces for Higher eNergy Efficiency, www.sunshineproject.eu) aims at delivering innovative digital services, interoperable with existing geographic web-service infrastructures, supporting improved energy effi-ciency measures at the urban and building level. SUNSHINE services are delivered from both a web-based client and a dedicated app for smartphones and tablets. The project is structured into three main scenarios: • Building Energy Performance Assessment: Automatic large-scale assessment of

building energy behavior based on data available from public repositories (e.g. cadas-ter, planning data etc.) to create Energy Maps.

• Building Energy Consumption Optimization: Optimization of energy consumption of heating systems supported by access to real-time consumption data measured by smart-meters and to localized weather forecasts.

• Public Lighting Energy Management: Interoperable control of public illumination systems based on remote access to lighting network.

This paper focuses on part of the results of the second of the three scenarios

(Building Energy Consumption Optimization). The aim of the Sensor Data Management service in the scope of this scenario is that of empowering building energy managers with the necessary knowledge about the energy behaviour of the buildings they are mon-itoring, such as collecting and providing highly detailed past consumption profiles, visu-alizing correlations between consumption and observed weather variables (outside tem-perature, solar irradiation, wind speed) and visualizing detailed weather forecasts for 3 days in advance.

In SUNSHINE project, the scope of Sensor Data Management Service has been extended from the management of meter data to the management of data coming more generally from sensors. More specifically, the Meter Data Management service manages: • Consumption data from energy meters in pilot buildings; • Indoor temperature readings from indoor sensors in pilot buildings; • Weather observation and forecasts data from a dedicated weather service from Mete-

ogrid;

All these data types are ingested via different data flows into the same Sensor DB, where they are managed and made available to further processing and visualization via common protocols and procedures, which will be described in this paper.

2. COMPONENTS

In brief, the purpose of the Sensor Data Management Service is to: • Gather all the data coming from meters/sensors (section 2.1); • Elaborate them and generate derived data, if necessary (section 2.2); • Store them in a normalized format into a repository (section 2.3) from which they can

be retrieved through a standard interface (section 2.4).

For consumption data from meters two data flows are supported by the platform, in order to enable both the pilots with low IT capacities and those who are able to develop software components: • Simple FTP (File Transfer Protocol) transfer of CSV (Comma Separated Values)

files (section 2.1.1); • Feed from Green Button standard protocol (Web link 2015a) web service (section

2.1.2). The flow of indoor temperature readings is channelled through the Green Button

web service (section 2.1.2) as all the pilots actually providing such data flow have im-plemented the needed infrastructure.

The flow of weather data (section 2.1.3) is established via a scheduling procedure that is planned to pull data daily from a dedicated Web Feature Service standard web protocol (ISO1942, 2010) set up by project partner Meteogrid (Web link 2015b).

2.1 Input Data Flows

2.1.1 Consumption data ingestion (FTP) It’s a scheduled program that checks if any CSV file to be loaded into the database

is arrived on the dedicated FTP folders. The files are removed from the folders and passed to the CSV loader component that does the real job of inserting data in the DB. Detailed guidelines have been prepared describing how to format name and content of CSV files in order to allow the automatic ingestion procedure to take place smoothly.

2.1.2 Consumption data ingestion (GreenButton) Green Button is an initiative of the U.S. Government that aims to allow consumers

to access their own meter data about energy consumption. In the original context, the name Green Button denotes the whole initiative, but in our project we will refer to GB specifically as the international data exchange standard for consumption data (Web link 2015a) and the suite of web services that makes the data access possible. GreenButton protocol and API were identified as the best option as they are already implemented and operational in a real use case scenario. Moreover, the standard includes a security and authentication module based on OAuth protocol (Web link 2015d).

2.1.3 Weather data ingestion Weather data are served by two Web Feature Services (WFS) standard protocol,

defined by the Open Geospatial Consortium (Web link 2010), and set up by project part-


ner Meteogrid (Web link 2015b) from a dedicated platform. The ingestion process que-ries the WFS services, collects the data for each meteorological quantity (temperature, irradiation, wind speed), and loads it into the Sensor DB. Two WFS services are availa-ble: • WFS forecast: a three-day forecast with hourly resolution for each pilot’s location. • WFS observation: measured or interpolated weather conditions with hourly resolu-

tion for each pilot’s location.

2.2 Data Elaboration and Aggregation Some elaborations are needed before the real data ingestion. For instance, some

aggregations are pre-calculated in order to avoid this task to the client. Another kind of processing is the interpolation for those readings that have been collected at irregular in-tervals of time (some kinds of data flows have this characteristic).

This module is specific to the consumption data from sensor reading and its role is that of guaranteeing a uniform format for its storage and therefore a cleaner server/client interaction. Stored consumption data has the following format: • Consumption is relative to the last reading interval; • Readings have a regular frequency; • Available frequencies are: every 15 minutes, hourly and daily.

These constraints do not apply to consumption data coming from billing documen-

tation that are stored in the DB as is.

2.3 Data Storage in Sensor DB It is the final repository of all sensor data. The database implementation chosen is

the one developed by the German research centre 52North (Web link 2015g), imple-menting the international Sensor Observation Service (SOS, Web link 2015f) standard, defined by the Open Geospatial Consortium (OGC); this open source database is imple-mented as a PostgreSQL DB and also makes use of the spatial extension PostGIS, and it has been installed and configured on SUNSHINE’s platform for the purpose of collect-ing and storing data from energy meters as well as outdoor/indoor conditions.

Database structure

The main constructs of the DB schema are the following: • Feature of Interest (FOI): represents the geo-object who is measured by sensors.

The FOI is the means of locating (geocoding) the measuring points via their coordi-nates;

• Observable Property: identifies the property observed by the sensor (e.g. gas con-sumption, temperature or lamp dimming level);

• Procedure: identifies a physical /virtual sensor which produces the observations associated with the offerings;

• Offering: a logical grouping of observations that are related to each other, which are jointly offered by a service.

2.3.1 CSV loader This component accesses the DB for inserting the readings in the proper tables. Be-

fore doing that, if it has been configured to do so, the files are pre-processed by the “Da-ta Elaboration” component. Readings are inserted in the DB using SOS insertion API, insertObservation.

2.3.2 Sensor data access The last module, in logical order, is the sensor data access. Access to sensor data is

guaranteed by two services: • Web feature service (see Figure 1): to publish the identifiers of the different sensors

and data flows via the linking with their geographical position. • Sensor observation service APIs, to access to actual measurements.

Figure 1 – Sensor locations (blue dots) and identifiers (attributes in the table) exposed via a Web Feature Service.

2.4 Data Visualization from client

2.4.1 Consumption Visualization tool The SUNSHINE web portal allows monitoring on the various components of the

pilot buildings. By clicking on the red dots, the dashboard related to building dynamic data will appear. Figure 2 shows an example of building dashboard for the city of Ferra-ra. Information offered by the dashboard refers to (see Figure 3): • Thermal Energy Consumption KWh • Gaseous Fuel Consumption m3 • Electrical Energy Consumption KWh

2.4.2 Weather Station visualization and forecast tool Within this functionality, the user will be able to query weather stations, in order to

visualize data coming from the selected weather station related to the past, but also have a localized weather forecast for the next three days.


Figure 2- Portion of public buildings in Ferrara pilot Weather information, both forecast and past observations, are referring to:

• Temperature in °C • Irradiance in W/m2 • Wind Speed in m/s • Figure 4 shows how weather information is displayed in the weather station dashboard.

Figure 3 - Dashboard for a public building in Ferrara

3. APPLICATIONS

The Sensor Data Management infrastructure is currently under testing in several selected pilot buildings within the project partners locations (Ferrara, Bassano, Rovereto, Trentino, IT; Zagreb, HR; Paola, MT; Lamia, GR). This section describes some of the outcomes of the data analysis performed on two pilot buildings in Ferrara, both served by district heating: • Scuole Elementari Poledrelli • Museo di Storia Naturale

3.1 Daily consumption profiles Daily consumption profiles plot four quantities (see Figure 5 for a sample):

• measured consumption (red line) • measured external temperature (blue line) • required periods of comfort (unshaded surfaces) • deduced heating system turn on time

From Figure 5 about Scuole Poledrelli we can infer some interesting observation,

such as the fact that the heating system is usually off (but not always) in the weekend and that, consequently, heating turn on is anticipated on Mondays and Tuesdays.

Figure 4 - Example of weather data and forecast for a Weather Station As general remarks: • Temperature profile sometimes is unrealistic or incomplete • As expected consumption trends are inversely proportional to external temperature,

with a delay due to thermal inertia.


• Scuole Poledrelli has a higher consumption, but comparison should be done after normalization with heated surface.

Figure 5 – Sample of daily consumption profiles for Scuole Elementari Poledrelli (Ferrara, IT)

3.2 Seasonal consumption profiles Seasonal profiles show the series of daily consumption in comparison with daily

average outside temperatures.

Analysis of the seasonal profile for Scuole Poledrelli (Figure 6) brings forward the following remarks: • A weekly pattern is clearly visible, with the consumption peaks on Mondays and

Tuesdays; • This kind of plot triggers the question, is turning turn off the heating system during

weekends more efficient than just living it on? The question can be evaluated by measuring and comparing the surface of the "Monday peaks" with that of the "week-end valleys";

• The comparison of consumption and temperature curves show an inverse proportion on the long term trends;

• The possible effect of thermal inertia is visible in the progressive smoothing of the "Monday peak" from one week to the following.

Figure 6 – Seasonal profile for Scuole Elementari Poledrelli (Ferrara, IT)

Figure 7 - Seasonal profile for Museo Storia Naturale (Ferrara, IT) Analysis of the seasonal profile for Museo di Storia Naturale (Figure 7) brings

forward the following remarks:


• The initial peak is not a real feature, consumption scale is different with respect with Scuole Poledrelli;

• A clear weekly pattern is absent, even if a week-scale signal seems to be present, es-pecially on the left part of the curve;

• A comparison of consumption and temperature curves show an inverse proportion on the long term trends.

CONCLUSIONS

The paper presented the Sensor Data Management service that has been imple-mented in the context of project Sunshine. The service manages the inbound flow of very different types of dynamical data, guarantees the storage of all of them in a single DB structure - the Sensor DB based on OGC SOS protocol - and their publication via a single interoperable SOS service. The potential use of such data management service in the context of building energy management has been presented by showing the type of energy consumption analysis performed on long high-frequency data series provided by the Sensor Data Management service for two of the project’s pilot buildings in Ferrara, IT.

REFERENCES

Fenger, J. 1999. Urban air quality. Atmospheric environment, 33.29: 4877-4900 ISO 19142. 2010. Geographic information – Web Feature Service. International Organi-

zation for standardization Web link 2015a. Energy.gov Green Button protocol, http://energy.gov/data/green-button Web link 2015b. Meteogrid, http://www.meteogrid.com/ Web link 2015c. Green Button ESPI Evolution, http://www.sgip.org/PAP-20-Green-

Button-ESPI-Evolution Web link 2015d. OAuth protocol, http://oauth.net/ Web link 2015e. Progetto "Sunshine" in Bassano del Grappa http://www.reverberi.it/it/application/progetto-sunshine-bassano-del-grappa-vi Web link 2015f. OGC’s Sensor Observation Service,

http://www.opengeospatial.org/standards/sos Web link 2015g. 52° North’s Sensor Web,

http://52north.org/communities/sensorweb/sos/index.html

AKNOWLEDGEMENTS

Project SUNSHINE has received funding from the EC, as part of the Competitive-ness and innovation Framework Programme. The authors are solely responsible of this work, which does not represent the opinion of the EC. The EC is not responsible for any use that might be made of information contained in this paper.

S.2.g Meter and Sensor Data Management Service

Technology

Transcript of S.2.g Meter and Sensor Data Management Service