Review Meeting – December 16, 2014 Task 2.2 Weather Forecasting Data Capturing Module

Functionalities Final Goal To provide the DSS with a reliable and standardized set of data regarding weather forecast evolution. Expected output to predict indoor quality to figure out expected energy demands to outline the expected energy production useful hints elaborated by the DSS for: the optimal use of the systems for heating, ventilation and air conditioning, depending on the season; the likely shape of the consumption profiles; the likely profiles of production of the systems using renewable sources; possible indication of malfunctioning of some devices. Data input external weather forecasting service transducers of weather parameters (i.e.: anemometers, natural radiation sensors, thermometers, humidity sensors, etc.) locally installed, where available. Side-effect The two types of input (forecasts + meters) help verify their consistency

Functionalities Forecast Timings Data provided once per day on a CSV file containing the forecast of the needed parameters for a fixed period and with a fixed time step the module receives the input file at 8.00 am every morning with the forecast for one week with one-hour pace. The module will interpolate data in order to provide a forecast with data every 15 minutes over the forecast time span. Output Once per day a complete 7-day forecast A set of triplets (forecast – measurement – difference) for every event of measurement that might occur The streams of information are consistent with the overall architecture defined for the capturing modules: the format of data is RDF; the communication protocol is HTTP; the server receiving the streams is Ztreamy.

Functionalities Example of CSV Output DateTime Temp (°C) Humidity (%) wind speed (m/s) wind direction (deg) pressure (mbar) solar radiation (w/m^2) weather_ condition (integer) cloud cover (%) rainfall (mm) snowfall (cm) realability (%) 21/10/201400:0019,43973, /10/201401:0019,55983, /10/201402:0019,60983,

Functionalities Data type et alia The tested module works with a CSV file transmitted over FTP. Service Provider to be engaged. Final transmission mode ( , ftp client, etc.), as well as file type (text, xml, binary, etc.) and data format depend on the service provider. Measures The module can collect and record data synchronously with the forecasts (same time step and same reference time) and compare the two series, recording the differences. Default procedure In case of missing input data (interruption of the forecast service, the failure of a meter or of its data transmission system) the module will send an error notification and use the latest available data set for the missing input the latest complete forecast for prevision data (forecasts), the data measured in the latest available day at the at the same time for (measures). In case of delayed delivery of the input file containing the forecast, a second output data set will be re-submitted by the module to the DSS to allow the use of the correct data instead of the default procedure.

Validation Savona Campus has a meteorological web service feeding the Distributed Energy Management System (DEMS) managing its Smart Polygeneration Microgrid. The Campus receives a daily weather forecast via ftp, and a script provides the DEMS with the data; it finally uses an internal module to assess the production of the PV system starting from the weather forecast. In OPTIMUS, the file daily used by the Campus is used as a template of the file that will be required for feeding the weather data capturing module. The same template is used for the input file of field measured data. The system was tested, successfully, managing to transfer the incoming forecast to the local server used for the test of the several modules.