SUNSHINE Project: meter and sensor data management service

1. 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 GIOVANNINI
1
– MARCO BERTI
2
- MARCO ZUPPIROLI
3,C
PIERGIORGIO CIPRIANO
1
– UMBERTO DI STASO
2
1
Sinergis Srl - Trento, Italy
2
Fondazione Graphitech - Trento, Italy
3
Dipartimento di Architettura, Università degli Studi di Ferrara, Italy
c
Corresponding author: marco.zuppiroli@unife.it
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.

2. 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.

3. 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.1Consumption 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.2Consumption 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.3Weather 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-

4. Servizio di gestione dei dati energetici degli edifici proposto nel Progetto Sunshine
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.

5. 2.3.1CSV 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.2Sensor 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.1Consumption 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.2Weather 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.

6. Servizio di gestione dei dati energetici degli edifici proposto nel Progetto Sunshine
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

7. 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.

8. Servizio di gestione dei dati energetici degli edifici proposto nel Progetto Sunshine
• 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.

9. 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:

10. Servizio di gestione dei dati energetici degli edifici proposto nel Progetto Sunshine
• 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.